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
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
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
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
For channel mapping 0 (which is always mono or sterero), the mapping is identical to the SMPTE one, so can copy the mapping as-is.
Differential Revision: https://phabricator.services.mozilla.com/D11000
--HG--
extra : moz-landing-system : lando
P2 changed the way the H264Converter would be calling the decoder. The assumption in the EMEDecryptor was pretty incorrect to start with.
Depends on D7865
Differential Revision: https://phabricator.services.mozilla.com/D7882
--HG--
extra : moz-landing-system : lando
Update content_decryption_module.h and other Widevine headers. This removes the
CDM8 interface and adds in the CDM10 and CDM11 interfaces. As such this patch
removes references to CDM8 from the code and adds some of the foundations for
supporting CDM10. Most of the CDM10 code will be implemented in another bug, but
there are a number of cases where it was straight forward to shuffle CDM8+9 code
-> CDM9+10, rather than deleting it and replacing it later.
Differential Revision: https://phabricator.services.mozilla.com/D5628
--HG--
extra : moz-landing-system : lando
AV1 support is behind a pref, as such, the result of canPlayType should depends on the value of that pref.
Additionally to this change we remove AOMDecoder::IsSupportedCodec as it implied confusion on what a codec mimetype is. There are two type of codec mimetype: the one describing the container content ("av1") and the one describing the codec itself "video/av1")
AOMDecoder shouldn't know anything about containers (e.g. mp4 or webm)
--HG--
extra : rebase_source : 72ebe662f76fb6c9d8be1f753890601aac440061
AV1 support is behind a pref, as such, the result of canPlayType should depends on the value of that pref.
Additionally to this change we remove AOMDecoder::IsSupportedCodec as it implied confusion on what a codec mimetype is. There are two type of codec mimetype: the one describing the container content ("av1") and the one describing the codec itself "video/av1")
AOMDecoder shouldn't know anything about containers (e.g. mp4 or webm)
This reflects the API changes to the aom_codec_decode function and the removal
of I440. It also sets allow_lowbitdepth to give proper support for 8 bit video,
and removes the git version from the mime type.
MozReview-Commit-ID: GuTvnPkR1Er
--HG--
extra : rebase_source : 4540f74df335d59714a61d5f7e2ad7a54f8fa00d
Summary:
The Apple VT decoder requires SPS+PPS at construction time. If not provided, in earlier macOS it used to give an error. In the current 10.13 it appears to work, however the decoder always report to be software only.
To properly determine the decoder capabilities, we construct a SPS NAL from the codec mimetype provided.
Details on the structure of the mimetype can be found in https://tools.ietf.org/html/rfc6381#section-3.3 and is a 1:1 match with the data found in the SPS.
Depends on D1718
Reviewers: bryce
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1719
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
This patch converts all the prefs in MediaPrefs to the new StaticPrefs system.
Note that the "media.wmf.skip-blacklist" pref was present in both MediaPrefs
and gfxPrefs. The copy in MediaPrefs was never used; this explains why this
patch does not add an entry for it to StaticPrefList.h.
Note also that the patch removes themedia.rust.mp4parser pref, because it's
unused.
MozReview-Commit-ID: IfHP37NbIjY
--HG--
extra : rebase_source : df84ea813b7c366d7be663c696891325610149c8
Returning UniquePtr is nicer than returning raw pointers, and has the
nice side effect of forcing us to clean up the uses of nsAutoPtr that
were hanging about.
Also ensure that the MP4 demuxer can't create such sample.
MozReview-Commit-ID: JANgHNiiz2H
--HG--
extra : rebase_source : d6a68579e76f1eda651e38bec5a9ed17c9de3fa4
Add logging to aid in debugging of our EME ADTS conversion path.
MozReview-Commit-ID: A7Wv8n31V8V
--HG--
extra : rebase_source : 13f20179aa29180047a37a127029d0e28a1c4f80
Update EMEDecoderModule to use 2 as profile number when the given profile is
less than 1 or greater than 4. The CDM doesn't appear to care what values are
given, but 2 was chosen as a safe fallback per discussion on the bug. This
addresses the use case where 0 values are stored in mProfile due to the use of
extended profiles (which are then stored in the mExtendedProfile field).
MozReview-Commit-ID: 5XgabNDsgdf
--HG--
extra : rebase_source : dd66a872aaac2acf4af55f06d3c24f53debe4e63
Under 8 channels, the audio will be reordered so it can be playable on any platforms.
Over 8 channels, the channels will be as output by the decoder. Playing of such stream will be platform dependent as neither Opus nor Vorbis define a channel layout with more than 8 channels.
With WebAudio however, the result will be platform independent (as long as you don't attempt to play it)
MozReview-Commit-ID: 93ATiKm9y20
This makes it for future easier conversion for the FFmpeg and Windows WMF decoder, so that we can use their channel map directly.
Also introduce a difference between 2F2 and QUAD, cubeb supports will be added in a future change.
MozReview-Commit-ID: L5NkjeuGslI
