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

Michael Niedermayer michaelni at gmx.at
Sun Feb 3 22:12:41 CET 2013

On Sun, Feb 03, 2013 at 09:39:22PM +0100, Nicolas George wrote:
> 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.

I think the docs state that no flushing or delay happens if theres
no resampling and sufficient output bufferf size
Obviously the docs are not as clear as i thought, thus, wherever this
was unclear worded, please improve the wording or point me to it
so i can try ...

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

can you provide a testcase for reordering of S32 that gets converted
to float ?
this should be easy to fix

about reordering packed->packed, code could be added to swr to handle
this case
Thats not meant to be an argument about doing it in alsa specific
code vs swr. Just that it would make sense to optimize it in swr


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator
-------------- 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/deb62820/attachment.asc>

More information about the ffmpeg-devel mailing list