Summary:
By default, when creating a H264 decoder it is wrapped into a H264Converter which will only create the actual decoder once a valid SPS/PPS has been seen.
As creating valid SPS/PPS NALs isn't trivial, when all we care about are capabilities of such decoder, we do not wrap the decoder so that it will be immediately created.
We can then test its capabilities.
We only enable this on windows, as on mac we need to generate a SPS/PPS, otherwise the mac decoder always report that HW decoding is not enabled.
Depends on D1632
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1633
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
It's a concrete class of OmxPlatformLayer for accessing OpenMAX IL
libraries directly. It will be usable on various embedded linux systems.
Note that it's not enabled by default yet. Add the following config to
your mozconfig.
ac_add_options --enable-openmax
TODO: Implement zero-copy mode
MozReview-Commit-ID: EMEXAKzzR64
--HG--
extra : rebase_source : ee6acf7d046e8ce6e18a53988a4ea308b8d4d44f
This patch converts all the prefs in MediaPrefs to the new StaticPrefs system.
Note that the "media.wmf.skip-blacklist" pref was present in both MediaPrefs
and gfxPrefs. The copy in MediaPrefs was never used; this explains why this
patch does not add an entry for it to StaticPrefList.h.
Note also that the patch removes themedia.rust.mp4parser pref, because it's
unused.
MozReview-Commit-ID: IfHP37NbIjY
--HG--
extra : rebase_source : df84ea813b7c366d7be663c696891325610149c8
It's a concrete class of OmxPlatformLayer for accessing OpenMAX IL
libraries directly. It will be usable on various embedded linux systems.
Note that it's not enabled by default yet. Add the following config to
your mozconfig.
ac_add_options --enable-openmax
TODO: Implement zero-copy mode
MozReview-Commit-ID: EMEXAKzzR64
--HG--
extra : rebase_source : d7c5b9baf66d87db38723b278c57fd581a3cbf98
extra : intermediate-source : b8c671a02a4fce085433b16db998c9b04ace87db
extra : source : 131b65580e3dd5c9dcb0ba6a05c16ab90c2dcc68
Automatic conversion (say from int to bool) makes DecoderParam difficult to extend.
MozReview-Commit-ID: G0T7jPogskN
--HG--
extra : rebase_source : 59437fd2b430ccd6be50b18c98b5a5c4ed2c8240
Change mLastError type to MediaResult and send it as parameter to PDM::CreateVideoDecoder
in order to get detailed error description.
MozReview-Commit-ID: 4sIRXTHsrzr
--HG--
extra : rebase_source : 23d72cc72f5683305745024de913f44298d717d5
Change mLastError type to MediaResult and send it as parameter to PDM::CreateVideoDecoder
in order to get detailed error description.
MozReview-Commit-ID: 4sIRXTHsrzr
--HG--
extra : rebase_source : 23d72cc72f5683305745024de913f44298d717d5
The TrackInfo [1] created in WMFDecoderModule::SupportsMimeType() doesn't contain valid image's width and height, because the TrackInfo is created without width and height [2] and the default width and height are both -1 [3].
Thesefore, we can't correctly check whether this resolution is supported by MFT [4]. We should use Supports() instead of SupportsMimeType().
[1] https://goo.gl/QV8Jgm
[2] https://goo.gl/4siShn
[3] https://goo.gl/BDoXYf
[4] https://goo.gl/BZh4QA
MozReview-Commit-ID: 4dIJ84eaytq
--HG--
extra : rebase_source : 1ac63d25d3c7473f9bfd595432273460649a26f1
The AndroidDecoderModule will be added into PDM queue twice if both PDMAndroidMediaCodecEnabled and PDMAndroidMediaCodecPreferred are set to true. It should be inserted into the head of the PDM queue in this case, and appended to the tail if only PDMAndroidMediaCodecEnabled is true.
MozReview-Commit-ID: Fj0z0meeb1V
--HG--
extra : rebase_source : 1d7f2b10fd4360d3f641ad6517e9f95afcb99768
It is no longer used and in its current state incompatible with promise based decoders.
We'll re-add it later.
MozReview-Commit-ID: DHsyTsFvTZB
--HG--
extra : rebase_source : 4b1a7dba2a001ff32ffe4ef4df63b91f15a43e83
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
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
