1908296 - lnk.lt/naujienos - Video is not starting at 1080p

Status: NEW

(Web Compatibility :: Site Reports, defect, P2)

Description

[railioaie]

Environment:
Operating System: Windows 10
Firefox version: Firefox Nightly 130.0a1 / Firefox Release 128

Preconditions:
Clean profile

Steps to reproduce:

1. Navigate on https://lnk.lt/naujienos
2. Go to any video.
3. Wait for the ads to end.
4. Change the video quality to 1080p.
5. Refresh the page.
6. Wait for the ads to end.
7. Play the video

Expected Behavior:
The video starts correctly

Actual Behavior:
The video is not starting

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in Firefox Nightly, Firefox Release
• Does not reproduce in Chrome

Comment 1

[railioaie]

Attachment: image_2024_07_17T07_07_34_858Z.png

Comment 2

[Jeff Muizelaar [:jrmuizel]]

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

Comment 3

[az [:az]]

The video Jeff linked works for me on Firefox on Linux / Windows, though it was stuck loading with a black bar when I had an adblocker enabled. I was able to repro the 1080p hang on Linux / Windows / Android and ran into the following errors:

JW Player Warning 330000. For more information see https://developer.jwplayer.com/jw-player/docs/developer-guide/api/errors-reference#330000
JW Player Warning 333011. For more information see https://developer.jwplayer.com/jw-player/docs/developer-guide/api/errors-reference#333011
JW Player Warning 334001. For more information see https://developer.jwplayer.com/jw-player/docs/developer-guide/api/errors-reference#334001

The second entry isn't listed on the error page, but the first and third entries correspond to "An unknown error occurred handling HLS media." and "HLS playback has stalled because not enough media is buffered."

Changing media.hls.enabled to true doesn't seem to make a difference, and I didn't see anything output by the HLS logger. None of the HLS errors show up on Chrome, so it looks like it might be an HLS issue on our side. :jolin, would you have any ideas here?

Comment 4

[Jim Mathies [:jimm]]

Comment 5

[Jim Mathies [:jimm]]

This one is tough to debug. For the 1080 case, I don't see any activity related to media happening at all when things stall out.

https://share.firefox.dev/4jqOGdg

The 720 side of things I see normal media activity happening.

https://share.firefox.dev/4gc9RNt

I don't think this is a media playback issue, seems more like some sort of a site issue in getting the media queued up for playback in Firefox.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

Moving to diagnosis-team:DOM because it seems like the issue might have more to do with getting the video started.

Comment 7

[Sean Feng [:sefeng211]]

I noticed that the site hit an error for 1080p.

The site has the following code in https://ssl.p.jwpcdn.com/player/v/8.34.1/jwplayer.core.controls.js

_playAttempt(t, e) {
          const {
            item: i,
            mediaModel: n,
            model: s,
            provider: a
          }
          = this,
          r = a ? a.video : null;
          return this.trigger(o.cq, {
            item: i,
            playReason: e
          }),
          (r ? r.paused : s.get(o.uc) !== o.r0) ||
          s.set(o.uc, o.Kb),
          t.then(
            (
              () => {
                n.get('setup') &&
                (
                  n.set('started', !0),
                  n === s.mediaModel &&
                  (
                    t => {
                      const e = t.get('mediaState');
                      t.trigger('change:mediaState', t, e, e)
                    }
                  ) (n)
                )
              }
            )
          ).catch(
            (
              t => {
                if (this.item && n === s.mediaModel) {
                  s.set('playRejected', !0);
                  if (null == r ? void 0 : r.paused) {
                    if (r.src === location.href) return this._loadAndPlay(i, a);
                    n.set('mediaState', o._5)
                  }
                  const l = Object.assign(new b.rG(null, (0, b.nm) (t), t), {
                    error: t,
                    item: i,
                    playReason: e
                  });
                  throw delete l.key,
                  this.trigger(o.Je, l),
                  t
                }
              }
            )
          )
        }

That catch block is only hit with 1080p. The error was this media error. So this still looks like an media issue.

Pushing this back to media :)

Comment 8

[Jim Mathies [:jimm]]

That catch block is only hit with 1080p. The error was this media error. So this still looks like an media issue.

Pushing this back to media :)

I see this when clicking pause on a video feed that hasn't played correctly, so I'm not sure this is related.

The site uses hlsjs which appears to work fine on lower resolutions. Not sure yet what's going on with 1080.

Comment 9

[Alastor Wu [:alwu]]

This is a H64 incompatibilities problem, like bug 1931436. The 1080p uses avc1.7a0028, which is not supported by the WMF video decoder. 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, which causes returning a null SourceBuffer 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.

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.

Comment 10

[Alastor Wu [:alwu]]

Attachment: Error stack

Comment 11

[Jeff Muizelaar [:jrmuizel]]

Alwu, can you file a webcompat knowledge base bug that describes the codec profile limitations of WMF? That way we can track other sites that run into the same problem.

This bug should stay open as long as the web compat issue exists.

Comment 12

[Alastor Wu [:alwu]]

