[FFmpeg-devel] [PATCH 4/4] lavd/oss: implement surround playback.

[Paul B Mahol]

On 2/3/13, Nicolas George <nicolas.george at normalesup.org> wrote:
> Le quintidi 15 pluviose, an CCXXI, Paul B Mahol a ecrit :
>> I see no point in rewriting same thing in several iteration
>
> The code is already there, it is only moving from one place to another. But
> that is of not much import.
>
>> and making it slower in each next iteration.
>
> Did you make benchmarks? If so, I would be interested in seeing the
> results.
>
>> Also why lavd should not depend on lswr?
>
> Right now, it does not, this is a fact. That does not mean it must not, but
> adding the dependency requires a little more forethought than fixing a typo
> in a comment.
>
>> I see no logic behind your reasoning.
>
> I will explain again.
>
> lswr does a lot of things, and channels reordering is the least of it. That
> means that it is not optimized for that task alone, neither API-wise nor
> speed-wise.
>
> The first part makes using lswr for that almost as complex as implementing
> the reordering from scratch. For example it requires handling delayed
> samples and flushing, even though there will _probably_ be none of them,
> and
> that makes memory management more complex.
>
> The second part makes it doubtful that it is faster. I looked at the code
> and saw that reordering packed S16 (anything in lavd must work with packed
> samples) requires converting them to planar and back. Even worse: packet
> S32
> is converted to planar float; that is a loss of precision, and very
> inefficient on top of that; this last point may be a misfeature, though.
>
> And of course, let us not forget that we would have to lie to lswr about
> the
> actual format of samples, because we are not dealing with samples in their
> internal format but with encoded PCM data. If any part of lswr uses the
> value for anything other than copying (for example, to convert S32 into
> float), all hell breaks loose. The current implementation of OSS only
> supports native S16, so it is not a problem there, but ALSA supports a
> whole
> lot of formats, and OSS can be extended to do the same.
>
> The code that is currently present in ALSA, and that I propose to share
> with
> OSS, is rather simple and does exactly what is needed, nothing more.
>
> Regards,

I see. +2 if this is documented so better solution, if ever is found,
can be fixed.
This should be fine without alsa in name of file that does reordering.
(Isn't it generic after all ...)

>
> --
>   Nicolas George
>