[FFmpeg-devel] [PATCH] Speex parser

[Michael Niedermayer]

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


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


> 
> 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() ?


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Thouse who are best at talking, realize last or never when they are wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090921/cd183ee1/attachment.pgp>