We don't need to check IsShutdown() which is a subset of |mPlayState != PLAY_STATE_PAUSED && !IsEnded()|.
MozReview-Commit-ID: BjYoLOLuPfC
--HG--
extra : rebase_source : 0d04b30a8bf955faed4907f77f0da29e0ccc011d
1. It is called from DurationChanged() which returns early when IsShutdown() is true.
2. It is called from Play() when IsEnded() is true.
MozReview-Commit-ID: Ixy5OMZHxIm
--HG--
extra : rebase_source : 4cd7229084c6af8b7123ee6c85156ef4932308f3
1. It is called from ChangeState() when IsEnded() is true.
2. It is called from OnMetadataUpdate(). The callback is disconnected in Shutdown().
MozReview-Commit-ID: 8m4jtcl91hT
--HG--
extra : rebase_source : 0988128ec6d05f07ab7b072cc70a9c2970c829c5
1. Pause() is called from HTMLMediaElement and happens before Shutdown().
2. Pause() is called from SetPlaybackRate() which is called from HTMLMediaElement.
MozReview-Commit-ID: DDr7Bg8jkF2
--HG--
extra : rebase_source : 8b8a4fdc914d0bce7572d9a1ccb0f530bdba062c
FireTimeUpdate() is only called from UpdateLogicalPositionInternal() which returns early when IsShutdown() is true.
MozReview-Commit-ID: 4GZwrI85aXj
--HG--
extra : rebase_source : 9d7cbd571fd794369c833723ea5fc50a26380e51
1. ConstructMediaTracks() is called from ChangeState() when |mPlayState == PLAY_STATE_PLAYING|.
2. ConstructMediaTracks() is called from MetadataLoaded() which asserts |!IsShutdown()|.
MozReview-Commit-ID: 6OaPYcCOCii
--HG--
extra : rebase_source : 9db9e841fe8a0d797a39cd527abf4f4e95b67131
Notify audible-changing when resuming audio by MediaElement::play() instead of control interface.
MozReview-Commit-ID: 10a1npQ46Th
--HG--
extra : rebase_source : 16cce6782a132a2aab4ad66dc216d6237fc2ba9f
Mingw python has a different os.path setup from native python, and has
os.sep and os.altsep reversed. In that case, the normsep function was
doing the wrong thing, leading to all sorts of problems.
While fixing this, also ensure the corresponding unit test covers this
peculiarity, even when running under the native win32 python.
--HG--
extra : rebase_source : 8fb18e0d4dc669c1d7e069f73fc44c22d419d43c
Python configure "environment variables" can be passed as actual
environment variables, but can also be passed as command line arguments
(unless they also make it to old-configure, which doesn't support that).
Passing empty environment variables is broken in msys2/cygwin: the
subprocess doesn't see the environment variable being set, so it can't
tell the difference between "not set" and "set to nothing", which has a
different meaning for python configure environment variables.
Currently, JS_STANDALONE is passed this way. Passing it as a command
line argument makes it properly passed down to the subconfigure.
--HG--
extra : rebase_source : d4ebaf9d626902166c3861ee9d6141255658194f
Given that we have a universal unpack method now do not keep 'unzip' in method names.
Also adapt arguments to be better understandable.
MozReview-Commit-ID: ClDB5mSVcI2
--HG--
extra : rebase_source : 5bfee9d3c56436dd3a9f7c279517642ac70bb179
Get rid of external unpack tools (unzip and tar) and use the Python internal classes instead.
This patch only changes this behavior for the base script class but not for custom code in other
test scripts and modules, which would make it too complex. A follow-up bug will be filed instead.
MozReview-Commit-ID: L0eoITlqTdC
--HG--
extra : rebase_source : 5c9f04c29eddea09f2bbac18d9fc491671b1ccdf
Currently, the gecko-decision and action tasks maintain a separate cache
for each "project" (Firefox repo) source checkout. In my opinion, this
is not necessary.
Separate caches/source checkouts mean a lower chance for a cache hit:
a lower chance that any given worker will have a source checkout readily
available for the "project" being built. They also mean workers store
more data and files in caches.
By using a shared cache for source checkouts, workers will ideally
only have a single source checkout cache and will be pretty much
guaranteed to have a checkout readily available (the main exception
being the first task on a freshly-provisioned worker).
A downside of a shared cache is that workers may spend more time doing
`hg update` operations. e.g. if the last task was from mozilla-release
and the current task is from mozilla-central, thousands of files will
be updated. However, I believe we will still be better off because
separate caches *increase* the probability for a full checkout, which
involves writing ~150,000 files! So I believe this change will lower
the overall amount of VCS work done by workers while possibly
sacrificing the lowest possible execution time (which is achieved by
minimizing the `hg update` work).
It's worth noting that `hg robustcheckout` (which is used by these
tasks) does the equivalent of an `hg purge --all`. This ensures that all
untracked and ignored files from previous tasks are deleted. So there
should be no contamination from previous tasks.
MozReview-Commit-ID: I5Ng3xFEfou
--HG--
extra : rebase_source : db423e5005d1e26d7dfebbbfa28893fc32caef6f
There are various differences between the new ogg player and the old OggReader that leads to inconsistencies on how durations are reported.
1- The old OggReader only use the end time as duration of the video, ignoring the start time of the first sample. This leads to incorrect duration calculation.
2- The OggReader do not ignore undecodable frames located at the beginning of the video, and those are used by the MDSM to calculate the start time. This leads to durations sometimes being shorter than they ought to.
MozReview-Commit-ID: 6yi1P4N6tPE
--HG--
extra : rebase_source : 31c0346c677f07e39c865d4f9f25dc0ebb70b18b
The OggReader always passed a complete ogg_packet to the vorbis decoder, ensuring that the right number of frames was be returned. In the conversion to the new architecture, this information got lost making the vorbis decoder always return more frames than normal on the last packet.
MozReview-Commit-ID: HYHxqXfYntJ
--HG--
extra : rebase_source : 3aa215576fe77357dd9a484626c0e5759aeedb3c
This is not the cleanest approach, but ensures identical behavior with the OggReader when it comes to firing loadedmetadata event and handling the change of seekability.
A more universal solution could be considered involving the MediaFormatReader and changing the MediaDataDemuxer API, of interest would be adding support for a new event fired whenever we have a change of content or metadata (useful with MSE or recorded webm of a WebRTC session
MozReview-Commit-ID: BojB2r1CtA3
--HG--
extra : rebase_source : 04704c13bfbdc83fe7c03505876deb8cda2043e6
A call to reset is always followed by a call to Seek; seeking is an heavy operation with ogg so let's minimize the number of times we are actually seeking.
MozReview-Commit-ID: Jz7dL9IFM14
--HG--
extra : rebase_source : b4c861b5963647292e3c8d8c8b8ac7ce097112fa
Note that the closest keyframes are for video 0.666667 and audio 0.645805, however the current OggReader still incorrectly seeks audio to an
earlier time as it seek to the index page boundary.
MozReview-Commit-ID: 5g7FHFmRQXD
--HG--
extra : rebase_source : cb105bafdf6aaa0f441da5130571b0b0b8e3a3f0
Fast seek in the old OggReader is broken: the audio track isn't seeked to the video track in order to preserve A/V sync and we end up always performing an accurate seek which explain why this test succeeded before.
The page index is only made of two entries, and so the first video frame returned after a seek, if within the first index will always have a time of 0.
MozReview-Commit-ID: 2EYzLMWRZAi
--HG--
extra : rebase_source : a7c73a757a841550cc7c5d2a0a7229a037a2bb9f
r?cpearce
A hack was in place to ensure that the first returned sample would have
a time of 0 so that the media start time would be 0. This was incorrect
for two primary reasons:
- The media start time is adjusted according to the first sample anyway.
- When seeking to 0, the first sample would have a time different to the
first sample decoded (when we want them to have the same time).
MozReview-Commit-ID: IyuT9O2F4EZ
--HG--
extra : rebase_source : 74b29eb5970c67aed6ca568d1882e3b6c54a6637
This ensure that the first sample demuxed will be identical to the first
one demuxed following a seek to the beginning.
Also, only demux the next packet when none is queued rather than all the time.
MozReview-Commit-ID: 5wtFVLiCAW
--HG--
extra : rebase_source : ce73d35f68fb800608a1182843de1d4abd469081
Not on by default yet. use media.format-reader.ogg preference
MozReview-Commit-ID: 7pH67XERTbW
--HG--
extra : rebase_source : 9868f07f622782b4859b95f237f7ee516345c2b2
If the app is build with MOZ_ANDROID_ACTIVITY_STREAM enabled then a preference for
activity stream will appear in the 'advanced' section. All upcoming activity stream
features should check ActivityStream.isEnabled() at runtime.
MozReview-Commit-ID: Hibh1j0lqFo
--HG--
extra : rebase_source : c70ca471361050e0ca613e12ee250bf0cb0cf1a8
JW Wang
eyim
Botond Ballo
Alastor Wu
Jan-Ivar Bruaroey
Wes Kocher
Mike Hommey
David Keeler
Henrik Skupin
Henry Chang
Joel Maher
Benoit Girard
Tom Tromey
Gregory Szorc
Jean-Yves Avenard
Brion Vibber
Sebastian Kaspari