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
In practice I'm pretty sure these cases wouldn't have a content docshell anyway.
We probably don't need more robust machinery here, since eventually we'll just
make stylo pref-based for every new prescontext regardless of type.
