This member is only assigned but never used now.
MozReview-Commit-ID: IbuAbRaXzc4
--HG--
extra : rebase_source : 166bd3bc7478f725b64b5b2a0e8e258980674d06
The assumption was that the waiting event would be fired once the last frame prior the gap had been played. This is however incorrect, as per spec, the waiting event is to be fired once readyState is <= HAVE_CURRENT_DATA. So the waiting event is actually fired anytime between the start of the last frame and its end.
MozReview-Commit-ID: AA4Qhn7okhB
--HG--
extra : rebase_source : fc1f336b2e07cc2549071563804de8fae9c9ab67
Otherwise we get intermittent in mochitests checking the value of currenTime when events are fired
MozReview-Commit-ID: AVktWrXochp
--HG--
extra : rebase_source : 76c952e62e9b449834d5924454c25ddad305ada6
1- We shouldn't reach ended if we have a gap in the buffered range prior the end of the file (see bug 1297036)
2- Waiting should be fired when readyState goes below HAVE_FUTURE_DATA
MozReview-Commit-ID: 18bEnkNpYvO
--HG--
extra : rebase_source : c42c7fd19fec9ede5bb64ea697a0086116882403
The test accidentally worked because any demuxing failures in ended mode would be treated as EOS. There's no audio between [0-3), so playback couldn't start
MozReview-Commit-ID: 4B90CrVUTy4
--HG--
extra : rebase_source : 9079aa8a6983877745baac71c7868ca360b85095
The aim is to only allow skipping gaps of fuzz=500ms.
MozReview-Commit-ID: 8uHxni2nPHI
--HG--
extra : rebase_source : ccef593170fb3a0c3ff61dc97ad1a0508be06934
This reverts commit 5a949eb358e27
Another more complete solution will follow.
MozReview-Commit-ID: K3lTdrBxW7W
--HG--
extra : rebase_source : d0f9443193b0816ae85972a4a368599b872fd437
Seeking in the buffered range should always succeed, even if we have no data in a given track
MozReview-Commit-ID: FGjsDCNIdWC
--HG--
extra : rebase_source : c91348e44055f82deee0e97da4abef0cf799b225
This is done by moving FlacFrameParsers' AutoByteReader to a more public spot
in libstagefright's bindings.
Using AutoByteReader means there is no more need for explicit calls to
DiscardRemaining(); which means our parsers relying on BoxReader will be more
lenient about boxes that are larger than needed.
MozReview-Commit-ID: 3EERU749WYB
--HG--
extra : rebase_source : 6deba02ac553303b0a2b694c24bfcb54c2e732b1
Also ByteReader and AutoByteReader are marked RAII, to help prevent misuses.
MozReview-Commit-ID: 7oklXs4QMnq
--HG--
extra : rebase_source : 54fca3168a70d951e6012baea4bf0544827cae11
ReleaseResources() is called when MDSM enters dormant or during shutdown.
When it is called in response to dormant request, we don't want to clear
current frames so we are able to enter dormant state more aggressively
even when the media element is visible to the user.
When it is called from MediaDecoderReader::Shutdown(), it doesn't really
call ClearCurrentFrame() because MediaFormatReader::Shutdown clears the
|mVideoFrameContainer| pointer. So it doesn't make a difference to remove
the call.
MozReview-Commit-ID: IakGHbSMWTv
--HG--
extra : rebase_source : 7a25de39e04f5c7728bf65fcd447cc67b7a85411
extra : source : 44ff0ffaf63ad51a7a382cf0ee1c16e64ade63b9
The fuzz value is a +/- one. To check if a target is within an interval
we need to check with half the fuzz only.
MozReview-Commit-ID: J5H5sbNokse
--HG--
extra : rebase_source : aeedcb111c84a353307c8e641385ef0800792fa7
Interval.LeftOf would always return true if the length of the interval
is less than the fuzzing value.
MozReview-Commit-ID: L9uyZjQXnGA
--HG--
extra : rebase_source : af14038da603b928c7a4942f1b37f031908e61bb
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
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
This patch removes checking of all the callback calls in memory reporter
CollectReport() functions, because it's not useful.
The patch also does some associated clean-up.
- Replaces some uses of nsIMemoryReporterCallback with the preferred
nsIHandleReportCallback typedef.
- Replaces aCallback/aCb/aClosure with aHandleRepor/aData for CollectReports()
parameter names, for consistency.
- Adds MOZ_MUST_USE/[must_use] in a few places in nsIMemoryReporter.idl.
- Uses the MOZ_COLLECT_REPORT macro in all suitable places.
Overall the patch reduces code size by ~300 lines and reduces the size of
libxul by about 37 KiB on my Linux64 builds.
--HG--
extra : rebase_source : e94323614bd10463a0c5134a7276238a7ca1cf23
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
H264 decoders always use those anyway, so may as well use them in the demuxer if SPS NAL is available.
This guarantees that we have correct dimensions when reading the MP4 metadata, and will have the side benefit that when loadedmetadata is fired, the dimensions provided at the time will be final; not having to wait to decode the first frame.
MozReview-Commit-ID: 3j70Xqw8jJY
--HG--
extra : rebase_source : 6bc0f1fa1c2db35bcaa683cc1a68042d122e2892
JW Wang
ctai
Munro Mengjue Chiang
Wes Kocher
Ryan VanderMeulen
Kaku Kuo
Jan-Ivar Bruaroey
Jean-Yves Avenard
Gerald Squelart
Byron Campen [:bwc]
Alex Chronopoulos
Michael Layzell
Randell Jesup
Andreas Pehrson
James Cheng
Sebastian Hengst
Nicholas Nethercote
Cykesiopka
Iris Hsiao
Thomas Wisniewski