The spec [1] defines what's the init segment, and the parser would return error
if the format is not correct.
[1] https://w3c.github.io/media-source/webm-byte-stream-format.html
MozReview-Commit-ID: 3nFHHdn5b89
--HG--
extra : rebase_source : 66fe592958801c4f9e2115f7729df2b9ece55ac3
The spec [1] defines what's the media segment, and the parser would return error
if the format is not correct.
[1] https://w3c.github.io/media-source/webm-byte-stream-format.html
MozReview-Commit-ID: 4hq59Pywz2t
--HG--
extra : rebase_source : 1136d2a673f11d612e0eb711db6affdce42bb525
The value by which we pre-roll is inconsequential, so long as we seek to the previous packet than the one we want. So 80ms will do.
MozReview-Commit-ID: 8iPOtjReZnb
--HG--
extra : rebase_source : 42908c6afc84cf783356fb7311ffe99b4ec76d96
mManager would be accessed in both main thread and task queue, and be set on task
queue, so we need to make sure it's thread-safe.
MozReview-Commit-ID: m76KeEsDgB
It would only be accessed on task queue now, so we don't need to lock it.
MozReview-Commit-ID: 6jd36TQW4aA
--HG--
extra : rebase_source : e8bb53a226154312496149ab8f6b00dead49a3b6
mTaskQueue is only read on the main thread, but read and written on the demuxer's taskqueue. We need to ensure that accesses are synchronised.
MozReview-Commit-ID: Gbc15iYgZOe
--HG--
extra : rebase_source : 006ff3f73c9895fa2f29e56123e690cdf66fe2c5
The use of the TrackBuffersManager once detached is explictly forbidden, as such
OnTaskQueue() can only be used before the DetachTask ran: we now strongly assert
as such.
MozReview-Commit-ID: ycOI4QRElb
--HG--
extra : rebase_source : ecce8ac75587470c15268ab729b068f049702a8a
Ensure the TBM would always be detached from demuxers, before calling
TBM::detach().
MozReview-Commit-ID: DLWZHB3M3GG
--HG--
extra : rebase_source : 9e455022ba9360fb549222e9ad1238a3ae9d88ad
From [1], the task was executed after finished detach task. It would be caused
by queuing two detach tasks in the task queue.
If the previous detach task is still waiting in the task queue when we're calling
the second detach(), then we might have two detach tasks in the queue.
[1] https://treeherder.mozilla.org/logviewer.html#?job_id=134315866&repo=try&lineNumber=2540
MozReview-Commit-ID: HohgKqeZy0s
--HG--
extra : rebase_source : 0d20f1b8648acaf2ed8e75b2631e905629c2abaf
Should never access the TrackBuffersManager once the SourceBuffer has been detached.
MozReview-Commit-ID: EgVINj9B1vZ
--HG--
extra : rebase_source : 4b4dc3e5c4b507fe4cc40e80f507b575a8b87eb3
After detaching TBM, we should not access it anymore. So we should finish all
other related detaching process, before detaching TBM.
MozReview-Commit-ID: 8bNzqXVHVyy
--HG--
extra : rebase_source : e135eb3d0fd4e5c41bbac4ebfc8d6fcbd1b32d5b
The use of the TrackBuffersManager once detached is explictly forbidden, as such
OnTaskQueue() can only be used before the DetachTask ran: we now strongly assert
as such.
MozReview-Commit-ID: ycOI4QRElb
--HG--
extra : rebase_source : 44ea3d0eb292e5c285d0aa4e10eefa41f20beed7
Ensure the TBM would always be detached from demuxers, before calling
TBM::detach().
MozReview-Commit-ID: DLWZHB3M3GG
--HG--
extra : rebase_source : 0334b71534cfaccaf1d8985d827fe4e5d5bf0e9f
From [1], the task was executed after finished detach task. It would be caused
by queuing two detach tasks in the task queue.
If the previous detach task is still waiting in the task queue when we're calling
the second detach(), then we might have two detach tasks in the queue.
[1] https://treeherder.mozilla.org/logviewer.html#?job_id=134315866&repo=try&lineNumber=2540
MozReview-Commit-ID: HohgKqeZy0s
--HG--
extra : rebase_source : b1dc3193d839ef3776195901339fae24f328207b
Should never access the TrackBuffersManager once the SourceBuffer has been detached.
MozReview-Commit-ID: EgVINj9B1vZ
--HG--
extra : rebase_source : 4b4dc3e5c4b507fe4cc40e80f507b575a8b87eb3
After detaching TBM, we should not access it anymore. So we should finish all
other related detaching process, before detaching TBM.
MozReview-Commit-ID: 8bNzqXVHVyy
--HG--
extra : rebase_source : e135eb3d0fd4e5c41bbac4ebfc8d6fcbd1b32d5b
The only actual code use in MediaSourceDemuxer can trivially be folded into
its caller GetNumberTracks in the same class.
MozReview-Commit-ID: E6zh98zmJwJ
--HG--
extra : rebase_source : 9358dc37523d6cd7c1a4d5ec62a790db6a092063
This patch does two things,
(1) check v.seekable after calling ms.endOfStream()
As test name suggests, we check seekable after calling endOfStream()
(2) check the time range of v.seekable
The seekable represents the ranges of the media resource [1], so it would be changed after calling ms.endOfStream().
Before calling the endOfStream(), seekable should be [0, ms.duration)
After calling the endOfStream(), seekable should be [0, ms.buffer.end(0))
[1] https://www.w3.org/TR/html51/semantics-embedded-content.html#dom-htmlmediaelement-seekable
MozReview-Commit-ID: 56AIZYVsHhW
--HG--
extra : rebase_source : a1f1df601dc8523cd5d4e58b41cada3c79d494c1
Use ErrorName() as it provides more useful information for the error detail.
MozReview-Commit-ID: BQUPQGcLd8L
--HG--
extra : rebase_source : 734825c88dfbe79de1e61498dcc24606c50314ee
