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

Steps to reproduce:

When VAAPI is enabled, when certain videos are fast forwarded and rewound (seems to be limited to H.264 codec), some distortions can appear for brief periods, but they go away as video continues playing.

I tested it with mpv + VAAPI for same videos and it's not happening, so it's likely a Firefox issue.

Observed for example with this video:

https://mirrors.dotsrc.org/blender/blender-demo/movies/BBB/bbb_sunflower_1080p_60fps_normal.mp4

Try using left and right arrow keys a bunch of times for fast forwarding and rewinding.

• OS: Debian testing.
• GPU: Sapphire Pulse RX 6800 XT.
• vainfo: Driver version: Mesa Gallium driver 22.0.3 for AMD Radeon RX 6800 XT (sienna_cichlid, LLVM 14.0.3, DRM 3.46, 5.18.1)
• ffmpeg: 4.4.2.

See attached example of such distortion.

(In reply to Shmerl from comment #0)

Firefox/102.0

Are you really using 102 and not 103 (https://nightly.mozilla.org)?
(Could this be bug 1765350 comment 6?)

It's for sure 102 and has been happening in previous versions too by the way, I've just reported it around now.

Can you test latest nightly?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Testing_Mozilla_binaries
Thanks.

Just tested nightly. Looks like it's better in some cases, but some artifacts still appear when fast forwarding and rewinding. So not really fully fixed.

Tested on RX 6600 XT/Fedora35/mesa-21.3.8 and I can't reproduce it.

Can you reproduce it in 102? In the linked one above, try around 0:58-1:01.

h.264 seek was broken in 102 (Bug 1765350).
That was uplifted so from VA-API perspective 102 is the same as 103 now , which is intended as 102 becomes next ESR.

OK, I can give it a try a few more times in 102 b5 to confirm once it comes out.

Testing with 102 b5. I can reproduce the issue. But it's not happening in every place.

See distortion in 102 b5.

It could be a Mesa issue though. I can open a bug there if needed.

Config:

vainfo: VA-API version: 1.14 (libva 2.12.0)
vainfo: Driver version: Mesa Gallium driver 22.1.0 for AMD Radeon RX 6800 XT (sienna_cichlid, LLVM 14.0.3, DRM 3.46, 5.18.1)

Can you try this one. A small excerpt that clearly shows distortions for me if you jump forward and backward in a bunch of times, but plays OK if you do it without interruptions

The problem still persists in Firefox 107.0b2.
Mesa, radeonsi / va: 22.2.0.

I tried different VA-API players (totem + gstreamer-vaapi) and I see the issues there too. Looks like a bug in radeon drivers. Please try different player (mpv for instance) and if you can reproduce please report at MESA.

I see similar issues on Intel Xe but I didn't investigate it yet. But it looks like a driver problem to me due to bugs in other players. One solution on FF side is to disable buggy formats (from my experience it's seen on H.264 and AV1 while VP8/9 are OK).

Tried to reproduce this with mpv using the snippet above, but I don't see it happening (using 1 second jumps with shift + arrows).

mpv reports using VAAPI:

(+) Video --vid=1 (*) (h264 1920x816 23.976fps)
 (+) Audio --aid=1 (*) (aac 2ch 48000Hz)
AO: [pulse] 48000Hz stereo 2ch float
Using hardware decoding (vaapi).
VO: [gpu] 1920x816 vaapi[nv12]

Config for mpv:

vo=gpu
gpu-api=opengl
hwdec=vaapi
gpu-context=wayland
gpu-hwdec-interop=vaapi-egl

It does happen in Firefox though.

I can still report it to Mesa if you think this isn't Firefox specific.

Thanks. Let's track it at Bug 1779186. I see that too and I can't reproduce it with mpv but I see it with gstreamer-vaapi+totem. Looks like we reuse vaapi dmabuf frames incorrectly or so. mvp has very short rendering queue so I'm not surprised it works.

Is this supposed to be fixed in 108?

While it got much better, it still happens sometimes if you do a lot of back / forward jumps. It happens with attached video above, just less frequent than before, so you really need to do like 10+ jumps or so.

Testing it with 108.0b1.

Distortion that still happens in 108.0b1 (see the roof in top left corner).

Please test 109.0 and open a new bug if you still see it.
Thanks.

btw. I don't see the bug with 109.0a1 (latest nightly) & the video attached here.

This still happens in 109.0b2.

You need to jump back and forward a bunch of times to trigger it though.

Still happens in 110.0b3.

I wonder if it's a Mesa bug or not after all. This or bug 1779186 should probably be reopened.

Yes, it's here again as Bug 1779186 is only a workaround and I decided to remove it as it breaks Intel hardware.
110.0 is fully affected by it and we should bring that to Mesa.
Meanwhile may disable H.264 decoding on AMD by default due to it.
I hoped Bug 1809162 can fix it but I was over optimistic here and Bug 1809162 doesn't help at all.

btw. I have reports about broken RX 6600, RX 6800 and RX 580. So looks like only new hardware is affected.

Does it still happen on Intel though? But it could be something common in Mesa may be. I'll open a bug there.

(In reply to Shmerl from comment #26)

Does it still happen on Intel though? But it could be something common in Mesa may be. I'll open a bug there.

Intel is not affected by the glitches (even the new Xe works okay). But workaround (Bug 1779186) causes shuttering after seek on all hardware.

Let's reopen this one.

Opened Mesa bug here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8234

This bug occurs for me as well, and it seems exclusive to H.264 video. When seeking, I sometimes get brief video distortion before it goes away. If a short video (such as a twitter video,) plays on loop, it'll sometimes distort on reset, too. I tried playing a bunch of h264 video files locally, but I couldn't reproduce the bug in VLC and Celluloid, so it seems exclusive to Firefox.

OS: Fedora Kinoite (Kernel ver. 6.1.12-200.fc37.x86_64)

GPU: Sapphire Nitro+ RX 6700XT

glxinfo: LLVM 15.0.7, DRM 3.49, Mesa 22.3.5

ffmpeg: 5.1.2

This also could be related: with the non-accelerated OpenH264 codec from Cisco, instead of distortion sometimes when seeking, the video will pause while the audio keeps playing. Seeking to a different point will fix it.

It looks much better in Firefox 112.0b3. So far I can't reproduce it, so it's possibly fixed?

Yes, should be fixed by Bug 1802844.