[Ffmpeg-devel] Re: Speex proposed addition to ffmpeg and suggestions
Thu Jun 23 14:01:20 CEST 2005
On Thu, 23 Jun 2005 10:35:19 +0200
Michel Bardiaux <mbardiaux at peaktime.be> wrote:
> Dario Andrade wrote:
> > So glad you've mentioned, since I have done something I use it for my own
> > purposes.
> > You're right, the reception to such a project was somewhat a little radical,
> > then I decided to keep it private. (Anyway, doing a native decoder did not
> > make sense to me. Speex is evolving really fast with tons of ports to DSP
> > chips and an included fixed point version, if needed).
> I agree. IMHO the only sensible approach to a 'native' codec would be to
> hook the cvs-co tree of speex *in* the cvs-co tree of ffmpeg (just like
> mplayer does w.r.t. ffmpeg). Opinions from the core?
Not i'm from the core, but i'm all for a wider audio codec support.
Speex would be a great addition as it's probably the most wanted
audio codec in lavc for ppl doing voip.
> > Do you have the interest in it?
> > I have only a few issues that I needed to
> > clarify, such as:
> > 4) In order for the speex codec to interpolate frames (in case of a lost
> >>>packet), I am expecting NULL to the "buf" parameter when decoding it.
> >>>That will create a single interpolated frame with no bytes consumed. May
> >>>I do that? Or should I just use the "flush" function for that?
> > The avcodec API does not specify a way for user to create a "lost frame"
> > (codec dependent interpolated frame). What do you think about that? (I guess
> > nobody will ever pass NULL to that function anyway).
> A NULL buffer to avcodec_decode_video requests the codec to output
> delayed frames (e.g. after a IBP in presentation order, thus IPB in
> stream order, decode returns image[the I]/nothing/image[the B] then you
> have to call decode again with a null buffer to get the P. I dont know
> what a NULL buffer is supposed to mean to an audio codec. But its no big
> issue to me, since AAMOF I take great care there is no lost frame in any
> of my files!
Well speex is mostly used for voip, so there lost frame are just part
of the transmission medium.
Imho the pb is rather that we are hitting the limit of the current api
used for audio codecs. It's too simple and is not even proprely serving
some of the currently implemented codecs (see my post about limiting the
number of samples decoded with pcm codecs for ex).
It's probably time to ditch the current api completly and pass some struct
to the codecs like it's done for video. Then passing parameters to ask for
interpolation and all this stuff could be done cleanly. Same goes for things
exported by the codec.
More information about the ffmpeg-devel