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
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 reverts commit 5a949eb358e27
Another more complete solution will follow.
MozReview-Commit-ID: K3lTdrBxW7W
--HG--
extra : rebase_source : d0f9443193b0816ae85972a4a368599b872fd437
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
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
A bit of a shot in the dark, but it is possible that data got received but that information got lost as reset was called.
MozReview-Commit-ID: 1KjQeCFsGPJ
--HG--
extra : rebase_source : 3a522045bde0658fdfeccbf4d0cac11b43bc35d7
As the decoder was flushed and reset prior the skip to next keyframe started, and future error would be unrecoverable. So only reset the decoder once the skip completes and succeeded. Otherwise we default back to normal decoding.
MozReview-Commit-ID: GEj1i0EsaYO
--HG--
extra : rebase_source : c1d2beafa6e35f571b941e8f173ec10b726ec1a0
currentTime may be past the start of the internal seek time, but before its end, which would have triggered a false positive: we do not want to jump to the next key frame here.
MozReview-Commit-ID: H5O9XXnk84T
--HG--
extra : rebase_source : 0bc96472acfe03ff0c87a6fc3712bd99b96064b6
With the new video-only seek type, we need to ignore the current audio decoding state whenever video-only seeking is in progress.
MozReview-Commit-ID: 5eynmG2UyyA
--HG--
extra : rebase_source : 7e9bdd7c44cb4a80129bfc468da87288e520c984
MediaFormatReader::mOriginalSeekTarget now has different use and the name was no longer reflective of the actual usage.
MozReview-Commit-ID: Fu0fmgUlbgr
--HG--
extra : rebase_source : 7c106fc4832def7c6a4b91e1950ed5b3e1109129
When resuming from suspended video, don't reset the audio queues or
audio demuxing state in MFR.
Extracted the code from ResetDemuxers() and inlined it at calling sites
as recommended by jya.
MozReview-Commit-ID: 3wpH075RrKW
Implemented by short-circuiting calls to RequestVideoData in MDSM so no
frames are decoded. Resuming playback when video moves to foreground by
using the SeekTask/SeekJob/Seek in MDSM with result of GetMediaTime().
Special consideration is made to only seek the video part of Seek() to
remove an audible glitch in the audio playback when the video becomes
visible again.
MozReview-Commit-ID: 7YFDTanslXu
Access to some members is not thread-safe; but the typical use of those informations is when a mochitest has timed out, and by that time the MFR will have been idled for over 5 minutes.
MozReview-Commit-ID: 21BxrSZXVVJ
Some decoders (WMF) keep some internal counters on how many frames have been output and use this to calculate the time of the decoded audio frame. As such, when internally seeking, the next frame decoded would have always been past the seek target.
MozReview-Commit-ID: puzs6ecqbD
Jean-Yves Avenard
Carsten "Tomcat" Book
Chris Pearce
James Cheng
Matt Woodrow
Phil Ringnalda
Kaku Kuo
Bryce Van Dyk
JW Wang
Kaku Kuo
Gerald Squelart
Jonathan Watt
Eugen Sawin
Alfredo Yang
Dan Glastonbury
Edwin Flores
Kyle Huey