On Wed, Feb 06, 2008 at 02:26:01PM -0500, Rich Felker wrote:
On Wed, Feb 06, 2008 at 08:02:10PM +0100, Michael Niedermayer wrote:
The point is that this does NOT apply to the "mpeg design" with transmit_ts as the 11 extra seconds are transmitted during the 1000 low bitrate frames before.
This means that:
A. During these 1000 low bitrate frames, each frame was actually transmitted well-before its decode/presentation time, so you have a lot of latency.
No the transmitter has access to the whole transmission unless its a realtime transmission. It really is a 0 vs. 11 second difference for the receier after you switch it on/or tune to the channel at the start. [...]
Anyway, transmit_ts is not necessary to do what you've described. It works perfectly well in my design, modulo the above points which apply either way. However due to the above, especially C, I consider this very bad broadcast system design. [...]
B. requires 11 seconds instead of 0 seconds initial preload in the example (and iam still not sure if clocks could really be synchronized in all cases)
Claiming 0 is simply false. See above.
No its not false, the receiver has a 0 second INITIAL preload requirement. At frame 1000 it has a 11 second preload requirementt. And the average should be around 5.5 seconds. Thats half of your suggestion. You can change all the numbers by a scalar of your choice, it remains your design needs 2x the latency on average.
And for both A and B the demuxer does not know what preload it needs to use it has to guess. And thus it will have to guess higher to be sure its large enough -> more preload and thus latency and buffering than what mpeg would need.
I told you, you're totally welcome to add an info packet with preload amount and other bitrate/buffer requirement information. Now if you want to ask whether this info packet is available right away when the receiver starts listening to the broadcast, well that's another issue entirely. You see, all the main/stream headers are needed, but they won't be available until the next time they're repeated if the broadcast is purely unidirectional. As long as you have this issue, it's ridiculous to try to tune NUT for broadcast usage. One certainly could repeat the headers once per preload-interval if desired, of course, or obtain them from some out-of-band source, but the latter would be way outside the scope of NUT...
The main/stream headers are just needed once, if i switch channels around, i already have them after a few minutes for all channels. And wont want to wait for them ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus