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
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
Remove string comparisons to determine from mime types if content is VPX or
H264. Replace with calls to VPXDecoder::IsVPX or MP4Decoder::IsH264 to
centralise such logic.
This patch introduces MP4Decoder:IsH264, and moves the similar functionality out
of H264Convertor for the sake of consistently having these functions in
decoders.
MozReview-Commit-ID: 5nfYusYHrUR
--HG--
extra : rebase_source : c013c4ebe28d5afedbb91ddfffadb40d23fd0ee3
