1384867 - widevineCdm mis-caught HDCP restriction on initial run

Status: UNCONFIRMED

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

Description

[ssham]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36

Steps to reproduce:

1) Connecting "Lenovo Thinkpad x260" computer onto "Thinkpad Pro Dock Type 40A1" dock
2) Connecting Dock to an external HDCP-compliant display with a HDCP-compliant cable
3) Startup Windows 7
4) Ensure no DRM video is playing in the background (on Chrome) & no plugin-container.exe exists on TaskManager process list
5) Open Firefox (54.0.1 - 32bit) and goto https://bcove.video/2vL4tM1


Actual results:

A) ShakaPlayer throws RESTRICTIONS_CANNOT_BE_MET on console and playback is failed, and reload the tab doesn't help.

B) But if you keep this tab as-is, and open another Firefox tab, and goto https://bcove.video/2vL4tM1 again, playback is successful.

C) After (B), if you terminate the process plugin-container.exe from TaskManager, and reload the tab, playback is failed with result (A).

D) If you close Firefox, goto https://bcove.video/2vL4tM1 on Chrome, and leave it as-is, then open Firefox and goto https://bcove.video/2vL4tM1, playback is successful; This showed that Chrome does not experience the same issue as in Firefox.

E) Playback is successful on Firefox on any scenario when the Computer is disconnected from the Dock; This showed the issue is with HDCP restriction detection.


Expected results:

Playback should be successful.
HDCP restriction handler should not behave differently on whether DRM is initialized on background or not.

Comment 1

[ssham]

>>>> Modification
2) Connecting Dock to an external HDCP-compliant display with a DisplayPort cable (Dock only has DisplayPort hub, no HDMI)

Also tested with current version, 55.0.2 (32bit)
Issue persists.

Comment 2

