[Ffmpeg-devel] Re: integrating AVS decoding into MPlayer
Sun Jul 16 14:35:49 CEST 2006
Michael Niedermayer <michaelni at gmx.at> writes:
> 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
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. In formats that, like MOV, already provide frame
synchronization, there is no need for this extra overhead.
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). It would of course be possible to send
SPS/PPS in a descriptor in a transport stream PMT, but that would only
complicate the decoder without gaining anything in bandwidth.
H.264 is widely used in both types of scenarios, so specifying both
types of encapsulation makes sense.
mru at inprovide.com
More information about the ffmpeg-devel