This is a similar problem as in bug 1132825. When evicting data, we calculate the position within the stream of the preceding moof (mp4) or cluster (webm); we then evict data up to that offset. However, the SourceBufferResource uses a ResourceQueue made of ResourceItems each matching the block of data fed to SourceBuffer::AppendData; no partial block can ever be removed. YouTube often feeds partial media segments, where the beginning of a media segment would be a partial mdat followed by a MOOF within the data. Should we attempt to evict from this MOOF, we would actually truncate the data at the beginning of the ResourceItem and as such, on the partial mdat. The MP4 parser is unable to parse this data as it is now corrupted. The buffered range for this source buffer is now empty. There's the same issue with WebM (actually it appears to happen more often than with MP4) When truncating data, we should never evict data so that the remaining data is unusable. (e.g for MP4 always truncate on a moof or cluster boundary)
There are two ways we can solve this problem. Store an offset value within the ResourceItem ; or create a new ResourceItem.mData that has been truncated. The later is much easier to implement, the trouble is if code using ResourceItem only hold a weak reference: it could result in data being deleted while using it.
As discussed on whiteboard, "create a new ResourceItem.mData that has been truncated" seems the better approach.
Created attachment 8568253 [details] [diff] [review] Allow partial truncation from ResourceQueue Handle partial ResourceItem eviction so we never truncate other than on a moof