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
Change test files to specify the mime type of the file. This is checked
by media test manager so that changes in mochitest.ini are not needed.
MozReview-Commit-ID: 4hFQmRknBOY
--HG--
extra : rebase_source : b76a8dfe071dec320a7ebef8fc071e671278c1fa
Bubble information from SamplesWaitingForKey to an HTMLMediaElement so that we
can emit a waitingForKey event. If we are unable to decode more samples due to
needing a key the event will be signalled. See
http://w3c.github.io/encrypted-media/#dom-evt-waitingforkey for more information
on this event.
The code in place before this patch handles updating readyState when we are
waiting for a key, this patch adds the event which should be emitted in such a
case. The spec defines certain preconditions should be the case before running
the algo to emit this event. For example, the element should potentially be
playing, and it should have at least HAVE_FUTURE_DATA ready state. This is not
strictly true for when the new code is run, due how existing code handles ready
state. We are honoring the spirit of the spec, though the letter of the spec is
lightly gone against in the handling of the preconditions.
MozReview-Commit-ID: LKlDd4wkRSE
--HG--
extra : rebase_source : 2c61fc41636e430afa23240ad5d26c886124d87f
We also move flac related files to their own flac folder.
MozReview-Commit-ID: YnV3HNbjZe
--HG--
extra : rebase_source : 59ade40278c324ffc2f4604ec9f93697406f3269
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 : f43e15646589379b3e5f7f71fe30f8de8028fa4f
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 : d6af6a028f50dea7c562cf62fac71ae23b1d5e01
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 : 5ab806335b4ad17b04a20e37caf87eeb37f68bed
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
In bug 1258870 I changed the media code so that we dropped all late video
frames. Without this, our A/V sync was broken when the decode was struggling
to keep up, and we weren't reporting dropped frames when the decode couldn't
keep up, and so players couldn't adapt to a bitrate which the decode could keep
up on.
However, dropping all late frames broke talos tests which relied on the old
behaviour of us rendering video frames that were late. So this patch adds a
pref to cause the frame dropping code to not drop the last frame in the
queue, so there will always be something for the compositor to composit. This
means talos will once again be able to test how fast it can composit frames
that aren't supposed to be drawn.
The pref is media.ruin-av-sync.enabled.
It defaults to false.
MozReview-Commit-ID: J3VvpzoDRmI
--HG--
extra : rebase_source : ee24f37f201ef266e0894ca2c5afda498629ec0a
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
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
Bug 1154802 provided a workaround for this race condition. So enable it in all platform.
MozReview-Commit-ID: BS1iW4O7TsZ
--HG--
extra : rebase_source : ac825a25b195b22106ae70cb412a0b61bd846bfb
This updates mLastComputedValue when removing events during the call to
CleanupEventsOlderThan.
MozReview-Commit-ID: 1Veyv8kLIna
--HG--
extra : rebase_source : 9ee9aeb458b60316f93616e3310ad26f9e85e79c
We can get out of A/V sync if the decode is struggling to keep up. This is
because of the loop in VideoSink::UpdateRenderedVideoFrames(). If this function
runs while there's only one frame in the video queue, we won't drop that one
frame if it's late. If we're struggling to keep up, it's increasingly likely
that we'll end up running this function with only one frame in the video queue.
That results in us entering VideoSink::RenderVideoFrames() with only 1 late
frame, which the compositor dutifully draws. Resulting in a late frame being
drawn, and thus broken A/V sync.
This change makes VideoSink::UpdateRenderedVideoFrames() drop all late
frames, even the last one in the video queue. We now keep A/V sync when the
decode is struggling to keep up. However, if I do this, we end up dropping
(and reporting that we drop) a lot more frames, and thus rendering a lot fewer.
But since we when we drop the frames we report them as dropped, a well written
MSE player can detect that we've failing miserably to keep up, and and lower
their bitrate.
MozReview-Commit-ID: ybkq48mKk2
--HG--
extra : rebase_source : f03c186059a365a45de698b2a30e632daae47fb8
We've proven that when seek is in action, mQueuedSeek.Exists() is always false and mCurrentSeek.Exists() is always true.
MozReview-Commit-ID: CxNU45NXG88
--HG--
extra : rebase_source : 893dbe33cb2f66b9a0bc7ddb03afb40f06d574d0
InitiateSeek() is called from several places where we can prove mQueuedSeek.Exists() is false:
1. MaybeFinishDecodeFirstFrame(): mQueuedSeek is moved when calling InitiateSeek().
2. Seek() rejects mQueuedSeek before calling InitiateSeek().
3. StartDecoding(): mQueuedSeek is moved when calling InitiateSeek().
4. VisibilityChanged(): it doesn't call InitiateSeek() when mQueuedSeek.Exists() is true.
MozReview-Commit-ID: BriPw0VID5O
--HG--
extra : rebase_source : 1417b108eab1cf9cf332e55e77077d7947505d27
In some cases, we need to resend missed VideoSegment to new added MediaStreamVideoSink. Append the latest video frames from updateTracks.
MozReview-Commit-ID: 76RFs5fgKpY
--HG--
extra : rebase_source : 1b1e4e60e0653cbf4ef21abf364239514cf171c5
This makes a lot of code more compact, and also avoids some redundant nsresult
checks.
The patch also removes a handful of redundant checks on infallible setters.
--HG--
extra : rebase_source : f82426e7584d0d5cddf7c2524356f0f318fbea7d
SetDormant() checks IsShutdown() and |mState == DECODER_STATE_DORMANT|.
So ReaderSuspendedChanged() can just call SetDormant(mIsReaderSuspended) to do the work.
MozReview-Commit-ID: J7Dzsm8IhIS
--HG--
extra : rebase_source : c8a0bc31071bfbe084c2a5f47821c0dc3cfd0860
This patch makes the following changes on many in-class methods.
- NS_METHOD F() override; --> NS_IMETHOD F() override;
- NS_METHOD F() override {...} --> NS_IMETHOD F() override {...}
- NS_METHOD F() final; --> NS_IMETHOD F() final;
- NS_METHOD F() final {...} --> NS_IMETHOD F() final {...}
Using NS_IMETHOD is the preferred way of marking in-class virtual methods.
Although these transformations add an explicit |virtual|, they are safe --
there's an implicit |virtual| anyway because |override| and |final| only work
with virtual methods.
--HG--
extra : rebase_source : 3010fade82a170eab7f13d81bf61b02cd693f3cf
This patch makes the following changes on many in-class methods.
- NS_IMETHODIMP F() override; --> NS_IMETHOD F() override;
- NS_IMETHODIMP F() override {...} --> NS_IMETHOD F() override {...}
- NS_IMETHODIMP F() final; --> NS_IMETHOD F() final;
- NS_IMETHODIMP F() final {...} --> NS_IMETHOD F() final {...}
Using NS_IMETHOD is the preferred way of marking in-class virtual methods.
Although these transformations add an explicit |virtual|, they are safe --
there's an implicit |virtual| anyway because |override| and |final| only work
with virtual methods.
--HG--
extra : rebase_source : 386ee4e4ea2ecd8d5001efabc3ac87b4d6c0659f
We need to update mLastComputedValue while processing events that occur at the
same time rather than just skipping over them.
MozReview-Commit-ID: LuxSK6PHFHv
--HG--
extra : rebase_source : be323da2a50ea32838aef322267115d153a14c3d
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
Calling NotifyDataArrived from each sourcebuffer will cause multiple unnecessary NotifyDataArrived to the MediaFormatReader when it could only be done once. Additionally, it ensures that the media duration is updated prior to the reader actioning on the notification.
Extra: mEnded is only ever accessed on the main thread, there's no need to make it atomic.
MozReview-Commit-ID: IKq7IRBbWic
--HG--
extra : rebase_source : 6cf18b1f71f5ee6c8e82c73bdd2857e783f343b8
The duration in the MediaDecoder is the canonical. It has as such a more up to date value than the mirror.
Under some circumstances, the MDSM may have reached the end of media playback before the duration mirror had time to update. So perform the currentTime adjustment in the MediaDecoder instead.
MozReview-Commit-ID: 1RFr4mT5LpA
--HG--
extra : rebase_source : 3151d86561b53d5d1922c7c16f042792bfd47283
With MediaSource, the duration is always known and exact. It is entirely possible that we have played data at some point, then removed that data and adjusted the duration.
MozReview-Commit-ID: HZe2yXtQfIL
--HG--
extra : rebase_source : be1b57575c28142d6b3091b23894a7e4e1c9b405
1. Called from SourceBuffer::AppendDataCompletedWithSuccess() where mMediaSource->GetDecoder() is not null.
2. Called from MediaDecoder::ResourceCallback::NotifyBytesDownloaded() which is disconnected in Shutdown().
MozReview-Commit-ID: 103pxZP02Bb
--HG--
extra : rebase_source : 72e8a9c29d5ca6a4932de3a119497b05bfadbe68
1. Called from SourceBuffer::AppendDataCompletedWithSuccess() where mMediaSource->GetDecoder() is not null so this must happen before Shutdown().
2. Called from SourceBuffer::Ended() where mMediaSource->GetDecoder() is not null.
3. Called from MediaDecoder::ResourceCallback::TimerCallback() which is canceled in Disconnect().
MozReview-Commit-ID: 5dqVuOcrABy
--HG--
extra : rebase_source : a134f552c4fae2317cbf93dc1e861199d4c91346
This is a follow up from bug 1289623, as I missed a few cases in that bug.
MozReview-Commit-ID: DM7FtVSZUo3
--HG--
extra : rebase_source : 4fd7ae93b1418ded54f0c21a50a654fc962d4892
Bump deps. Previous deps resulting in failures with current builds.
MozReview-Commit-ID: BUEfDmmE00E
--HG--
extra : rebase_source : a5437a86a875531945c558fab9427c6c31059289
Previously the tests would check if playback had started by looking at the first
recorded time, and then looking at the current time. If there were a lag it was
possible for the first recorded time to be at the end of the video (i.e.
playback already finished), in which case the video playing would not register.
This patch instead uses the played ranges from the video element. Now so long as
there is a non-empty played range we trust playback started.
MozReview-Commit-ID: 5C39A42KRdj
--HG--
extra : rebase_source : e4e8a35df3bac4c9e7765272acb6300b44b45d4e
This behaviour changed as part of Bug 1279493, and the tests should be updated
to reflect this.
MozReview-Commit-ID: oITf0hVjKk
--HG--
extra : rebase_source : 26f54e0ac49a2f27f364c75a63851df5a85ce18f
I also added more testing around ClearKey's base64 decoding, since that affected
how keyIds were handled.
MozReview-Commit-ID: 2UH1JNT4NC3
--HG--
extra : rebase_source : 8e2c861e6b030d7e4a1378d3fafed7630324d940
This patch is really two separate changes.
The first change is that rust crates are large, standalone entities that
may contain multitudes of source files. It therefore doesn't make sense
to keep them in SOURCES, as we have been doing. Moving to use cargo
will require a higher-level approach, which suggests that we need a
different, higher-level representation for Rust sources in the build
system.
The representation here is to have the build system refer to things
defined in Cargo.toml files as the entities dealt with in the build
system, and let Cargo deal with the details of actually building things.
This approach means that adding a new crate to an existing library just
requires editing Rust and Cargo.toml files, rather than dealing with
moz.build, which seems more natural to Rust programmers. By having the
source files for libraries (and binaries in subsequent iterations of
this support) checked in to the tree, we can also take advantage of
Cargo.lock files.
The second is that we switch the core build system over to building via
cargo, rather than invoking rustc directly.
We also clean up a number of leftover things from the Old Way of doing
things. A number of tests are added to confirm that we'll only permit
crates to be built that have dependencies in-tree.
So, we have 4 boolean variables and here is the truth table.
Case 1, 2, 3, 4, 7, 8, 10 and 12 are not possible to happen.
Then, the remaining cases could be clustered into three categories:
(1) Case 5, 9 and 13: no sample is demuxed at all, return 0.
(2) Case 6, 11, 14 and 15: either audio or video is able to be demuxed, return the known value.
(3) Case 15: both audio and video are demuxed, return the minimum of the values.
For simplifying the logic, I will initialize the audioStartTime and videoStartTime
to be INFINITY if we don't have the first-demuxed sample, otherwise, initialize
them to be the real first-demuxed sample's time.
Then, the final calculation will be:
(1) Case 5, 9 and 13: the minimum of two INFINITY values is still INFINITY, return 0.
(2) Case 6, 11, 14 and 15: return the minimum of one real first-demuxed-time and the INFINITY.
(3) Case 15: return the minimum of two real first-demuxed-time values.
Case HasAudio HasVideo HasAudioSample HasVideoSample ExpectedResult
---------------------------------------------------------------------------------------------------
1 F F F F not possible
2 F F F T not possible
3 F F T F not possible
4 F F T T not possible
---------------------------------------------------------------------------------------------------
5 F T F F return 0
6 F T F T return video sample
7 F T T F not possible
8 F T T T not possible
---------------------------------------------------------------------------------------------------
9 T F F F return 0
10 T F F T not possible
11 T F T F return audio sample
12 T F T T not possible
---------------------------------------------------------------------------------------------------
13 T T F F return 0
14 T T F T return videoSample
15 T T T F return audioSample
16 T T T T return min(auidoSample, videoSample)
MozReview-Commit-ID: ANsYDth7slJ
--HG--
extra : transplant_source : %DAj%1A%EC%19%82%7B%B3%05%FE%21%04a%16%9A%9F%18x1%95
In some cases, we need to resend missed VideoSegment to new added MediaStreamVideoSink. Append the latest video frames from updateTracks.
MozReview-Commit-ID: 76RFs5fgKpY
--HG--
extra : amend_source : e35a9fafbf1deb61944d6a9dd9d9fad5580c592e
This change avoids lots of false positives for Coverity's CHECKED_RETURN
warning, caused by NS_WARN_IF's current use in both statement-style and
expression-style.
In the case where the code within the NS_WARN_IF has side-effects, I made the
following change.
> NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
> -->
> Unused << NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
In the case where the code within the NS_WARN_IF lacks side-effects, I made the
following change.
> NS_WARN_IF(!condWithoutSideEffects);
> -->
> NS_WARNING_ASSERTION(condWithoutSideEffects, "msg");
This has two improvements.
- The condition is not evaluated in non-debug builds.
- The sense of the condition is inverted to the familiar "this condition should
be true" sense used in assertions.
A common variation on the side-effect-free case is the following.
> nsresult rv = Fn();
> NS_WARN_IF_(NS_FAILED(rv));
> -->
> DebugOnly<nsresult rv> = Fn();
> NS_WARNING_ASSERTION(NS_SUCCEEDED(rv), "Fn failed");
--HG--
extra : rebase_source : 58788245021096efa8372a9dc1d597a611d45611
Now everything is ready. We can make NotifyQueuedTrackChanges only triggered by TRACK_EVENT_CREATED and TRACK_EVENT_ENDED without breaking anything. Also we make TrackUnionStream no longer copying data in video case.
MozReview-Commit-ID: IgLx1mpBWB3
--HG--
extra : transplant_source : %21M%C5%07%B9%CB%16%96%D6gN%C0g%0A%E8%7D%A0%AB%98%26
Add MediaStreamVideoRecorderSink into MediaEncorder. In this patch, I still keep use duration to pass to TrackEncoders. Don't want to make this bug too big and out of control. We can file a new bug to change TrackEncoders use TimeStamp only.
MozReview-Commit-ID: KGftzulZynj
--HG--
extra : transplant_source : %E9%22B%90%D6%CF%08%12X%D1%E2%17%90%99%B2%91%24B%EA%1D
Make CaptureTask to inherite from MediaStreamVideoSink. The main change is to move the logic of |NotifyQueuedTrackChanges| to |SetCurrentFrames|.
The original image capture is not modified for support multiple video MediaStreamTracks. The design still used the track id in owned media stream. The should be fixed in the following bug if we still want to support ImageCapture in multiple video tracks case.
MozReview-Commit-ID: Od4tHoR8Ef
--HG--
extra : transplant_source : %AA%1BD%20%1D%8F%D0%9A%5B%9C%7Ef%A0%1C%E9%D7%EE%AE%E6%93
In this patch, we first deal with the case of MediaElement. Now we replace |PlayVideo| with |VideoFrameContainer::SetCurrentFrames| in |SourceMediaStream::AppendToTrack|. The MSG use TimeStamp::Now() for the TimeStamp of each video frame in most of case except MediaElement case. Becasue the MediaElement has its own VideoQueue, we need to calucalte the correct Timestamp based on the StartTimeStamp of this MediaStream and the elpased time of the video frame in DecodedStream.
MozReview-Commit-ID: 2bm2AHkFXHu
--HG--
extra : transplant_source : %3D%AA%00%CE%A3SV5%8F%84%96%AC%E2%D9%10%EC%85%07N%DF
Replace the pointer of VideoFrameContainer with the pointer of MediaStreamVideoSink.
MozReview-Commit-ID: 5bqEMpemwuR
--HG--
extra : transplant_source : %008z%D8W%EE%87%8E%E9/%2CT%26%EBvo%AE%099%A6
Jean-Yves Avenard
JW Wang
Gerald Squelart
Byron Campen [:bwc]
Alex Chronopoulos
Ryan VanderMeulen
Michael Layzell
Randell Jesup
Munro Mengjue Chiang
Wes Kocher
Andreas Pehrson
Chia-hung Tai
James Cheng
Sebastian Hengst
Nicholas Nethercote
Cykesiopka
Iris Hsiao
Thomas Wisniewski
Dan Glastonbury
Bryce Van Dyk
clui
Jan-Ivar Bruaroey
Chris Pearce
Andi-Bogdan Postelnicu
Kan-Ru Chen
Sotaro Ikeda
Dan Minor
bechen
John Lin
Nathan Froyd
Anthony Jones
Igor
Kaku Kuo
Jan de Mooij
Kilik Kuo
Carsten "Tomcat" Book
Randell Jesup
Matt Woodrow
Gregory Szorc
Alastor Wu
Henrik Skupin
Eugen Sawin
Alexandre Lissy
John Dai