1801576 - [AMD RX 5700 XT] VA-API/H264 Stuttery playback when seeking

Status: VERIFIED FIXED

(Core :: Audio/Video: Playback, defect, P3)

Description

[tgn-ff]

Attachment: about_support_graphics.txt

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/109.0

Steps to reproduce:

1. Start playing a video that's encoded with h264. (Use the h264ify extension on yt. -- Higher quality (1080p/60fps) will have a more pronounced effect.)
2. Use the mouse to go to a specific time.

Actual results:

The videos stutters for a few seconds before it starts playing well again. It looks it's dropping frames, but no dropped frames are reported.

Expected results:

This is a regression from Bug 1779186.

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f16db56098b0ec268a7dd0cf551f2abebba42135&tochange=3107f2cb0ec9b46325929a12626da6aca04e5eae

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:stransky, since you are the author of the regressor, bug 1779186, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Comment 2

[Martin Stránský [:stransky] (ni? me)]

Can you attach a video where you see it (and time where you see it) and about:support?
Thanks.

Comment 3

[tgn-ff]

When I try to capture the screen, the resulting video is all stuttery. In fact, it looks worse at the part where the actual playback is good. I don't have a good enough camera to capture it externally either.

Comment 4

[tgn-ff]

Attachment: about_support_full.txt

Comment 5

[Martin Stránský [:stransky] (ni? me)]

It's enough to attach actual clip and time where it happens so I can reproduce it.

Comment 6

[tgn-ff]

I cannot attach any video due to the size limit of bugzilla and their licence. I have verified that the issue reproduces with this video when opened as a local file. With youtube-dl installed: youtube-dl -f 299 https://www.youtube.com/watch?v=LXb3EKWsInQ. You can reproduce the bug when seeking with the keyboard arrows or by clicking in the time bar. For example, while the video is playing, click at 2:35, let it play a couple of seconds and click again at the same point in time. To notice the difference, click at 2:25 and let the video play through 2:35+.

Comment 7

[Martin Stránský [:stransky] (ni? me)]

I do see that too. But I see the same tearing with SW decode and with HW decode + disabled frame drop. So looks like a general problem with the video stream. I also see similar tearing in Chromium.

Comment 8

[Martin Stránský [:stransky] (ni? me)]

I'm testing that on Intel [UHD Graphics 630]. It's possible that your RX 5700 XT has additional issues here (I see h264 decoding issues specific to AMD RX 6600 - Bug 1802844).

Comment 9

[Boris Carvajal]

Attachment: ff_vid_issue.mkv

Comment 10

[Boris Carvajal]

I'm suffering the same annoying problem since that commit, even I'm using the previous build (20221111093717) when viewing a lot of video sites. Luckily, YouTube is pretty much fine because of vp9 media (av1 disabled), still there are some videos that are only served as h264 that are also affected.

I'm attaching a screen video reproducing the issue.

First in the unaffected 20221111093717 build when I seek back to the start of the video, it keeps playing normally.

But in a recent build, however, after seeking, the video starts playing like at half of its frame rate for almost 6 seconds and in this period of time the message "D/PlatformDecoderModule FFMPEG: Requested pts XXX decoded frame pts XXX" is printed continuously in the logs, implying there is something wrong with this code:

    if (mFrameDrop == AVDISCARD_NONREF) {
      FFMPEG_LOG("Requested pts %" PRId64 " decoded frame pts %" PRId64,
                 packet.pts, GetFramePts(mFrame) + mFrame->pkt_duration);
      // Switch back to default frame skip policy if we hit correct
      // decode times. 5 ms treshold is taken from mpv project which
      // use similar approach after seek (feed_packet() at f_decoder_wrapper.c).
      if (packet.pts - 5000 <= GetFramePts(mFrame) + mFrame->pkt_duration) {
        FFMPEG_LOG("Set frame drop to AVDISCARD_DEFAULT.");
        mFrameDrop = AVDISCARD_DEFAULT;
      }
    }

The issue doesn't happen with software decoding.
I'm using Intel UHD 630.

Comment 11

[Boris Carvajal]

Comment on attachment 9308630 [details]
ff_vid_issue.mkv

Test video downloaded using: yt-dlp -f 137 'https://www.youtube.com/watch?v=LpIX5PEDw6k'

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 13

[alosarjos]

I can confirm this is also happening to me too, also 5700XT, I think this happened after updating to 108

Comment 14

[luniac]

I have the same problem on Fedora linux when using hardware accelerated decoding on the 5850U iGPU with VA-API with h264. Occurs on youtube when it uses h264, and on e.g. emby/plex when that uses h264.

I've attached PlatformDecoderModule logs. The stuttering occurs at the point where "FFMPEG: Frame skip AVDISCARD_NONREF" starts appearing in the logs. I haven't attached a video as it looks the same as the ones already attached.

Comment 15

[luniac]

Attachment: 5850U_igpu_PlatformDecoderModule.log

Comment 16

[luniac]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #8)

I'm testing that on Intel [UHD Graphics 630]. It's possible that your RX 5700 XT has additional issues here (I see h264 decoding issues specific to AMD RX 6600 - Bug 1802844).

I don't think it is a GPU/driver bug. When I use mpv with vaapi (mpv -v --hwdec=vaapi --vo=gpu ff_vid_issue.mkv) the stuttering does not occur when seeking. It's only in firefox.

Comment 17

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1801576 [Linux] Remove frame drop after seek on HW accelerated backend r?alwu

Frame drop after seek brings new regression and does not fixes video decoding artifacts completelly so let's remove it and go with video frame copy (Bug 1802844).

Comment 18

[ValdikSS]

I can confirm this issue on Intel HD 3000 (Sandy Bridge) hardware accelerated decoding. Happens on every Youtube H264 video. No radeon hardware.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3129e44ef99c
[Linux] Remove frame drop after seek on HW accelerated backend r=alwu

Comment 20

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/3129e44ef99c