[Bug 21299] memory management in MSE

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21299

Aaron Colwell <acolwell@chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |acolwell@chromium.org

--- Comment #1 from Aaron Colwell <acolwell@chromium.org> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Saturday, 16 March 2013 15:40:33 UTC