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

[silviapfeiffer1]

On Sun, Jul 4, 2010 at 12:07 PM, timeless <timeless at gmail.com> wrote:
> On Fri, Jul 2, 2010 at 4:20 PM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>> This latter one is already defined as a 5 sec video extract from the
>> full file.ogv - it's not possible to overload that with turning the
>> byte range into an animated gif.
>
> So, <img> isn't restricted to animated GIFs, Mozilla supports animated
> PNGs (APNG), and some browsers support MNG.
>
> To some extent, there's nothing wrong with using a video file as an
> image, or an animated image.
>
> I'm not absolutely certain i'd want to see it used this way, but I can
> understand why someone would ask for it.
>
>> You will also need to use transcoding
>> for this and thus will want to create a new URI query scheme.
>
> As <img> doesn't require that animations be GIF based, there's no need
> for transcoding. There would be a requirement for browsers to choose
> to support the proposed format, but ...


It doesn't actually matter what element the URI appears in - your
element has to deal with the data that it receives and if
"file.ogv#t=1:00,1:15" is an Ogg Theora segment out of a video, then
that is what the <img> element receives.

Of course you can call any file any name, so if "file.ogv" is an
animated gif or an animated png (contrary to what your file extension
indicates), then your <img> element may be able to deal with it. I am
not aware though of any <img> element implementation that can deal
with Ogg Theora video.

If you are, however, asking to turn the Ogg Theora video into a APNG
or a animated GIF or even a MNG, there will need to be a transcoding
step at the server, which means you have to change the mime type of
your resource "file.ogv", which means, it cannot continue to be called
"file.ogv". So, if you really want to do it this way, you can only use
a URI query to transcode your resource into a different mime type and
would need to use a URI such as e.g.
"file.ogv?t=1:00,1:15&target=apng" such that the server knows what
mime type to return instead of the original one.

The gist of the issue is: A fragment ("#") addition to a URI is not
allowed to change the mime type of the resource, since it only points
to a subresource, i.e. basically only to a byte range of the original
resource. But you can do anything to your resource if you use a URI
query ("?").

Cheers,
Silvia.