W3C home > Mailing lists > Public > public-media-fragment@w3.org > February 2009

Re: Proposed text to close ISSUE-2

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 13 Feb 2009 08:35:08 +1100
Message-ID: <2c0e02830902121335o32ea6927of46f03232195670f@mail.gmail.com>
To: Conrad Parker <conrad@metadecks.org>
Cc: RaphaŽl Troncy <Raphael.Troncy@cwi.nl>, Media Fragment <public-media-fragment@w3.org>

On Fri, Feb 13, 2009 at 12:52 AM, Conrad Parker <conrad@metadecks.org> wrote:
> 2009/2/12 RaphaŽl Troncy <Raphael.Troncy@cwi.nl>:
>> Dear Conrad,
>>> This rationale seems to be limited to subviews of the original
>>> resources, eg. an excerpt of video; in that situation it makes sense.
>>> There was an earlier discussion about addressing a single frame of a
>>> video as an image, ie. where the returned data would be formatted as
>>> valid jpeg or png. In that situation, I think the mime-type of the
>>> returned data should be image.
>>> (Apologies if that is outside the scope of ISSUE-2).
>> This is perfectly in-scope of this ISSUE. However, it seems to me that the
>> group consensus is that "addressing a single frame of a video as an image"
>> will create a *new* resource. It is therefore *NOT* a fragment. It might be
>> possible to create such a resource using a '?' followed by the same syntax
>> of the media fragment URI. It might be possible to use the link header
>> provided by http to provide a (typed) link towards the video resource from
>> which the image comes from. The mime type of this new resource would
>> certainly be image/jpeg for example.
>> The summary is, returning an image frame from a video is not a fragment of
>> this video.
> Ok that's much clearer. Perhaps that clarification should be added to
> the summary, as that case is (apparently, nearly) in scope of the
> issue :-)

Agreed - in particular since the whole discussion about ISSUE-2 was
about extracting keyframes from videos, it is important to explain
this particular case.

Received on Thursday, 12 February 2009 21:35:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:42 UTC