Some invalid streams incorrectly tag all frames as keyframes, which cause the frames to be inserted in the wrong order in the trackbuffer.
MozReview-Commit-ID: EZurdiMxmle
--HG--
extra : rebase_source : d739eecb9e5b06aaeefcf044b5735949db86522d
Follow-up to bug 1259274, where TBM lost its inheritance.
MozReview-Commit-ID: 24tyq8tZYHp
--HG--
extra : rebase_source : 34dafd58ca0daca53649e04a0781bf6e23db3cbe
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
The index at which we are removing frames is always the one where we will be inserting the next ones.
MozReview-Commit-ID: DHeJDmwiMS9
--HG--
extra : rebase_source : 3730c0ed7fbdb4d9f8b4157f36aa7bb9d03a6517
We keep the next position on where to add frames so that we do not break the current coded frame group. However, when the new group of added frames starts with a keyframe we do not have to worry about breaking the previous coded frame group.
MozReview-Commit-ID: G81xGuSa4Y2
--HG--
extra : rebase_source : 4cbe5d0b5921c68c877815af15bbd10b40f18c80
The condition will be perfectly handled by the MediaFormatReader anyway.
MozReview-Commit-ID: Dm6evq6T4t6
--HG--
extra : rebase_source : 6e49cfae68bfa856aad891faf3cea565b152e565
If no keyframe are found after our time threshold, we can still skip to another keyframe (despite being prior the desired time).
So this is just a workaround for our inability to tell the MDSM when to enter buffering mode and instead the MDSM incorrectly uses the time of the last frame returned.
MozReview-Commit-ID: 5sGULpvqY5m
--HG--
extra : rebase_source : 392fe16a00eb9e10812ba4ada2e4e7c4e4aaa016
P2 let all tasks run until completion, as such we don't need to deal with interrupted tasks anymore.
MozReview-Commit-ID: 45lYcIGk2ce
--HG--
extra : rebase_source : 33438284685d8f1b48f54fd109880baf0353b976
We need to ensure that the MSE TaskQueue gets shutdown as soon as possible and not wait for the MediaSource parent to be destroyed by the cycle collector.
XPCOM shutdown will deadlock if any SharedThreadPool are still in use, and it possible for the cycle collector to only occur after xpcom has shutdown.
So it's important to ensure mTaskQueue is cleared when the MediaSourceDecoder has been shutdown.
This is done by queueing a new DetachTask that will clear mTaskQueue when run.
MozReview-Commit-ID: C3FXcRtq1wy
--HG--
extra : rebase_source : 79a7c5cb451655c4679b9d4e11d0b5ca0d9814b9
This ensures that the tasks are processed in the expected order.
MozReview-Commit-ID: JPxlwReZ4Az
--HG--
extra : rebase_source : 4ffac9deaf531c9dfd8443b2e26812d7c8a89102
P2 let all tasks run until completion, as such we don't need to deal with interrupted tasks anymore.
MozReview-Commit-ID: 45lYcIGk2ce
--HG--
extra : rebase_source : db9c8db1b3f1d51d57ad090fdeb2cad6682de2be
We need to ensure that the MSE TaskQueue gets shutdown as soon as possible and not wait for the MediaSource parent to be destroyed by the cycle collector.
XPCOM shutdown will deadlock if any SharedThreadPool are still in use, and it possible for the cycle collector to only occur after xpcom has shutdown.
So it's important to ensure mTaskQueue is cleared when the MediaSourceDecoder has been shutdown.
This is done by queueing a new DetachTask that will clear mTaskQueue when run.
MozReview-Commit-ID: C3FXcRtq1wy
--HG--
extra : rebase_source : 38c0b5548b32e89b0994704c1318ff77fba76eba
This ensures that the tasks are processed in the expected order.
MozReview-Commit-ID: JPxlwReZ4Az
--HG--
extra : rebase_source : 873a373c5a6ccf20eb69f6d36b1ebdf25e6ddea3
P1 let all tasks run until completion, as such we don't need to deal with interrupted tasks anymore.
MozReview-Commit-ID: 45lYcIGk2ce
--HG--
extra : rebase_source : 87731ae2ef2c1aa2fae57ef4b232374f9ad5e0bc
We need to ensure that the MSE TaskQueue gets shutdown as soon as possible and not wait for the MediaSource parent to be destroyed by the cycle collector.
XPCOM shutdown will deadlock if any SharedThreadPool are still in use, and it possible for the cycle collector to only occur after xpcom has shutdown.
So it's important to ensure mTaskQueue is cleared when the MediaSourceDecoder has been shutdown.
This is done by queueing a new DetachTask that will clear mTaskQueue when run.
MozReview-Commit-ID: C3FXcRtq1wy
--HG--
extra : rebase_source : 034319517bd8b90668b6311efb54c3a1a864cb5b
On Windows, it is possible for the WMF decoder to consume more than the amount of frames available before outputting the first frame. So just to produce the loadeddata event, we may have in fact already reached the end of the content. To guarantee that the "playing" event is fired, we must add more data than what was originally there.
MozReview-Commit-ID: 12eQnchNGLB
It ensures that resume from waiting for data is correct and the MediaFormatReader internal seek can handle partial GOP.
MozReview-Commit-ID: 1jyv3dajQPv
--HG--
extra : rebase_source : d9aba013aaacc9c19ee6a47ead839adda5c1299e
If the last frames of a media segment were evicted due to gap detection, mLongestFrameDuration would have been reset.
Additionally, simplify the code by using temporary variables.
MozReview-Commit-ID: HCjuZkgwANN
--HG--
extra : rebase_source : eed2837fd4b05fe3f7c4774c4486a201d0100cf7
This makes us closer to the spec, while still allowing some leeway in gap detection which was found to too strict in the past.
MozReview-Commit-ID: 9EPT2e2F6ed
--HG--
extra : rebase_source : 2bdc01667c3aaeae7a72eb5c6861076113a34c59
It had originally been added to improve speed though further changes to the processing of frames made this optimization unecessary.
And it means that we don't properly handle invalid media segment with discontinuities within their range.
MozReview-Commit-ID: wGjWEQxLX3
--HG--
extra : rebase_source : 1a14e404c9e4630cab525472978a8c6cbfbc3bd0
