Turns out runnables added through
MediaStreamGraph::DispatchToMainThreadAfterStreamStateUpdate on the same
iteration are all run in the same task. Creating them in the owning dom stream
in one task solves the timing issues and lets us add them
(and raise "addtrack") in individual tasks.
MozReview-Commit-ID: 9Q3NoFrmnQs
--HG--
extra : rebase_source : aa391668ec424d2f9b1485f6218d7d1f9948abc9
This adds support for HTMLMediaElement.mozCaptureStream() and
mozCaptureStreamUntilEnded() for a HTMLMediaElement playing a MediaStream.
This is up to spec, while capturing a HTMLMediaElement playing a file is not.
This incompatibility means we cannot mix sources for the returned MediaStream.
As such, a MediaStream returned while the HTMLMediaElement was playing a file
will only have content while the element is playing files. If the src changes
to a MediaStream, the stream will be empty.
It works the same way if a MediaStream was captured while the HTMLMediaElement
was playing another MediaStream.
This is due to TrackID management - MediaDecoder doesn't care, and creates new
tracks when you seek, so users are unable to keep track, while for MediaStream
we control everything from main thread and keep track of the TrackIDs used
previously.
This also adds a separate path from MediaElementAudioSourceNode so that we don't
forward video tracks when the returned MediaStream is only used internally for
WebAudio. We should in that case not require a DOMMediaStream but just forwarding
tracks to a TrackUnionStream should be enough, and will save us some cpu cycles.
This is however fine for now as it's simpler.
MozReview-Commit-ID: Bg8hESDISDU
--HG--
extra : rebase_source : 83885a73ec8cfc5fbe3c30a9330a52cd6b6dff12
extra : source : f1aec79078869c0a6435a1c06957c649d7a40dd9
Sometimes a track is added to a stream synchronously (before the stream is
exposed to script), and sometimes asynchronously (see the mediacapture-main spec
on the "addtrack" event).
In the latter case we might still need to create the MediaStreamTrack object
synchronously for tracking purposes. CaptureStream of Media element playing a
MediaStream wants this.
MozReview-Commit-ID: 7me8xzN7rwj
--HG--
extra : rebase_source : 4f129b127b855e47aad2ae9ab3981ffde057412d
When we expect multiple events of the same type (in this case "addtrack" on
MediaStream) we can use this convenience function to attach a listener and
wait for the expected number of events before removing the listener and resolving.
This also adds a function to check that there were no extra events of the same
kind after the expected N events, and a function that checks that we don't see
a certain event within a given timeout period.
MozReview-Commit-ID: 1P8MkEI0Yzm
--HG--
extra : rebase_source : a815d5834c71785359613c2fb5af3cdb14ba1a54
On Linux x64 PGO try, HTMLMediaElement was reliably invoking
decoder->NotifyOwnerActivityChanged() after SetVisible(false) was
called. This caused the pending suspend to be cancelled and the test
waits for an event that never arrives.
Fixed by adding 'forced hidden' to MediaDecoder that overrides the
element visibility that comes from HTMLMediaElement.
MozReview-Commit-ID: 5aRhxxZ5cZd
--HG--
extra : rebase_source : 5a4e1c44ddd2265eab545f8fe19c4ae47cebf7bf
The playing event is sent asynchronously. By the time the playing event
actually gets fired, it is possible that playback has already started.
MozReview-Commit-ID: 1iD3ZSmWtmb
--HG--
extra : rebase_source : c9ea91b5102370f3b063a05f69f7eaf805bd8eb0
GetEndOfAppendedData() returns null and calls a NS_ERROR() if the track we're
looking for doesn't exist - to indicate an error in the caller's code.
When we end a MediaEngine track we set the state to stopped, which we can use
to guard the calls to GetEndOfAppendedData() (and appending data in general).
The locking is already in place.
MozReview-Commit-ID: DuknmBF883H
--HG--
extra : rebase_source : 6304e61a4050f0ea9c31ee01f5b42f5cb45b9bf6
enum classes are in general safer than plain enums, and as such should be
preferred.
MozReview-Commit-ID: 1FK89SNhdk4
--HG--
extra : rebase_source : 764c4855026c02d8c9e33ca33637fec54ea5ca31
We also move flac related files to their own flac folder.
MozReview-Commit-ID: YnV3HNbjZe
--HG--
extra : rebase_source : 5f064723d68a877d9790f0c51c5d1579d7a9bac4
When the content is served by Apache, a file with an .aac extension always see its Content-Type set to x-aacp.
MozReview-Commit-ID: 65NANlKNQek
--HG--
extra : rebase_source : 5f5d4bf65117f862a22698b450dedd2d5f0ef8d1
This feature is intended to debug the flac parser only and is behind a hidden pref.
There's lots of redundant code in OggCodecState, there's need for a serious cleanup there.
MozReview-Commit-ID: 9H4efd2cfuE
--HG--
extra : rebase_source : cd5f6d16dd319391a0469b8317a18ef1d5e58331
Make it just like MP4, WebM and all the others new demuxers.
Additionally, make the ogg related preferences part of MediaPrefs.
MozReview-Commit-ID: DTedHyIMv9I
--HG--
extra : rebase_source : 8bfdf971993281454776a7c4fa644c9fc7c5ee8c
The code was designed around the need for a MediaResource::Read which is
no longer possible since bug 1190238
MozReview-Commit-ID: 7s76YWg93jS
--HG--
extra : rebase_source : 3f6756193c352cf766471dd8cb1fb7646af191e6
The MP4 demuxer returns INT64_MAX when all data can be safely evicted
from the MediaResource.
Additionally, the MP4Demuxer will read the MediaResource using
CacheReadAt.
Eviction in the SourceBufferResource had a safeguard to ensure we would
never evict data we hadn't read yet. This was done by keeping the
position of the last data read in the mOffset member. CacheReadAt
however doesn't update mOffset.
As a result, no data was ever removed from the input buffer when using
MP4.
MozReview-Commit-ID: 2tAWzpMlOjG
--HG--
extra : rebase_source : bec585ca46e7fd0665c00bce525aaacede1b3897
With raw streaming flac, we can't determine the audio format at the time the codec is opened.
Additionally, when using streaming flac, we do not have a STREAMINFO block. The FFmpeg flac decoder check that extradata is null and not its size and would error due to an invalid extradata.
MozReview-Commit-ID: KZ3n8b8WUMo
--HG--
extra : rebase_source : a0dd8f517d730b1414c6461fc5c5e5b08d0d8b10
Andreas Pehrson
Dan Glastonbury
Jean-Yves Avenard
JW Wang
Munro Mengjue Chiang
Chia-hung Tai
James Cheng
Sebastian Hengst
Cykesiopka
Ryan VanderMeulen
Iris Hsiao
Randell Jesup
Thomas Wisniewski