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
The android 5.1.1 OMX decoder claims to support audio/opus
but crashes on the output of our mp4 demuxer. Work around
this by rejecting the mime type, allowing fallback to the
libopus-based AgnosticDecoderModule.
In any case, since we're shipping the libopus-based decoder
we're prefer to use it for consistency.
MozReview-Commit-ID: GQaTMALajnZ
--HG--
extra : rebase_source : fb43ddc6bd7b5ed92308124045ad2330a8043f46
If "media.libavcodec.allow-obsolete" is set to true, the checks for older
libavcodec library versions are ignored.
MozReview-Commit-ID: HBhHfFomsrr
--HG--
extra : rebase_source : 6bfe06bd4354fcda90d7d33bedcbd176663cab31
FFmpegLibWrapper returns a precise success/failure code.
FFmpegRuntimeLinker uses that to record the most interesting issue and
associated library name (if any).
MozReview-Commit-ID: J7asDfngw5e
--HG--
extra : rebase_source : 206c5bccc1ca2e2284dd836aef4b4781447459b2
The WMFDecoderModule can override Supports(TrackInfo) to reject resolutions
that we know are too big for the platform decoder.
MozReview-Commit-ID: dU905wjZcJ
--HG--
extra : rebase_source : 40e5987deeffff652a88264f157391c0dbc0a2da
Add a new method alongside SupportsMimeType, which takes a TrackInfo that may
contain more information that just the MIME type.
Eventually the old SupportsMimeType should be removed, but we keep it for now,
as it is used quite extensively and it would be out of scope of this bug to
totally replace it now.
MozReview-Commit-ID: LJQBvSUB6J2
--HG--
extra : rebase_source : 6f43bf61dc6e51de3714c9a556428c7ba4fd484d
When we add SPS/PPS NAL in front of each keyframe data, this somehow makes the WMF decoder to misbehave and to always return an invalid timestamp.
MozReview-Commit-ID: 2SzTiwP0ii1
--HG--
extra : rebase_source : b499c83d504df772e6d722053630ff4d92306d4f
I was able to reproduce the crash in CMFPropertyStore::CreatePropertyStore
once when running under Win95 Compatibility mode. Normally Firefox crashes
trying to start up under Compatibility mode, so it's hard for me to verify
that this patch fixes the crash. We'll just have to push it and see.
In compatibility mode, GetVersionEx() returns the Windows version being
emulated, so if we add version checks around where we start up WMF, we
should catch the users running in compatibility mode.
We can also refrain from starting the RemoteDecoderModule if we're not
going to be able to use WMF in the GPU process; if we're on Windows less
than Vista, or if we're emulating Windows less then Vista.
MozReview-Commit-ID: Iu4B1NcgHio
--HG--
extra : rebase_source : 80e9f446a60c7f4edcb1219ec2702e68376e3aa0
We already report failure in |LoadDlls| on the initial failure to load, there's
no need to warn more than once per session.
MozReview-Commit-ID: FhsR2ZaMSLT
--HG--
extra : rebase_source : ae7d94af5c9d9253b82b2d45dc6967b5b21c6492
Add jni::IsFennec() that returns whether we're in a Fennec environment
(defined as the presence of the GeckoApp class). Then, add
jni::IsFennec() checks to places where we use JNI for Fennec-only classes.
This allow consistency between platforms. A decoder will now always be shutdown and another one created if the video configuration changes.
MozReview-Commit-ID: 1SPzhVuBrip
--HG--
extra : rebase_source : f4d0347c4686d2f3ec0e4cf065a6c3fa36b7ea06
