This function now always returns false (since bug 1253395), so
WMFDecoderModule::HasH264 doesn't need to call it anymore.
Note that we are keeping the code, as we will slightly modify it in the next
patch for a different use.
MozReview-Commit-ID: 7fzktsnFU2m
--HG--
extra : rebase_source : e7538ae792b7c31393079244a286c340d798588d
Additionally, we disable hardware decoding on those systems.
MozReview-Commit-ID: 9zzUJ0utqQm
--HG--
extra : rebase_source : 0e7fdaf166a47969338018dea0d5fd9f1efb8d4b
The VP9 decoder doesn't properly set the sample duration, leading to all samples being marked as having a zero duration.
The compositor drops those frames incorrectly. This issue will be addressed in bug 1222874.
MozReview-Commit-ID: JQdtTL4nAN
--HG--
extra : rebase_source : 7c69cd3522c4b2231a07ab3f3c1d012843ac2f69
Using a float to store the last duration was unwise (as it has only a 24 bits mantissa), luckily it wasn't used except very particular circumstances.
MozReview-Commit-ID: BpL8ufQFNeR
--HG--
extra : rebase_source : b4a5a1301be4a0a81d1907b6296cbb4b6c4877d9
SupportsMimeType is called in the content process, for which, following bug 1338011, dxva is marked as disabled.
CanCreateWMFDecoder already performs the check of allowing VP9 only if it's hardware accelerated, so we don't need to test if dxva is enabled prior.
MozReview-Commit-ID: 7Jvaop6ZznU
--HG--
extra : rebase_source : 854e7b09718863e710843d11c9327de47abf1076
We enable by default the VP9 hardware decoder on intel GPU.
MozReview-Commit-ID: FzMzbpZErjQ
--HG--
extra : rebase_source : f34c969f7dda1ef24224e982f31d5e43cfae7cc0
We want to replace the use of int64_t for microseconds by TimeUnit
whenever possible since int64_t is ambiguous which could be microseconds
or milliseconds.
MozReview-Commit-ID: LRz9d4yKBYJ
--HG--
extra : rebase_source : 1f73f1f338142b3183491d04726821a881ccabbe
extra : intermediate-source : 88e167b7b06303d10d92cd5317502f405d1c553e
extra : source : 98deb30ec93d395f9951f5fc488170ae35e29675
1. using media::TimeUnit to save some typing.
2. replace TimeUnit() with TimeUnit::Zero().
3. replace TimeUnit::FromXXX(0) with TimeUnit::Zero().
4. replace TimeUnit::FromMicroseconds(std::numeric_limits<int64_t>::max()) with TimeUnit::FromInfinity().
5. replace some uses of int64_t with TimeUnit.
6. replace t > TimeUnit() with t.IsPositive().
MozReview-Commit-ID: 6hC94PXx86i
--HG--
extra : rebase_source : 1ea3b409e6ec12915f3e1a00359d6ff4152c8917
extra : intermediate-source : e31a12ad0e7a4840119036f261ed17eaaff85734
extra : source : ae07ee48000c4a52da0e4fd502b4d690ec51ce1f
Windows AAC decoder decode a mono AAC stream into a stereo PCM. Bug 1347101 set the output to be mono, which caused a failure to find the appropriate IMFMediaType.
This partially revert bug 1347101 audio changes.
MozReview-Commit-ID: 2M4X4rKKvXl
--HG--
extra : rebase_source : 6b7330a7edfc2c0504171828526221dcccb6f8c5
Under some circumstances, and seen on Windows 8, a decoded sample can be returned without the MFT returning MF_E_TRANSFORM_STREAM_CHANGE.
For historical reasons, we required that message to be returned at least once to set the output image size. This was required as the decoder used to be recycled with different video streams.
This is no longer the case, we can rely on the video info instead. It also greatly simplifies the code
MozReview-Commit-ID: H14KBiNWrjQ
Under some circumstances, and seen on Windows 8, a decoded sample can be returned without the MFT returning MF_E_TRANSFORM_STREAM_CHANGE.
For historical reasons, we required that message to be returned at least once to set the output image size. This was required as the decoder used to be recycled with different video streams.
This is no longer the case, we can rely on the video info instead. It also greatly simplifies the code
MozReview-Commit-ID: H14KBiNWrjQ
--HG--
extra : rebase_source : d098f884127bc95e3ca4363bf3d0cdda6d3bd771
VideoData doesn't care what's in aInfo but display size and aPicture are unused.
MozReview-Commit-ID: IBqq8Rm8dM4
--HG--
extra : rebase_source : 10e2390f87925ef9179d28d86240f68a35c6c6d4
