New issue
Advanced search Search tips

Issue 599588 link

Starred by 2 users
Status: Fixed
Owner:
xhw...@chromium.org
Closed: Jan 2018
Cc:
ddorwin@chromium.org
jrumm...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Potential mismatch between key system info and the CDM created

Project Member Reported by xhw...@chromium.org, Mar 31 2016 
This is related to the case where we already have a CDM, but then we get a new CDM through component update.

Case 1: 
1. The old CDM is registered. No Renderer is using the CDM yet.
2. A Renderer calls requestMediaKeySystemAccess(), and gets the information (e.g. codec support) from the old CDM.
3. The new CDM is updated, and added to the top of the plugin list.
4. Renderer 1 calls createMediaKeys(), which tries to load the CDM. The new CDM is loaded.
5. So now Renderer 1 has key system info for the old CDM, but is using the new CDM. This could be a problem if there are dropped functionality in the new CDM.

Case 2:
1. The old CDM is registered. No Renderer is using the CDM yet.
2. Renderer 1 calls requestMediaKeySystemAccess(), and gets the information (e.g. codec support) from the old CDM.
3. Renderer 1 calls createMediaKeys(), which tries to load the CDM. The old CDM is loaded in the PPAPI process.
4. The new CDM is updated, and added to the top of the plugin list.
5. Renderer 2 calls requestMediaKeySystemAccess(), and gets the information (e.g. codec support) from the new CDM.
6. Renderer 2 calls createMediaKeys(), which tries to load the CDM. The old CDM is used because we already have a plugin module running in the PPAPI process using the old CDM.
5. So now the Renderer 2 has key system info for the new CDM, but is using the old CDM. This could be a problem if there are added functionality in the new CDM.

Case 1 is not a big issue since we rarely drop functionality. Case 2 would be a bigger issue.
Project Member

Comment 1 by sheriffbot@chromium.org, Apr 3 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 2 by xhw...@chromium.org, Apr 3 2017

Labels: -Hotlist-Recharge-Cold
Status: Available (was: Untriaged)
I'll look into this when working on project SoDo.
Project Member

Comment 3 by bugdroid1@chromium.org, Jan 30 2018 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/15aba67733cb10140cd9c197ac9b131e718cd71b

commit 15aba67733cb10140cd9c197ac9b131e718cd71b
Author: Xiaohan Wang <xhwang@chromium.org>
Date: Tue Jan 30 00:07:11 2018

media: Always use the first registered CDM

See BUG for more details. With this CL, for a given key system, the
first registered CDM will always be used for handling the capability
query, and for creating the CDM instance. Hence, there's no way for any
inconsistency to happen (as described in the BUG).

This means that a later registered CDM will not be used until browser
restart (e.g. component updated CDM), which should be fine in most
cases.

BUG= 599588 

Change-Id: I9390f4ea73e5f40395ab8f87fc1d9c1c1f5c75ad
Reviewed-on: https://chromium-review.googlesource.com/889982
Reviewed-by: David Dorwin <ddorwin@chromium.org>
Reviewed-by: John Rummell <jrummell@chromium.org>
Commit-Queue: Xiaohan Wang <xhwang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#532678}
[modify] https://crrev.com/15aba67733cb10140cd9c197ac9b131e718cd71b/content/browser/media/cdm_registry_impl.cc
[modify] https://crrev.com/15aba67733cb10140cd9c197ac9b131e718cd71b/content/browser/media/cdm_registry_impl_unittest.cc

Comment 4 by xhw...@chromium.org, Jan 30 2018

Status: Fixed (was: Available)
►

Sign in to add a comment