1896948 - [wmfme] DRM-protected livestream shows blackframe on tvthek.orf.at

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect, P1)

Description

[[:philipp]]

hi, after bug 1881620 landed, i have issues getting livestreams from https://tvthek.orf.at/livestreams (that's the public broadcaster in austria) to play on nightly.

str (a likely precondition is a vpn with an austrian ip-address as exit point, since the content is probably geo-locked):

• make sure that tvthek.orf.at has the permission to autoplay audio and video content
• visit https://tvthek.orf.at/livestreams and scroll down a bit to the livestream section. click on one of the current livestream links for channels "1", "2" or "+" (channel "III" seems to be without drm-protection an is therefore not affected), which are marked with a red dot
• instead of the video livestream you're stuck on a static preview image of the particular broadcast

when the pref change from bug 1881620 is reverted and media.wmf.media-engine.enabled is set to 0 instead, the live content is starting to play automatically after a few moments once a page is loaded.

Comment 1

[Alastor Wu [:alwu]]

Will take a look later, thanks.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 3

[[:philipp]]

bad timing for filing the bug - they are currently revamping their site, so the URL reported originally might be unavailable soon.
the issue can be be observed now at https://on.orf.at/live?channel=orf1 or https://on.orf.at/live?channel=orf2

Comment 4

[Daniel Holbert [:dholbert]]

Given the regressing bug 1881620, this seems to be dependent on the media.wmf.media-engine.enabled pref which is currently off-by-default for non-nightly channels per:
https://searchfox.org/mozilla-central/rev/893f350260faac2ee6bf2b14c627d55eb2babfb0/modules/libpref/init/StaticPrefList.yaml#10504

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit BugBot documentation.

Comment 6

[Alastor Wu [:alwu]]

Attachment: PIP-button.png

When I tried to reproduce this issue, the main problem I found is not about autoplay, but the video playback was all black. That seems the same problem with the bug 1804134, where we failed to render the external image. I'm discussing that with gfx team to see if we can find a way to solve this issue.

philipp, could you help me verify if the problem you encounter is same as me after reverting the change on media.wmf.media-engine.enabled? Also, if you see black frames, does watching video in PiP work for you (there will be a pip button showing on right side of the video control)? Thanks!

Comment 7

[[:philipp]]

oh, actually i'm not able to reproduce the issue anymore on the site now when reverting media.wmf.media-engine.enabled back to 2 (had it off since filing the bug, so unfortunately i have no more insight into when and how it started working again). as mentioned, this streaming platform got a rework fairly recently, so there might be ongoing changes still and perhaps one of them stopped triggering this bug :-/

when i load the page now, the stream starts playing instantly also while not in pip-mode - no black frame.

close as wfm?

Comment 8

[Alastor Wu [:alwu]]

Thank for the confirmation! I will change this bug to black frame problem I mentioned above, which can only be reproduced when the device has PlayReady key system support.

Comment 9

[Alastor Wu [:alwu]]

Hello, Tim, I would like to see if you have any idea how we could disable applying complex clips on a DRM image. For the hardware drm playback, we don't want Firefox to access the data of the image, so it's not possible and unnecessary to add complex clips. :gw mentioned you might know the way to do it in the gecko side, something like not adding the image into the display list.

gw : (for a little extra context - we could add functionality to WR to forcibly disable complex clips via a primitive flag or similar, but I'm wondering if it might be simpler to not include them in the DL from Gecko for this case, which would mean no changes needed to WR

Related discussion can be seen in bug 1804134. Thanks!

Comment 10

[Timothy Nikkel (:tnikkel)]

Answered this on matrix. Feel free to ask for further info.

Comment 11

[Alastor Wu [:alwu]]

Problem

STR

1. Using Firefox Nightly on a Win10+ and the device has PlayReady support (check about:support -> Content Decryption Modules Information -> if Video Robustness is not empty for com.microsoft.playready.recommendation.XXX)
2. go to https://on.orf.at/live and click any video on the list which is available to watch

Expected
3. video is displayed correctly

Actual
3. only black frames are displayed, but if you watch video in PiP mode, it would be displayed correctly.

---

Root cause

I assumed that WR couldn't process the external image successfully due to the error [WARN webrender::renderer] Invalid ext-image. In bug 1804134, the black frame is showed due to the rounded corner is applied to the video, so we hit this condition causing the black frame issue.

But on ORF website, the root cause seems different. By applying this patch, it shows the error is caused by atomic operation.

[WARN webrender::picture] Surface promotion of prim at Box2D((120.0, 200.00003), (2187.0, 1363.0)) failed with: slice is atomic.
[WARN webrender::renderer] Invalid ext-image

Comment 12

[Alastor Wu [:alwu]]

Per Jeff's debugging, it seems backdrop-filter: blur(2px) on .b-needle::after causing this issue.

Comment 13

[Jeff Muizelaar [:jrmuizel]]

I suspect our backdrop-filter code is causing us to think we need to filter the video content while Chrome/Edge does not try to do this.

Comment 14

[Alastor Wu [:alwu]]

Do you know who would be the right person to check the backdrop-filter code? So it sounds like the video content shouldn't be filtered?

Comment 15

[Jeff Muizelaar [:jrmuizel]]

Glenn.

Comment 16

[Glenn Watson [:gw]]

Yes, most likely cause is that the backdrop-filter implementation makes us not allow promoting videos here. The current implementation marks an entire backdrop-root as a container that is treated atomically, when a backdrop-filter is encountered. This occurs during scene building when we are slicing up the display list, so we have less information available such as which tiles the filter and/or video affects. Allowing videos to be promoted that are part of a backdrop-root is possible, but will require some thought on how best to achieve it, and will not be a simple / small change.

Comment 17

[Alastor Wu [:alwu]]

I filed bug 1901334 for addressing the real issue for different cases which could all cause the surface promotion fail, and I will do a temporary workaround in this bug.

Comment 18

[Alastor Wu [:alwu]]

Attachment: Bug 1896948 - restrict MFCDM support based on origin.

We wanted to have a temporary workaround to explicitly allow/block
domains to use MFCDM due to the bug 1901334. As this is only a
workaround, we'd like to do it in a simplest way in order to save our
resource.

Our strategy is to keep Nightly unfiltered so that we could discover
more websites affected by the CSS problem. On other channels, we would
currently only allow Netflix to use MFCDM as we have been testing
with them and know that issue won't affect them.

We will first try to use the allow list first to ensure the MFCDM
playback quality, and gradually switch to the block list to enable the
MFCDM ability to more websites.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f34a76aaa3c6
restrict MFCDM support based on origin. r=media-playback-reviewers,padenot

Comment 20

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/f34a76aaa3c6

Comment 21

[Alastor Wu [:alwu]]

Hello, FYI now you can fix this issue by setting media.eme.mfcdm.origin-filter.enabled to 2 and turn media.wmf.media-engine.enabled back to normal, which would disable the MFCDM usage on on.orf.at. We will have a better solution on bug 1901334 in order to solve this kind of issue on every websites. Thanks!

Comment 22

[[:philipp]]

thank you for the follow-up and for getting the issue fixed!