Blocking artifacts with mpeg-ts in fixes/32 when using nvdec or vdpau

[KungFuJesus]

• Platform: Linux mythtvbox 5.17.5-gentoo #1 SMP PREEMPT Sun May 1 02:28:31 EDT 2022 x86_64 Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz GenuineIntel GNU/Linux

• MythTV version: fixes/32

• Package version:

• Component: mythfrontend / mythavcodec

What steps will reproduce the bug?

Playback 1080i video from OTA MPEG-TS with nvdec or VDPAU decoding.

How often does it reproduce? Is there a required condition?

Somewhat random but most often occurs during sharp scene transitions or high motion

What is the expected behaviour?

No blocking artifacts

Here's the "debug" playback output when this issue occurs:
https://pastebin.com/m6cfem9q

Here's a screenshot:

What do you see instead?

Blocking artifacts

Additional information

This issue I believe to be inherited during a resync to ffmpeg 4.4 but it's hard to say for certain. I only exhibit this with VDPAU or nvdec decoding and the issue seems to disappear when the video is pulled from the transport stream into a regular mpeg2 container. I was able to see this same buggy behavior with nvdec on a different machine with mpv for a while, but now that I've updated ffmpeg and mpv over the past year or so, I cannot observe it anymore. The issue cropped up right around the v32 update and I seem to not be the only one exhibiting this issue, as this mailing list user also seems to have the symptoms: https://lists.archive.carbon60.com/mythtv/dev/638570

I'm attaching a minimally sized ts that exhibits the issue. Hopefully it's not too large.
problem.zip

I've mentioned this issue in issue #428. The machine using nvdec with mpv is leveraging ffmpeg 4.4.2, so it's at least fixed in that verison.

Let me know if there's anything more I can provide.

[KungFuJesus]

Oh and the option to use FFmpeg's vanilla demuxer does not make the issue go away. It's unclear if an update to ffmpeg made the issue disappear with mpv or if a fix applied to mpv's ffmpeg usage made the issue go away, but mpv plays this file with no issues, and mythtv reliably has these artifacts, whether seeking / skipping or not.

[Jpilk]

I'm running current devel/ffmpeg-resync f813141 with the PR#610 patch and VDPAU with an nVidia 470 driver. I see this blocking-after-skip only in recordings from the 'local' mux, which is encoded with the 'field pictures' feature which the PR targets when using software decoding.

I believe some channels in the USA also use that feature - but I suppose I may have the hammer/nail diagnosis syndrome.

[KungFuJesus]

I can't recall with any concreteness whether I see this with progressive scan broadcasts but that could simply be coincidence or a consequence of the fact that most of what I view that's interlaced is 1080i content. It could be the 1080 part that's the common factor when I see the issue and not the 'i' part. I don't watch enough content stuck in 480i on broadcast to know.

For me, there's no need to skip around, it just shows up. For a while, it also showed up in mpv. Either an update in mpv or an update to the ffmpeg it relies on made this issue disappear. I haven't seen these artifacts on a va-api system which initially led me to believe that it was a hopeless nvidia-specific issue but with it disappearing in mpv...maybe it's something ffmpeg fixed upstream?

Turning off the deinterlacer does not make the issue disappear, so it's certainly not specific to the deinterlacer.

[bennettpeter]

Is this only with mpeg-2 and only on certain channels? There was a bug in NVidia mpeg-2 decoding that caused intermittent pixelation on certain channels that used a high level of compression. The explanation from NVidia was "longer than expected motion vector" or something to that effect. Newer NVidia cards may not have this problem.

[KungFuJesus]

Mpeg2 in pretty much every 1080i broadcast. It goes away after transcoding losslessly into an mpeg2 container. I have a Maxwell GPU with mpv I can test this on. Admittedly my most recent test was with an ampere. Let me see if mpv+newer ffmpeg on the Maxwell GPU is enough to make the issue disappear or if it's still affected.

This had not been an issue until v32 from what I recall.

[bennettpeter]

