native wma breaks with recent ffmpeg

[mc2man]

Whether this is overall an issue or just confined to ubuntu/debian I'm not sure

At least here native wma (wma3pro) decoding in 1.02, 1.03, fails with ffmpeg -r's > 19777, while using any prior ffmeg it works fine.
( that includes -r's that have wmapro support built-in or wmapro patched -r's
Also working fine are pre native support vlc versions I'd patched myself to move wma3 decoding from dmo to avcodec ( 1.0, 1.01, 1.02-git

This is reflected on builds on both 8.04 and 9.10 ( I know 8.04 is not recommended, but building is possible with a few disables

In the last 1.1-git I built ( about 5 wks. ago ), wma3 thru avcodec also worked fine (self patched

The failure is from frame errors, can post the output (log is on other machine - 9.10 ubuntu

I believe this commit is what broke the native support ( here at least

http://git.ffmpeg.org/?p=ffmpeg;a=commi ... 7094f41a94

( have not tried using different gcc than 4.2.4 on 8.04 and 4.4.1 on 9.10, don't think it would matter, but can if a possibility

[Rémi Denis-Courmont]

you should rather report the problem to FFmpeg developers. There is not much to be done about this from VLC forums.

[mc2man]

you should rather report the problem to FFmpeg developers. There is not much to be done about this from VLC forums.

An interesting response
The point here is that for at least the last 7 months or so wma3 decoding thru avcodec has worked fine in vlc 0.9.x -> 1.1 even though it was not part of the released vlc code. (whether with a wmapro patched ffmpeg or recently the wmapro enabled vlc

And as I mentioned it continues to work fine in 0.9.x -> 1.03 (leaving 1.1 out because I haven't built recently) as long as the ffmpeg -r is 19777 or less.

Also noting that decoding in ffmpeg itself and mplayer builds also work fine no matter what the -r , ffmpeg fiddles with the code and mplayer syncs to it

While I certainly can't speak for ffmpeg, why should they be responsible to keep their code compatible with vlc, particularly in this case.

Vlc added the 'if' to avcodec/fourcc.c to "support" native wmapro decoding, not ffmpeg

The release note for 1.0.2
Changes between 1.0.1 and 1.0.2:
--------------------------------

Decoders:
* Native support for WMA Professional, without the use of the Win32 dlls

While overall this was a good move, especially for 64 bit users ( suggested as much in a post some time ago), I'd think vlc would be prepared to support their own change, not pass it off on ffmpeg.

And the main reason for the prior post was to see. if in fact, any -r's greater than 19777 do or should be expected to work with vlc.

There is also an ironic effect here, because of the 'if', if your ffmpeg -r is recent, (> than 19777 from what I see) playback becomes broken on 32 bit installs that are dmo enabled. ( unless one cli's a codecs command.or removes the lines in avcodec/fourcc.c before building

Maybe ( if in fact 19777 is the last -r to work), the release should be

Changes between 1.0.1 and 1.0.2:
--------------------------------

Decoders:
* Native support for WMA Professional, without the use of the Win32 dlls ( with wmapro enabled ffmpeg <= 19777

[xtophe]

Also noting that decoding in ffmpeg itself and mplayer builds also work fine no matter what the -r , ffmpeg fiddles with the code and mplayer syncs to it

You should have told us that in the first message.

While I certainly can't speak for ffmpeg, why should they be responsible to keep their code compatible with vlc, particularly in this case.

Vlc added the 'if' to avcodec/fourcc.c to "support" native wmapro decoding, not ffmpeg
[...]

Again, that's an important piece of information. Do you happen to have the commit id handy ?
Ideally you should answer to the commit message on vlc-devel@

But if you have the commit-id or the author of the commit, i'll transmit your bug report to him

[mc2man]

You should have told us that in the first message

My apologies, I thought that was understood in 1st post, will be more verbose in future if needed.

But if you have the commit-id or the author of the commit, i'll transmit your bug report to him

I linked to the ffmpeg commit I believe broke vlc native support in the first post. Unfortunately ffmpeg seems to make adjustments to their wmapro code from time to time though this commit was fairly substantial.

My saying that ffmpeg -r 19777 is the last to work properly with vlc is based at this point solely on what I've found, confirmation one way or the other was one of the reasons I posted. ( and would be prudent

If any debug and or build logs for vlc 1.0.2, 1.0.3 are needed will gladly provide ( have debuild produced logs for vlc builds using 19777 and a couple more current ffmpeg -r's

[fenrir]

It should be fixed by [5964d90680547862f7e22003b074370cd1febcf0] in master and by [29372c90602c8fb11be11f11381d6fd4df1696b7] in 1.0.

[Jean-Baptiste Kempf]

Thanks fenrir!