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
