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
Upstream has removed the requirement to set this when
initializing the stream_info struct.
MozReview-Commit-ID: 24OJ550Ral
--HG--
extra : rebase_source : 501fd9f51084a4b6f779462536e94c71cf8c5bb7
If the pending first frame decoding was cancelled, the next call to decode could lead to a crash.
MozReview-Commit-ID: 6Q4eKUzqOly
--HG--
extra : rebase_source : 3640a2edd07fdbd4811295c0088a4086ac579b26
If the pending first frame decoding was cancelled, the next call to decode could lead to a crash.
MozReview-Commit-ID: 6Q4eKUzqOly
--HG--
extra : rebase_source : 620efb39265944998c23c184e831a5b71f9b437f
We enable by default the VP9 hardware decoder on intel GPU.
MozReview-Commit-ID: FzMzbpZErjQ
--HG--
extra : rebase_source : f34c969f7dda1ef24224e982f31d5e43cfae7cc0
When av1 video playback is enabled, declare it as supported
in the webm container in MediaSource.IsTypeSupported.
Also support special mime types of the form
video/webm; codecs=vp9.experimental.<git-commit-id>
so test sites can verify playback support of particular encodings
while the av1 bitstream is under development.
MozReview-Commit-ID: GS4n7cPxfQ7
--HG--
extra : rebase_source : a595942242304ccf97a341474b6e2e1e869e7a77
On android, where decoders can sometimes be recycled, the h264converter can be fed over its lifetime MediaRawData with different mExtraData.
So we need to ensure that not only, the inband ones don't change, but that the out of band one hasn't changed either.
This is a condition we could totally ignore on desktop, as when the resolution change the H264Converter is destroyed.
MozReview-Commit-ID: 7w6ku6by1Qi
--HG--
extra : rebase_source : d35f07b372ef0623dbd74384aa5d3a865a3e067a
The value never changes on a system, so there's no point checking it every single time
MozReview-Commit-ID: KTSslluQsKw
--HG--
extra : rebase_source : 40274727d0e7202087a8282eedb2c78404212f31
The format member isn't set when an audio frame hasn't been decoded yet.
MozReview-Commit-ID: IgUj6bjVzdF
--HG--
extra : rebase_source : bb47fa523384f9a85ee7d0ed5b6de4fe2c73526a
This works around an Android 4.2.2 bug that reports incorrect sizes for hardware buffers.
MozReview-Commit-ID: 4rAu8d1RwOJ
--HG--
extra : rebase_source : f63ad96427b90dc24e0cb84319f256d1ec354b5e
The duration is rounded down to 0 if |frames| is smaller than |mInfo.mRate|.
We should call FramesToTimeUnit() instead.
MozReview-Commit-ID: E7eOQuD48x2
--HG--
extra : rebase_source : 1edabb9a9fe495f89a13df71d73d3b9aef49fa9d
Jean-Yves Avenard
Sebastian Hengst
Carsten "Tomcat" Book
Bill McCloskey
Chris Pearce
John Lin
Makoto Kato
Ralph Giles
Cameron McCormack
James Willcox
Alfredo Yang
JW Wang