[NUT-devel] r20926 - trunk/DOCS/tech/nut.txt

[Rich Felker]

On Wed, Nov 15, 2006 at 02:45:04AM +0000, Måns Rullgård wrote:
> >> That is not good. Many hardware MPEG decoders require video to be
> >> about 80ms ahead of audio.  
> >
> > since when does a _MPEG_ decoder support nut streams?
> 
> Since when do the NUT goals exclude certain applications domains
> entirely?

It doesn't, but NUT is not for making device-specific files. Any
particular delay/offset between streams is a DEVICE-SPECIFIC hack that
does not belong in a device-independent format.

> > now if it doesnt then what relevance has that comment? none?
> > and if you meant that demuxing is done in software and than the ES are
> > sent to the HW then you can just buffer these 80ms audio (it just needs
> > a 4kb buffer assuming ~200kbit audio)
> 
> In the chips I'm talking about demuxing is done in hardware.  If
> someone wanted to make a hardware decoder with NUT demuxer, there
> could be trouble because of this restriction.  The reason for the
> offset is that the audio and video decoders have different delays, and
> buffers have to be kept to a minimum.  Even 4kB can be a lot of space
> in these devices.
> 
> I wasn't aware that NUT was intended exclusively for software decoders
> with huge buffers.

It's not. Just make your hardware decoder correctly without delay and
you have no problem. 0 delay is the only natural value. Anything else
is device-dependent. Again, NUT files are not device-dependent. Even
if NUT did support having an offset between audio/video times, only
files created with the "correct" offset for the particular device
would be playable on the device. Other files would fail to play. This
is a hopelessly broken situation.

The solution is to simply require that the offset be 0. It is
_possible_ to make hardware that operates like this with no buffer.
Any other arbitrarily-chosen offset aside from 0 would be wrong
because it would be linked to a particular real-world timescale with
units rather than a unitless quantity (0).

> > * you can seek to keyframes (in mpeg you MUST have many keyframes or
> >   live with several second delay for seeking on slow media)
> 
> You seem to be very concerned about seeking.  Personally, I use seek
> functions less than once per hour of video.  When I do use seeking, I
> don't really care if it takes 10ms longer to find the right spot, or
> exactly where it lands.

When you do seek, you usually do it several times to get to the exact
spot you want. And we're not talking 10ms longer but several seconds!!

> > * you can store any codec, mpeg limits you to mpeg1/mpeg2/h264/ac3
> >   and a few other standard ones
> > * muxing is MUCH easier (btw if you disagree please help me fix the broken
> >   mpeg-ts muxer in ffmpeg :))))))
> 
> A prerequisite of muxing is understanding the spec.  As far as anyone
> knows, this has never happened for NUT.  You and Oded arguing over
> what things mean are proof of this.

...

Rich