WMV 8 playback crippled since Feisty

Bug #108453 reported by Topper
10
Affects Status Importance Assigned to Milestone
xine-lib
Confirmed
Undecided
Unassigned

Bug Description

Since upgrade to Feisty some of my WMV videos play crippled (grey/green/pink blocks), sound is ok though.
After investigation, it seems that only WMV8 streams are crippled, WMV9 are ok.
I tested with Kaffeine-xine and Codeine-xine, same result, Mplayer and VLC play fine so it's rather a Xine backend bug.
Kaffeine reports that the stream is decoded by ffmpeg, could this package be faulty too ?

I have Feisty up to date with the latest medibuntu repos.

Topper (t-harley)
Changed in xine-lib:
status: Unconfirmed → Confirmed
Revision history for this message
niglch (niglch) wrote :

I also ran into the same issue of seeing grey/green/pink blocks with Totem-xine on Feisty. I haven't tried playing WMV 8 yet, but I have had the issue occur with WMV 9 videos, so I don't think the problem is restricted to only WMV 8. Playback occurs without problems on VLC, however.

I'm also up to date with the latest Medibuntu repos.

Revision history for this message
MiTcH (m-i-t-c-h) wrote :

me too , i used kaffeine/totem/vlc and i get this error message :

[wmv3 @ 0xb50898b4]Profile value 2 is forbidden (and WMV3 Complex Profile is unsupported)

otherwise, mplayer run it correctly...

i have no images (black screen), just sounds. (on feisty+medibuntu)

Revision history for this message
Topper (t-harley) wrote :

running xine from cli with scrambled wmv8 gives me heaps of :

...
[wmv2 @ 0xb66df8b4]
error while decoding inter block: 7 x 12 (3)
[wmv2 @ 0xb66df8b4]Error at MB: 499
[wmv2 @ 0xb66df8b4]concealing 884 DC, 884 AC, 884 MV errors
[wmv2 @ 0xb66df8b4]ignoring overflow at 25 1
[wmv2 @ 0xb66df8b4]ignoring overflow at 19 2
[wmv2 @ 0xb66df8b4]ignoring overflow at 4 3
[wmv2 @ 0xb66df8b4]ignoring overflow at 28 3
[wmv2 @ 0xb66df8b4]ignoring overflow at 31 3
[wmv2 @ 0xb66df8b4]ignoring overflow at 34 3
[wmv2 @ 0xb66df8b4]dc overflow- block: 2 qscale: 20//
[wmv2 @ 0xb66df8b4]
error while decoding intra block: 12 x 5 (2)
[wmv2 @ 0xb66df8b4]Error at MB: 217
...

The output is scrambled. Seems that the decoder is dropping frames although I have lots of CPU power
I also uninstalled w32codecs, same result, the decoder is ffmpeg in my case anyway.

I tried to manually convert a wmv8 file with command line ffmpeg, and the result is fine, no blocky output file

Hope it helps

Revision history for this message
Justin J Stark (justinjstark) wrote :

Same problem here. I get all kinds of overflows which cause green boxes. I filed a bug upstream to xine but I don't think this problem happens with xine-lib 1.1.6. Ubuntu's version of 1.1.4 is broken. This really needs fixed.

Revision history for this message
Justin J Stark (justinjstark) wrote :

I installed xine-lib 1.1.6 and xine-lib-ffmpeg 1.1.6 from Debian experimental

http://packages.debian.org/experimental/libs/libxine1

along with all of its dependencies.

The problem still exists although it doesn't seem as bad. I still get a lot of overflow errors but not nearly as many as with 1.1.4.

I hate this bug. Xine was rock solid in Edgy.

Revision history for this message
Topper (t-harley) wrote :

Yes I had no problem playing those files in edgy too :(

Revision history for this message
Topper (t-harley) wrote :

Workaround :

I installed w32codecs and edited ~/.xine/config to prioritize w32codec over ffmpeg :

 engine.decoder_priorities.win32a:5
 engine.decoder_priorities.win32v:5

 Kaffeine plays wmv fine now, my wmv thumbnails are fine too !

Revision history for this message
Hugin (karsten-loh) wrote :

Using the w32codecs as Topper suggested indeed works... on 32bit systems. Sadly even with the w64codecs installed xine does not allow for an alternate wmv codec to be used on 64-Bit Feisty (not sure the w64codecs even contain wmv codecs).

Revision history for this message
MamiyaOtaru (mamiyaotaru-sogetthis) wrote :

Not only wmv8. _Some_ wmv9 and wmv7 videos are affected. They play fine in ffmpeg, mplayer (ffmpeg backend), mplayer (win32 backend), and xine (win32 backend) but are broken with xine (ffmpeg backend).

wmv9 example: http://www.gamevideos.com/video/watch?video=14503&largeFormat=wmv

Stuff like this on the output with wmv7:
...
[wmv1 @ 0xb6474b48]ignoring overflow at 39 21
[wmv1 @ 0xb6474b48]concealing 80 DC, 80 AC, 80 MV errors
[wmv1 @ 0xb6474b48]invalid picture type
[wmv1 @ 0xb6474b48]header damaged
[wmv1 @ 0xb6474b48]error, slice code was 10
[wmv1 @ 0xb6474b48]header damaged
[wmv1 @ 0xb6474b48]invalid picture type
[wmv1 @ 0xb6474b48]header damaged
[wmv1 @ 0xb6474b48]overreading 12836 bits
...

and with wmv9:
[wmv3 @ 0xb5c73b48]warning: first frame is no keyframe
[wmv3 @ 0xb5c73b48]Bits overconsumption: 26660 > 26656 at 8x17
[wmv3 @ 0xb5c73b48]Bits overconsumption: 8839 > 8672
[wmv3 @ 0xb5c73b48]Bits overconsumption: 40536 > 40448
...

Again, it works fine with ffmpeg, and mplayer using ffmpeg. It's just broken with xine (kaffeine and xine-ui) using ffmpeg

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.