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

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> Hi
>
> On Tue, Nov 14, 2006 at 11:42:40PM +0000, Måns Rullgård wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> 
>> > Hi
>> >
>> > On Tue, Nov 14, 2006 at 06:03:37PM +0100, ods15 wrote:
>> >> Author: ods15
>> >> Date: Tue Nov 14 18:03:33 2006
>> >> New Revision: 20926
>> >> 
>> >> Modified:
>> >>    trunk/DOCS/tech/nut.txt
>> >> 
>> >> Log:
>> >> allow info packets to appear in mid-stream, outside of main headers.
>> >> these SHOULD NOT appear in non-realtime-streams
>> >
>> > reverse this at once!
>> > not a single person has agreed to this change except you
>> >
>> > you cannot just change the (frozen) spec at will, next time someone
>> > is pissed at the dts ordering rule and changes it to a SHOULD to have
>> > audio packets 1 sec before video
>> 
>> Hmm... does NUT require strict monotony of DTS even between streams?
>
> not exactly but something similar:
>     Pts of all frames in all streams MUST be bigger or equal to dts of all
>     previous frames in all streams, compared in common timebase. (EOR
>     frames are NOT exempt from this rule)
>
> why we ended up with this and not strict dts ordering is something i dont
> remember, but it doesnt seem like pts-dts vs dts-dts makes a big difference

I'll have to think about that a bit...

>> 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?

> 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.

> additionally having audio and video with arbitrary delay will not reduce
> the problem but rather make it worse (i think you agree here?)
>
> and specifying exactly what delay there should be would again not really
> change a thing or?

The spec could allow for a constant offset between streams, possibly
specified in a header field.  I can't think of a case where variable
delay would make sense.

>> Guess I'll just have to stick with MPEG-TS for those then...
>
> you will never use anything except mpeg no matter what advantages

I will use whatever works best for the problem at hand.  Quite
frequently, that happens to be MPEG.

> or disadvantages the formats have and iam not saying nut is better
> then mpeg in all cases, just in most :)
>
> more specifcially that is
> * smaller overhead

Yes, the overhead is smaller.  That can't be argued.  MPEG-TS was
never intended to have a small overhead.  The main goal was that it
should work well for broadcast applications with frequent packet loss.

> * you can actually seek to a specific time (in mpeg thanks to timestamp
>   discontinuities you cant)

You obviously haven't seen the set top boxes we make at work.

> * 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.

> * 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.

-- 
Måns Rullgård
mru at inprovide.com