Bug 177483
| Summary: | Appending media to the start of a buffer range drops buffer after the append. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Robert Bryer <robert.bryer> |
| Component: | Media | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED CONFIGURATION CHANGED | ||
| Severity: | Normal | CC: | eric.carlson, jeremyj-wk, jer.noble, jesus, jonlee, peng.liu6, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 10 | ||
| Hardware: | Mac | ||
| OS: | macOS 10.12 | ||
Robert Bryer
When appending media to the start of a buffered range, webkit will remove a portion of buffer after the append, keeping the buffer as two separate ranges.
To reproduce:
http://reference.dashif.org/dash.js/v2.6.0/samples/dash-if-reference-player/index.html
1. Click load.
2. Seek forward to a time like 3:00, await some buffer at this time.
3. Seek back to 2:45, play until 3:00.
4. Observe that there is a gap in the buffer at the first segment downloaded(between 176 and 178).
When appending the segment again to fill the gap, a new gap appears at the next segment boundary, and so on - effectively meaning we need to replace all the buffered media from 3:00 onwards.
The fact that the above example doesn't play out is our fault(we should be checking .buffered when deciding what to fetch, and we have a fix already for this so we can make it play). But we probably shouldn't need to replace all the buffer ahead after seeking backwards. What's going on here?
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/54354873>
Peng Liu
Hi Robert, is this bug still reproducible? Thanks!
Robert Bryer
On Safari 12.1.2 I can't reproduce it, it looks fixed - It was reported for a Safari 10 version though.
Peng Liu
Great! Thanks for the information.