This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This issue results from a joint meeting between the Open IPTV Forum, HbbTV and the UK DTG. These organizations originally sent a liaison statement to the W3C Web & TV IG: https://lists.w3.org/Archives/Member/member-web-and-tv/2013Jan/0000.html (W3C member only link) There is no mention in the document about memory management in the user agent except for the sourceBuffer.remove method. In an email on the public-html-media list (http://lists.w3.org/Archives/Public/public-html-media/2013Feb/0071.html) there is a mention of “If the UA decides to garbage collect part of the presentation timeline to free up space for new appends it is not clear how the web application could reappend the garbage collected regions without appending the whole file again.” How does this relate to sourceBuffer.remove()? There are clearly some assumptions about how memory management which should be written down – even if they are non-normative.
How memory is managed is up to the UA. remove() and the 'coded frame eviction algorithm' remove coded frames from the Track Buffers based on a start and end timestamp. The only assumption being made here is that coded frames can be removed from the Track Buffers based on any time range the web application or eviction algorithm chooses. The eviction algorithm is implementation dependent and the time ranges it selects for removal will likely be biased by its internal representation of the Track Buffers. You may not have seen this before you filed this bug, but the most recent update to the editors draft specifies how eviction works. remove() and the 'coded frame eviction algorithm" both use the 'coded frame removal algorithm' to remove a range of coded frames from all the Track Buffers in a Source Buffer. The only difference between these two mechanisms is what entity selects the ranges to remove. In my comment you quoted below, the problem arises when only part of a non-fragmented MP4 file gets evicted. Since there are no fragment boundaries in the file, the application has no choice, but to append the whole file again. In the fragmented file case, the application can choose to only append the fragment that covers the evicted section. This is not a problem with normal <video> usage because the media engine can use range requests to refetch the portions of the file that got evicted. This is not an option with MSE because it leaves the media fetching up to the application and expects fragments of media to be appended to the SourceBuffer when needed.
(In reply to comment #1) <snip> > You may not have seen this before you filed this bug, but the most recent > update to the editors draft specifies how eviction works. You're right that the comments pre-date the most recent update to the editors draft even though they were uploaded after it. > remove() and the > 'coded frame eviction algorithm" both use the 'coded frame removal > algorithm' to remove a range of coded frames from all the Track Buffers in a > Source Buffer. The only difference between these two mechanisms is what > entity selects the ranges to remove. The members of the 3 organisations will need to think some more about this issue. My immediate reaction is to wonder how big a variation in behaviour will be seen by apps depending on the resources available for SourceBuffers - e.g. embedded devices using only RAM, embedded devices using a HD and PCs (etc). Will an app have sufficient information to determine the start and end values to pass to SourceBuffer.remove()?
Without a specific proposal, I recommend closing this bug WORKSFORME. If there are specific technical changes proposed it would be helpful to describe those. Otherwise this sounds like something we need implementation experience from in the Candidate Recommendation phase.