Re: Change Proposal for ISSUE-147

On Thu, Mar 17, 2011 at 2:19 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Thu, 17 Mar 2011, Frank Olivier wrote:
>>
>> >> . Setting playbackRate larger than 1.0 for live video will not work.
>> > Sure it will, so long as the playhead is far enough back that there is
>> > buffered content to play.
>>
>> Sure, but what happens when you play through the buffered content and
>> get to (effectively) a live feed? The author should be able to determine
>> that effective playback rate is now 1.0 in this outcome - and setting to
>> >1.0 should not work.
>
> The spec already covers this -- it's the same as what happens if you're
> playing at the rate of 1.0 but you're receiving only one second's worth of
> media every two seconds.
>
> If we're agreed that the browsers _should_ support this, why would we make
> it effectively optional? Shouldn't this be a quality-of-implementation
> issue, where browsers try their best to approximate the requested rate and
> some do a better job than others? It would be equivalent to how some
> browsers can render canvas faster than others, or how some browsers render
> text more beautifully than others. We don't say that browsers that don't
> support rendering text well should simply refuse to add Text nodes to the
> DOM, right? Why would we require that browsers decide whether or not they
> can do a good enough job of going at the requested rate and force them to
> change the playbackRate accordingly?
>
> Would reporting the playback quality (e.g. number of frames rendered over
> the past second of playback as a fraction of the number of frames that
> would ideally have been rendered during that same period) be an acceptable
> alternative solution?

Hmm, I regard the rendered frames as a statistic of video quality -
maybe the audio displayed properly in that time, but video frames had
to be dropped to be played, either because of network issues or
because the CPU wasn't fast enough. This is different to not
supporting the playback rate.

Maybe it's better to make a differentiation explicit on playbackRate, such as:
* defaultPlaybackRate - continues to be the recommended playback rate
for the video
* requestedPlaybackRate - is the rate that the author/user requested
it to be played back
* actualPlaybackRate - is the actual rate at which the browser is
managing to play it back (read-only)

Silvia.

Received on Thursday, 17 March 2011 05:08:19 UTC