- From: <bugzilla@jessica.w3.org>
- Date: Sun, 17 Mar 2013 11:00:02 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21299 --- Comment #2 from Jon Piesing (OIPF) <oipfjon@gmail.com> --- (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()? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Sunday, 17 March 2013 11:00:03 UTC