Use Wrapped Device Id Rather Than Parsing String |
||||||
Issue descriptionFor example, in class [1] and [2] we implement Parse and ToString function, and in [3] we parse the string. Ideally, we should pass a structured Id along code paths and avoid string conversion. [1]https://cs.chromium.org/chromium/src/content/public/browser/web_contents_media_capture_id.h?q=webcontentsmedi&sq=package:chromium&l=15 [2]https://cs.chromium.org/chromium/src/content/public/browser/desktop_media_id.h?q=desktopmediaId&sq=package:chromium&l=58 [3]https://cs.chromium.org/chromium/src/content/browser/renderer_host/media/audio_input_renderer_host.cc?sq=package:chromium&rcl=1474370620&l=427 ⛆ |
|
|
,
Sep 21 2016
We may not need any kind of structured ID at all. Basically, as discussed a long while ago in bug 163100 (comments 13 and 19), the plan was to make the tab capture device IDs work like the desktop capture device IDs. Meaning: Whenever the extension API is invoked (with desired settings for the capture device), the request is stored in a registry in the browser process. From then on, a randomly-generated string is all the device ID that is needed. The huge problem here is how to cross the libcontent boundary into src/chrome/browser/extensions/... I haven't thought all this through yet, but I'm sure it would be quite a bit of plumbing. Hmm...So maybe we *do* need to just better structure the IDs we have, after all. I'm not sure...
,
Sep 21 2016
Thanks miu@: I just noticed that we'd even have the device_id string available to Javascript as [1]. So device_id currently is not purely back end stuff, and thus this is beyond a code refactor fix and requires a thorough design. [1]https://cs.chromium.org/chromium/src/content/renderer/media/user_media_client_impl.cc?sq=package:chromium&rcl=1474442403&l=672
,
May 31 2017
|
|||
►
Sign in to add a comment |
||||||
Comment 1 by qiangchen@chromium.org
, Sep 20 2016