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

Re: video aspect use case

From: RaphaŽl Troncy <Raphael.Troncy@cwi.nl>
Date: Wed, 09 Sep 2009 17:09:17 +0200
Message-ID: <4AA7C51D.5010209@cwi.nl>
To: Philip Jšgenstedt <philipj@opera.com>
CC: Yves Lafon <ylafon@w3.org>, public-media-fragment@w3.org
  I'm not a big fan of this use case and don't necessarily want to 
defend it ... but:

> 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.

 > 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!)

> 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 :-)


RaphaŽl Troncy
EURECOM, Multimedia Communications Department
2229, route des CrÍtes, 06560 Sophia Antipolis, France.
e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
Tel: +33 (0)4 - 9300 8242
Fax: +33 (0)4 - 9000 8200
Web: http://www.cwi.nl/~troncy/
Received on Wednesday, 9 September 2009 15:10:25 UTC

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