On Jan 21, 2014, at 7:06 PM, Philip Jägenstedt <philipj@opera.com> wrote: > On Wed, Jan 22, 2014 at 3:31 AM, Aaron Colwell <acolwell@google.com> wrote: >> >> On Tue, Jan 21, 2014 at 8:05 AM, Eric Carlson <eric.carlson@apple.com> >> wrote: >>> >>> >>> On Jan 17, 2014, at 6:38 PM, Philip Jägenstedt <philipj@opera.com> wrote: >>> >>>> I hadn't thought about those case either. It would be nice (simple) to >>>> just say that for all in-band tracks, when the buffered ranges are >>>> updated, evict all cues which now do not overlap the buffered ranges. >>>> Is that going to break something? >>>> >>> >>> That does seem like the simplest (to implement and understand)) solution >>> to this issue. >>> >>> I don’t know of anything that it will break. >> >> I have a few questions about this: >> >> 1. Does "evict all cues" include ones added by JavaScript or just the ones >> added by the inband track? > > All cues. If you don't want to lose them, put them in a script-created > track or keep them around to re-insert later when that regions becomes > buffered again. > I agree. >> 2. For out-of-band tracks is the application expected to remove cues from >> unbuffered regions? I'm mainly thinking about a live broadcast where cues >> are inserted by JavaScript instead of in-band. > > I don't think we should throw away cues for out-of-band or > script-created tracks, no. The application will have to throw them > away if it's an infinite stream. > Ditto. eric
Received on Wednesday, 22 January 2014 17:32:54 UTC