[Bulk Bug Changes for mreavy's org]

Mass change P1->P2 to align with new Mozilla triage process

Comment 3

[Blake Wu [:bwu][:blakewu]]

Hi ssham,
Does this bug still exist?

Comment 4

[ssham]

(In reply to Blake Wu [:bwu][:blakewu] from comment #3)
> Hi ssham,
> Does this bug still exist?

Hi,
yes it is still happening.

But to illustrate more, the display port is not directly connecting with the PC device.
[Thinkpad] <- Dock port -> [Dock] <- Display port -> [Monitor]

However, this doesn't explain why duplicated tabs will make the playback successful.

Comment 5

[Blake Wu [:bwu][:blakewu]]

(In reply to ssham from comment #4)
> (In reply to Blake Wu [:bwu][:blakewu] from comment #3)
> > Hi ssham,
> > Does this bug still exist?
> 
> Hi,
> yes it is still happening.
> 
> But to illustrate more, the display port is not directly connecting with the
> PC device.
> [Thinkpad] <- Dock port -> [Dock] <- Display port -> [Monitor]
> 
> However, this doesn't explain why duplicated tabs will make the playback
> successful.
Thanks for your feedback.

Comment 6

[Blake Wu [:bwu][:blakewu]]

Forward this bug to our expert!

Comment 7

[James Cheng[:JamesCheng]]

From the description, I felt confused.

Hello ssham,

The user agent string indicates that you are using Mac but you said you are using Lenovo?

Does that mean you install Mac on a Lenovo computer?

Maybe the driver on Mac is not compatible with Lenovo... 

Could you please provide us some information I list below, thanks.

1. Does the issue only happen on this machine or every machine with Firefox?
2. If you switch to Windows(OS), can it be reproduced?

Thank you :)

Hi cpearce,

Please see the comment 0, do you have any idea what happened?

The (B) is weird because we didn't do anything with HDCP but when opening the second tab, the issue cannot be reproduced.

By(D) with Chrome running, Firefox can play well, that means Chrome might configure something to the OS...

Do you think it is responsible for a browser to communicate with the video card (HDCP stuff)?

I think of ``EnableOutputProtection``[1] but we didn't implement it.

I searched in Chromium [2], there is no caller for this API and I guess it is just an optional API that we don't need to enable it by our browser.

Do you know more detail about this API? What is the use case for this API? 

Thanks.


Keep me ni since I have no idea how to do now.

[1]
https://searchfox.org/mozilla-central/rev/f6f1731b1b7fec332f86b55fa40e2c9ae67ac39b/dom/media/gmp/ChromiumCDMChild.h#69

[2]
https://cs.chromium.org/chromium/src/media/cdm/cdm_adapter.cc?l=1048&rcl=c92b2329448dd4b2a1edfd451da707cebbb7c48c

Comment 8

[ssham]

(In reply to James Cheng[:JamesCheng] from comment #7)
Hi,

> Does that mean you install Mac on a Lenovo computer?
No, I'm sorry, the problematic computer is not my working computer.
The issue is happening on Lenovo, and I'm using Mac to report the issue. 
Bugzilla was attaching my UA without my input, which is not related to this issue.

> 1. Does the issue only happen on this machine or every machine with Firefox?
As far as we know, only on that model of machine & device setup (Lenovo + Dock), which is not common on the market.

> 2. If you switch to Windows(OS), can it be reproduced?
It is happening on Windows 7 as mentioned on step to reproduce.
We don't have another OS to switch at the moment sorry.

I'm sorry for the confusion caused.

Comment 9

[Tomas Bucher]

The issue, it seems, does require a docking station. I am experiencing similar behavior with a Dell laptop Latitude E5270 when in the dock and connected to the monitor via DisplayPort. If connected directly via HDMI outside of the dock, the issue does not manifest. The issue is reproducible both in Windows 7 and Windows 10 and I do not think that the cables or the various digital interfaces themselves are the culprit.

1) I believe that the HDCP handshake simply takes longer to finish when using the dock. Shaka throws the error right after EME Key status change event returns "output-restricted" because the HDCP handshake has not finished yet or possibly has failed the first time around. Once it successfully completes by itself a second later, however, the Key status change event switches to "usable" and in my case the stream becomes playable even though Shaka still displays the error.

2) One browser is affecting another. The issue is present for me also on Chrome and if I do it the other way around and leave Firefox with the player tab open, Chrome then works right away without the error message. It appears that once HDCP session is initiated, GPU driver is then using the dock as HDCP-compliant device and any other client attempting to use HDCP works immediately without the need of doing the handshake first.

In my opinion, the browsers are not at fault here, nor is Shaka, although it might try to query the Key status change event from EME a couple more times before throwing the error. I think that the underlying issue is either in the docking station hardware or the GPU driver that it first causes the "output-restricted" status which is present during initialization and which is propagated by the browser to the player.



Ssham, can you please confirm or deny whether the stream is playable for you once you close the RESTRICTIONS_CANNOT_BE_MET error overlay?

Comment 10

[ssham]

(In reply to Tomas Bucher from comment #9)
> The issue, it seems, does require a docking station. I am experiencing
> similar behavior with a Dell laptop Latitude E5270 when in the dock and
> connected to the monitor via DisplayPort. If connected directly via HDMI
> outside of the dock, the issue does not manifest. The issue is reproducible
> both in Windows 7 and Windows 10 and I do not think that the cables or the
> various digital interfaces themselves are the culprit.
> 
> 1) I believe that the HDCP handshake simply takes longer to finish when
> using the dock. Shaka throws the error right after EME Key status change
> event returns "output-restricted" because the HDCP handshake has not
> finished yet or possibly has failed the first time around. Once it
> successfully completes by itself a second later, however, the Key status
> change event switches to "usable" and in my case the stream becomes playable
> even though Shaka still displays the error.
> 
> 2) One browser is affecting another. The issue is present for me also on
> Chrome and if I do it the other way around and leave Firefox with the player
> tab open, Chrome then works right away without the error message. It appears
> that once HDCP session is initiated, GPU driver is then using the dock as
> HDCP-compliant device and any other client attempting to use HDCP works
> immediately without the need of doing the handshake first.
> 
> In my opinion, the browsers are not at fault here, nor is Shaka, although it
> might try to query the Key status change event from EME a couple more times
> before throwing the error. I think that the underlying issue is either in
> the docking station hardware or the GPU driver that it first causes the
> "output-restricted" status which is present during initialization and which
> is propagated by the browser to the player.
> 
> 
> 
> Ssham, can you please confirm or deny whether the stream is playable for you
> once you close the RESTRICTIONS_CANNOT_BE_MET error overlay?

Hi Tomas,

Thanks for your input. I don't have the device on hand, but sure will test it asap.

Regarding 2), the issue doesn't happen on Chrome in my case.
I'm thinking whether Google has some secret trick on WidevineCDM :/

Comment 11

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to James Cheng[:JamesCheng] from comment #7)
> Hi cpearce,
> 
> Please see the comment 0, do you have any idea what happened?

I'd guess that Tomas Bucher's theory is close to the mark; I suspect that the HDCP handshake on the dock is slow or unreliable.


> By(D) with Chrome running, Firefox can play well, that means Chrome might
> configure something to the OS...

Tomas said he had the same problems with Chrome.


> Do you think it is responsible for a browser to communicate with the video
> card (HDCP stuff)?

We only ensure that HDCP stuff is usable by the CDM inside the sandbox. We don't do any more facilitation other than that.

> 
> I think of ``EnableOutputProtection``[1] but we didn't implement it.
> 
> I searched in Chromium [2], there is no caller for this API and I guess it
> is just an optional API that we don't need to enable it by our browser.
> 
> Do you know more detail about this API? What is the use case for this API? 

I wasn't aware of that API. Is it ChromeOS only?

Given we suspect this is a hardware issue, there may not be much we can do here. It also isn't likely to be a common use case.

Comment 12

[James Cheng[:JamesCheng]]

It seems EnableOutputProtection is an interface that only being implemented by ChromeOS

https://cs.chromium.org/chromium/src/chrome/browser/media/output_protection_proxy.cc?l=49&rcl=b3eed2f98566836a1b2a25be5aeb132ece2a8655

As cpearce said, there may not be much we can do here.

Comment 13

[James Cheng[:JamesCheng]]

I think the issue only happened on certain hardware combination,

I set it to P3.

Please feel free to adjust the priority if you think it should be P2.