[whatwg] media resources: addressing media fragments through URIs spec

Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> On Sun, Jul 4, 2010 at 9:19 AM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
> > All of the image formats that you are pointing out have an image mime
> > type. I am merely pointing out that to support ogg theora browsers
> > would need to support a video mime type in an <img> element. I don't
> > see that as the intention of the <img> element, in particular since
> > <img> elements do not have transport controls and the like. Otherwise,
> > why did we create a <video> element in the first place.
> 
> I'd expect that a video in <img> would behave like an animated GIF --
> no sound, no APIs to control playback, no browser-provided controls.

Is the no controls part specified by the spec? A MUST in that regard
seems plain wrong. UI shall be implementation defined.

The <video> element is there to allow "webapp" authors to control the
playback of video they link to in ways that may make even less sense
for different media types and to allow linking to multiple related
media streams.


> You might want this sometimes, especially if you're only selecting one
> frame.  Animated images are conceptually different from videos, and
> there's no reason you couldn't support the same format for both <img>
> and <video>, with those different semantics.  It would be particularly
> useful to support video frames as images in places where <video> can't
> be used, like for the <video poster> attribute, CSS backgrounds, and
> so on.  The video MIME type does not conflict at all with allowing
> this kind of usage.
> 
> So to cover this use-case, it would be good if there were a way of
> explicitly selecting one frame, which could be treated as a video that
> contains only one frame.  This might, in turn, be accepted by some
> browsers in places where they accept images.  You could do this by
> explicitly allowing syntax like #t=10,10, where the start point equals
> the end point, as selecting only one frame.  (But I guess this could
> be emulated by #t=10,10.001 or something, assuming the frame starts at
> exactly t=10.)
IMO single frames should be encoded as frames/images rather than full
blown videos consisting of a single frame. The format that the video
codec uses for (golden) frames. In the case of fragments the frame will
of course have to be extracted dynamically on the client side.

Received on Sunday, 4 July 2010 16:57:11 UTC