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

Re: video aspect use case

From: Philip Jägenstedt <philipj@opera.com>
Date: Wed, 09 Sep 2009 18:59:58 +0200
To: Raphaël Troncy <Raphael.Troncy@cwi.nl>
Cc: "Yves Lafon" <ylafon@w3.org>, public-media-fragment@w3.org
Message-ID: <op.uzz1h8w9atwj1d@sisko.linkoping.osa>
On Wed, 09 Sep 2009 17:09:17 +0200, Raphaël Troncy <Raphael.Troncy@cwi.nl>  

> <disclaimer>
>   I'm not a big fan of this use case and don't necessarily want to  
> defend it ... but:
> </disclaimer>
>> It appears it's not well defined what aspect ratio is supposed to mean  
>> here. Assuming that we are using URI fragments and not query strings,  
>> the 4:3 in video.ogg#aspect=4:3 isn't communicated to the server.
> The whole idea is to communicate to the server that the UA wants the 4:3  
> fragment of 'video.ogg' using a Range request.

The spec doesn't say if the aspect ratio correction should be done by the  
client or the server. In any event, neither client side fixing of broken  
files or server side cropping are compelling use cases in my opinion, and  
hardly need to be standardized as any number of simple hacks could do this  

>  > I've
>> only been able to understand it as forcing the aspect ratio of the  
>> resource, rather than somehow modifying the resource (i.e. the exact  
>> same bytes should be sent).
> Well, not exactly. Converting formats of unequal ratios is done by  
> either cropping the original image to the receiving format's aspect  
> ratio (zooming), by adding horizontal mattes (letterboxing) or vertical  
> mattes (pillarboxing) to retain the original format's aspect ratio, or  
> by distorting the image to fill the receiving format's ratio. Depending  
> on the strategy, if done on server side, the server will not serve the  
> exact same bytes ... and possibly save some bandwidth (needs to be  
> measured though!)

FWIW, CSS3 has image-fit and image-position to specify exactly this  
(likely to be renamed content-fit and content-position).

>> Using it to negotiate byte-different resources with the server is  
>> something else completely, and would require new HTTP headers. It  
>> doesn't seem to be worth spending time specifying in my opinion.
> That might be very well the case :-)
> Cheers.
>    Raphaël

Philip Jägenstedt
Core Developer
Opera Software
Received on Wednesday, 9 September 2009 17:00:39 UTC

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