So that the suspended video element won't be rendered any more and keeps the last decoded frame.
This is the effect that UX specification defines.
And actually, we don't need to set ImageContainer if there are no valid new images.
MozReview-Commit-ID: B7RS3LXu8J0
--HG--
extra : rebase_source : 114d68046cbbb478fda63d16da7fbb4fa2fc3dd3
extra : intermediate-source : 29e6d114dfb0c64d0b6a77d924066be9f69bb287
extra : source : d6a2b47b14f6ac00ea420f5eba7190c7af725381
So that the suspended video element won't be rendered any more and keeps the last decoded frame.
This is the effect that UX specification defines.
And actually, we don't need to set ImageContainer if there are no valid new images.
MozReview-Commit-ID: B7RS3LXu8J0
--HG--
extra : rebase_source : de7d014ebad34f032a0ea8bfbe9aa723ffe922de
extra : source : d6a2b47b14f6ac00ea420f5eba7190c7af725381
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
Carsten "Tomcat" Book
JW Wang
Kaku Kuo
Iris Hsiao
karo
Michael Layzell
Wes Kocher
Tom Tromey
Chun-Min Chang
Jean-Yves Avenard
Bevis Tseng
John Lin
Chris Pearce
Sebastian Hengst
Jamie Nicol
Sotaro Ikeda