[Webkit-unassigned] [Bug 180643] New: [MSE] SourceBuffer::provideMediaData() may remove sample from decode queue unexpectedly
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Dec 11 04:53:07 PST 2017
https://bugs.webkit.org/show_bug.cgi?id=180643
Bug ID: 180643
Summary: [MSE] SourceBuffer::provideMediaData() may remove
sample from decode queue unexpectedly
Product: WebKit
Version: WebKit Nightly Build
Hardware: Unspecified
OS: Unspecified
Status: NEW
Severity: Normal
Priority: P2
Component: Media Elements
Assignee: webkit-unassigned at lists.webkit.org
Reporter: zhangququ at gmail.com
I found in some cases, a sample already in trackBuffer.decodeQueue could be removed unexpectedly when there is gap ahead of it. For example, if samples of the following ranges are already in the trackBuffer.decodeQueue,
[0 .. 5.0) [10.0, ... 30.0)
when SourceBuffer::provideMediaData() is called on such a decodeQueue, it may remove sample 10.0 (decode time) due to one second gap. Then, if the gap is filled (segment re-appended) later, it will enqueue samples from this decodeQueue but without sample 10.0.
The problem usually happens after playback for a while, e.g. buffered [10.0, ... 30.0), then seeking to the beginning. During re-appending the first segments, provideMediaData() may remove sample 10.0. As the removed sample is usually a sync sample, it results in playback issue if the enqueued samples are sent to decoder (not flushed).
I suggest to move the following removal code to be after the one-second gap checking:
trackBuffer.decodeQueue.erase(trackBuffer.decodeQueue.begin());
How do you think? Thanks.
Best Regards,
Daniel ZHANG
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20171211/f3f45b04/attachment.html>
More information about the webkit-unassigned
mailing list