- From: <bugzilla@jessica.w3.org>
- Date: Sun, 11 Dec 2011 09:40:57 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14104 --- Comment #30 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-12-11 09:40:54 UTC --- (In reply to comment #29) > (In reply to comment #27) > > (In reply to comment #23) > > > (In reply to comment #22) > > > > > > > During live streaming, no seeking should be possible. > > > > > > A live stream is basically just a resource which is not byte range seekable, > > > but that doesn't mean that the client can't seek in the data they have > > > buffered. I think Firefox already does this and we (Opera) want to do it. > > > > That's ok. It's client-side seeking only. In this case, I would simply replay > > everything exactly how it was received before, including the edits. > > I don't understand, when we seek we invalidate what cues are visible and start > fresh. It has to be defined what happens with the changes you propose, since if > the cues are mutated by later cues' arrival one can't "simply replay everything > exactly how it was received". OK, this is way off topic from what the bug was originally registered for. But I'll run with it. Ian suggested to introduce an "editing" command into cues called <redoline>. This is a command that, along the timeline changes something that has been displayed before. For example a line that starts at with the text "I ma hnugry" would be erased a few seconds later with the <redoline> command and replaced with the text "I am hungry". As I understand it, the markup would look something like this: LIVE--> rollup-size:3 <00:00:00.000> I ma hnugry <00:00:05.000> <redoline> I am hungry This specifies a clear display order, even with the changes. So, when you seek back to any time between 0 and 5 sec, you display the "I ma hnugry" text again, and for any time after 5 sec, you display the "I am hungry" text. This is what I mean by "replay everything exactly how it was received". Hope that clarifies what I meant. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Sunday, 11 December 2011 09:40:58 UTC