docs/piranha_plant.md

   1 # Piranha Plant
   2
   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.
   5
   6 Project members are listed in the
   7 [group for the project](https://groups.google.com/a/chromium.org/forum/#!members/piranha-plant).
   8
   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."
  12
  13 ![http://files.hypervisor.fr/img/super_mario_piranha_plant.png](http://files.hypervisor.fr/img/super_mario_piranha_plant.png)
  14
  15 [TOC]
  16
  17 ## Background
  18
  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.
  26
  27 Since the early days, the MediaStream spec has evolved so that PeerConnection is
  28 just one destination for a MediaStream, multiple teams are or will be consuming
  29 the MediaStream infrastructure, and we have a clearer vision of what the
  30 architecture should look like now that the spec is relatively stable.
  31
  32 ## Goals
  33
  34 1.  Document the idealized future design for MediaStreams in Chromium (MS) as
  35     well as the current state.
  36 1.  Create and execute on a plan to incrementally implement the future design.
  37 1.  Improve quality, maintainability and readability/understandability of the MS
  38     code.
  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.
  45
  46 ## Deliverables
  47
  48 1.  Project code name: Piranha Plant.
  49 1.  A [design document](http://www.chromium.org/developers/design-documents/idealized-mediastream-design)
  50     for the idealized future design (work in progress).
  51 1.  A document laying out a plan for incremental steps to achieve as much of the
  52     idealized design as is pragmatic. See below for current draft.
  53 1.  A [master bug](https://crbug.com/323223) to collect all existing and
  54     currently planned work items:
  55 1.  Sub-bugs of the master bug, for all currently known and planned work.
  56 1.  A document describing changed and improved team policies to help us keep
  57     improving code quality (e.g. naming, improved directory structure, OWNERS
  58     files). Not started.
  59
  60 ## Task List
  61
  62 Here are some upcoming tasks we need to work on to progress towards the
  63 idealized design. Those currently being worked on have emails at the front:
  64
  65 *   General
  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).