An invalid webm block at this stage is either a non init segment or non media segment.
MozReview-Commit-ID: 46NrhCwqas1
--HG--
extra : rebase_source : b5be124fc0789cfe0fe757c5fb83f18a769a8bd4
This still requires all the ContainerParser to be updated in properly handling errors.
MozReview-Commit-ID: A7gDmXSJXmc
--HG--
extra : rebase_source : c438fdd40deb843e43f341d107e48171141dc746
Previously two separate monitors were used to find the highest end time, and then work on tracks, introducing the possibility that tracks could be modified between these two operations. Now only one monitor is used to ensure consistency.
MozReview-Commit-ID: 1foB82S6W1Z
--HG--
extra : rebase_source : 817ff8cf231372a4db90b2c11f3bb60d1031fa89
Replace both uses of nsContentTypeParser with MediaContentType.
MozReview-Commit-ID: KV7ze3ASRf3
--HG--
extra : rebase_source : b3d102b02fa671d0a42d70ae7fe66bdd51ac5d86
It's write only, so there's no point storing this, and it's not accurate
anyway, as it's actually tracking whether there's encrypted init data in
the media, not whether its got encrypted tracks.
MozReview-Commit-ID: 78iFUyXwRBV
--HG--
extra : rebase_source : f500b90d32da042a550172128a4c79c142048a98
extra : amend_source : c4e31f686e2c0f2c400225919c45c3a530373a8c
While never evicting less than 512kB saves CPU cycles, it reduces the chances to evict data when we actually need to and requires currentTime to advance much further.
MozReview-Commit-ID: LcQFFtarbbi
--HG--
extra : rebase_source : 381de3d926bbb12377f4332eb87c08b52a56551a
When using gcc on linux, about:media shows incorrect content due to incorrect printf formatter.
MozReview-Commit-ID: IWtl6cX1OFA
--HG--
extra : rebase_source : 392143e1f5a3af3b9353a6824487c328ab9a3878
The MSE specs require a synchronous step which would evict data prior to an appendBuffer. This is however, fundamentally incompatible with our multi-threaded, almost lock-free architecture.
So instead, we keep track of how much data we have prior to currentTime, and check that value before appending new data.
MozReview-Commit-ID: Fl58R7dZsig
--HG--
extra : rebase_source : 41ea607249f94d1e1034055789160fab79616990
Conditions may have changed (such as currentTime moving since the last attempt). So we try again.
MozReview-Commit-ID: 2zexl1FzOd7
--HG--
extra : rebase_source : 5c21f6edc438fb012e18eda45237383fc8b83794
Will allow to pass detailed failure causes in a followup patch.
MozReview-Commit-ID: 5yGjzZNcYWg
--HG--
extra : rebase_source : fdd76c98900320352ee3c349de1c40df29122ca9
Following bug 1301307, exception is properly thrown when buffer is full, giving the opportunity to the JS player to adjust accordingly. Confirmed to work with YouTube with an audio threshold of only 1MB.
MozReview-Commit-ID: 77K8UPhb9zj
--HG--
extra : rebase_source : 64b75f7f563ba9d6fc0c6feeaf7c945894fd6a06
DiscardRemaning was needed to prevent debug-time assertion that the buffer was
read completely or explicitly discarded.
However this required extra work in cases where buffer didn't need to be read
to the end.
And also it could cause crashes (in debug versions) if a buffer was not fully
read, be it because the parser was incorrect or because the media file itself
was wrong (though possibly still readable despite that).
Finding parser issues is still possible by manually instrumenting ByteReader
during development.
And reading media file with small recoverable errors is a bonus.
MozReview-Commit-ID: 2RUYzaYAeRW
--HG--
extra : rebase_source : 26c41758b1b2c87542bf4e41d08e361198ca5b13
The assumption was that the waiting event would be fired once the last frame prior the gap had been played. This is however incorrect, as per spec, the waiting event is to be fired once readyState is <= HAVE_CURRENT_DATA. So the waiting event is actually fired anytime between the start of the last frame and its end.
MozReview-Commit-ID: AA4Qhn7okhB
--HG--
extra : rebase_source : fc1f336b2e07cc2549071563804de8fae9c9ab67
1- We shouldn't reach ended if we have a gap in the buffered range prior the end of the file (see bug 1297036)
2- Waiting should be fired when readyState goes below HAVE_FUTURE_DATA
MozReview-Commit-ID: 18bEnkNpYvO
--HG--
extra : rebase_source : c42c7fd19fec9ede5bb64ea697a0086116882403
The test accidentally worked because any demuxing failures in ended mode would be treated as EOS. There's no audio between [0-3), so playback couldn't start
MozReview-Commit-ID: 4B90CrVUTy4
--HG--
extra : rebase_source : 9079aa8a6983877745baac71c7868ca360b85095
The aim is to only allow skipping gaps of fuzz=500ms.
MozReview-Commit-ID: 8uHxni2nPHI
--HG--
extra : rebase_source : ccef593170fb3a0c3ff61dc97ad1a0508be06934
Seeking in the buffered range should always succeed, even if we have no data in a given track
MozReview-Commit-ID: FGjsDCNIdWC
--HG--
extra : rebase_source : c91348e44055f82deee0e97da4abef0cf799b225
The fuzz value is a +/- one. To check if a target is within an interval
we need to check with half the fuzz only.
MozReview-Commit-ID: J5H5sbNokse
--HG--
extra : rebase_source : aeedcb111c84a353307c8e641385ef0800792fa7
The playing event is sent asynchronously. By the time the playing event
actually gets fired, it is possible that playback has already started.
MozReview-Commit-ID: 1iD3ZSmWtmb
--HG--
extra : rebase_source : c9ea91b5102370f3b063a05f69f7eaf805bd8eb0
The code was designed around the need for a MediaResource::Read which is
no longer possible since bug 1190238
MozReview-Commit-ID: 7s76YWg93jS
--HG--
extra : rebase_source : 3f6756193c352cf766471dd8cb1fb7646af191e6
The MP4 demuxer returns INT64_MAX when all data can be safely evicted
from the MediaResource.
Additionally, the MP4Demuxer will read the MediaResource using
CacheReadAt.
Eviction in the SourceBufferResource had a safeguard to ensure we would
never evict data we hadn't read yet. This was done by keeping the
position of the last data read in the mOffset member. CacheReadAt
however doesn't update mOffset.
As a result, no data was ever removed from the input buffer when using
MP4.
MozReview-Commit-ID: 2tAWzpMlOjG
--HG--
extra : rebase_source : bec585ca46e7fd0665c00bce525aaacede1b3897
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
The mochitest relied that the video track was processed first. Additionally, change for the file with only a single video track as the previous video didn't have aligned segments, making the use of sequence mode useless.
We swap the segment around, which allow to more easily visually inspect the result (counter goes forward and then back)
MozReview-Commit-ID: 33PsrmRF1GL
--HG--
extra : rebase_source : e98a7714f81f5c7913091128b5ee04cf41c2d09b
Otherwise, the ended event would never be fired should the decoder have reached the end of the stream prior endOfStream being called.
MozReview-Commit-ID: CbWCnzi3nxj
--HG--
extra : rebase_source : 729e25919fdb7f8a8918c4d5a9bcae17d8c8bdc5
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
Calling NotifyDataArrived from each sourcebuffer will cause multiple unnecessary NotifyDataArrived to the MediaFormatReader when it could only be done once. Additionally, it ensures that the media duration is updated prior to the reader actioning on the notification.
Extra: mEnded is only ever accessed on the main thread, there's no need to make it atomic.
MozReview-Commit-ID: IKq7IRBbWic
--HG--
extra : rebase_source : 6cf18b1f71f5ee6c8e82c73bdd2857e783f343b8
1. It is called from SetInitialDuration() when mMediaSource is non-null which happens before Shutdown() which clears |mMediaSource|.
2. It is called from MediaSource::SetDuration() which happens before MediaSourceDecoder::Shutdown() for |mDecoder| is non-null.
3. It is called from MediaSource::DurationChange() where |mDecoder| is non-null.
MozReview-Commit-ID: 56AmWRLkkiv
--HG--
extra : rebase_source : 1f9443ac3670b12401ffa5ad397638c095e72566
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
update/updateend is no longer fired when changing the duration. Also update the test to use promises, it makes things more readable
MozReview-Commit-ID: AeuEolCR5yT
See w3c/MSE Issue 19, 20 & 26.
Changing the duration now can never call the range removal algorithm. An explicit call to remove must be used for range removal.
This change performs the following:
- Require remove() for all Range Removals
- Error on Duration Changes that need remove first
MozReview-Commit-ID: 1fK2O1slnQ1
JW Wang
Jean-Yves Avenard
Sebastian Hengst
bechen
Phil Ringnalda
Jonathan Hao
Gerald Squelart
Carsten "Tomcat" Book
Chris Pearce
James Cheng
Matt Woodrow
Matthew Woodrow
Ben Kelly
Wes Kocher
Bryce Van Dyk
Igor
Nicholas Nethercote
Jim Chen
Iris Hsiao
Tom Tromey
eyim