Some encrypted MP4 streams don't contain PSSH boxes in their MOOV boxes, but
they still have tracks with valid TENC boxes which we still parse. So we need
to consider media encrypted if any of its tracks have crypto meta data, rather
than only if the media has crypto init data.
The WebM demuxer's crypto init data is all the tracks' crypto meta data, so
WebM isn't broken by this change.
MozReview-Commit-ID: 1qOi4uTtCE3
--HG--
extra : amend_source : 0f266976a3d65fb8dc720cd40d70bd6da1712420
Warnings were provided earlier on and got removed. So we instead make it consistent across all decoders.
MozReview-Commit-ID: 53obtEClq98
--HG--
extra : rebase_source : f2e22e0d8ff33e8198b39f5a955b8f233a97daa6
We provide even further details for the GMP decoder. Other decoders to follow.
MozReview-Commit-ID: 7NxJPec8xWv
--HG--
extra : rebase_source : f44120983070e5c107ecd5cafc762da90aab44bf
The MediaFormatReader will no longer attempt to decode several frames in advance and ahead of the MDSM actually requesting it. The speed advantages were dubious at best, and as most MediaDataDecoders abused the use of InputExhausted callbacks we had to place artificial throttle that would often cause side effects.
As such, it is now expected that the MediaDataDecoder will now always call InputExhausted once Input has been called. InputExhausted indicates that the current decoding session has completed and the MediaDataDecoder is waiting for another input.
MozReview-Commit-ID: 9KUpNP9jozV
--HG--
extra : rebase_source : d261a5eb98de54d5bd29acb738c4205c56abca6b
The MediaFormatReader will no longer attempt to decode several frames in advance and ahead of the MDSM actually requesting it. The speed advantages were dubious at best, and as most MediaDataDecoders abused the use of InputExhausted callbacks we had to place artificial throttle that would often cause side effects.
As such, it is now expected that the MediaDataDecoder will now always either return a decoded sample or call InputExhausted. Never both.
MediaDataDecoder will continue to work as-is, even if they call InpuxExhausted too many times as the MediaFormatReader will only feed a single sample at a time.
MozReview-Commit-ID: 9KUpNP9jozV
--HG--
extra : rebase_source : ebb919fd3f1ce1adf5d08ed3f4292839b84c8321
This member is only assigned but never used now.
MozReview-Commit-ID: IbuAbRaXzc4
--HG--
extra : rebase_source : 166bd3bc7478f725b64b5b2a0e8e258980674d06
This reverts commit 5a949eb358e27
Another more complete solution will follow.
MozReview-Commit-ID: K3lTdrBxW7W
--HG--
extra : rebase_source : d0f9443193b0816ae85972a4a368599b872fd437
ReleaseResources() is called when MDSM enters dormant or during shutdown.
When it is called in response to dormant request, we don't want to clear
current frames so we are able to enter dormant state more aggressively
even when the media element is visible to the user.
When it is called from MediaDecoderReader::Shutdown(), it doesn't really
call ClearCurrentFrame() because MediaFormatReader::Shutdown clears the
|mVideoFrameContainer| pointer. So it doesn't make a difference to remove
the call.
MozReview-Commit-ID: IakGHbSMWTv
--HG--
extra : rebase_source : 7a25de39e04f5c7728bf65fcd447cc67b7a85411
extra : source : 44ff0ffaf63ad51a7a382cf0ee1c16e64ade63b9
Bubble information from SamplesWaitingForKey to an HTMLMediaElement so that we
can emit a waitingForKey event. If we are unable to decode more samples due to
needing a key the event will be signalled. See
http://w3c.github.io/encrypted-media/#dom-evt-waitingforkey for more information
on this event.
The code in place before this patch handles updating readyState when we are
waiting for a key, this patch adds the event which should be emitted in such a
case. The spec defines certain preconditions should be the case before running
the algo to emit this event. For example, the element should potentially be
playing, and it should have at least HAVE_FUTURE_DATA ready state. This is not
strictly true for when the new code is run, due how existing code handles ready
state. We are honoring the spirit of the spec, though the letter of the spec is
lightly gone against in the handling of the preconditions.
MozReview-Commit-ID: LKlDd4wkRSE
--HG--
extra : rebase_source : 2c61fc41636e430afa23240ad5d26c886124d87f
With MSE, the actual duration is always exact as it is amended when data is added. We do not want to fire ended when we attempt to seek to unbuffered data once endOfStream has been called. Instead we will fire the waiting event.
MozReview-Commit-ID: Cl2uBLk2qRQ
--HG--
extra : rebase_source : 6763c6f5a6e15264e276e486fab4d39491ea7f1b
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
So, we have 4 boolean variables and here is the truth table.
Case 1, 2, 3, 4, 7, 8, 10 and 12 are not possible to happen.
Then, the remaining cases could be clustered into three categories:
(1) Case 5, 9 and 13: no sample is demuxed at all, return 0.
(2) Case 6, 11, 14 and 15: either audio or video is able to be demuxed, return the known value.
(3) Case 15: both audio and video are demuxed, return the minimum of the values.
For simplifying the logic, I will initialize the audioStartTime and videoStartTime
to be INFINITY if we don't have the first-demuxed sample, otherwise, initialize
them to be the real first-demuxed sample's time.
Then, the final calculation will be:
(1) Case 5, 9 and 13: the minimum of two INFINITY values is still INFINITY, return 0.
(2) Case 6, 11, 14 and 15: return the minimum of one real first-demuxed-time and the INFINITY.
(3) Case 15: return the minimum of two real first-demuxed-time values.
Case HasAudio HasVideo HasAudioSample HasVideoSample ExpectedResult
---------------------------------------------------------------------------------------------------
1 F F F F not possible
2 F F F T not possible
3 F F T F not possible
4 F F T T not possible
---------------------------------------------------------------------------------------------------
5 F T F F return 0
6 F T F T return video sample
7 F T T F not possible
8 F T T T not possible
---------------------------------------------------------------------------------------------------
9 T F F F return 0
10 T F F T not possible
11 T F T F return audio sample
12 T F T T not possible
---------------------------------------------------------------------------------------------------
13 T T F F return 0
14 T T F T return videoSample
15 T T T F return audioSample
16 T T T T return min(auidoSample, videoSample)
MozReview-Commit-ID: ANsYDth7slJ
--HG--
extra : transplant_source : %DAj%1A%EC%19%82%7B%B3%05%FE%21%04a%16%9A%9F%18x1%95
Replace the pointer of VideoFrameContainer with the pointer of MediaStreamVideoSink.
MozReview-Commit-ID: 5bqEMpemwuR
--HG--
extra : transplant_source : %008z%D8W%EE%87%8E%E9/%2CT%26%EBvo%AE%099%A6
Replace the pointer of VideoFrameContainer with the pointer of MediaStreamVideoSink.
MozReview-Commit-ID: 5bqEMpemwuR
--HG--
extra : amend_source : 7eb1e87fdcbc61f2f9831fa3a6d803cc50306604
Replace the pointer of VideoFrameContainer with the pointer of MediaStreamVideoSink.
MozReview-Commit-ID: 5bqEMpemwuR
--HG--
extra : transplant_source : %9D%86%93%A6%DF%D5%9Ep%20%DF%FD%C1%E2%BA%A3Gq%1A%7E%A3
FrameStatisticsData can now store inter-keyframe information, which is
provided by the MediaFormatReader (based on live decoding).
MozReview-Commit-ID: HhBy6pgT6ZX
--HG--
extra : rebase_source : 6a072623e8a5b0f23b81307e8ea4b19a3e21b252
Decoders now use FrameStatisticsData to gather data for their frame-related
notifications. This will ease introducing new members later on.
MozReview-Commit-ID: DWdOSPX3JM
--HG--
extra : rebase_source : a3e05f34353a397d1c82b3f4d935c0864f90556e
Handle encrypted WebM streams for the clearkey case. Add checking for the
widevine case, though these should currently fail, as not all of the plumping
is in place for widevine.
MozReview-Commit-ID: 5d9fvc5IkZF
--HG--
extra : rebase_source : 9baad2afd7778c350c404c72dcd81426092aa908
Extract all the parameters passed to CreateAudioDecoder/CreateVideoDecoder and
place them into a structure that is passed down to the creation of the actual
decoder, where the relevant parameters can be extracted.
This makes it easier to add more arguments to the Create*Decoder calls in future.
MozReview-Commit-ID: 9LZlcfRVz6A
--HG--
extra : rebase_source : ce3f0c7d0784b96267728697ff5d535ccb8ee7a6
Carsten "Tomcat" Book
Chris Pearce
James Cheng
Jean-Yves Avenard
Matt Woodrow
Phil Ringnalda
Kaku Kuo
JW Wang
Iris Hsiao
Bryce Van Dyk
Nicholas Nethercote
Kaku Kuo
ctai
Sebastian Hengst
Eugen Sawin
Gerald Squelart
Dan Glastonbury
Alfredo Yang