When ffmpeg is enabled, it will use the FFmpeg's VPX decoder. FFmpeg appears to always buffer 15 frames before returning one (this is the same with h264) causing the waiting event to be fired much earlier than when using libvpx
Other modules than MediaTrackLists may want to receive updates on a
DOMMediaStream's track set. This moves the MediaTrackListListener out of
the MediaTrackList class into DOMMediaStream as a general interface.
The logic for adding MediaTracks to the MediaTrackList when
MediaStreamTracks are added or removed from a DOMMediaStream is moved to
HTMLMediaElement as this fits the model better - HTMLMediaElement is the
owner of the MediaTrackLists.
--HG--
extra : commitid : 3I8mAeBB3oL
extra : rebase_source : 66b8ffcfb5343811c181e4169f295b08494f2ee0
This is needed to make tests pass until we have bug 1208316 implemented.
--HG--
extra : commitid : GPSNwBVyD4j
extra : rebase_source : b7cb9cb1678a582fbf85b729b8f43508889f5c78
TrackUnionStream guarantees that TrackIDs are maintained if no tracks
have claimed them before.
In the gUM case, we have a SourceMediaStream which we wholly own (the
DOMMediaStream's Input stream), piped into a TrackUnionStream which
no-one external is able to add tracks to (the DOMMediaStream's Owned
stream) - addTrack()ed tracks are added to the DOMMediaStream's Playback
stream.
The MediaStreamTracks being enabled/disable refer to a TrackID in the
DOMMediaStream's Owned stream.
Alas, we don't need to forward a track's enabled state, we can just do
it on the source.
--HG--
extra : commitid : GPSNwBVyD4j
extra : rebase_source : 4388211be87ebe8a3839ea031b5c504d642806ab
A DOMMediaStream's owned stream is piped from the input stream which is
under the control of the DOMMediaStream's owner/producer (like
captureStream or gUM). When producers like these create new tracks after
the stream has already been created (the initial set should be available
to JS synchronously), it is nice if the DOMMediaStream picks them up
automatically and create the corresponding MediaStreamTracks.
The OwnedStreamListener added here does just that; creates an owned
MediaStreamTrack when a track appeared in the stream that didn't already
have a MediaStreamTrack.
It also moves the logic for ended tracks from the PlaybackStreamListener
to the OwnedStreamListener as we previously would see a track end in the
playbak stream after removeTrack() and that would be interpreted as the
track ending at the source.
--HG--
extra : commitid : GPSNwBVyD4j
extra : rebase_source : ee7d81282ee3fe0e05b55358dee8fc97a22473fe
Simplifies the structure of MediaManager somewhat. Possible since
MediaManager owns both the SourceMediaStream and the DOMMediaStream.
--HG--
extra : commitid : GPSNwBVyD4j
extra : rebase_source : 494b8b673084ea050420dfaf8d16e44a3bc49672
This lets us separate tracks by ownership like so:
* Input - Owned by the producer of the DOMMediaStream (gUM etc.)
* Owned - Contains Input tracks (per above) or tracks cloned tracks
if this DOMMediaStream is a clone.
* Playback - Contains Owned tracks plus tracks addTrack()ed to this
DOMMediaStream minus tracks removeTrack()ed from this
DOMMediaStream.
--HG--
extra : commitid : GPSNwBVyD4j
extra : rebase_source : fba22e96c6c65a74e012509f3da67a4d7df7a244
Locking to specific tracks lets us dynamically remove and add single
tracks to a ProcessedMediaStream.
--HG--
extra : commitid : GPSNwBVyD4j
extra : rebase_source : 0b1b79077f95bbefc8c71de551c5e3483a7d6ac0
This allows for tracking the input track of an added track (for
ProcessedMediaStream tracks; SourceMediaStream tracks don't have input
tracks) directly in the NotifyQueuedTrackChanges handler, which will be
necessary for locking MediaInputPorts to specific tracks.
--HG--
extra : commitid : GPSNwBVyD4j
extra : rebase_source : 4bed5dffe66b71b7ad23f4c02531d84af25cd316