- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 17 Mar 2011 07:25:52 +0000 (UTC)
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- cc: Frank Olivier <Frank.Olivier@microsoft.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>
On Thu, 17 Mar 2011, Silvia Pfeiffer wrote: > > > > 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) Something like that would work too, sure. The idea being that the author can get information from the UA about the actual results the UA is succeeding in providing, while the UA has the instructions from the author (as it does today) regarding the rate it _should_ be playing at. Frank, would something like that work for you? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 17 March 2011 07:26:21 UTC