Without this, we can end up with very short, or even negative, update
intervals, meaning we unnecessarily use CPU when we can't actually
advance the playback position.
MozReview-Commit-ID: 6H32uVCyCll
--HG--
extra : rebase_source : 952799b846bcbb562d4ff99e97a8dcb5d8b2f558
Our logic to do A/V sync sets a timer to drop expired frames based on the
start time of the next frame in the queue. If the frames in the queue are
badly muxed and don't have monotonically increasing start times, we can
end up setting a timer with a negative interval. This causes us to reevaluate
the frames in the VideoSink's queue immediately, set the same timer again,
and so we end up hot-looping.
This is a simple low-risk fix that detects when we're about to set a negative
interval timer, and instead sets the timer 1/30th of a second in the future.
This fix is deliberately low risk, such that it's suitable for uplift. I have
an idea how to do this better, but the lower risk this is most suitable for
uplift.
MozReview-Commit-ID: CDOqJJodx4l
--HG--
extra : rebase_source : b2833382d95143ee1845f2ea32dcc77a1903dc00
Because the TaskQueue of MDSM will shut down soon and TaskQueue::Dispatch() will fail (via mOnOutput.Notify()).
We reset mStream in Forget() on the TaskQueue thread of MDSM so NotifyOutput() can check it
and ensure mOnOutput.Notify() always happen before DecodedStream::Stop().
MozReview-Commit-ID: 4sCXk1KAfCC
--HG--
extra : rebase_source : 1ec50a86fa1519c4fc8caa1087f2794411aa23b0
This is only for safeguarding, in case an audio buffer was over allocated. There should be none. But better be safe than sorry
MozReview-Commit-ID: JszA8CqycTr
--HG--
extra : rebase_source : ddeb1ff1f19abba36e4cbb1bab5132f15f5a2a74
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
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
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
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 : amend_source : 7b9c51dcb4046c6c807d1cf1e48bef301e45fa8e
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 : %C4n%D7a%10%CFK%D5%F2%DC%10%08%C2%24%EC%11%13J%DB%5D
Decoders now use FrameStatisticsData to gather data for their frame-related
notifications. This will ease introducing new members later on.
MozReview-Commit-ID: DWdOSPX3JM
--HG--
extra : rebase_source : a3e05f34353a397d1c82b3f4d935c0864f90556e
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
This can reduce the include header dependency. MediaStreamVideoSink will inherit from DirectMediaStreamTrackListener. But we can't use forward declaration on MediaStreamListener because the usage of nsTArray<RefPtr<MediaStreamVideoSink>>.
MozReview-Commit-ID: 328s4Kw9NvW
--HG--
extra : transplant_source : %D2%18%E3%3B%0C%D8%F04%F3%EB%EB%A0%A7%8B%B1%A9%AB%97rY
Almost identical to gfxPrefs, with the exception that preferences can't be set (as it doesn't work with e10s anyway). The generated code size is tiny enough that we don't have to bother about having duplicates.
MozReview-Commit-ID: 5SZyscvIzzS
--HG--
extra : rebase_source : 1a2577bbe24d2d6644c3f1f5d0c47850b67fdea0
Performing all audio processing operations in the same place, allows to simplify the code.
Additionally, if accessibility.monoaudio.enable is not set, we always upmix mono to stereo so that if the first audio stream seen was mono, we aren't stuck playing all future streams in mono.
MozReview-Commit-ID: 5yANN6PLFhX
--HG--
extra : rebase_source : 8b2138368d97f4ec2857c021ed9605c633282ed2
We attempt to avoid unnecessary resampling of 44.1kHz and 48kHz content, for all others we use cubeb's preferred sampling rate as final sampling rate.
MozReview-Commit-ID: 413qnsDFHzY
--HG--
extra : rebase_source : ca3508aefb29e2e64e84774bddb9fe77654c8945
The audio is automatically converted to always match the format of the first processed sample.
This is a temporary approach, as it would be preferred to use a final sampling rate not causing too much quality loss.
MozReview-Commit-ID: Lo3827aon43
--HG--
extra : rebase_source : 946eabde451a33018722cb6f1c0ca7b8c1d87009
This will allow to easily detect audio configuration change prior immediate playback.
MozReview-Commit-ID: IwDUGOd17ND
--HG--
extra : rebase_source : ef2b492cfeed5eca8fdfcb5442dedc2b65fc1d8f
Performing all audio processing operations in the same place, allows to simplify the code.
Additionally, if accessibility.monoaudio.enable is not set, we always upmix mono to stereo so that if the first audio stream seen was mono, we aren't stuck playing all future streams in mono.
MozReview-Commit-ID: 5yANN6PLFhX
--HG--
extra : rebase_source : f40dfacc9fc323794325de0431c4958854012180
We attempt to avoid unnecessary resampling of 44.1kHz and 48kHz content, for all others we use cubeb's preferred sampling rate as final sampling rate.
MozReview-Commit-ID: 413qnsDFHzY
--HG--
extra : rebase_source : a469cb7269be48bfbca82fbbd90c3e2caf21b9a7
The audio is automatically converted to always match the format of the first processed sample.
This is a temporary approach, as it would be preferred to use a final sampling rate not causing too much quality loss.
MozReview-Commit-ID: Lo3827aon43
--HG--
extra : rebase_source : 51322d12415995bd5ba7d8a25500860f333c9c3e
This will allow to easily detect audio configuration change prior immediate playback.
MozReview-Commit-ID: IwDUGOd17ND
--HG--
extra : rebase_source : 3af32634eb431661436bf1d3aaeb80124b229716
Performing all audio processing operations in the same place, allows to simplify the code.
Additionally, if accessibility.monoaudio.enable is not set, we always upmix mono to stereo so that if the first audio stream seen was mono, we aren't stuck playing all future streams in mono.
MozReview-Commit-ID: 5yANN6PLFhX
We attempt to avoid unnecessary resampling of 44.1kHz and 48kHz content, for all others we use cubeb's preferred sampling rate as final sampling rate.
MozReview-Commit-ID: 413qnsDFHzY
The audio is automatically converted to always match the format of the first processed sample.
This is a temporary approach, as it would be preferred to use a final sampling rate not causing too much quality loss.
MozReview-Commit-ID: Lo3827aon43
Performing all audio processing operations in the same place, allows to simplify the code.
Additionally, if accessibility.monoaudio.enable is not set, we always upmix mono to stereo so that if the first audio stream seen was mono, we aren't stuck playing all future streams in mono.
MozReview-Commit-ID: 5yANN6PLFhX
--HG--
extra : rebase_source : c789ba66fa168bc11064b2a329311d90b046c7fc
We attempt to avoid unnecessary resampling of 44.1kHz and 48kHz content, for all others we use cubeb's preferred sampling rate as final sampling rate.
MozReview-Commit-ID: 413qnsDFHzY
--HG--
extra : rebase_source : 2c783be7f6d2ccaab88cee70372905ea92b690f4
The audio is automatically converted to always match the format of the first processed sample.
This is a temporary approach, as it would be preferred to use a final sampling rate not causing too much quality loss.
MozReview-Commit-ID: Lo3827aon43
--HG--
extra : rebase_source : d8de2c85de5a78c2d1a17201a9d0c418ce3312e4
This will allow to easily detect audio configuration change prior immediate playback.
MozReview-Commit-ID: IwDUGOd17ND
--HG--
extra : rebase_source : 37e9e19a58d2e90b107eaf63a2ac19233c521033
Using the gfxprefs for the time being, in order to access the preferences outside of the main thread.
It will allow to easily test future cubeb changes to support change of sampling rate / multichannels.
MozReview-Commit-ID: 2Qvq4zAtzCL
--HG--
extra : rebase_source : 46e272ca46ceb35b8e97b62cd1d2be949ba054f2
Rather than performing the audio processing a few frames at a time, we perform the operation when popping the audio data block.
The only downmixing task left to AudioStream is to handle the force mono preference.
Resampling is currently disabled.
MozReview-Commit-ID: GNQA1h0xcp7
--HG--
extra : rebase_source : c58aa4514a0dc4de06be6dc1da6a598742caa262
PrincipalHandle is a thread safe pointer to a holder of (the main-thread-only
nsIPrincipal) that can be passed around the MSG.
A MediaStreamTrack whose source has just updated its principal, sets the new
principal aside (as its "pending principal"), and combines the new principal
into its current principal.
Then the source starts passing the new principal to the MediaStreamGraph as
a PrincipalHandle.
Changes to a track's PrincipalHandle on the MSG will be surfaced through the
MediaStreamTrackListener API. These changes are dispatched to main thread
and compared to a MediaStreamTrack's pending principal. In case of a match
the track knows the correct principal is flowing and can move the pending
principal to be the current principal and update any main thread principal
observers.
MozReview-Commit-ID: D0JXGWhQFFU
--HG--
extra : rebase_source : 296e269bb46fc5a85a9c3f90dfc0dc40e53572bc
This is a partial reversal of bug 1230338. We can't distinguish frames that are never composited because the media element is hidden from the frames genuinely dropped due to machine slowness. So until we can distinguish them, let's not report them as dropped.
MozReview-Commit-ID: ERV8Luaxp3F
Chun-Min Chang
Jean-Yves Avenard
Carsten "Tomcat" Book
JW Wang
Bevis Tseng
John Lin
Kaku Kuo
Chris Pearce
Sebastian Hengst
Jamie Nicol
Sotaro Ikeda
ctai
Gerald Squelart
Tom Tromey
Farmer Tseng
Andreas Pehrson
Chris Peterson
Alastor Wu
Kyle Huey
Kaku Kuo
Wes Kocher
Matthew Gregan