Hello, having an issue with VDPAU absolutely mauling MPEG2-TS playback. Issue happens with multiple NVIDIA cards on multiple ubuntu machines. If I playback the test file (video, nvidia-bug-report.log, and vdpau_trace.log from mplayer all available in one combined zip at http://www.thekorn.net/temp/thekorn_vdpau_bug.zip ) using VDPAU acceleration, extreme screen corruption occurs in mplayer, vlc (using vaapi -> vdpau bridge), and mythTV.
If VDPAU is switched off, file plays near perfectly (a couple of visible transmit errors, typical for MPEG2-TS) in mplayer, vlc, and mythTV. File also plays perfectly well in windows using VLC w/ directX acceleration, and also via windows media player (i.e. no acceleration).
Believe this might be similar to https://devtalk.nvidia.com/default/topic/642188/linux/a-bug-in-vdpau-mpeg2-decoding-with-video-and-source-data-/ , which never was resolved.
file was recorded OTA, MythTV Version : v0.27-193-g8ee257c, mplayer version is MPlayer2 2.0-701-gd4c5b7f-2ubuntu2 . Pretty much everything else you should need should be in either the vdpau trace or the bug report log.
If I’ve missed anything, feel free to shout! Thanks!
Examples of the extreme corruption introduced by VDPAU (from the test file, above). Again, these artifacts do not happen when playing the same file without using VDPAU! (i.e. these artifacts are being caused by VDPAU!)
Perhaps unrelated but I’ve been seeing similar issues when decoding h264 encoded video for a while now, and Nvidia seems to be ignoring the issue:
Hmmm, hard to say if they’re related but my gut feel is that they aren’t. I have lots of H264 content, but I tend to jump rather than scan forward/backwards in mythtv so it’s unlikely I would have noticed your issue even if I am affected by it.
That is caused my jumping forward (ala the right arrow).
Tracking this issue under bug 1802410
Sandipt, might you be able to attach this post to the ticket as well?
The symptoms are similar and they may be related. I know for sure I’m not the only one encountering this bug and MythTV, Kodi, & other ffmpeg based applications have been able to reproduce this for months across several versions of drivers, so it’s a fairly old regression.
Hooray, my bug has been fixed in version 370.28. Thanks for finally fixing this.
Lucky you; still no word on mine.
Given that there was no mention of any VDPAU fixes in the changelog, it’s quite possible the fix was incidental rather than on purpose. I did see some evidence from somebody having the same or a similar issue whose problem disappear with VDPAU debug settings cranked up, as if it’s some race condition occurring without some proper fencing for the framebuffer.
Who knows, but I’ve not been able to produce your issue with mpeg-2 at all. I don’t use mplayer2 (just mplayer), but I don’t seem to have any issues (yours or mine) on that for some reason. Mythtv & Kodi may be unique cases in that their OSDs are rendered in GL, I’m not sure that is the case for mplayer.
We are able to reproduce this issue and investigating…