W3C home > Mailing lists > Public > public-media-fragment@w3.org > January 2011

Re: Video cropping demo

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 21 Jan 2011 15:21:00 +0100
Message-ID: <AANLkTimSaWY-3V5BzRq6hZnqYXqkOqyTJUhK25Qpp3GZ@mail.gmail.com>
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,
> 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

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