[FFmpeg-devel] [PATCH] Speex parser

[Baptiste Coudurier]

Hi Michael,

On 09/20/2009 06:52 PM, Michael Niedermayer wrote:
> On Mon, Sep 21, 2009 at 12:23:45AM +0100, M?ns Rullg?rd wrote:
>> Michael Niedermayer<michaelni at gmx.at>  writes:
>>
>>> On Sun, Sep 20, 2009 at 10:05:36PM +0100, M?ns Rullg?rd wrote:
>>>> "Ronald S. Bultje"<rsbultje at gmail.com>  writes:
>>>>
>>>>> Hi,
>>>>>
>>>>> 2009/9/20 M?ns Rullg?rd<mans at mansr.com>:
>>>>>> What I would like is a raw demuxer returning exactly what is in the
>>>>>> file, no decoding, no parsing.  This can be done separately if
>>>>>> needed.
>>>>>
>>>>> Isn't that av_read_packet() (instead of av_read_frame())?
>>>>
>>>> Sort of, except that av_read_packet() doesn't actually work.  During
>>>> file opening, some packets are read, analysed, and placed in a queue.
>>>> This queue is bypassed by av_read_packet() so you miss the first few
>>>> packets of the file.
>>>>
>>>> It is possible to open a file without having it analysed, but then yet
>>>> other things stop working, e.g. the list of streams might not be
>>>> populated for an mpeg-ps file.
>>>
>>> iam trying to implement what you want but iam hitting a wall here
>>> there really are so many things filled in and you clearly do want many
>>> to be kept. I cant read your mind, please say clearly which values you
>>> want not to be filled in by lavf?
>>
>> I don't need this urgently or anything, so don't spend your time on
>> this unless you really want to.
>
> it should be easy to implement, if i run into some problems ill
> put it aside and maybe post a patch for others to finish ...
>
>
>> I'm sure there are more pressing
>> things in need of attention (such as my patches ;-).
>>
>>> 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.

> 2. when doing stream copy the global headers will always be in extradata, a
>     muxer can store them or ignore them as it sees fit

This has caused problems in the past, for mpeg-2 especially this is why 
it was disabled.

Besides it seems stream copy bistream changes should be done in 
bitstream filters.

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

[...]

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