Note CompletedState doesn't need to check this flag because prerolling should be done when entering the COMPLETED state.
MozReview-Commit-ID: 4Z7mFYf7wdR
--HG--
extra : rebase_source : fba2f8dfb7544225531e8b816154205d42cf9784
extra : source : 3335ed64b39859a2211017a5794ff46da2ce605c
Because we haven't decoded any data and are at position 0, there is no need to seek when exiting the dormant state.
MozReview-Commit-ID: AKAcqW3HfRN
--HG--
extra : rebase_source : 45056ef8a67a2869b90ea3b1ab842bfca310b9aa
extra : source : 2dc17c8ca765eee1d05956b087804bb760af0e48
VisibilityChanged() could be called before reading metadata.
MozReview-Commit-ID: F3OIiC4mXo3
--HG--
extra : rebase_source : 2ce037b5bbdd4a8e58a59c1efe1026339b492644
extra : source : bcc536974529f4e3330e297b2f8b10c0f9fc92c2
This makes us match the spec and pass more cases of
http://www.w3c-test.org/encrypted-media/drm-mp4-syntax-mediakeysystemaccess.html
but we still need to adjust the test so that it's consistent, as pointed out
by bz.
MozReview-Commit-ID: KEfRk4QnJKR
--HG--
extra : rebase_source : feba0407aa8742b58b8f976bf31a494ea65c5319
Bug 1307016 attempted to address issues with output not being ascii and thus
being incompatible with terminals on test machines. However my changes in that
bug introduced two issues:
- They introduced a bug where field names were being read from an incorrect
source.
- They attempted to construct a string internally then converted that string to
ascii replacing non-ascii chars. This is an issue as in python 2 strings are
implicitly ascii, so the initial conversion to a string would fail if the
underlying object couldn't be represented as ascii.
Both of these issues are addressed here. The first by fixing the bad source in
the code, the second by converting to unicode for the intermediate
representation.
MozReview-Commit-ID: HC6Fd9TLRe2
--HG--
extra : rebase_source : bb7493b9074baa0273fb4110465f8bd13477f1d6
Now that we can link gmp-clearkey's PSSH parser into Gecko, we can
simply use that inside MediaKeySession to validate that the CENC
init data matches the spec.
This change enforces that CENC init data uses the common system Id.
As far as I can tell, Widevine only uses that now.
MozReview-Commit-ID: HrlKQHcv5DI
--HG--
extra : source : f61138f1030e87026eb432e83d36e46c81e55b33
Use a WebIDL dict to define the "keyids" EME init data format, and
then use that to parse and validate incomint "keyids" EME init data
and ensure it's in the expected JSON format, i.e.:
https://w3c.github.io/encrypted-media/format-registry/initdata/keyids.html
This means we now pass the "generateRequest() with too short key ID."
case of encrypted-media-generate-request-disallowed-input.html
(upstream that is, our local copy of that WPT is out of sync).
MozReview-Commit-ID: 6W7j2a9Bg7E
--HG--
extra : source : fed2a26df89a5c2a600a6e6d1ab63ab86706fc45
Implement more of MediaKeySession.generateRequest() to validate initData before
passing to CDM.
Also throw TypeErrors when initData is not valid, as per the spec.
Only trivial validation happens here, I'll add more comprehensive validation in
subsequent patches.
MozReview-Commit-ID: 3jTOsJNvRDo
--HG--
extra : source : d023aec75d1ef1486116510efcc31e2b587e6e50
The WMFDecoderModule can override Supports(TrackInfo) to reject resolutions
that we know are too big for the platform decoder.
MozReview-Commit-ID: dU905wjZcJ
--HG--
extra : rebase_source : 40e5987deeffff652a88264f157391c0dbc0a2da
MP4Decoder can translate the new MediaContentType into the relevant TrackInfo
to interrogate PDMs about codec support, with extra information if present.
MozReview-Commit-ID: K0jcYm8pJrp
--HG--
extra : rebase_source : e809824285a85035b81ad7f91406bce6393384f6
Add a new method alongside SupportsMimeType, which takes a TrackInfo that may
contain more information that just the MIME type.
Eventually the old SupportsMimeType should be removed, but we keep it for now,
as it is used quite extensively and it would be out of scope of this bug to
totally replace it now.
MozReview-Commit-ID: LJQBvSUB6J2
--HG--
extra : rebase_source : 6f43bf61dc6e51de3714c9a556428c7ba4fd484d
Create a TrackInfo (VideoInfo or AudioInfo) from a codec MIME type, and
optionally with extra parameters from a MediaContentType.
MozReview-Commit-ID: JfDMQjVgCNT
--HG--
extra : rebase_source : 10eb8f14ce28a74883752c536b2312658bc0cb4d
Just passing the new MediaContentType struct, with no processing changes (yet).
MozReview-Commit-ID: KZ4xkCihPb1
--HG--
extra : rebase_source : e40eb72cc63e0a814306c25ea9b609178517729e
