[FFmpeg-devel] [PATCH] Speex parser

[Michael Niedermayer]

On Mon, Sep 21, 2009 at 03:07:59AM +0100, M?ns Rullg?rd wrote:
> 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.

That depends on the application design and if it really needs to know
the stream array ahead of time. One surely could imagine an application
that does not need it ...


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

what about
if(s->packet_buffer)
    av_read_frame()
else
    av_read_packet()
?

packet_buffer should IIRC only be non NULL for the first few packets that
have been preread in av_find_stream_info() (i didnt check that though by RTFS)
also the parsers still would have to be disabled to not have any half packet
stuck in one ...


and "not needed" depends on what is done with the data ...


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

well, if the demuxer normally allocates a packet and there is no parser
then av_dup_packet() is a return;
If there is a parser then the packet returned may point into the source
packet, or into an internal buffer of the parser, in that sense several
output packets can point to the same allocated array.
av_dup_packet() in this case will copy the packet to provide a non
shared array that can be freed normally. That of course could be
avoided if we did reference counting and thread synchronization on
packet destruction, but that has its overhead as well and surely would
add some complexity ...
that said, a patch implementing reference counting & thread sync for
AVPacket management is welcome given that it is faster and
not slower in any practical cases and is clean ...


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- 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/86a1f0bd/attachment.pgp>