[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.
More information about the Libav-user