Firefox Nightly is unable to play some video formats on Wayland with media.ffmpeg.vaapi.enabled. For example, pressing Play on https://archive.org/details/Sintel/sintel-2048-stereo.mp4 shows the following error:

This video file cannot be played.
(Error Code: 224002)

(For reference, 224002 is JWPlayer "Equivalent to the HTML5 MEDIA_ERR_DECODE mediaError." https://developer.jwplayer.com/jwplayer/docs/jw8-player-errors-reference#224002 )

Navigating directly to the media file at https://archive.org/download/Sintel/sintel-2048-stereo_512kb.mp4 shows "Video can't be played because the file is corrupt." with the following errors on the console:

Media resource https://archive.org/download/Sintel/sintel-2048-stereo_512kb.mp4 could not be decoded. 56 sintel-2048-stereo_512kb.mp4
Media resource https://archive.org/download/Sintel/sintel-2048-stereo_512kb.mp4 could not be decoded, error: Error Code: NS_ERROR_DOM_MEDIA_DECODE_ERR (0x806e0004)

Bisecting with mozregression --pref media.ffmpeg.vaapi.enabled:true -a https://archive.org/download/Sintel/sintel-2048-stereo_512kb.mp4:

Last good revision: 5e5c1c7e7db0d6e996ccbf56a9aa8e445bc099eb
First bad revision: 97fb4c742d684da863aa27a32ae9d1daa8d67928
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5e5c1c7e7db0d6e996ccbf56a9aa8e445bc099eb&tochange=97fb4c742d684da863aa27a32ae9d1daa8d67928

Which suggests it was regressed by Bug 1692881.

Thanks,
Kevin

For reference, I am using Sway 1.6 on Debian. vainfo:

vainfo: VA-API version: 1.10 (libva 2.10.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Ivybridge Mobile - 2.4.1
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Simple            :	VAEntrypointEncSlice
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileH264StereoHigh         :	VAEntrypointVLD
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc
      VAProfileJPEGBaseline           :	VAEntrypointVLD

I'm unable to reproduce the issue on X (with i3).

Set release status flags based on info from the regressing bug 1692881

Hmm interesting because my change in bug 1692881 is not related with VAAPI at all. If you disable media.ffmpeg.vaapi.enabled, could those video be played? does this issue still happen on today's Nightly? Would you mind to capture the debug log with MOZ_LOG=MediaDecoder:5,MediaFormatReader:5?
Thank you.

If you disable media.ffmpeg.vaapi.enabled, could those video be played?

That's correct. With media.ffmpeg.vaapi.enabled:false the video plays correctly. With media.ffmpeg.vaapi.enabled:true it displays "Video can't be played because the file is corrupt."

does this issue still happen on today's Nightly?

Yes. I can reproduce the issue with mozregression --pref media.ffmpeg.vaapi.enabled:true -a 'https://archive.org/download/Sintel/sintel-2048-stereo_512kb.mp4' --launch 2021-06-16 which used:

application_buildid: 20210616094608
application_changeset: 593c9e377f44615d071e2e31a726aa2db31eee27

Would you mind to capture the debug log with MOZ_LOG=MediaDecoder:5,MediaFormatReader:5?

Roger wilco.

Thank you so much. I did see the ffmpeg decoder returned an error when we kept requesting video data. I wonder if that was because we already ran out of the GPU memory or so. Could you help me again to capture the log, but this time using MOZ_LOG=MediaDecoder:5, PlatformDecoderModule:5?
Thank you.

Sure thing. Thanks for the fast follow-up!

Here's the log with MOZ_LOG=MediaDecoder:5,PlatformDecoderModule:5.

From the log in bug 1716638 comment 0, which includes the ffmpeg log, we can see the failure reason was failed on get buffer. The change in bug 1692881 will allow Firefox to store more video data than before, so maybe we queued too many video frames that hasn't been consumed so that ran out of the memory of ffmpeg that couldn't allocate more spaces for decoding new data.

I wonder if bug 1713276 can help on this issue? If we directly decode to the surface that we create, then we don't need to allocate space inside the AVcontext?

Hi, Martin,
Do you have any thought about that?
Thank you.

From the log:
[Child 235030: MediaPDecoder #4]: D/PlatformDecoderModule avcodec_send_packet error: -1094995529
41 44 4E 49
According to https://stackoverflow.com/questions/22944133/how-can-i-find-out-what-this-ffmpeg-error-code-means
it's AVERROR_INVALIDDATA.

So looks like we don't post correct data to decoder.

I'll post a patch with better logging of the AV errors.

I am seeing this with GNOME with an X session and MOZ_X11_EGL=1.

At least with 20210624093849 it works again for me.

The issue also appears to be fixed for me:

First good revision: ed0202284d7e59612f8f64f58df913a293381d7f
Last bad revision: 7c64fbd1cb953424a6c5a3178a3914d247027b86
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7c64fbd1cb953424a6c5a3178a3914d247027b86&tochange=ed0202284d7e59612f8f64f58df913a293381d7f

Looks like it was fixed by Bug 1717119. Thanks!

Yup, I can confirm that Bug 1717119 fixed my issue on Bug 1716638.

Confirmed.