Re: video aspect use case

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
Accept-Video-Aspect.

cheers,

Conrad.

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