Re: Informal (dynamic) Media Fragments URI discussion

Hi all,

Please find my rough summary of the informal meeting below, additions
or corrections welcome:

===
Present: Pierre-Antoine Champin (University of Lyon), Olivier Aubert
(University of Nantes), Harald Sack (HPI Potsdam), Raphaël Troncy
(EURECOM), Thomas Kurz (Salzburg Research, Redlink GmbH), Thomas
Steiner (Google, University of Lyon)

Group photo: http://twitter.com/tomayac/status/601364759829688320

===
(i) Dynamic spatial media fragments

We started off with a demo of dynamic spatial media fragments that I
had hacked together (demo: tomayac.github.io/dynamic-media-fragments/,
explanation: https://github.com/tomayac/dynamic-media-fragments). The
core idea here was to expand the syntax with the minimum required
changes to the current &xywh parameter by simply adding more
quadruples of rectangles like so:
#t=0,10&xywh=0,0,10,10,20,50,120,150,120,40,180,90,200,200,100,100,300,100,90,200.
No separator is needed (but might improve legibility if introduced),
as there are necessarily always a multiple of four digits present.

Currently the individual rectangles are equally distributed according
to the duration of the temporal fragment (if you have a 10s long
temporal media fragment and two pairs of rectangles, then each would
be active during 5s). A micro syntax to specify alternative lengths
could be introduced like so:
&t=0,10&xywh=0.1:0,0,10,10,0.9:20,50,120,150 (for the previous 10s
temporal media fragment, the first rectangle would be active 0.1 * 10s
of the duration, and the second 0.9 * 10s of the duration). This would
be an optional factor and if omitted would default to the equaled
remaining time after all existing factors have been applied (for
&t=0,10&xywh=0.1:0,0,10,10,20,50,120,150, the first rectangle with
factor would be displayed during 0.1 * 10s, the second without factor
during 10s - 0.1 * 10s = 9s).

Note, this is just a rough, first draft idea, nothing more, nothing
less, and not everybody necessarily liked it or all parts of the
proposal.

===
(ii) More shapes for spatial media fragments

There was general agreement that more shapes are needed, at minimum
ellipses, ideally polygons.

We discussed SVG paths, which allow for full freedom, but may be hard
to create manually and require tooling (which exists). Instead of
providing the SVG paths as URL parameters, we looked at allowing for a
reference parameter &ref=http%3A%2F%2Fexample.org%2Fpath.svg with
complex polygon descriptions (this was done in the scope of the
EUROPEANA project). Disadvantages are that the media fragments are no
longer self-contained, that we introduce a potential security problem,
and that we need to deal with potentially delayed loading. We noted
that while the URL length is not limited by specification, it is
limited in practice by implementation choices made in browsers and
servers.

===
(iii) Use cases

We discussed potential use cases:
- Highlighting (demo: http://tomayac.github.io/dynamic-media-fragments/)
- Cropping/clipping (demo: http://tomayac.github.io/xywh.js/demo.html)

We wondered whether the different use cases (highlighting and
clipping/cropping) can be somehow specified through an additional
parameter. We noted that clipping/cropping is "lossy" (servers should
only deliver the clipped/cropped parts), while highlighting is
"lossless" (servers deliver the whole media item and then apply the
highlighting), The CSS WG apparently invites us to spec it, a quick
brainstorm revealed the idea to have a CSS property like
fragment-display=clip|highlight and fragment-border=[as CSS border]
with further things like fragment-opacity etc. possible. We further
thought of video/img/audio::fragment pseudo classes, but did not
discuss the idea closer.

Should multiple temporal fragments be contained in one URI? Use case:
dialog video "Alice, Bob, Alice, Bob"; select only Alice's dialog
contributions. The same effect is possible with multiple URIs. General
big themes we noted were _annotations_ (related:
http://www.openvideoannotation.org/), _display_ (in a player, e.g.,
https://github.com/pasqLisena/Media-Fragment-Player), and _bandwidth
saving_ by only serving parts of media items. We agreed that we need a
common demo platform (tbd): http://mediafragments.org/.

===
(iv) Media fragment querying

Currently driven by Thomas Kurz. Already supports Allen (temporal
algebra), before, after, during, left, right, up, down,…, touch.
Specified in http://2014.eswc-conferences.org/sites/default/files/eswc2014pd_submission_65.pdf.
===

Cheers,
Tom

-- 
Dr. Thomas Steiner, Employee, Google Inc.
http://blog.tomayac.com, http://twitter.com/tomayac

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtP5://xKcd.c0m/1181/
-----END PGP SIGNATURE-----

Received on Friday, 22 May 2015 10:37:32 UTC