Filed bug 1960746.

Comment 13

[AutoWebCompat]

Attachment: Reproduction script generated by autowebcompat bot

On lnk.lt news videos, once 1080p is selected and the page is reloaded, the JW Player/hls.js video never starts in Firefox: after the ads the player stays paused/buffering at currentTime 0 with readyState 1 and logs "JW Player Warning 330000". The 1080p rendition is H.264 High 4:2:2, which Firefox reports as unsupported for MSE, so no source buffer is created. Chrome plays the identical 1080p stream normally. Lower qualities (720p/576p) play fine in Firefox.

Comment 14

[AutoWebCompat]

Root cause analysis generated by autowebcompat bot:

Firefox MSE rejects the H.264 codec string avc1.7a0028 (profile_idc 122 = High 4:2:2 profile, level 4.0); Chrome accepts it. lnk.lt plays its news video as HLS through JW Player and hls.js, feeding the media through MediaSource (the video element gets a blob: src). The master playlist served from vod.lnk.lt has no CODECS attribute on its EXT-X-STREAM-INF lines, so hls.js must derive the codec string itself from the SPS NAL of the first demuxed transport-stream segment of the chosen level, in the RFC 6381 section 3.3 form avc1.PPCCLL where PP is profile_idc. The 576p and 720p renditions have SPS 67 64 00 1f, giving avc1.64001f (High profile), but the 1080p rendition has SPS 67 7a 00 28, giving avc1.7a0028, even though the picture itself is ordinary 4:2:0 content. hls.js then passes that derived type to MediaSource.isTypeSupported and MediaSource.addSourceBuffer. Firefox's codec gate admits only H.264 profile_idc 66, 77 and 100 (Baseline, Main, High) and refuses the 4:2:2 and 4:4:4 profiles, so isTypeSupported returns false and addSourceBuffer throws NotSupportedError, whereas Chrome returns true and creates the buffer. Relevant spec text: the MSE definitions of MediaSource.isTypeSupported and MediaSource.addSourceBuffer (w3c.github.io media-source, anchors dom-mediasource-istypesupported and dom-mediasource-addsourcebuffer), and RFC 6381 section 3.3 for the avc1.PPCCLL codec string. The set of supported codecs is UA-defined, so neither browser violates the spec, but this divergence is what breaks the site. JW Player persists the quality choice in localStorage (keys jwplayer.qualityLabel and jwplayer.bitrateSelection), so after the reload in the steps to reproduce the player starts directly on the remembered 1080p level; no video SourceBuffer is ever attached, the video element stays at readyState 1 with currentTime 0 and videoWidth 0, the player sits in buffering, and JW Player logs Warning 330000 repeatedly. Selecting 720p or 576p works because those are plain High profile. This is not UA sniffing: both browsers receive byte-identical manifests and segments.

Evidence:

Feature detection on lnk.lt, same page in both browsers. Firefox 156.0: MediaSource.isTypeSupported for video/mp4 codecs avc1.7a0028 is false, while avc1.64001f, avc1.640028 and avc1.42E01E are all true; canPlayType for avc1.7a0028 returns the empty string. Chrome 152: avc1.7a0028 is true, canPlayType maybe.

Content fetched from the page, identical in both browsers. The master playlist has no CODECS attribute at all, only BANDWIDTH 1192000 NAME 576p RESOLUTION 1024x576, BANDWIDTH 2192000 NAME 720p, BANDWIDTH 3692000 NAME 1080p RESOLUTION 1920x1080. First SPS NAL header bytes of the first segment per level: 576p and 720p are 67 64 00 1f, i.e. avc1.64001f; 1080p is 67 7a 00 28, i.e. avc1.7a0028 with profile_idc 122 and level 4.0.

Real site in Firefox: set localStorage jwplayer.qualityLabel to 1080p and jwplayer.bitrateSelection to 3692000 on lnk.lt, loaded lnk.lt/zinios, sat through the pre-roll ad pod and kept calling play. 41 samples over about 80 seconds were all identical: quality levels Auto, 1080p, 720p, 576p with the current label 1080p, state buffering, currentTime 0, readyState 1, videoWidth 0, videoHeight 0. Playback never starts, and the console repeats JW Player Warning 330000, six of them within three seconds. The pre-roll ads themselves, which are plain non-MSE mp4 files from serveris.lnk.lt, played fine at 1920x1080 with readyState 4, so H.264 decoding and the resolution are not the problem; it is specifically the MSE path that dies. The reproduction script exits 1 in Firefox and 0 in Chrome.

Reduced testcase loaded from the local file in both browsers. Firefox: avc1.64001f true and SourceBuffer created, avc1.640028 true and created, avc1.7a0028 false with addSourceBuffer throwing NotSupportedError MediaSource.addSourceBuffer Can't play type, and avc1.f4000d (4:4:4) likewise rejected. Chrome: all four rows true and SourceBuffer created. The page prints the matching verdict line in each browser.

Comment 15

[AutoWebCompat]

Attachment: Reduced testcase generated by autowebcompat bot