[FFmpeg-devel] [PATCH][WIP] lavfi/aconvert: use libswresample.

[Stefano Sabatini]

On date Thursday 2012-01-26 17:24:49 +0100, Clément Bœsch encoded:
> On Thu, Jan 26, 2012 at 04:05:32PM +0100, Nicolas George wrote:
> > Le septidi 7 pluviôse, an CCXX, Clément Bœsch a écrit :
> > > BTW, what is planned for the audio packing in lavfi?
> > 
> > I think I do not understand what you mean here.
> > 
> 
> As you mentioned later, lavfi has a bit flag to indicates if it is
> processing a planar or packed format. It was done like this before the
> planar formats got introduced.
> 

> Now the information is "embedded" in the sample format and we don't need
> that bit anymore, so that attribute could be dropped. It would also
> simplifies of this filter by dropping the last parameter (you use "s16" if
> you want packed signed 16-bit samples, and "s16p" if you want planar
> signed 16-bit samples).

After quick thought I think the better thing is to drop the
packed/planar attribute at all, and gain consistency with lavu and
with the video path (for which "packing" information is stored in the
pix_fmt).

Note that there is an intrinsic difference between pixfmt and
samplefmt, pixfmt encodes both the information related to the type of
content and to the layout, samplefmt contains the information related
to the type of samples and to the packing, but not to the layout.

> Still, dropping the packing format flag has various implications:

>  - we won't have a way of specifying "auto" for the planar/packed if we
>    don't "auto" the sample format

yes, thus should not be a big issue (unless someone can provide a
meaningful use case), also we can provide facilities for generating
a list of packed/planar and provide means and syntax for filtering a
specific type of sample_fmt.

>  - the packing format is an enum which might have become more than just
>    "packed" or "planar"; dropping it might put an end to other potential
>    way of packing samples (unlikely to reach the filters?)

I'm not aware of other types of packing formats, but I suppose they
may be dealt with at the decoding level.

>  - ABI/API?

Yes this would break audio ABI/API in a non-trivial way, note that
this shouldn't be a big issue since I didn't introduce lavfi in
ffmpeg/ffplay, the only affected component from the user point of view
would be the lavfi device.
-- 
FFmpeg = Fantastic and Fancy Martial Powered Elastic Generator