[Libav-user] Converting audio sample buffer format

"René J.V. Bertin" rjvbertin at gmail.com
Mon Feb 25 12:37:20 CET 2013


On Feb 25, 2013, at 12:00, Carl Eugen Hoyos wrote:

> Unfortunately, turning auto-vectorisation on triggers 
> bugs in gcc and is therefore no option;-(

Maybe in ffmpeg sources, but we're not talking about that here. 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. Yes, it's on by default in gcc 4.7 and has to be switched off explicitly. 

BTW, I did force a gcc-4.7 auto-vectorised build of ffmpeg recently (using also -ftracer), and didn't notice any errors once alignment issues were avoided (i.e. on OS X). I just noticed no speed gains in my application that justified the effort that would be required to ensure correct alignment on MSWin.

Oh, and I didn't claim that a compiler-optimised ad-hoc scalar function would perform better. I just wouldn't be amazed if it had less overhead than using a generic function, as I think we're talking about a very simple operation ... and especially if the buffers are relatively small. And debugging your own code is (almost) always easier than debugging someone else's code O:-)

> And since this is a mailing list for developers, it 
> makes absolutely no sense to argue "compilation is 
> so difficult", especially as it is only a question 

No one ever said that ... I just raised the point that a local build would be required. Note that the step from using prebuilt static libraries to self-built libraries does require satisfying all the dependencies first. Not necessarily difficult, but it can be a nuisance if you don't want to use something like MacPorts or apt-get because they'd impose even more dependencies...

As to the cast - I suppose Brad put it there just to get rid of a compiler warning (or error, if he's using c++). Of course it shouldn't be doing anything else.

R


More information about the Libav-user mailing list