W3C home > Mailing lists > Public > public-media-fragment@w3.org > June 2010

Re: ACTION-180: Add the WebM codec into our fitting table

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 24 Jun 2010 21:41:47 +1000
Message-ID: <AANLkTil7VCeqRLSCzPM7Cw8BAACF70065cR4bh9vO3fo@mail.gmail.com>
To: Davy Van Deursen <davy.vandeursen@ugent.be>
Cc: Media Fragments Working Group WG <public-media-fragment@w3.org>
Yeah, ok, fair enough. Things are a bit different now than when we
started discussing this.

On Thu, Jun 24, 2010 at 4:15 PM, Davy Van Deursen
<davy.vandeursen@ugent.be> wrote:
> Hi Silvia,
>> -----Original Message-----
>> From: public-media-fragment-request@w3.org [mailto:public-media-
>> fragment-request@w3.org] On Behalf Of Silvia Pfeiffer
>> Sent: woensdag 23 juni 2010 16:18
>> To: Davy Van Deursen
>> Cc: Media Fragments Working Group WG
>> Subject: Re: ACTION-180: Add the WebM codec into our fitting table
>> Well, but we do offer special actions for such formats in HTTP
> interactions.
>> I'm not sure we should be removing that insight that there is a difference
>> between formats that (basically) require header updates and formats that
>> don't. It's also still done when we use URI query rather than URI
> fragment.
> What do you mean by 'special actions' in the context of this conditionally
> fit discussion? You're right that for URI queries, we do have a playable
> resource in the response, but there can be anything behind a URI query (from
> extraction over extraction+syntax element modifications to transcoding). I
> found the distinction between fit and conditionally fit rather confusing for
> media fragment implementers, because it is irrelevant when only URI
> fragments are supported at server-side. In order to also support URI
> queries, implementers might need to take care of header adaptations (from a
> media extractor point-of-view), but I prefer to leave everything open for
> URI queries. For example, even if a requested temporal media fragment is
> extractable in the compressed domain (e.g., t=10,20 results in a byte range
> corresponding to t=9,21), one might decide to transcode anyway (in case of
> URI query) in order to return a media fragment as accurately as possible
> (i.e., when t=10,20 is requested, return a transcoded media fragment
> corresponding to t=10,20).
> Best regards,
> Davy
> --
> Davy Van Deursen
> Ghent University - IBBT
> Department of Electronics and Information Systems - Multimedia Lab
> URL: http://multimedialab.elis.ugent.be/dvdeurse
Received on Thursday, 24 June 2010 11:42:39 UTC

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