Re: video aspect use case

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.

Best Regards,
Silvia.