[FFmpeg-devel] [PATCH] Speex parser
Mon Sep 21 03:58:53 CEST 2009
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:
>>>>> 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
>>>>> 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
> 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
> 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.
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
More information about the ffmpeg-devel