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.