This is a H64 incompatibilities problem, like bug 1931436. The 1080p uses `avc1.7a0028`, which is not supported by [the WMF video decoder](https://learn.microsoft.com/en-us/windows/win32/medfound/h-264-video-decoder#format-constraints). The 720p uses `avc1.64001f`, which is supported so that is why 720p doesn't have a problem. As `avc1.7a0028` is a `High 4:2:2 Profile`, it would first be blocked by [our H264 whitelist check](https://searchfox.org/mozilla-central/rev/6cc05c6620814bf3eb05278ccf3b1f49690b7740/dom/media/mp4/MP4Decoder.cpp#25-49), which causes returning [a null SourceBuffer](https://searchfox.org/mozilla-central/rev/6cc05c6620814bf3eb05278ccf3b1f49690b7740/dom/media/mediasource/MediaSource.cpp#316-318) when the website is trying to create a source buffer. This behavior will trigger the errors showing in the console, like what :az saw in the [comment 3](https://bugzilla.mozilla.org/show_bug.cgi?id=1908296#c3). I tried temporarily allowing source buffer creation and fed those video samples to the WMF video decoder, but it didn’t work—no video output was returned. > This video doesn't play at all for me in Firefox: https://lnk.lt/straipsniai/lietuvoje/kaunas-nori-tramvajaus-kodel-kaunieciams-prireike-naujos-viesojo-transporto-rusies/295090 but does in Chrome Since Chrome uses the D3D11 API directly for H.264 decoding, it offers broader H.264 support compared to the WMF decoder. Unfortunately, that’s not something we can implement at this time. --- Therefore, for this issue, my suggestion would be to either mark it as WONTFIX (due to platform decoder limitations), or reach out to the website to see if they’re open to using a different profile for 1080p content.
Bug 1908296 Comment 9 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
This is a H64 incompatibilities problem, like bug 1931436. The 1080p uses `avc1.7a0028`, which is not supported by [the WMF video decoder](https://learn.microsoft.com/en-us/windows/win32/medfound/h-264-video-decoder#format-constraints). The 720p uses `avc1.64001f`, which is supported so that is why 720p doesn't have a problem. As `avc1.7a0028` is a `High 4:2:2 Profile`, it would first be blocked by [our H264 whitelist check](https://searchfox.org/mozilla-central/rev/6cc05c6620814bf3eb05278ccf3b1f49690b7740/dom/media/mp4/MP4Decoder.cpp#25-49), which causes returning [a null SourceBuffer](https://searchfox.org/mozilla-central/rev/6cc05c6620814bf3eb05278ccf3b1f49690b7740/dom/media/mediasource/MediaSource.cpp#316-318) when the website is trying to create a source buffer. This behavior will trigger the errors showing in the console, like what :az saw in the [comment 3](https://bugzilla.mozilla.org/show_bug.cgi?id=1908296#c3). I tried temporarily allowing source buffer creation and fed those video samples to the WMF video decoder, but it didn’t work—no video output was returned. > This video doesn't play at all for me in Firefox: https://lnk.lt/straipsniai/lietuvoje/kaunas-nori-tramvajaus-kodel-kaunieciams-prireike-naujos-viesojo-transporto-rusies/295090 but does in Chrome Since Chrome uses the D3D11 API directly for H.264 decoding, it offers broader H.264 support compared to the WMF decoder. Unfortunately, that’s not something we can implement at this time. --- Therefore, for this issue, my suggestion would be to either mark it as WONTFIX (due to platform decoder limitations), or reach out to the website to see if they’re open to using a different profile/codec for 1080p content.