user-images.githubusercontent.com - "No video with supported format and MIME type found" error message when accessing the video

[JakeQZ]

URL: https://user-images.githubusercontent.com/15205088/175407710-39c2f6dc-2643-450f-b64b-ed6adad60feb.mp4

Browser / Version: Firefox 101.0 Operating System: Windows 10 Tested Another Browser: Yes Chrome

Problem type: Video or audio doesn't play Description: The video or audio does not play Steps to Reproduce: Navigate here:

https://user-images.githubusercontent.com/15205088/175407710-39c2f6dc-2643-450f-b64b-ed6adad60feb.mp4

View the screenshot

Browser Configuration

• None

From webcompat.com with ❤️

[JakeQZ]

Moreover, if I right-click on the non-playing video in this report, I have the option 'Open Video in New Tab', but clicking it does absolutely nothing.

[JakeQZ]

I've cleared cache and offline data, to no avail.

[JakeQZ]

Same problem in 'Troubleshoot Mode'.

[JakeQZ]

Same problem with Firefox Nightly 102.0a1 (2022-05-19) (64-bit) which has a pretty clean profile.

[JakeQZ]

And Nightly 103.0a1 (2022-06-12) (64-bit) and 103.0a1 (2022-06-23) (64-bit).

[softvision-raul-bucata]

@JakeQZ We appreciate your report. I was able to reproduce the issue. The page returns an error message:

Tested with:

Browser / Version: Firefox Release 101.0.1 (64-bit)/ Firefox Nightly 103.0a1 (2022-06-22) (64-bit) /Chrome Version Version 103/0/5060.53 (Official Build) (64-bit) Operating System: Windows 10 PRO x64

Notes:

1. Reproducible regardless of the status of ETP.
2. Reproducible on the latest build of Firefox Nightly and Release.
3. Works as expected using Chrome:

Moving this to NeedsDiagnosis for further investigations.

[qa_25/2022]

[JakeQZ]

Further information:

• The video was recorded using 'Game Bar' on Windows 10;
• In the HTTP response header, the MIME type is video/mp4 which I think is correct.

[denschub]

This looks like a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1755936, but @ksy36 wants to make sure.

[JakeQZ]

https://bugzilla.mozilla.org/show_bug.cgi?id=1755936

That was logged against MacOS, and a comment there says that video plays on Windows. I can also confirm that video plays for me.

It's related, but not a duplicate.

[Zaggy1024]

It looks like this is an issue with how Firefox handles live-recorded videos when they need to be buffered from network, I've filed it on Bugzilla:

https://bugzilla.mozilla.org/show_bug.cgi?id=1780905

[JakeQZ]

It looks like this is an issue with how Firefox handles live-recorded videos when they need to be buffered from network.

I don't think so. And what do you mean by "live-recorded videos"? Aren't all videos recorderd live at the time of the shooting?

It's most likely due to a specific encoding that Firefox fails with. MP4 is a container format. The video and audio within can be encoded with any of a variety of different algorithms, such as H.264 and AAC, most commonly, but many others are available.

I haven't checked what the encoding is on the videos that fail, but think it's most likely that an 'unsupported' encoding is causing the problem.

And obviously all encoding formats should be supported, ideally via the OS so that onboard hardware decoding can be used whenever possible.

[Zaggy1024]

I don't think so. And what do you mean by "live-recorded videos"? Aren't all videos recorderd live at the time of the shooting?

Most videos on the web are rendered or transcoded from source videos. When uploading a game recording to YouTube it will be transcoded into an MP4/ISOBMFF format that is suited more for live playback.

After debugging the issue, I determined that the linked video has all metadata appended to the end of the file after all encoding of input frames has completed, so the browser has to wait for the whole file to download before it can begin playing. Currently, Firefox isn't doing that properly, so it will instead think that the metadata isn't present and consider the file to be corrupted.

It's most likely due to a specific encoding that Firefox fails with. MP4 is a container format. The video and audio within can be encoded with any of a variety of different algorithms, such as H.264 and AAC, most commonly, but many others are available.

I haven't checked what the encoding is on the videos that fail, but think it's most likely that an 'unsupported' encoding is causing the problem.

The video encoding is unrelated to the issue, as the file will play correctly from my hard drive. Over the internet, the issue is actually an intermittent depending on how quickly the file can be loaded, so if the file was fully cached to disk instead of failing playback early, it would play correctly every time.

[JakeQZ]

Most videos on the web are rendered or transcoded from source videos. When uploading a game recording to YouTube it will be transcoded into an MP4/ISOBMFF format that is suited more for live playback.

Yes, YouTube will re-encode videos uploaded to it into the 'standard' YouTube format. Just like Istagaram will re-encode images and reduce them to the size of a postage stamp.

live playback

I still don't get what you mean by this, though it is probably irrelevant anyway.

After debugging the issue, I determined that the linked video has all metadata appended to the end of the file after all encoding of input frames has completed, so the browser has to wait for the whole file to download before it can begin playing.

Makes sense. Seems like perhaps FF could do a range request to get the metadata at the end of the file if it's not found at the start, and it's unable to otherwise play them as a stream. Though it should be able to play the stream without needing the metadata.

[Zaggy1024]

Yes, YouTube will re-encode videos uploaded to it into the 'standard' YouTube format. Just like Istagaram will re-encode images and reduce them to the size of a postage stamp.

live playback

I still don't get what you mean by this, though it is probably irrelevant anyway.

That phrasing was my mistake, I meant that it makes it more suited to streamed playback. The MP4 format allows for the decoder initialization metadata to be placed after the video data, which isn't ideal for streaming, since the browser can't immediately create a decoder after the video begins buffering. I haven't worked on the AVC side of things much so I'm not sure whether the bitstream specifies everything that is needed for decoder initialization separately from the container's metadata, but I believe this type of issue came up before, so I would like to think it's been considered.

[ksy36]

Thanks for investigating this @JakeQZ @Zaggy1024

Looks like the fix for https://bugzilla.mozilla.org/show_bug.cgi?id=1781063 (and 1780905) has landed in Nightly and going to be uplifted to beta and possibly release.

I've verified that https://user-images.githubusercontent.com/15205088/175407710-39c2f6dc-2643-450f-b64b-ed6adad60feb.mp4 plays in recent Nightly (106) on Windows and on MacOS, so I think we can close this?

[XeonG]

This is still a an issue with Firefox.127 nightly.. can open the video in another tab and it will play fine.. yet inline on the page you get that MIME error