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
Now that the Firefox UI tests are in the tree, this is possible and less
of a pain. Unfortunately, due to bug 1228446, this test is disabled for
e10s.
MozReview-Commit-ID: A16EVJ8eYyB
--HG--
extra : rebase_source : 3d7b1401a4bafcd7c4bcb0804fe8c98a804a2611
There are some packages like 'requests' that are bundled in the mozharness venv, but not in the test
package. It would be easy to manually add these to sys.path in the mach bootstrap script, but it's
much nicer to simply activate this virtualenv in the first place.
MozReview-Commit-ID: 8xeJEIgUbLj
--HG--
extra : rebase_source : b87e5ef46041d9d5a89d419e97fe3a316de6c8c2
Because it is now possible for options.app to get set after 'parse_args' time, we need to make sure
the argument validation happens later. To accomplish this we pass in the parser instance to
'run_test_harness' and do parser.validate there. This unfortunately requires some minor uses of
global to accomplish easily due to how mach handles parsers.
MozReview-Commit-ID: s3Js1aZlSE
--HG--
extra : rebase_source : 3a94debda3dbed839074094707cadf32e7f7337c
The audio should only be resumed when we lose audio-focus transiently. Eg. interrupt by ringtone or telephony.
MozReview-Commit-ID: 78QHSqxEhcp
--HG--
extra : rebase_source : e6e1f2f85b0082a5729b31c0b81aa579b623ff26
- Update the tooltool manifests to use the new package.
- Update mozconfig paths to reflect MSVC tooltool package changes.
--HG--
extra : rebase_source : 2f2da35ec1d1b3fb5ca9210951d9ac3a38a2bd75
While we're here changing the MSVC tooltool package, and since we're
going to remove the INCLUDE and LIB lines from mozconfigs that contain
the SDK version, we might as well make the SDK in the tooltool package
closer to an actual SDK, so that automation and local build more or
less follow the same (upcoming) configure code path.
--HG--
extra : rebase_source : d760931fd721df1a6b27ae8caee37874eb1252f5
