OLD | NEW |
1 # Introduction | 1 # Piranha Plant |
2 | 2 |
3 Piranha Plant is the name of a project, started in November 2013, that aims to d
eliver the future architecture of MediaStreams in Chromium. | 3 Piranha Plant is the name of a project, started in November 2013, that aims to |
| 4 deliver the future architecture of MediaStreams in Chromium. |
4 | 5 |
5 Project members are listed in the [group for the project](https://groups.google.
com/a/chromium.org/forum/#!members/piranha-plant). | 6 Project members are listed in the |
| 7 [group for the project](https://groups.google.com/a/chromium.org/forum/#!members
/piranha-plant). |
6 | 8 |
7 The Piranha Plant is a monster plant that has appeared in many of the Super Mari
o games. In the original Super Mario Bros, it hid in the green pipes and is thus
an apt name for the project as we are fighting "monsters in the plumbing." | 9 The Piranha Plant is a monster plant that has appeared in many of the Super |
| 10 Mario games. In the original Super Mario Bros, it hid in the green pipes and is |
| 11 thus an apt name for the project as we are fighting "monsters in the plumbing." |
8 | 12 |
9 ![http://files.hypervisor.fr/img/super_mario_piranha_plant.png](http://files.hyp
ervisor.fr/img/super_mario_piranha_plant.png) | 13 ![http://files.hypervisor.fr/img/super_mario_piranha_plant.png](http://files.hyp
ervisor.fr/img/super_mario_piranha_plant.png) |
10 | 14 |
11 # Background | 15 [TOC] |
12 | 16 |
13 When the MediaStream spec initially came to be, it was tightly coupled with Peer
Connection. The infrastructure for both of these was initially implemented prima
rily in libjingle, and then used by Chromium. For this reason, the MediaStream i
mplementation in Chromium is still somewhat coupled with the PeerConnection impl
ementation, it still uses some libjingle interfaces on the Chromium side, and pr
ogress is sometimes more difficult as changes need to land in libjingle before c
hanges can be made in Chromium. | 17 ## Background |
14 | 18 |
15 Since the early days, the MediaStream spec has evolved so that PeerConnection is
just one destination for a MediaStream, multiple teams are or will be consuming
the MediaStream infrastructure, and we have a clearer vision of what the archit
ecture should look like now that the spec is relatively stable. | 19 When the MediaStream spec initially came to be, it was tightly coupled with |
| 20 PeerConnection. The infrastructure for both of these was initially implemented |
| 21 primarily in libjingle, and then used by Chromium. For this reason, the |
| 22 MediaStream implementation in Chromium is still somewhat coupled with the |
| 23 PeerConnection implementation, it still uses some libjingle interfaces on the |
| 24 Chromium side, and progress is sometimes more difficult as changes need to land |
| 25 in libjingle before changes can be made in Chromium. |
16 | 26 |
17 # Goals | 27 Since the early days, the MediaStream spec has evolved so that PeerConnection is |
18 1. Document the idealized future design for MediaStreams in Chromium (MS) as w
ell as the current state. | 28 just one destination for a MediaStream, multiple teams are or will be consuming |
19 1. Create and execute on a plan to incrementally implement the future design. | 29 the MediaStream infrastructure, and we have a clearer vision of what the |
20 1. Improve quality, maintainability and readability/understandability of the M
S code. | 30 architecture should look like now that the spec is relatively stable. |
21 1. Make life easier for Chromium developers using MS. | |
22 1. Balance concerns and priorities of the different teams that are or will be
using MS in Chromium. | |
23 1. Do the above without hurting our ability to produce the WebRTC.org delivera
bles, and without hurting interoperability between Chromium and other software b
uilt on the WebRTC.org deliverables. | |
24 | 31 |
25 # Deliverables | 32 ## Goals |
26 | 33 |
27 1. Project code name: Piranha Plant. | 34 1. Document the idealized future design for MediaStreams in Chromium (MS) as |
28 1. A [design document](http://www.chromium.org/developers/design-documents/ide
alized-mediastream-design) for the idealized future design (work in progress). | 35 well as the current state. |
29 1. A document laying out a plan for incremental steps to achieve as much of th
e idealized design as is pragmatic. See below for current draft. | 36 1. Create and execute on a plan to incrementally implement the future design. |
30 1. A [master bug](http://crbug.com/323223) to collect all existing and current
ly planned work items: | 37 1. Improve quality, maintainability and readability/understandability of the MS |
31 1. Sub-bugs of the master bug, for all currently known and planned work. | 38 code. |
32 1. A document describing changed and improved team policies to help us keep im
proving code quality (e.g. naming, improved directory structure, OWNERS files).
Not started. | 39 1. Make life easier for Chromium developers using MS. |
| 40 1. Balance concerns and priorities of the different teams that are or will be |
| 41 using MS in Chromium. |
| 42 1. Do the above without hurting our ability to produce the WebRTC.org |
| 43 deliverables, and without hurting interoperability between Chromium and |
| 44 other software built on the WebRTC.org deliverables. |
33 | 45 |
34 # Task List | 46 ## Deliverables |
35 Here are some upcoming tasks we need to work on to progress towards the idealize
d design. Those currently being worked on have emails at the front: | 47 |
36 * General | 48 1. Project code name: Piranha Plant. |
37 * More restrictive OWNERS | 49 1. A [design document](http://www.chromium.org/developers/design-documents/idea
lized-mediastream-design) |
38 * DEPS files to limit dependencies on libjingle | 50 for the idealized future design (work in progress). |
39 * Rename MediaStream{Manager, Dispatcher, DispatcherHandler} to CaptureDevic
e{...} since it is a bit confusing to use the MediaStream name here. | 51 1. A document laying out a plan for incremental steps to achieve as much of the |
40 * Rename MediaStreamDependencyFactory to PeerConnectionDependencyFactory. | 52 idealized design as is pragmatic. See below for current draft. |
41 * Split up MediaStreamImpl. | 53 1. A [master bug](https://crbug.com/323223) to collect all existing and |
42 * Change the RTCPeerConnectionHandler to only create the PeerConnection and
related stuff when necessary. | 54 currently planned work items: |
43 * Audio | 55 1. Sub-bugs of the master bug, for all currently known and planned work. |
44 * [xians](xians.md) Add a Content API where given an audio WebMediaStreamTra
ck, you can register as a sink for that track. | 56 1. A document describing changed and improved team policies to help us keep |
45 * Move RendererMedia, the current local audio track sink interface, to //med
ia and change as necessary. | 57 improving code quality (e.g. naming, improved directory structure, OWNERS |
46 * Put a Chrome-side adapter on the libjingle audio track interface. | 58 files). Not started. |
47 * Move the APM from libjingle to Chrome, putting it behind an experimental f
lag to start with. | 59 |
48 * Do format change notifications on the capture thread. | 60 ## Task List |
49 * Switch to a push model for received PeerConnection audio. | 61 |
50 * Video | 62 Here are some upcoming tasks we need to work on to progress towards the |
51 * [perkj](perkj.md) Add a Chrome-side interface representing a sink for a vi
deo track. | 63 idealized design. Those currently being worked on have emails at the front: |
52 * [perkj](perkj.md) Add a Content API where given a video WebMediaStreamTrac
k, you can register as a sink for that track. | 64 |
53 * Add a Chrome-side adapter for libjingle’s video track interface, which may
also need to change. | 65 * General |
54 * Implement a Chrome-side VideoSource and constraints handling (currently in
libjingle). | 66 * More restrictive OWNERS |
| 67 * DEPS files to limit dependencies on libjingle |
| 68 * Rename MediaStream{Manager, Dispatcher, DispatcherHandler} to |
| 69 CaptureDevice{...} since it is a bit confusing to use the MediaStream |
| 70 name here. |
| 71 * Rename MediaStreamDependencyFactory to PeerConnectionDependencyFactory. |
| 72 * Split up MediaStreamImpl. |
| 73 * Change the RTCPeerConnectionHandler to only create the PeerConnection |
| 74 and related stuff when necessary. |
| 75 * Audio |
| 76 * [xians] Add a Content API where given an audio WebMediaStreamTrack, you |
| 77 can register as a sink for that track. |
| 78 * Move RendererMedia, the current local audio track sink interface, to |
| 79 //media and change as necessary. |
| 80 * Put a Chrome-side adapter on the libjingle audio track interface. |
| 81 * Move the APM from libjingle to Chrome, putting it behind an experimental |
| 82 flag to start with. |
| 83 * Do format change notifications on the capture thread. |
| 84 * Switch to a push model for received PeerConnection audio. |
| 85 * Video |
| 86 * [perkj] Add a Chrome-side interface representing a sink for a video |
| 87 track. |
| 88 * [perkj] Add a Content API where given a video WebMediaStreamTrack, you |
| 89 can register as a sink for that track. |
| 90 * Add a Chrome-side adapter for libjingle’s video track interface, which |
| 91 may also need to change. |
| 92 * Implement a Chrome-side VideoSource and constraints handling (currently |
| 93 in libjingle). |
OLD | NEW |