So m{Audio,Video}.mDecoder will never reference a half-baked decoder.
MozReview-Commit-ID: FwuzaRR9ugf
--HG--
extra : rebase_source : 32b13b5e3041072bb5e48e6a633281bd8df76a41
extra : intermediate-source : 3d5bc0ca507717f09e1429a5ea05f98e18b48dfc
extra : source : 039ed0007b2e63c381c1ad0f638eed5b4c53266f
While it's unlikely to have been a problem as the decoder would have been idled at this stage. During the time the TrackInfo was reset and the decoder actually be shut down, the reference to the object would have been invalid causing a potential UAF.
MozReview-Commit-ID: 7pGJtYRy2Yr
--HG--
extra : rebase_source : d32b8ff393f55685ef182b00f286aea1d1d75464
The issue is particularly problematic with the Apple audio decoder. The Apple decoder relies on the sampling rate to configure the CoreAudio transform.
The actual output rate may be different (such as with HE-AAC). Should the decoder ever need to be reset again, future initialization would have failed as the initial rate was now incorrect.
MozReview-Commit-ID: 7kTiaUYuOgf
--HG--
extra : rebase_source : 00119a13205c610542a2f690ce6c3b9caeb1b69c
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