We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
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
As well as the obvious #ifdefs, this allows DOMHwMediaStream to be
removed, and also the "phone-state-changed" observer.
--HG--
extra : rebase_source : 373280183e228bd4b9bd9d866959409f2444c77e
It's silly to use prmem.h within Firefox code given that in our configuration
its functions are just wrappers for malloc() et al. (Indeed, in some places we
mix PR_Malloc() with free(), or malloc() with PR_Free().)
This patch removes all uses, except for the places where we need to use
PR_Free() to free something allocated by another NSPR function; in those cases
I've added a comment explaining which function did the allocation.
--HG--
extra : rebase_source : 0f781bca68b5bf3c4c191e09e277dfc8becffa09
HasSPS, ExtractExtraData and CompareExtraData have nothing to do with the handling of annex B format. They are raw H264 related methods.
It will also prevent in the following change to have cycling references between two headers.
MozReview-Commit-ID: FCs5aU4GcTU
--HG--
extra : rebase_source : a96fe0c70416d38690b0c2f1dee567b0b025e947
HasSPS, ExtractExtraData and CompareExtraData have nothing to do with the handling of annex B format. They are raw H264 related methods.
It will also prevent in the following change to have cycling references between two headers.
MozReview-Commit-ID: FCs5aU4GcTU
--HG--
extra : rebase_source : b204723cdbb599d4f0a227871ed28f5da39e9cff
Additionally, we disable hardware decoding on those systems.
MozReview-Commit-ID: 9zzUJ0utqQm
--HG--
extra : rebase_source : 0e7fdaf166a47969338018dea0d5fd9f1efb8d4b
Allow to get rid of the mPendingSample member, making the logic easier to follow.
MozReview-Commit-ID: F7a25p1TP8J
--HG--
extra : rebase_source : 9413f8a685df44b6e93e7382a0eda77dce27056f
The next version of the Widevine CDM (970) has a new H.264 decoder and it does
not appear to be outputing frames it decodes in presentation order, so we need
to reorder the frames output by the CDM.
MozReview-Commit-ID: HMsQVN3NCIU
--HG--
extra : rebase_source : 68ef406556087434fa12b72ae5ed5c2e1bce2b64
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
Prior bug 1313398, the only time we would call H264Converter::CreateDecoderAndInit was if we encountered AVC3 content where the H264 extradata didn't exist in the metadata.
AVC3 was the only situation where mDecoder would be null after construction.
However, now, it is possible for the construction of the decoder to be interrupted, which would leave mDecoder null. For AVC1 content, if this happened, we wouldn't have in-band SPS/PPS necessary for CreateDecoderAndInit to complete.
So we use whichever extradata is available.
MozReview-Commit-ID: 702xj045LAv
--HG--
extra : rebase_source : e85077cedfece066398e36d8a4dd16f4bd406db6
This is a simpler approach required as both InitPromise and FlushPromise are exclusives.
It's in practice simpler too.
MozReview-Commit-ID: ItaAhC0Bk8T
--HG--
extra : rebase_source : 2c68b8843cfccd784bfcf1ae4fd08407ee891349
On android and devices supporting decoder recycling the decoder would be reset for every new sample not containing inband SPS/PPS
MozReview-Commit-ID: 8BHALsDgPvg
--HG--
extra : rebase_source : 11802954ec0dac885d61aebb9983588daff88dc2
When building Fennec using clang, the following build error occurs.
0:17.02 /mozilla/mobile/media/webrtc/signaling/src/media-conduit/WebrtcMediaCodecVP8VideoCodec.cpp:1099:27: error: 'GetNative' is a protected member of 'mozilla::jni::NativeImpl<mozilla::java::CodecProxy::NativeCallbacks, mozilla::JavaCallbacksSupport>'
0:17.02 JavaCallbacksSupport::GetNative(mJavaCallbacks)->Cancel();
0:17.02 ^
0:17.02 /mozilla/objdir-android/dist/include/mozilla/jni/Natives.h:821:18: note: declared protected here
0:17.02 static Impl* GetNative(const typename Cls::LocalRef& instance) {
0:17.02 ^
We should define GetNative as public into JavaCallbacksSupport.h.
MozReview-Commit-ID: DYEyB2dRK8y
--HG--
extra : rebase_source : 8f77cac02800149aef814ce5fcd7bd3d23b56193
Update our in-tree copy of the aom reference implementation
of the av1 video codec to upstream git commit id
aadbb0251996c8ebb8310567bea330ab7ae9abe4.
This picks up recent changes and addresses a build issue on win64.
MozReview-Commit-ID: 34LXXzFtEFN
--HG--
extra : rebase_source : 0face926928de6bd1c6a1726df912bd20e363e60