As of bug 1325299, WINVER is always >= 0x0601 (Windows 7).
MozReview-Commit-ID: BJYg9d3zuYx
--HG--
extra : source : 4eff752dd001a722fe1d8e60e56ccb5f70c8d872
This is a big change, and unfortunately impossible to break down with independently functional commits.
There are four main changes being applied here:
* Code cleanup, including making all MediaDataDecoder related code mozilla coding style compliant
* Make MediaDataDecoder use MozPromise
* Making Flush and Shutdown processes fully asynchronous
* Fixing few data races encountered across the code, in particular in the Android PDM
MozReview-Commit-ID: DpiZucGofJT
--HG--
extra : rebase_source : 80bd6c6f9726d536b6f306c40d9af6df27333be9
Previously the combined tests meant that if a track was H264, and we supported
H264, BUT media.wmf.allow-unsupported-resolutions==true, we would just skip the
whole block, meaning we would return 'false' (unsupported) in the end.
Instead, if a track is H264, and we support H264, we should return 'true'
(supported), unless media.wmf.allow-unsupported-resolutions==false and the
resolution is too high.
MozReview-Commit-ID: 5YUhlxmfPIO
--HG--
extra : rebase_source : 48fdcdc0ec83368fe1e97f30d87fb9384129700f
When MFT returns MF_E_NOTACCEPTING means the input buffer is full and it can't
accept input data anymore, so we need to output the data first and then resummit
the input data.
MozReview-Commit-ID: DfSTASsEX7r
--HG--
extra : rebase_source : fd3cff6284345872dd580fbd0568d99129af936c
When we want to decode with DXVA2 aPI directly instead of using it by MFT, we need to take responsibility for
creating a decoder and handle the related decoding operations by ourself. So implement a method to create and
hold a ref to DXVA2 decoder for DXVA2Manager.
MozReview-Commit-ID: 4EyrsjzEyYK
--HG--
extra : rebase_source : 6719bfe15243395711984d66919baca2bb74699e
Reversing bug 1313343, as MediaPrefs are not available from the UI process.
Instead media.wmf.skip-blacklist is used when setting D3D-blacklisting gfxVars,
leaving them empty if we want to skip these blacklists.
MozReview-Commit-ID: JYED4ovC0jq
--HG--
extra : rebase_source : 087230ba95927ced52d7af502b96a988b4077c31
If pref "media.wmf.skip-blacklist" is true, disable D3D blacklisting based on
"media.wmf.disable-d3d9-for-dlls" and "media.wmf.disable-d3d11-for-dlls".
MozReview-Commit-ID: IothZlUnK7h
--HG--
extra : rebase_source : 1731b39808526fce70d84342a016bd25b6cd8571
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
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
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
We provide even further details for the GMP decoder. Other decoders to follow.
MozReview-Commit-ID: 7NxJPec8xWv
--HG--
extra : rebase_source : f44120983070e5c107ecd5cafc762da90aab44bf
If initializing DXVA fails, we end up destroying the DXVA2Manager on the
decode task queue. The DXVA2Manager asserts that it's destroyed on the
main thread, so we should dispatch a task to destroy it on the appropriate
thread instead of destorying it on the wrong one.
MozReview-Commit-ID: 2pbeMOm74et
--HG--
extra : rebase_source : c4a6871877747d4e04494c638d83b225decaf249
The WMF decoder doesn't handle well the case where a single frame was given to decode.
When draining, the output is a correctly decoded frame but with a time of 0 and a duration set at 1/30th.
This is a workaround
MozReview-Commit-ID: JbjgNmPXKIM
--HG--
extra : rebase_source : f25a1fd503678383265ec5053b41f3116ff52da0
We've had large numbers of shutdown hangs with the Windows H.264 decoder stuck
calling IMFTransform::ProcessOutput(), blocking shutdown. I can reproduce this
with videos with dimensions less than 32 pixels.
Chrome also encountered this with the WMF decoder:
https://bugs.chromium.org/p/chromium/issues/detail?id=373288
The WMF H.264 Decoder is documented to have a minimum resolution of 48x48 pixels.
So this patch causes us to reject H.264 files with either width or height less
than 48 pixels.
I have been able to play files down to 34x34 pixels on Windows 10, but it seems
safest to just follow the what's documented in MSDN, and reject files that are
smaller than the documented minimum.
MozReview-Commit-ID: 5peP6UGnAaB
--HG--
extra : rebase_source : 6e29812642bc3f8ca0f5b39b36064a6d50e09ea7