Bug 849746 (e10s-webrtc)

[meta] make webrtc e10s ready

REOPENED
Unassigned

Status

()

REOPENED
6 years ago
4 months ago

People

(Reporter: slee, Unassigned)

Tracking

(Depends on: 2 bugs, {meta})

unspecified
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s+)

Details

(Whiteboard: [e10s])

(Reporter)

Description

6 years ago
Currently, WebRTC is not e10s ready. 
For what I know,
1. Webrtc creates sockets in the content process which is not allowed. 
2. The permission checks of camera api and audio capture

Comment 1

6 years ago
The first task here is to have a conversation about what we think the right architecture is
here. I'll be following up on this next week when I get back from IETF.
I think we should discuss how to do that, too.

We have some discussion in Taiwan locally, but no conclusion now.
The ideal implementation would be let chrome process take care of hardware (audio/video/codec) and socket. Then content side just instruct chrome process about what they want. However, that would be a huge architecture change I think. :S

By the way, Bug 845727 is for camera part. But I think the Camera API is only available on B2G currently.

Updated

6 years ago
Whiteboard: [WebRTC] → [WebRTC][blocking-webrtc-]
Is Bug 834093 a duplicate of this bug?

Comment 4

6 years ago
I spent a while talking to Jonas Sicking about this yesterday.

We really don't want to move everything into the chrome process because
that obviates the security benefits of process separation. However,
some of it does need to be in there, likely including proxies for
the camera and microphone. Jonas also suggested the ICE stack
because that will allow the chrome process to enforce the
ICE consent guarantees.
I agree, it is necessary to Manage how to allocate camera hw resource to app/web page. But I don't want to move camera hw handling code to chrome process.
To provide product level performance/quality, camera hw needs to be near to content process as possible. Some problem is at Bug 844248 and Bug 848627. For Firefox OS 1.1, we should not do big change about how to handle camera stream.

In Bug 803471, I moved camera hw hal and hw codec to android's media server process as a short term solution for FirefoxOS 1.1. It does not request a big change to how to handle camera and codec in gecko. And still can get good performance and normal content process can use camera/codec hw. Do this at camera hw is easier than hw codec. About hw codec, it become very difficult to do it.

For a longer term,  "Implement a dedicated 'media service' process" is a way to go, I think. Bug 845209, Bug 785592 are related bug. By implement the service process, we can replace "android's media server process". And we can do a correct permission check in the serviec process.
(In reply to Sotaro Ikeda [:sotaro] from comment #5)
>
> In Bug 803471, I moved camera hw hal and hw codec to android's media server
> process as a short term solution for FirefoxOS 1.1. It does not request a
> big change to how to handle camera and codec in gecko. And still can get
> good performance and normal content process can use camera/codec hw. Do this
> at camera hw is easier than hw codec. About hw codec, it become very
> difficult to do it.
> 
> For a longer term,  "Implement a dedicated 'media service' process" is a way
> to go, I think. Bug 845209, Bug 785592 are related bug. By implement the
> service process, we can replace "android's media server process". And we can
> do a correct permission check in the serviec process.

I put "Do this at camera hw is easier than hw codec...." in a wrong position. Following is correct one.
--------------------------------------

In Bug 803471, I moved camera hw hal and hw codec to android's media server process as a short term solution for FirefoxOS 1.1. It does not request a big change to how to handle camera and codec in gecko. And still can get good performance and normal content process can use camera/codec hw.

For a longer term,  "Implement a dedicated 'media service' process" is a way to go, I think. Bug 845209, Bug 785592 are related bug. By implement the service process, we can replace "android's media server process". And we can do a correct permission check in the serviec process.Do this at camera hw is easier than hw codec. About hw codec, it become very difficult to do it.
Duplicate of this bug: 834093
(Reporter)

Updated

6 years ago
Depends on: 853356

Updated

5 years ago
Keywords: meta
Whiteboard: [WebRTC][blocking-webrtc-] → [WebRTC][blocking-webrtc-][b2g-webrtc-]

Updated

5 years ago
Blocks: 750011
tracking-e10s: --- → +
Blocks: 997462
Priority: -- → P1

Comment 8

4 years ago
I recently did a review (bug 1036653) of new webrtc screen sharing code which generated a discussion about webrtc's current architecture which is not e10s/sandbox compatible.

The issues are that device capture / interfacing and desktop/window screen sharing happen entirely in the child process. Giving access to these devices in the child has security consequences, and additionally when we turn on sandboxing, none of this code will work on Windows since sandboxed processes run in a locked down, low integrity, virtual desktop.

The required work here apparently entails significant architectural changes. :/
Alias: e10s-webrtc
Flags: needinfo?(blassey.bugs)
I've asked GCP to track the changes needed for WebRTC under e10s and sandboxing.
Flags: needinfo?(blassey.bugs)
Moving old M2 P1 bugs to M3.
tracking-e10s: + → m3+
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
tracking-e10s: m3+ → +
Resolution: FIXED → ---

Updated

4 years ago
No longer depends on: 841674

Updated

4 years ago
Depends on: 1127727

Updated

3 years ago
backlog: --- → webRTC+
Rank: 15
Whiteboard: [WebRTC][blocking-webrtc-][b2g-webrtc-] → [e10s]

Updated

3 years ago
Depends on: 1165423
This is a meta, which typically don't prioritize.  We prioritize the dependent bugs (except at the very beginning - prior to bug breakdown).
backlog: webRTC+ → ---
Rank: 15
Priority: P1 → --
You need to log in before you can comment on or make changes to this bug.