- 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
On Wed, 09 Sep 2009 17:09:17 +0200, Raphaël Troncy <Raphael.Troncy@cwi.nl> wrote: > <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 already. > > 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