The VideoLAN Forums

Hi,

I haven't watched wmv files for a while, so I don't know in which version the issue was introduced.
But currently, wmv files look like this:

• I've tried all "Ouptput" options, none worked (can't tell for "ASCII art)
• All the wmv videos I've tried played fine with previous VLC versions
• All the wmv videos I've tried are affected
• All the wmv videos I've tried play fine with mplayer
• No other video format is affected

System & version info:

Arch Linux 64 bit updated today
AMD Radeon 7750 with radeon driver
VLC 2.2.4 "Weatherwax"

Regards,
vlc-user

Maybe a display driver bug? Disable hardware-accelerated decoding?

well ... I've tried with VDPAU and other output drivers. Is that what you mean ?

No.

Specific WMV files and payload parsing regression ?
That should work with samples from there: http://streams.videolan.org/streams/asf-wmv/

I have some news ... it looks like some sort of initialization problem. After clicking on stop and play several times, the video plays. Sometimes it helps to add a video in a different format to the playlist and play that one for a few seconds, then return to the wmv video.

I can confirm same issue. The workaround is disabling HWA at the expense of heavy cpu usage. Thankfully most of my hd videos are in different containers and this issue is limited to .wmv's -- so I immediately switch HWA back to "automatic" once I'm done with the .wmv's.

Relevant system info:

This strongly suggests a display driver bug.

Well ... from the "dumb user" perspective it feels strange that an issue that's specific to a file format should be a video driver bug.

But the more important question is: If we try to file a bug report for the display driver, how can we describe the bug details so they won't reject it right away as "strongly suggests an application bug" ?

I already see myself playing ping-pong ...

Did you actually check any other application with WMV hardware decoding support? And if so, did you use the exact same libavcodec version, and threads count? Otherwise, comparing other apps is kinda meaningless.

AFAIK, mpv/mplayer uses single threaded VDPAU, so that is not a good reference for comparison.

Did you actually check any other application with WMV hardware decoding support? And if so, did you use the exact same libavcodec version, and threads count? Otherwise, comparing other apps is kinda meaningless.

AFAIK, mpv/mplayer uses single threaded VDPAU, so that is not a good reference for comparison.

If you're talking to me I can confirm the same glitchy behaviour on smplayer when HW decoding is set on "auto" and "vdpau." (It's disabled by default.)
I don't believe mpv supports HWA as it's a very simple player. (I'm probably wrong about this but w/e.)

So it's not a VLC (nor smplayer) bug. The only commonality between them are libavcodec and the VDPAU device driver. And in my experience, it's far more likely a problem with AMD drivers than libavcodec...

Btw a word of caution for those of you with an r9-280, if you're thinking about replacing stock radeon with amdgpu, I suggest you don't (seriously trust me on this.) At least, not now.

Oh, thanks for the warning. I'm using a Radeon 7750 and AFAIK, the amdgpu driver supoorts this old card now too. And indeed, I planned to switch to amdgpu in near future.

And thanks for saving me the time testing mplayer / smplayer.

This might have something to do with something.
Reproducible by dragging a video (not just wmv) into an already-playing video within vlc's main window.
Not reproducible if the existing video is stopped/done playing.