[NUT-devel] Broadcasting nuts [PATCH]

[Michael Niedermayer]

On Wed, Feb 06, 2008 at 10:51:04AM -0500, Rich Felker wrote:
> On Wed, Feb 06, 2008 at 04:24:06PM +0100, Michael Niedermayer wrote:
> > 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.
> 
> You misunderstood the word device-dependent. I do not mean that the
> files are unplayable by agnostic devices which do not care about the
> added nonsense. Rather, I meant that the file is polluted with
> device-specific information, information which in the case of
> transmit_ts also happens to be totally irrelevant!

Please try to keep the discussion technical.


> 
> > > 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.
> 
> This all has nothing to do with redundant timestamps.

I tried to explain the problems in small steps as you seem to not understand
them at all.


> 
> > Thats the first unavoidable device dependance
> 
> Not unavoidable and not permissible.

What is not unavoidable? My claim was "the decoder cannot decode what it hasnt
received yet.".
I fear that is not avoidable.


> 
> > 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.
> 
> Mark the buffer with actual receive times, according to the local
> clock, and correlate them with the timestamps in the NUT stream,
> smoothing out any timing adjustments over a long interval that's still
> an order of magnitude away from the length needed for drift to become
> a problem. 

Ill try again with an even simpler example to make it harder to miss the
problem. Eventually you will have a problem to ignore it and pretent
some disconnected solution might work

lets assume 1 frame/sec video, and 100byte/sec channel rate
Frame 0   dts   0 99byte received at 0
Frame 1   dts   1 99byte received at 0.99
Frame 2   dts   2 99byte received at 1.98
...
Frame 1000 dts 1000 99bytereceived at 990

vs.

99byte/sec channel rate
Frame 0   dts   0 99byte received at 1
Frame 1   dts   1 99byte received at 2
Frame 2   dts   2 99byte received at 3
...
Frame 1000 dts 1000 99byte received at 1000

The above 2 are with atomic clock based transmitters and receivers. 
Now assume the clocks drift how are you going to detect let alone compensate
for this? Either of the 2 outputs could have come from the other stream if the
clock drifts in the right direction.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- 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/e446e149/attachment.pgp>