There's a strong cycle of references between SamplesWaitingForKey and
CDMProxy that does not get cleared unless keys actually come in. This
causes a leak. One way to avoid that leak is to clear the proxy
reference when the things holding the SamplesWaitingForKey is shut
down.
Differential Revision: https://phabricator.services.mozilla.com/D17960
--HG--
extra : moz-landing-system : lando
Processing MediaCodec output in Android binder threads while flushing
in task queue could cause race condition and leftover frames. Dispatch
the processing to task queue ensures all frames prior to flushing will
be cleared (by mDecodedData.Clear()) or ignored (by mInputInfos.Clear()).
Also consolidate all flushing operations in one task to avoid frame
insertion between emptying mDecodedData and mInputInfos.
Differential Revision: https://phabricator.services.mozilla.com/D15228
--HG--
extra : moz-landing-system : lando
Usually the threshold is reset internally in MediaDataDecoder subclasses
that support the hint in their Flush() implementations so the value
will start fresh after seeking completed. But sometimes when there are
consecutive seek requests, MediaFormatReader::DecoderData::Flush() could
return early because DecoderData::mFlushed stays true when there is no
sample demuxed yet, and the threshold will not be cleared. Also, in
MediaFormatReader::SetVideoDecodeThreshold() we decide not to set the
hint when the seek target is close to EOS by checking the existence of
the next keyframe, and that could fail when there are gaps between MSE
buffered ranges. To make sure the hint is never out of date, we should
clear it rather than leaving it untouched.
Differential Revision: https://phabricator.services.mozilla.com/D15227
--HG--
extra : moz-landing-system : lando
Explicitly store the crypto scheme being used on our crypto structs to let us
differentiate between cenc and cbcs data. In doing so remove mMode and replace
mValid with IsEncrypted() for the following reasons:
- Different modes within the existing schemes are not currently utilized by the
spec: the scheme implies mode. Having a mode and a scheme could lead to confusion
between the two. We can return mMode if ever needed by the spec --
possibly if the isProtected flag which we were tracking with mMode, is
ever changed to be more than a bool in the spec.
- mValid was typically used to check if these structs contained valid crypto
data or not. With only one scheme this was often shorthand for 'IsEncrypted',
but with multiple schemes what is considered valid data for one may not be for
another. Do away with this and just explicitly have an 'IsEncrypted'.
Differential Revision: https://phabricator.services.mozilla.com/D15874
--HG--
extra : moz-landing-system : lando
Explicitly store the crypto scheme being used on our crypto structs to let us
differentiate between cenc and cbcs data. In doing so remove mMode and replace
mValid with IsEncrypted() for the following reasons:
- Different modes within the existing schemes are not currently utilized by the
spec of implementation. Having a mode and a scheme could lead to confusion
between the two. We can return mMode if ever needed by the spec.
- mValid was typically used to check if these structs contained valid crypto
data or not. With only one scheme this was often shorthand for 'IsEncrypted',
but with multiple schemes what is considered valid data for one may not be for
another. Do away with this and just explicitly have an 'IsEncrypted'.
Differential Revision: https://phabricator.services.mozilla.com/D15874
--HG--
extra : moz-landing-system : lando
Processing MediaCodec output in Android binder threads while flushing
in task queue could cause race condition and leftover frames. Dispatch
the processing to task queue ensures all frames prior to flushing will
be cleared (by mDecodedData.Clear()) or ignored (by mInputInfos.Clear()).
Also consolidate all flushing operations in one task to avoid frame
insertion between emptying mDecodedData and mInputInfos.
Differential Revision: https://phabricator.services.mozilla.com/D15228
--HG--
extra : moz-landing-system : lando
Usually the threshold is reset internally in MediaDataDecoder subclasses
that support the hint in their Flush() implementations so the value
will start fresh after seeking completed. But sometimes when there are
consecutive seek requests, MediaFormatReader::DecoderData::Flush() could
return early because DecoderData::mFlushed stays true when there is no
sample demuxed yet, and the threshold will not be cleared. Also, in
MediaFormatReader::SetVideoDecodeThreshold() we decide not to set the
hint when the seek target is close to EOS by checking the existence of
the next keyframe, and that could fail when there are gaps between MSE
buffered ranges. To make sure the hint is never out of date, we should
clear it rather than leaving it untouched.
Differential Revision: https://phabricator.services.mozilla.com/D15227
--HG--
extra : moz-landing-system : lando
In libavcodec 58 and later, the old avcodec_decode_video2 is broken and only return the first visible frame found after a VP9 super-frame.
This resulted in some YouTube videos for about 10% of the frames to never be returned.
Only the new API properly behaves so we upgrade our code to use it.
Differential Revision: https://phabricator.services.mozilla.com/D14682
--HG--
extra : moz-landing-system : lando
Latest dav1d version supports to store the timing information in undecoded frame and restore it later from decoded picture. This can provide more accurate timing especially during drain. In additionto that, colorspace information is set according to the size of the image. Finally this patch addresses some style comments.
Differential Revision: https://phabricator.services.mozilla.com/D13428
--HG--
extra : moz-landing-system : lando
Latest dav1d version supports to store the timing information in undecoded frame and restore it later from decoded picture. This can provide more accurate timing especially during drain. In additionto that, colorspace information is set according to the size of the image. Finally this patch addresses some style comments.
Differential Revision: https://phabricator.services.mozilla.com/D13428
--HG--
extra : moz-landing-system : lando
Child processes cannot access textures allocated in the parent process,
which is needed by the compositor to render video elements efficiently.
Unfortunately, Android doesn't expose Sufrace buffers (sharable across
processes) in the SDK/NDK as other platforms, so we need to generate
extra texture/surface in the child process and update texture images
through the surface, which is passed to the parent process for the remote
texture to copy its contents into.
Differential Revision: https://phabricator.services.mozilla.com/D11939
--HG--
rename : mobile/android/geckoview/src/main/aidl/org/mozilla/gecko/gfx/ISurfaceAllocator.aidl => mobile/android/geckoview/src/main/aidl/org/mozilla/gecko/gfx/SyncConfig.aidl
extra : moz-landing-system : lando
Due to changes in where things end up in the unified builds.
Depends on D8482
Differential Revision: https://phabricator.services.mozilla.com/D8483
--HG--
extra : moz-landing-system : lando
We also set the TrackInfoSharedPtr to each decoded sample so that on decoder that can be recycled (android) the frames are displayed with the right size.
Depends on D11588
Differential Revision: https://phabricator.services.mozilla.com/D11589
--HG--
extra : moz-landing-system : lando
And use it to determine if a frame is a keyframe, its size and display size.
Differential Revision: https://phabricator.services.mozilla.com/D11588
--HG--
extra : moz-landing-system : lando
- also makes RemoteMediaDecoder generic so it can work with the remote decoders on the RDD process
- changes VideoDecoderChild to subclass IRemoteDecoderChild
Differential Revision: https://phabricator.services.mozilla.com/D8482
--HG--
rename : dom/media/ipc/RemoteVideoDecoder.cpp => dom/media/ipc/GpuDecoderModule.cpp
rename : dom/media/ipc/RemoteVideoDecoder.h => dom/media/ipc/GpuDecoderModule.h
extra : moz-landing-system : lando