[FFmpeg-devel] [PATCH] Speex parser

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> 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
> 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
> 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
>
>> 
>> > fps:                        (unreliable without parsers)
>> > values that need decoding:  (unreliable without parsers)
>> 
>> I want whatever fields are provided by global headers.  If fps is
>> provided, return it unchecked, otherwise leave undefined.  Any
>> decoding/parsing required to determine missing values I can do myself.
>
> but what is with the stream array then? av_find_stream_info() does look
> ahead and its the demuxers itself that fill it based on packets found
> for new streams not a global header.

For the few formats (I can only think of MPEG-PS) that don't have any
kind of header mandated, the something will of course have to look
ahead to populate the stream array.

> And indeed the global header is in some cases (flv for example) not
> reliable.
> Basically, to me it seems everything that av_find_stream_info() does
> would fall under the "dont do it" category, if there really is a
> global header that lists all streams the demuxer should already have
> used that to create streams when read_header() was called.

Some formats list all streams in a global header, but this header
might not contain all stream parameters, only enough to allow later
stages to do the right thing, e.g. select the correct decoder.

>> I'm mentioning these things because, although I'm not working on
>> anything lavf-based at the moment, whenever I do, I often find these
>> raw access functions lacking.  I know others who use lavf share this
>> experience.
>
> maybe somehow keeping track of what is straight from the container and
> what is inferred from other values would be a good idea, but i dont know
> how to do that cleanly and efficiently, a struct of int64_t and a enum
> would of course do but it seems a little ugly ...

I don't see the point in that.  What I'm looking for is a way to avoid
the overhead of all the extra processing in lavf when it's not needed.

>> Another thing I didn't mention earlier: it seems that packets returned
>> by av_read_frame() must be consumed by application before calling it
>> again.  In other words, it is impossible to buffer frames for later
>> decoding without copying the data out of the AVPacket.
>
> did you try av_dup_packet() ?

That function looks like it makes a copy of the packet, which is
exactly what I wanted to avoid.

-- 
M?ns Rullg?rd
mans at mansr.com