[FFmpeg-devel] [PATCH] Speex parser

[Baptiste Coudurier]

On 9/21/2009 12:53 AM, Michael Niedermayer wrote:
> On Sun, Sep 20, 2009 at 06:58:53PM -0700, Baptiste Coudurier wrote:
> [...]
>>>>> please correct below:
>>>>> pts/dts:                    no
>>>>> frame boundaries:           no
>>>>> start_time:                 ?
>>>>> file duration:              ?
>>>>> packet duration:            (pretty much meaningless without parsers)
>>>>> stream array:               yes
>>>
>>>>> extradata:                  (unreliable without parsers)
>>>>
>>>> Why is that?  If a file header contains extradata, it should be
>>>> returned, otherwise not.  The ogg abomination is of course a special
>>>> case.
>>>
>>> its because its convenient ...
>>> some formats (mpeg4, aac, ...) can have their global headers in stream or
>>> in a seperate field in the container
>>> if now the parser extracts that stuff from in stream in
>>> av_find_stream_info()
>>> that has several advantages
>>> 1. the decoder only has to look at extradata
>>
>> Extradata is sometimes a way to differentiate between bitstream formats,
>> example are VC-1 and in some way H.264.
>>
>
> [...]
>
>>
>>> 3. when a file is cut and the global headers occur later,
>>> av_find_stream_info()
>>>      will look ahead until these headers and put them in extradata. The
>>>      application will then have them available for the first frame even if
>>> they
>>>      are stored after the first frame
>>
>> For which container is this happening ? global header is something usually
>
> mpeg-ps/ts (mpeg4+h264+ (mpeg2 if its enabled again))
> raw h264,mpeg4, (mpeg2 if its enabled again)

Humm, I wouldn't consider these formats using a global header 
technically. Sequence headers are repeated where appropriate.

>> put in header, and is put only once to avoid repeating it, ex mp4, wmv,
>> mkv(?)
>>
>
>> I tend to agree with Mans here, av_find_stream_info should not populate
>> extradata if it is not in the container.
>
> this would cause us to loose a few seconds of video at the start in some
> cases. I dont think any user would like that.

Well, many people are using libavcodec h.264 decoder without libavformat 
(mplayer, vlc) and I don't think they complained that much :)

[...]

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org