Bug 252782 – SourceBuffer.timestampOffset usage doesn't behave correctly with webm content.

• Status: RESOLVED
• Resolution: FIXED
• Component: Media

[Jean-Yves Avenard [:jya]]

STR: 
Open https://jyavenard.github.io/htmltests/tests/mse_webm/vorbis_timestampOffset.html

This page load a single webm media segment, then set the sourceBuffer timestampOffset to the SourceBuffer.buffered.end(0) so that we can concatenate all those media segments together in one long chunk.

In Safari we see:
```
36: SourceBuffer buffered ranges grew from TimeRanges: [0, 1.3392199546485262) to TimeRanges: [0, 1.3392199546485262)
36: Append a media segment.
36: SourceBuffer buffered ranges grew from TimeRanges: [0, 1.3392199546485262) to TimeRanges: [0, 1.3392199546485262)
36: Append a media segment.
37: SourceBuffer buffered ranges grew from TimeRanges: [0, 1.3392199546485262) to TimeRanges: [0, 1.3392199546485262)
37: Append a media segment.
37: SourceBuffer buffered ranges grew from TimeRanges: [0, 1.3392199546485262) to TimeRanges: [0, 1.3392199546485262)
37: Append a media segment.
37: SourceBuffer buffered ranges grew from TimeRanges: [0, 1.3392199546485262) to TimeRanges: [0, 1.3392199546485262)
37: Append a media segment.
38: SourceBuffer buffered ranges grew from TimeRanges: [0, 1.3392199546485262) to TimeRanges: [0, 1.3392199546485262)
38: Append a media segment.
41: SourceBuffer buffered ranges grew from TimeRanges: [0, 1.3392199546485262) to TimeRanges: [0, 1.3392199546485262)
41: Append a media segment.
42: SourceBuffer buffered ranges grew from TimeRanges: [0, 1.3392199546485262) to TimeRanges: [0, 1.3392199546485262)
```

we can see that the buffered range doesn't grow.

Firefox and Chrome behave properly:
```
42: SourceBuffer buffered ranges grew from TimeRanges:  to TimeRanges: [0, 1.34)
42: Append a media segment.
42: got durationchange event
42: SourceBuffer buffered ranges grew from TimeRanges: [0, 1.34) to TimeRanges: [0, 2.68)
42: Append a media segment.
42: got durationchange event
42: SourceBuffer buffered ranges grew from TimeRanges: [0, 2.68) to TimeRanges: [0, 4.02)
42: Append a media segment.
42: got durationchange event
42: SourceBuffer buffered ranges grew from TimeRanges: [0, 4.02) to TimeRanges: [0, 5.359999)
42: Append a media segment.
42: got durationchange event
42: SourceBuffer buffered ranges grew from TimeRanges: [0, 5.359999) to TimeRanges: [0, 6.699999)
42: Append a media segment.
42: got durationchange event
42: SourceBuffer buffered ranges grew from TimeRanges: [0, 6.699999) to TimeRanges: [0, 8.039999)
42: Append a media segment.
42: got durationchange event
42: SourceBuffer buffered ranges grew from TimeRanges: [0, 8.039999) to TimeRanges: [0, 9.379999)
42: Append a media segment.
42: got durationchange event
42: SourceBuffer buffered ranges grew from TimeRanges: [0, 9.379999) to TimeRanges: [0, 10.719999)
42: Append a media segment.
42: got durationchange event
42: SourceBuffer buffered ranges grew from TimeRanges: [0, 10.719999) to TimeRanges: [0, 12.059999)
43: got durationchange event
```

[Radar WebKit Bug Importer]

<rdar://problem/105801920>

[Jean-Yves Avenard [:jya]]

The reason for this is that the libwebmparser enforces checking the size of the WebM Segment parent.
In this particular case the Segment' size is 13705 bytes and the single cluster is 9992 bytes.

When we append a cluster a second time, the overall size becomes larger than the parent Segment could fit and the parser aborts.

Considering a webm is only ever have made of one Segment, and that the matryoshka specification allows for an element size to be unknown and other browsers ignore that size, the simplest way to fix this would be to ignore the Segment's size.

This would allow to add as many cluster as one wants, regardless of the init segment added.

[Jean-Yves Avenard [:jya]]

Pull request: https://github.com/WebKit/WebKit/pull/10565

[EWS]

Committed 260822@main (bee529142266): <https://commits.webkit.org/260822@main>

Reviewed commits have been landed. Closing PR #10565 and removing active labels.