[NUT-devel] Broadcasting nuts [PATCH]

[Michael Niedermayer]

On Tue, Feb 05, 2008 at 11:55:37PM -0500, Rich Felker wrote:
> On Tue, Feb 05, 2008 at 09:31:14PM +0100, Michael Niedermayer wrote:
> > Hi
> > 
> > Attached patch should make broadcast of single program nuts possible.
> 
> It's already possible. The claim that any of these things are needed
> is a fallacy.
[...]
> > +transmit_ts (t)
> > +    The timestamp at which the first bit of the syncpoint is transmitted.
> > +    MUST be less than or equal to all following dts.
> > +    See broadcast buffering model.
> 
> Waste of space and does not do anything useful.
> 
> > +
> > +Broadcast buffering model:
> > +--------------------------
> > +Nut files can be broadcast. Such specific nut files must be encoded and
> 
> There are not different types of NUT files. NUT is device-independent
> and the muxing MUST NOT DIFFER depending on the intended use. This is
> fundamental.

And they dont, now please return to technical discussion! Nothing will be
added to nut if you can proof that its unneeded. But you should listen to
what others say as well. And i do think nut as it is has a serious problem
with being broadcasted.

And the only broadcast specific thing are the transmit_ts, and the spec
explicitly says that a demuxer in non broadcast mode must ignore them. So
your claim of device dependance for an existing use case is not correct.


> 
> > +muxed so as to not exceed the decoder side buffering or available bandwidth.
> 
> This can be achieved purely with codec bitrate constraints.

No, not at all.


> 
> > +The time at which a syncpoint is transmitted as well as received is stored in
> > +the transmit_ts of it. The receiver/demuxer/decoder can use these timestamps
> > +to synchronize its clock. The (possibly variable) rate at which the following
> 
> Unnecessary. Any timestamp works equally well for synchronizing the
> clock as long as the receiver has an approximately accurate local
> clock source and measures corrections over long periods.

No, again not even slightly correct, and even with infinite buffers.

Let me try to give some examples to show the problems.
First we have a single file with a single (video) stream. This stream is
variable bitrate.
The very first constraint here is that the bits from the start until
time t of the movie must never exceed the channel bandwidth*( t + preload ).
Preload here is decided by the demuxer currently. This is true no matter how
large the decoder buffers are. As the decoder cannot decode what it hasnt
received yet.

Thats the first unavoidable device dependance


Now lets take a slightly more complex case, where instead of starting
playback from the very start at time 0. We start from time s. This changes
the max bits of the area between s and t to
channel bandwidth*( (t-s) + preload )

The question now is how much does the demuxer do preload. Having transmit_ts
would awnser that (dts - transmit_ts). Without that the demuxer has to guess.
If it guesses too large the user has to wait longer after seeking and at the
start. And that can be quite long, forget <1sec seek times. If it guesses too
short the video and audio will freeze as the demuxer runs out of data at some
point in the future.

Now in the above theres still one critical detail ive ignored. That the
streaming generally is done at a real time scale. That is the 1h movie
is not streamed at the max channel bitrate in 35min but with variing bitrate
over 1h. This is even more true for realtime streaming.

Lets for example assume a decoder has a buffer of size X (that can be 50gb if
you want). And let us further assume the muxer/transmiter by using magic
knows that size and stays within the limit. that is the buffer might be
0-0.1% full for an hour or 99.9-100% full for an hour. No problem but
the decoder CANNOT with that detect clock drift. because the dts/pts it
receives as well as all other timestamps in nut currently, will differ from
its clock by the buffer fullness. transmit_ts can easily be used as it is
the true transmit time.
Now i belive you will agree that without clock synchronization its just a
matter of time until the buffer will end up empty and the video/audio
freezing. Again the buffer might be infinitly large, it doesnt help.
You would need atomic clocks or some other means of keeping time accurate.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/nut-devel/attachments/20080206/062d5e2f/attachment.pgp>