A bug in VDPAU MPEG2 decoding (with video and source data)


there’s a DVB-T multiplex in Czech Republic that encodes their MPEG2 stream with some less usual settings (yet fully standard, I was told). I think it’s called field-encoded. NVIDIA VDPAU has problems decoding it and players using VDPAU show scary visual artefacts whenever there’s a major scene change. It would be good if NVIDIA engineers analyzed the stream (see link below) and updated their MPEG2 decoder, if possible (if it’s not hardwired in hardware or something).

I’ve prepared a video for you showing MythTV 0.27 on NVIDIA ION replaying the same recording first with VDPAU help (00:54 - 01:09) and then using software (FFMPEG) decoder (02:00 - 02:15). The problem is clearly visible.

You can download the whole recording from http://web.zln.cz/~joy/mpeg2vdpau.mpg - the particular part shown on Youtube above is from 03:15 to 03:30. I haven’t tried shortening the recording because it could affect the encoding and I didn’t want to break the evidence.

Thanks and please let me know your opinion.

[This file was removed because it was flagged as potentially malicious] (322 KB)

PetrS, Can I reproduce this issue with mplayer?


mplayer -vc ffmpeg12vdpau -vo vdpau mpeg2vdpau.mpg
MPlayer SVN-r36496-4.7.3 (C) 2000-2013 MPlayer Team
205 audio & 425 video codecs

Playing mpeg2vdpau.mpg.
libavformat version 55.19.104 (internal)
TS file format detected.
VIDEO MPEG2(pid=3301) AUDIO MPA(pid=3302) SUB Teletext(pid=3305)  PROGRAM N. 1
VIDEO:  MPEG2  720x576  (aspect 2)  25.000 fps  4500.0 kbps (562.5 kbyte/s)
Load subtitles in ./
Forced video codec: ffmpeg12vdpau
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 55.39.100 (internal)
Selected video codec: [ffmpeg12vdpau] vfm: ffmpeg (FFmpeg MPEG-1/2 (VDPAU))
Opening audio decoder: [mpg123] MPEG 1.0/2.0/2.5 layers I, II, III
AUDIO: 48000 Hz, 2 ch, s16le, 192.0 kbit/12.50% (ratio: 24000->192000)
Selected audio codec: [mpg123] afm: mpg123 (MPEG 1.0/2.0/2.5 layers I, II, III)
AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample)
Starting playback...
[VD_FFMPEG] Trying pixfmt=1.
[VD_FFMPEG] XVMC-accelerated MPEG-2.
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
VO: [vdpau] 720x576 => 768x576 MPEG2 VDPAU acceleration
[VD_FFMPEG] XVMC-accelerated MPEG-2.

Then a minute later you get thousands of

[vdpau] Failed VDPAU decoder rendering: The size of a supplied object does not match the object it is being used with.
A:47123.4 V:47123.4 A-V: -0.001 ct:  0.007 150/172  0%  0%  0.7% 0 0
[vdpau] Failed VDPAU decoder rendering: The size of a supplied object does not match the object it is being used with.
A:47123.4 V:47123.4 A-V: -0.000 ct:  0.007 151/173  0%  0%  0.8% 0 0

This clip changes resolution midfile, so that might be the reason NVIDIA doesn’t like it. BTW MPEG has very low demands in regard to computational power - why do you use VDPAU in the first place?

PetrS, Please provide nvidia-bug-report by running nvidia-bug-report.sh as root user. Also what version of MythTV you are using?

PetrS, Filed bug 1414846 to track this issue. I think you are using MCP79 ION VGA [10de:087d] Did you tested with any latest GPU ?

it’s not about changing resolution midfile but rather about encoding each half of interlaced frame differently, or something like that. It’s definitely related to interlaced. I may obtain more technical information if you can’t see it from the provided MPEG file.

I use NVIDIA ION computer and haven’t tried it on anything else because I need it working on the HTPC with NVIDIA ION.

I think it’s called “field-encoded” and is less known yet fully standard MPEG2. A friend of mine patched Project X recently that also didn’t cope with that.

nvidia-bug-report attached. I’m using latest stable MythTV 0.27 from Mythbuntu repos running on Mythbuntu 12.04 (that is Xubuntu basically).

Here’s the patch for Project X that fixes the issue. You might find it useful for debugging the NVIDIA MPEG2 decoder as well: http://sourceforge.net/p/project-x/patches/30/


  1. What is the repository that you used to get MythTV 0.27?
  2. The youtube video that you mentioned is with different language and I could not understand the steps described in the video https://www.youtube.com/watch?feature=player_embedded&v=1to0jkxd2f0 , since different lanuguage. Can we get repro steps or repro video capture in english language?
  3. Can we get confirmation that, if the you can see such corruption with different players(like mplayer or any other player) when using vdpau? or only with MythTV software?
  4. Is this issue no repro with any older driver for user? (just to know, if this is regression)

Sandipt, can you hear me?

I said I can reproduce this bug with 331.20 drivers, vdpau-0.7, mplayer 1.1 and SVN on GTX 660.

Have you even tried to download the source file?

Why are asking these questions when this bug has nothing to do with MythTV?

We are able to reproduce this issue with MythTV

Hi PetrS and birdie - We’ve spent some time researching this issue internally and are at something of an impasse. I suggest first contacting MythTV developers to see if this issue is restricted to VDPAU API usage. MythTV may be mis-parsing the video stream, and/or may be using threading incorrectly.

At 11/21/2013 07:50 AM, birdie noted that (s)he was able to see corruption readily using mplayer:

$ mplayer -vc ffmpeg12vdpau -vo vdpau mpeg2vdpau.mpg

Internally, we are unable to see corruption. This would be starting at 46958 seconds, relative to the file itself. Our mplayer version was “MPlayer svn r34540 (Ubuntu)”, the version bundled with Ubuntu 12.04.4 LTS.

birdie, locally I created a truncated version of mpeg2vdpau.mpg that was correctly aligned to begin with an MPEG stream code (00 00 01 B3). This is easy enough to create for yourself:

$ dd if=mpeg2vdpau.mpg of=truncated.mpg bs=1 count=5847448 skip=72550171

Does truncated.mpg have different behavior for you?

If you do manage to get corruption in MPlayer specifically, please generate an API trace as well. You might do this by running:

  mplayer -vc ffmpeg12vdpau -vo vdpau truncated.mpg

, and sending us trace.log. Also please remember to include an nvidia-bug-report.log.gz as well.

In response to some previous comments: the MPEG-1 and MPEG-2 specifications operate on groups of pictures, delineated by the 000001B3 start code. When decoding, there will be no dependencies between successive groups of pictures. Thus, it will always be perfectly safe to truncate a video stream using standard tools such as dd, cat, etc. If this causes different behavior in the player then this is a player bug, in that the player is mis-handling parsing somewhere. As resolution is specified at the group of pictures level changing resolutions midway through a sequence is perfectly valid and somewhat common for OTA broadcasts.

In general we prefer the simplest reproduction possible. That will be corruption when using mplayer, ffmpeg, or another similar tool: something extremely simple that runs from the command line. MythTV is an extremely complex application and often difficult to debug directly.

Hope this helps.

works OK with mpv-player