Bug report: jerky playback of 1080i with vdpau and 8400gs

[resoli]

I'm using 180.51 under ubuntu 8.10 and mythtv (from jyavenard repository); i'm experiencing blocking and severe artifacts; playing with sw decoder ("High quality" profile under mythtv) is ok.

I'm attaching the nvidia-bug-report output; a sample of jerky video is at http://www.resolutions.it/jerky.ts .

bye,
Rob

[cehoyos]

Originally Posted by resoli

I'm experiencing blocking and severe artifacts;
a sample of jerky video is at http://www.resolutions.it/jerky.ts .

Artefacts reproducible with MPlayer, FFmpeg does not report relevant problems with the stream and decodes it fine.

Carl Eugen

[Stephen Warren]

Thank you for the bug report. I've filed a bug. I haven't repro'd the issue yet, but will try to soon. I'll post any updates in this thread.

[resoli]

Originally Posted by Stephen Warren

Thank you for the bug report. I've filed a bug. I haven't repro'd the issue yet, but will try to soon. I'll post any updates in this thread.

Great. Some more information: I thought at beginning that it was a deinterlace issue, but even with no deinterlacing at all the artifacts are there. 1080p plays wonderfully.

If you need I can provide the mythtv debug trace with VDPAU_TRACE=1 VDPAU_NVIDIA_DEBUG=3 set.

bye,
rob

[thefirstm]

It happens to me, as well. I downloaded the video and played it in KMplayer with the mplayer backend using vdpau, and I got all sorts of artifacts. I also got a green screen when attempting to restart the video after it ended, along with this NVRM Xid:

[44279.291092] NVRM: Xid (0001:00): 13, 0007 00000000 0000502d 0000060c 000002c8 00000040

[Stephen Warren]

I believe this is an ffmpeg bug; I dumped the various VDPAU pictureInfo values, and found that the field_order_cnt and referenceFrames fields were completely mismatched with the correct values.

I don't understand why ffmpeg SW decoding doesn't show the artifacts. Perhaps ffmpeg internally detects the problems somehow, skips decoding corrupt data, and simply shows the previous frame content? Or, perhaps there's some bug in the way these fields are converted from ffmpeg data structures to VDPAU data structures (although there is basically no processing on these fields, and I can't see how such significant errors would appear for this one stream but not others).

[resoli]

Originally Posted by Stephen Warren

I believe this is an ffmpeg bug; I dumped the various VDPAU pictureInfo values, and found that the field_order_cnt and referenceFrames fields were completely mismatched with the correct values.

If you mean that the source is faulty, I suspected that; anyway playing with mythtv sw decoder you simply would'nt have noticed anything bad.

Originally Posted by Stephen Warren

I don't understand why ffmpeg SW decoding doesn't show the artifacts. Perhaps ffmpeg internally detects the problems somehow, skips decoding corrupt data, and simply shows the previous frame content? Or, perhaps there's some bug in the way these fields are converted from ffmpeg data structures to VDPAU data structures (although there is basically no processing on these fields, and I can't see how such significant errors would appear for this one stream but not others).

The "mplayer jerky.ts" output appears to confirm skipping ...

[h264 @ 0x89070e0]B picture before any references, skipping??,?% 0 0
[h264 @ 0x89070e0]decode_slice_header error
[h264 @ 0x89070e0]no frame!
Error while decoding frame!
[h264 @ 0x89070e0]B picture before any references, skipping??,?% 1 0
[h264 @ 0x89070e0]decode_slice_header error
[h264 @ 0x89070e0]no frame!
Error while decoding frame!
[h264 @ 0x89070e0]B picture before any references, skipping??,?% 1 0
[h264 @ 0x89070e0]decode_slice_header error
[h264 @ 0x89070e0]no frame!
Error while decoding frame!
A:56771.3 V:56771.1 A-V: 0.113 ct: -0.205 62/ 62 51% 5% 0.7% 1 0

If I can help in any way...

Correctly watching that source is vital to me, it's the only free HD source available here (Italian public television HD test broadcasts). With ION boards appearing, I was really starting to plan a mythtv frontend upgrade, but this problem stopped me.

[cehoyos]

Originally Posted by Stephen Warren

Perhaps ffmpeg internally detects the problems somehow, skips decoding corrupt data, and simply shows the previous frame content?

I don't think that is the case.
The reference decoder (15.1) only differs from ffmpeg in the second frame (which is not the one showing artefacts), the rest is bit-identical.

Carl Eugen

[resoli]

Any new on this? I can provide more (and bigger) jerky samples, if needed.

bye,
rob

[Stephen Warren]

A quick update on this. I haven't really looked into why the DPB looks very different between ffmpeg and our the other decoder I tested against. However, we're looking into whether there are some changes we can make to improve the decoding of this clip either way. I'll post any updates here if/when they occur.

[resoli]

Originally Posted by Stephen Warren

However, we're looking into whether there are some changes we can make to improve the decoding of this clip either way. I'll post any updates here if/when they occur.

Many thanks Stephen, I will check here; I hope this will be solved, playing 1080i dvb-t streams is very important for htpc functionality.

Bye,
rob

[Stephen Warren]

185.18.14 should fix this.