1779186 - [VA-API] H.264 video playback artifacts on RX 6600 XT

Status: RESOLVED FIXED

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

Description

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

I see H.264 video playback artifacts on RX 6600 XT. Only H.264 is affected.

Comment 1

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

Attachment: Screenshot from 2022-07-12 11-31-56.png

Comment 2

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

It's visible during video seek. I also see frozen video images while audio is playing.

Comment 3

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

This comes from https://www.youtube.com/watch?v=64yianfGvzc + forced H.264 codec.

Comment 4

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

To reproduce keep the video playback and then seek to 0:58.

Comment 5

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

Comment on attachment 9285069 [details]
Screenshot from 2022-07-12 11-31-56.png

Frame corruption at 0:58 time.

Comment 6

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

It's also reproducible with downloaded h.264 clip so it's not a streaming issue.

Comment 7

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

Seems to affect seek only, continuous playback is OK.

Comment 8

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

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 11

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

The severity field for this bug is set to S4. However, the following bug duplicate has higher severity:

• Bug 1780731: S3

:jimm, could you consider increasing the severity of this bug to S3?

For more information, please visit auto_nag documentation.

Comment 12

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

Looks like the decoder is re-initialized after seek and dmabuf frames are reset:

#3 0x00007f0156a3dc7c in mozilla::ChooseVAAPIPixelFormat(AVCodecContext*, AVPixelFormat const*) (aCodecContext=<optimized out>, aFormats=0x7f011c216e80)
at /raid/src/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:149
#4 0x00007f014fe160f0 in ff_get_format (avctx=0x7f015f760000, fmt=<optimized out>) at libavcodec/decode.c:1118
#5 0x00007f014fedb210 in get_pixel_format (h=<optimized out>, force_callback=<optimized out>) at libavcodec/h264_slice.c:903
#6 0x00007f014fee427d in h264_init_ps (h=h@entry=0x7f014c203000, sl=sl@entry=0x7f01333bd000, first_slice=first_slice@entry=1) at libavcodec/h264_slice.c:1149
#7 0x00007f014fee60e3 in h264_field_start (first_slice=1, nal=0x7f013304a430, sl=0x7f01333bd000, h=0x7f014c203000) at libavcodec/h264_slice.c:1554
#8 ff_h264_queue_decode_slice (h=0x7f014c203000, nal=0x7f013304a430) at libavcodec/h264_slice.c:2291
#9 0x00007f014fef2707 in decode_nal_units (buf_size=78217, buf=0x7f014c17e000 "", h=0x7f014c203000) at libavcodec/h264dec.c:648
#10 h264_decode_frame (avctx=<optimized out>, data=0x7f013337d3c0, got_frame=0x7f014c3fe49c, avpkt=<optimized out>) at libavcodec/h264dec.c:1021
#11 0x00007f014fe0ff00 in decode_simple_internal (discarded_samples=<synthetic pointer>, frame=0x7f013337d3c0, avctx=0x7f015f760000) at libavcodec/decode.c:325
#12 decode_simple_receive_frame (frame=<optimized out>, avctx=<optimized out>) at libavcodec/decode.c:520
#13 decode_receive_frame_internal (avctx=avctx@entry=0x7f015f760000, frame=<optimized out>) at libavcodec/decode.c:540
#14 0x00007f014fe11130 in avcodec_send_packet (avctx=0x7f015f760000, avpkt=0x7f014c3fe558) at libavcodec/decode.c:607
#15 0x00007f0156a3e105 in mozilla::FFmpegVideoDecoder<59>::DoDecode(mozilla::MediaRawData*, unsigned char*, int, bool*, nsTArray<RefPtr<mozilla::MediaData> >&)
(this=0x7f015f764000, aSample=0x7f011c595080, aData=0x7f012fdea000 "", aSize=78217, aGotFrame=0x7f014c3fe75f, aResults=mozilla::MediaDataDecoder::DecodedData &)
at /raid/src/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:846
#16 0x00007f0156a3a17f in mozilla::FFmpegDataDecoder<59>::DoDecode(mozilla::MediaRawData*, bool*, nsTArray<RefPtr<mozilla::MediaData> >&) (this=0x0,
this@entry=0x7f015f764000, aSample=0x7f014c3f50b0, aSample@entry=0x7f011c595080, aGotFrame=0x7f014c3fe750,
aGotFrame@entry=0x7f014c3fe75f, aResults=mozilla::MediaDataDecoder::DecodedData &) at /raid/src/dom/media/platforms/ffmpeg/FFmpegDataDecoder.cpp:193
#17 0x00007f0156a39ebe in mozilla::FFmpegDataDecoder<59>::ProcessDecode(mozilla::MediaRawData*) (this=0x7f015f764000, aSample=0x7f011c595080)
at /raid/src/dom/media/platforms/ffmpeg/FFmpegDataDecoder.cpp:147

Comment 13

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

Okay, found the problem. We need to drop non-ref frames after seek.

Comment 14

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

Attachment: Bug 1779186 [Linux] Use DMABUF log for VideoFramePool r?alwu

Comment 15

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

Attachment: Bug 1779186 [Linux] Skip non-ref frames after seek when stream is decoded by VA-API r?alwu

When stream is decoded by VA-API and position is changed we may see decoding artifacts.
MPV project uses AVDISCARD_NONREF frame skip until requested/decoded frames are synced so let's use the same approach.

Depends on D161723

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2f0cd4043f3c
[Linux] Use DMABUF log for VideoFramePool r=alwu
https://hg.mozilla.org/integration/autoland/rev/3107f2cb0ec9
[Linux] Skip non-ref frames after seek when stream is decoded by VA-API r=alwu

Comment 17

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/2f0cd4043f3c
https://hg.mozilla.org/mozilla-central/rev/3107f2cb0ec9

Comment 18

[Robert Mader [:rmader]]

Awesome, glad that you found it!

Comment 19

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

This one was reverted in Bug 1801576 as it causes regression on Intel. Tracked now in Bug 1772028.