Re: Should <video> buffer control be tri-state?

On Mon, Jan 4, 2010 at 1:23 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Jan 3, 2010, at 1:15 PM, Robert O'Callahan wrote:
>
> On Mon, Jan 4, 2010 at 12:37 AM, Philip Jägenstedt <philipj@opera.com>
> wrote:
>>
>> Replace it with a single multi-state attribute like "buffering" instead.
>> Values "none", "auto" (the default) and "full", or similar. Unless there's a
>> cleaner way to represent the semantics "this is (un)likely to be used"....
>
> I'm still unconvinced three states will actually be needed, but this
> proposal sounds OK to me. At least it's forwards-extensible if more than two
> states do turn out to be needed.
>
> Representing the different states as attribute values seems ok to me too.
> I'm not totally convinced the "don't buffer" hint should also mean "don't
> load metadata" and "don't load the first frame even if the poster attribute
> is missing". In the use case that spawned this thread, namely a blog with
> embedded video, it seems likely you want to hint not to buffer, but you do
> want enough metadata for controls to show the right duration, since in this
> type of case controls are typically always visible.

Durations could be provided by the server using a "Content-Duration"
HTTP header with a HEAD request on the resource. That would minimise
the required data download. A "X-Content-Duration" HTTP header is
already in use with several Ogg based servers. The Xiph community is
currently discussing to move this to Content-Duration and register a
RFC for it with a provisional HTTP header. It would make life easier
for media element displays.

Regards,
Silvia.