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

Nicolas George nicolas.george at normalesup.org
Sun Feb 3 21:39:22 CET 2013


Le quintidi 15 pluviôse, an CCXXI, Paul B Mahol a écrit :
> 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,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130203/524d0c4d/attachment.asc>


More information about the ffmpeg-devel mailing list