Hello, Most Linux distributions using libav have voted to move to ffmpeg in the future, Debian (and thus Ubuntu) being one of the most prominent ones. Even with ffmpeg API changes, remaining source-compatible should not be a problem for wine. But I guess the problem is not source-compatibility for wine but binary-compatibility for CrossOver. In that case, I'd suggest dlopen'ing and checking for the symbol you want. Maybe even have different code paths if avcodec_decode_audio5 is available (that means a later version of ffmpeg is available on that system). Or you could forget about everything and just take libwmapro from RockBox: https://github.com/mguentner/rockbox/tree/master/apps/codecs/libwmapro They took ffmpeg, isolated the WMA code and made it a standalone library. They even further optimized the code. It's taken from an old version of ffmpeg (2010) but it works :-) On Thu, Aug 20, 2015 at 9:47 PM, Andrew Eikum <aeikum@xxxxxxxxxxxxxxx> wrote: > I have a working implementation of the new xaudio2 API in my tree. > Microsoft is treating it as a replacement for dsound[1], and as a > result, this new API is used by lots of recent games; see Bug > 26808[2] for some examples. > > Most games that use the xaudio2 API use a version of Microsoft's WMA > codec. Wine doesn't currently have the ability to decode this audio > for playback. In order for the xaudio2 implementation to be useful for > most games, we'll need some way to convert it. I chose to use the > FFmpeg library to decode WMA audio. > > This means for most games, Wine's built-in xaudio2 will require that > the 32-bit FFmpeg library be available on the system to successfully > play audio. > > The new code only uses the audio decoding features of FFmpeg, > specifically linking only against libavcodec and libavutil. The newest > APIs that we use were introduced in 2013. Most of the rest date from > 2011 and a few from 2002. FFmpeg's API isn't stable, but I don't > expect much maintenance burden from the small piece that we're using. > > An additional complication is the libav fork. The APIs that we're > using are currently unchanged between FFmpeg and libav, so libav > should function as a drop-in replacement. Further, distros seem to be > migrating back to FFmpeg, if they ever changed. So again, I don't > expect this to be a barrier. > > Wine packagers and developers, do you have any thoughts or objections > to depending on FFmpeg/libav's libavutils and libavcodec for xaudio2 > support? > > [1] > https://msdn.microsoft.com/en-us/library/windows/desktop/ee415813%28v=vs.85%29.aspx > > [2] https://bugs.winehq.org/show_bug.cgi?id=26808 > > Thanks, > Andrew > > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.winehq.org/pipermail/wine-users/attachments/20150823/59f0ea15/attachment.html>
