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
We now call NotifyAsyncPanZoomStarted/Stopped precisely on the document
which is being transformed, so we no longer need to notify the child
docshells which was added in Bug 1088559.
Remove the |nsIDocument| argument for ProcessAPZStateChange(), which is not
used anymore.
mActiveAPZTransforms added in bug 1142926 is removed because AccessibleCaret
is the only consumer for AsyncPanZoomStarted/Stopped, and it now defaults to
always show while scrolling, i.e.
"layout.accessiblecaret.always_show_when_scrolling" defaults to true. And I
cannot reproduce the bug even if I turn off the preference.
MozReview-Commit-ID: DiEk2gCIHn2
The commit removes TestGetURL.cpp which wasn't doing anything useful anyway
because it required an argument but wasn't being passed one, and so it was just
aborting immediately with a usage message.
--HG--
rename : dom/base/test/TestNativeXMLHttpRequest.cpp => dom/base/test/gtest/TestNativeXMLHttpRequest.cpp
rename : dom/base/test/TestPlainTextSerializer.cpp => dom/base/test/gtest/TestPlainTextSerializer.cpp
extra : rebase_source : 224fd2f984eb456b7db56fbe7fc396aeec3a84c1
I've repeated myself a few times, so make a helper to make determining which
GMPs are available easier.
MozReview-Commit-ID: 2fFLeaA5o8u
--HG--
extra : rebase_source : 74ea0b429d339273535610df3bbd7fec7beae469
We have this for H.264, so we may as well have it for AAC too.
MozReview-Commit-ID: 2k64ANJGUNN
--HG--
extra : rebase_source : 6fe2543788afd26682d31c0ec45b9ac80e501ab1
We don't want to stop the loading process even we canceled the play operation.
MozReview-Commit-ID: FyPqBlDKYo0
--HG--
extra : rebase_source : fdbc4390a7763bdbe26e8b809d977234bb5360ea
The old way is to start playing first, and then block the media element. This
way is too complicated because it involves lots of interal state and isn't intuitive.
The new way is to ignore the play if the media element should be blocked. It's
easy to know and we doesn't need to keep any internal states because we don't play
the media element.
MozReview-Commit-ID: B20e0pvXES4
--HG--
extra : rebase_source : 6bff5447783c2997050e5c69884afe2c85ddf382
In order to refactor the blocking mechanism, we want to know the blocking state
before calling notifyStartedPlaying().
MozReview-Commit-ID: 3wa2M7qwUAm
--HG--
extra : rebase_source : d128463b7fd892b966d80d5b5f76537819f35bcf
Since the agent is created in beginning in patch1, we need another way to know
whether we have already called notifyStartedPlaying().
MozReview-Commit-ID: 5YNhwEl5Xfp
--HG--
extra : rebase_source : 6a2913e5d81591faf1a7383d9fcb9db2cf3f83d3
We create audio channel agent in the beginning in oreder to use some agent's methods.
But the agent is still started after media element starting playing.
MozReview-Commit-ID: KPGb7snB2t7
--HG--
extra : rebase_source : dba4b687f572d520481721f48a0b4e9796f73e1f
