Re: AW: Public feedback on HTML5 video

On Tue, Dec 29, 2009 at 6:46 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Tue, 29 Dec 2009 04:17:56 +0100, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>
>> On Tue, Dec 29, 2009 at 10:23 AM, Philip Jägenstedt <philipj@opera.com>
>> wrote:
>>>
>>> On Mon, 28 Dec 2009 23:56:39 +0100, Aryeh Gregor
>>> <Simetrical+w3c@gmail.com>
>>> wrote:
>>>
>>>> On Mon, Dec 28, 2009 at 5:44 PM, Philip Jägenstedt <philipj@opera.com>
>>>> wrote:
>>>>>
>>>>> The only wiggle-room this leaves for implementation is whether to show
>>>>> the
>>>>> poster frame or the first video frame when the first video frame has
>>>>> been
>>>>> decoded. I think it should be the poster image, if other browser
>>>>> vendors
>>>>> agree perhaps the spec should simply say that.
>>>>
>>>> That seems sensible to me as well.  Why would implementations show the
>>>> first video frame if a poster is explicitly provided?
>>>>
>>>>> If the author doesn't want to use a poster image they simply shouldn't
>>>>> use
>>>>> that attribute. To show a certain frame of video, set .currentTime in a
>>>>> script.
>>>>
>>>> That's not equivalent.  In particular, it will change what happens
>>>> when the user hits play, and will probably change what gets buffered.
>>>> Not to mention it requires script.
>>>>
>>>> Perhaps someone should suggest to the Media Fragments WG that they
>>>> should create a syntax where you can address a frame of a video like a
>>>> picture?  The current WD doesn't seem to allow it:
>>>>
>>>> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/
>>>
>>> Shouldn't using e.g. #t=10,10 do just that?
>>
>> No, not if you are expecting it to return an actual image. A media
>> fragment can only return the same mime type as the original resource.
>> Thus, this will just return the video data for that particular time -
>> it's still video data and not converted to jpg or png or anything
>> else. It does essentially the same as setting the currentTime to 10.
>>
>> The media fragment WG recommends using queries where a image is to be
>> extracted from a video,
>> e.g. ?t=10,10&format=image/png .
>>
>> URI queries have been identified to be important for addressing media,
>> in particular to extract shorter version of videos or retrieve another
>> representation of a video (or audio). URI queries create new
>> resources, so it is possible to do this with URI queries. URI
>> fragments do not create new resources, so they cannot return a
>> different mime type.
>>
>> The possibilities with URI queries are much larger and it is expected
>> that media servers will develop a large repertoire of URI query
>> parameters, but for now, the focus is on URI fragments and their
>> equivalents in URI queries only where the mime type is not changed.
>>
>> Cheers,
>> Silvia.
>>
>
> In theory, the mime type does not need to change, all that matters is that a
> single frame can be addressed, the rest is up to the UA. However, I doubt we
> will see implementations supporting that very soon.

OK, then the media fragment URL will do the job.

As for implementations: it should be no more difficult than the
network-based seeking approaches that are currently being used by
browsers (in particular Firefox) to do the .currentTime offset. So, I
am hopeful.

Cheers,
Silvia.

Received on Tuesday, 29 December 2009 13:00:05 UTC