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

Re: video aspect use case

From: Conrad Parker <conrad@metadecks.org>
Date: Thu, 10 Sep 2009 21:17:45 +0900
Message-ID: <dba6c0830909100517j577eb1cx21f51e8598db82f5@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: public-media-fragment@w3.org
2009/9/10 Silvia Pfeiffer <silviapfeiffer1@gmail.com>:
> On Thu, Sep 10, 2009 at 7:35 PM, Yves Lafon <ylafon@w3.org> wrote:
>> On Thu, 10 Sep 2009, Davy Van Deursen wrote:
>>> What I wanted to say is that, in my view, a different aspect ratio of a
>>> media resource is not a fragment (but a version). Since our task is to
>>> identify media fragments, I think aspect ratio is out of our scope.
>>> Similarly, we do not consider spatial, quality, or temporal scaling.
>> Well, we support clipping, which is roughly equivalent (apect ratio
>> adaptation 'done right' is more than just clipping, it's more adaptative
>> clipping), anyway if people want to drop this, I won't stand in the way.
> I think we should.
> Firstly: if we have a resource where the aspect ratio is known (because the
> resource encodes it - and all common formats do so AFAIK), then the user
> agent can react to an aspect ratio that is different to the one given in its
> display area and add letterboxing or whatever else makes sense. It makes
> sense for the user agent to do this because it knows best what is required
> in terms of display. It does not make sense IMO for a server to make those
> changes to the video because there are different options that can be taken
> and different user agents / applications may want to deal differently with a
> unsuitable aspect ratio. A digital TV should be no exception.
> Secondly: as Philip pointed out: in files where the aspect ratio is wrong,
> it would be possible to provide a URL parameter to communicate this between
> user agent and server. However, it would be much easier if the user agent
> was told this directly rather than a URL be made up for it. Also, if we can
> make up URLs that fix a broken aspect ratio, would we not rather fix the
> file that is broken than implement a server extension that has to go and
> make these fixes for every request?
> I am really not convinced that we can come up with a sensible use case that
> really requires this parameter. And in case there is, we can always leave it
> as an extension to a query mechanism.

I agree.

FWIW for the original use case that Yves posted, I think this should
be negotiated through HTTP headers, eg. Accept-Video-Size or


Received on Thursday, 10 September 2009 12:18:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:43 UTC