WebRTC use of H264 in a fresh profile does not trigger OpenH264 install
Categories
(Core :: Audio/Video: GMP, defect, P3)
Tracking
()
People
(Reporter: jimm, Unassigned)
References
(Blocks 3 open bugs)
Details
In a fresh profile use of H264 encoding through WebRTC does not trigger OpenH264 install. The browser waits for idle before attempting the download. Attempted use should trigger download and install.
See bug 1766037 for details.
|
Reporter | |
Updated•2 years ago
|
|
|
Reporter | |
Comment 1•2 years ago
|
||
Bryce, any idea why we don't trigger a download in this case like we do for Widevine?
(In reply to Jim Mathies [:jimm] from comment #1)
Bryce, any idea why we don't trigger a download in this case like we do for Widevine?
I am not certain, as some of this is from before my time, but my guess would be that it's a combination of
- The WebRTC case has a fallback path in that it can use other codecs. So depending on the usage, not having h264 available is not a hard failure.
- We haven't implemented it yet (for whatever reason, maybe just engineering cycles).
I am not aware of a limitation that means we cannot. With Widevine we trigger based off certain calls to EME APIs on the basis we will need Widevine installed to service those calls. I don't see why we couldn't do the same for this case. I imagine we could restrict it to only when h264 is on the cards, so we don't end up blocking calls where we'd be using VPx.
|
|
Reporter | |
Comment 3•2 years ago
|
||
(In reply to Bryce Seager van Dyk [:bryce] (he/him) from comment #2)
(In reply to Jim Mathies [:jimm] from comment #1)
Bryce, any idea why we don't trigger a download in this case like we do for Widevine?
I am not certain, as some of this is from before my time, but my guess would be that it's a combination of
- The WebRTC case has a fallback path in that it can use other codecs. So depending on the usage, not having h264 available is not a hard failure.
- We haven't implemented it yet (for whatever reason, maybe just engineering cycles).
I am not aware of a limitation that means we cannot. With Widevine we trigger based off certain calls to EME APIs on the basis we will need Widevine installed to service those calls. I don't see why we couldn't do the same for this case. I imagine we could restrict it to only when h264 is on the cards, so we don't end up blocking calls where we'd be using VPx.
Can you point me generally to where we trigger the widevine install in eme code?
We trigger the process during handling of the requestMediaKeySystemAccess call.
- Within content, this code triggers the Widevine install if the access request is for Widevine and Widevine is not already installed.
- Specifically, these lines postpone the current request for access, and notify observers that will kick off installation of the CDM.
- The EncryptedMediaChild actor observes the message that is created above. It does a small amount of parsing, and passes the data across to the parent actor.
- The parent actor will do yet another notification for the CDM not installed case, continuing the installation process.
- The GMPProvider will observe the message from our parent actor and will call
checkForUpdates, which is the code that actually does the installing.
|
||
Comment 5•2 years ago
|
||
Is it true that both Widevine and OpenH264 get installed when checkForUpdates is called regardless of what caused checkForUpdates to be called?
|
|
||
Comment 6•2 years ago
|
||
We had a small discussion about the best place to trigger and wait for checkForUpdates and the rough answer is PeerConnection.createOffer(). Ideally, though we'd only wait if we knew H264 was going to be required but we don't really have a good way of doing that.
We'd like to better understand how often and why users don't have OpenH264 before pushing too hard here.
|
||
Comment 7•2 years ago
•
|
||
It might still be a good idea to trigger download on WebRTC use, even if we don't wait for it.
It would let sites that require H264 detect its absence in the offer, and wait a short amount of time (less than 20 seconds) before trying again.
|
|
||
Comment 8•2 years ago
|
||
Correction from looking at code: it seems checkForUpdates is only called in response to "EMEVideo:CDMMissing", or 10 seconds after an EME prefs change, and that the function of interest is one level down: simpleCheckAndInstall, which is also called from _scheduleBestEffortUserIdleTasks.
simpleCheckAndInstall itself appears to check for EME+H264 at most once every 24 hours (or twice on days Firefox is updated), so checkForUpdates may be over-promising on its responsiveness.
I'm struck by the decision logic here seeming designed for EME, with H264 as a tag-along.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #5)
Is it true that both Widevine and OpenH264 get installed when
checkForUpdatesis called regardless of what causedcheckForUpdatesto be called?
Short answer, yes.
Long answer
- In practice, yes. You can see this if you create a fresh profile and visit a page with EME, it will trigger both Widevine and OpenH264 install.
- Code wise, mostly yes, but it's messy.
Different layers of the code attempt to abstract over specific GMPs (Widevine, OpenH264), while others do not. So some layers do care about what the triggering event is.
E.g. GMPProviders have knowledge of what plugin they're supposed to be providing. However, as you point out, once a GMPProvider starts calling things like checkForUpdates the logic can become non-specific to the plugin that provider cares about. For checkForUpdates the logic mostly becomes non-specific because IIRC simpleCheckAndInstall just tries to update all GMPs (with some pref checking internally so it doesn't update them when they're disabled). However, there is a small amount of GMPProvider specific logic prior to that point with things like the appDisabled.
So you can trigger the OpenH264 install by notifying that the CDM is missing at different levels. E.g. EMEVideo:CDMMissing will do it. Obviously that's a yucky thing to do, but could be done as a quick bandaid. I think both the EME and non-EME path could use some love and tending to here so that they're clearer and easier to interact with for things like this.
|
||
Comment 10•2 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #1)
Bryce, any idea why we don't trigger a download in this case like we do for Widevine?
The answer is that it was never designed to it this way. OpenH264 for WebRTC usage is suppose to get downloaded automatically by Firefox in the background, when it is idle. So that it is ready to use when you try to do WebRTC based video call. So basically when you open in a fresh profile you would need to let Firefox sit for several minutes to wait for the download to start.
Note: I have not tested if this still works as described above.
The reason this doesn't get downloaded when one tries to enter a call is that the assumption back then was: entering a call is way more timing sensitive than waiting for your movie to start.
There is no way for the WebRTC libraries to explain to the WebRTC page you are own why you have to wait potentially for several seconds for the download to finish. So users will end up with a really strange user experience. And the sites customer support will have a hard time to figure out what the customer is complaining about.
Description
•