W3C home > Mailing lists > Public > public-html@w3.org > August 2013

Re: Dropping cues when playbackRate != 1.0

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 9 Aug 2013 12:21:11 +1000
Message-ID: <CAHp8n2=J0JbZV0cjYZe4sYj169aTo8Y38zMkV1GVeeJLERh-oA@mail.gmail.com>
To: Brendan Long <self@brendanlong.com>
Cc: "HTML WG (public-html@w3.org)" <public-html@w3.org>
On Fri, Aug 9, 2013 at 6:11 AM, Brendan Long <self@brendanlong.com> wrote:
> There's section of the HTML5 CR spec saying:
>
> Similarly, when the playback rate is not exactly 1.0, hardware, software, or
> format limitations can cause video frames to be dropped and audio to be
> choppy or muted.
>
>
> I think this should also apply to text track cues, something like:
>
> Similarly, when the playback rate is not exactly 1.0, hardware, software, or
> format limitations can cause video frames and text cues to be dropped and
> audio to be choppy or muted.
>
> When playing at non-standard speeds, an efficient implementation may want to
> skip portions of the file, which could mean skipping cues.

I assume you are talking about a situation where the playback would
need to jump multiple seconds (call them "s") at a time to achieve the
speedup.
And you are further assuming that when the current time jumps from
second x to second x+s, there may be a cue that would have both their
start and end time between x and x+s.
So you're saying that if there is no audio or video rendered to which
the cue refers, the "time marches on" algorithm doesn't actually
activate these cues and therefore they are "dropped".

In actual fact, the "time marches on" algorithm will activate the
enter and exit events of the "missed cues", so they are not really
"dropped". They are, however, not rendered, because they don't become
active.

Silvia.
Received on Friday, 9 August 2013 02:21:58 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:34 UTC