[Libav-user] Converting audio sample buffer format

[Paul B Mahol]

On 2/25/13, "Rene J.V. Bertin" <rjvbertin at gmail.com> wrote:
> On Feb 25, 2013, at 12:53, Carl Eugen Hoyos wrote:
>
>> Rene J.V. Bertin <rjvbertin at ...> writes:
>>
>>> I for one assume that the gcc devs would not have provided
>>> default-on auto-vectorisation if the feature triggered
>>> (too many) bugs they know of.
>>
>> You probably also assume the gcc developers do know
>> the difference between a undecidable and a NP-hard problem?
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
>
> Who cares, as long as they don't release versions that fail on too many
> kinds of code? As far as I'm concerned they can use whatever kind of magic
> as long as it isn't too black ;)
>
>> Seriously: If auto-vectorisation works (for some gcc
>> versions) and has a performance-gain, please send a
>> patch.
>
> Wilco, but don't count on it. If gains are to be had they'll probably not
> only be for specific compiler and host types/versions, but also be on a
> case-by-case basis (file or even function level), which is probably hard to
> integrate into the build procedure.
>
> To be honest, the example I cited earlier was the 1st time I ever saw a true
> gain from auto-vectorisation (as opposed to automatic use of the SSE abi for
> 'regular' calculations). And even that spectacular gain is completely
> drowned in my application ... little does it matter if a pixel format
> conversion routine runs at 10kHz or at almost 25kHz when you're calling it
> at typical video frequencies (or there are a number of other bottlenecks).
>
> BTW, is there some documentation on ffmpeg.org on how to create patches
> after having hacked around in the source tree?

Yes, it is on usual location on project web page.

> And a related question: what's a good way to perform real-world benchmarks
> on the libraries? Can ffmpeg be compiled so that it collects performance
> statistics on specific operations? Because I presume no one will be
> interested in patches that give a performance gain that's significant
> (reproducible) but completely irrelevant on the overall timescale of
> operations...
> (in fact I'm quite sure of that, having read a discussion on a patch to
> support building universal binaries on OS X ... which could be as easy as
> implementing the more-or-less standard --disable-dependency-tracking option
> in configure :) )
>
> R
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user
>