The problem started for me when they re-arranged channel frequencies to put more channels on one frequency.
Try this extract, put it in your videos directory
https://drive.google.com/file/d/1OTFY3MWJg8pM-bLgX-IWLXKQoDEYuSz-/view?usp=sharing
This used to show pixelation artifacts on older nvidia with VDPAU or NVDEC.

[KungFuJesus]

So mpv + nvdec with a Maxwell GPU does not exhibit this (mpv linked ffmpeg 4.4.2 in this case). The same machine does exhibit these artifacts when running mythtv when using both VDPAU and nvdec. So, while that doesn't completely exonerate nvidia bugs, it definitely points the fingers at at least a potential workaround.

[KungFuJesus]

The problem started for me when they re-arranged channel frequencies to put more channels on one frequency. Try this extract, put it in your videos directory https://drive.google.com/file/d/1OTFY3MWJg8pM-bLgX-IWLXKQoDEYuSz-/view?usp=sharing This used to show pixelation artifacts on older nvidia with VDPAU or NVDEC.

Yes, mythtv exhibits this with the internal player (however, mpv does not).

It's less pronounced but it's there.

[KungFuJesus]

And on the Maxwell based machine, the issue is entirely concealed as well. Though, perhaps relevant, we see this message printed:

[adam@lanbox2 ~]$ mpv --hwdec=nvdec Downloads/ch710_pixellating_extract.mkv 
 (+) Video --vid=1 (*) (mpeg2video 1920x1080 29.970fps)
 (+) Audio --aid=1 --alang=eng (*) (ac3 6ch 48000Hz)
     Audio --aid=2 --alang=spa (ac3 2ch 48000Hz)
[ffmpeg/video] mpeg2video: ignoring pic cod ext after 0
 (+) Video --vid=1 (*) (mpeg2video 1920x1080 29.970fps)
 (+) Audio --aid=1 --alang=eng (*) (ac3 6ch 48000Hz)
     Audio --aid=2 --alang=spa (ac3 2ch 48000Hz)
     Subs  --sid=1 (*) (eia_608)
AO: [pulse] 48000Hz 5.1(side) 6ch float
VO: [gpu] 1920x1080 yuv420p
AV: 00:00:30 / 00:00:34 (88%) A-V:  0.000 ct:  0.073 Dropped: 1

I see that message immediately at the start of play so it's hard to say if the troublesome area is causing that or not. This could just be a red herring. But the good news is that these issues seem absent with mpv, at least with newer ffmpeg (4.4.2 in this circumstance).

[bennettpeter]

On my laptop with NVidia GeForce GTX 1650, with latest master of MythTV, this clip is perfect. On older NVidia hardware it would show pixelation like you saw. I believe this is dependent on the hardware, and would happen irrespective of the ffmpeg or MythTV version.
The workaround is to use mythfrontend setup to force mythtv to use software decoding (i.e. OpenGL) for MPEG-2 and allow NVDEC for all other formats.

[KungFuJesus]

Yes that's the most obvious workaround however my frontend is fairly under powered and while it could do decode duty on mpeg2 without too much trouble it'd be a fair amount of fan noise and power consumption. Especially with software deinterlacing.

And more interestingly, the issue disappears in mpv for both recordings when compiled with a newer ffmpeg. It's still unclear if mpv fixed this or ffmpeg did but it seems fixable if it's specifically a decoder bug on certain models.

Maybe I could ld_preload an older ffmpeg to see if the issue comes back for mpv.

[ulmus-scott]

@KungFuJesus If you want to try the latest FFmpeg release/4.4 see the attached patch. It was a straightforward merge without conflicts.
0001-FFmpeg-update-to-current-version-4.4.2.patch.zip

[KungFuJesus]

@KungFuJesus If you want to try the latest FFmpeg release/4.4 see the attached patch. It was a straightforward merge without conflicts. 0001-FFmpeg-update-to-current-version-4.4.2.patch.zip

Giving it a go now 🤞 . Compiling on the Q9650, could be a bit.