[Ffmpeg-devel] Re: integrating AVS decoding into MPlayer

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> Hi
>
> On Sun, Jul 16, 2006 at 01:35:49PM +0100, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> 
>> > Hi
>> >
>> > On Sat, Jul 15, 2006 at 10:56:47PM +0100, M?ns Rullg?rd wrote:
>> >> Michael Niedermayer <michaelni at gmx.at> writes:
>> >> 
>> >> > Hi
>> >> >
>> >> > On Sat, Jul 15, 2006 at 08:26:35PM +0200, Baptiste Coudurier wrote:
>> >> >> IMHO H264 NAL formating in MOV is better than in AVI. Not
>> >> >> standardizing wraping is just laziness IMHO.
>> >> >
>> >> > h.264 specifies how things should be formated if iam not mistaken
>> >> > (dont kill me if i remember this wrong, its some time since i
>> >> > read the spec) and that is how things should be stored obviously
>> >> > ... mov does something different its not a avi vs. mov question
>> >> > but a standard vs. non standard thing
>> >> 
>> >> The H.264 spec only mentions the NAL format with SPS and PPS
>> >> transmitted inband with the rest of the video data.  ISO 14496-15
>> >> (along with -12 and -14) specifies the out of band version.  
>> >
>> > ok, it seems you are right the h.264 spec doesnt specify how nal
>> > units must be "seperated" just that everything must be in a nal unit
>> >
>> >> Both have advantages in the applications they were intended for.
>> >
>> > i dont agree, theres no real advantage of the format used in mov
>> > compared to simply putting the startcode prefixes infront of the NAL
>> > units
>> 
>> The NAL bytestream format (H.264 Annex B) adds a startcode prefix in
>> front of each NAL unit so the boundaries can be located within a
>> stream.  
>
> yes
>
>> In formats that, like MOV, already provide frame
>> synchronization, there is no need for this extra overhead.
>
> frame synchronization will not make the startcode prefixes for
> slices, sps&pps, ... redundant so no i dont agree

The 0x00000001 prefixes are not needed if you know where the
startcodes will be anyway.  You still need the actual startcode of
course.

>> The same thing goes for SPS/PPS.  In a streaming context, like TV
>> broadcast, the SPS/PPS must be transmitted inband since there is no
>> other way of getting this data to the decoder.  In a file context, or
>> streaming with a separate connection to each client, it is more
>> efficient to store SPS and PPS in a file header (or send them to each
>> client as they connect). 
>
> iam fully agreing here but thats not what i was talking about, i am not 
> talking about where the SPS & PPS are stored but how they are
> mov uses a very weird method of reformatimg them while all it had to do was
> just to leave the startcode prefixes before the SPS & PPS

Indeed, and it's very annoying.  It gets especially annoying when they
decide to split the thing into as many 14496-x parts as possible,
charging separately for each one.

> also note, just in case anyone doenst know, AVI has a spot where a codec
> can store a global header, SPS&PPS should be stored there, its just that
> whoever first put mpeg4 / h.264 in avi decided due to stupidity not to put
> the global headers there ...

The lavf avi muxer is quite happy to put H.264 headers there, but
refuses to play the resulting files.  TCVP+lavc plays them though.

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