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

Re: Dropping cues when playbackRate != 1.0

From: Bob Lund <B.Lund@CableLabs.com>
Date: Thu, 8 Aug 2013 20:45:31 +0000
To: Brendan Long <self@brendanlong.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>
Message-ID: <CE295D98.32644%b.lund@cablelabs.com>


From: Brendan Long <self@brendanlong.com<mailto:self@brendanlong.com>>
Date: Thursday, August 8, 2013 2:11 PM
To: "HTML WG (public-html@w3.org<mailto:public-html@w3.org>)" <public-html@w3.org<mailto:public-html@w3.org>>
Subject: Dropping cues when playbackRate != 1.0
Resent-From: <public-html@w3.org<mailto:public-html@w3.org>>
Resent-Date: Thursday, August 8, 2013 2:12 PM

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 don't think this should be done. Not playing video or audio tracks when the playrate != 1 might make sense because of rendering issues. Rendering of text tracks or providing meta-data text track Cues to JavaScript can, and should, be done for any play rate.

Section http://www.w3.org/TR/html5/embedded-content-0.html#time-marches-on  describes UA behavior vis-a-vis Cues when seeking.
Received on Thursday, 8 August 2013 20:46:01 UTC

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