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

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 06:16:18 UTC