- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Fri, 21 Jan 2011 15:21:00 +0100
- To: Thomas Steiner <tomac@google.com>
- Cc: Media Fragment <public-media-fragment@w3.org>
On Fri, Jan 21, 2011 at 3:15 PM, Thomas Steiner <tomac@google.com> wrote: > Hi again, > >> I don't understand the connection. If it can be done in CSS, then it's >> a display mechanism. The URL linking mechanism is a very different use >> case, in particular for sharing and embedding etc. I don't really see >> why the availability of one should have any influence on the other. >> Can you explain? > Basically all that I'm saying (and that I think you're saying) is: all > spatial fragmentations (be it clipping ==? cropping, highlighting, > even rotating) can be done purely client-side, however, always > requesting the untouched (spatially-speaking) resource from the > server. I guess we agree on that. Yes, agreed. > Now my question is: are we envisioning servers to handle delivery of > spatial fragments of video/image resources? We are expecting the display of these things through a URI. But we are not expecting the server to do this work. In fact, in the spec we have identified that the cropping cannot easily be done on the server, but it's trivial on the client. So, we expect these media fragment URIs to be interpreted on the client. > Say, on a split-screen > resource (think C64, like > http://img.youtube.com/vi/WZDoPEmo0KU/0.jpg), the delivery of a video > of just the player 2's view (i.e. the server would somehow > live-re-encode the video before it is delivered)? No, no re-encoding with fragments. If you want to provide reencoding services, provide it through a query parameter. > Clearer now, or did > I cause even more confusion? Sorry in either case. No problem at all! Cheers, Silvia. > > Cheers, > Tom > > -- > Thomas Steiner, Research Scientist, Google Inc. > http://blog.tomayac.com, http://twitter.com/tomayac >
Received on Friday, 21 January 2011 14:21:53 UTC