You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1379 lines
54 KiB
1379 lines
54 KiB
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
|
|
<html lang='en' xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
|
|
<head>
|
|
<meta name="generator" content=
|
|
"HTML Tidy for Linux (vers 6 November 2007), see www.w3.org" />
|
|
|
|
<title>Media Fragments Working Group Teleconference -- 15 Jun
|
|
2010</title>
|
|
<link type="text/css" rel="STYLESHEET" href=
|
|
"http://www.w3.org/StyleSheets/base.css" />
|
|
<link type="text/css" rel="STYLESHEET" href=
|
|
"http://www.w3.org/StyleSheets/public.css" />
|
|
<link type="text/css" rel="STYLESHEET" href=
|
|
"http://www.w3.org/2004/02/minutes-style.css" />
|
|
<meta content="Media Fragments Working Group Teleconference"
|
|
name="Title" />
|
|
<meta content="text/html; charset=utf-8" http-equiv=
|
|
"Content-Type" />
|
|
</head>
|
|
|
|
<body>
|
|
<p><a href="http://www.w3.org/"><img src=
|
|
"http://www.w3.org/Icons/w3c_home" alt="W3C" border="0" height=
|
|
"48" width="72" /></a></p>
|
|
|
|
<h1>- DRAFT -</h1>
|
|
|
|
<h1>Media Fragments Working Group Teleconference</h1>
|
|
|
|
<h2>15 Jun 2010</h2>
|
|
|
|
<p><a href=
|
|
'http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda'>Agenda</a></p>
|
|
|
|
<p>See also: <a href=
|
|
"http://www.w3.org/2010/06/15-mediafrag-irc">IRC log</a></p>
|
|
|
|
<h2><a name="attendees" id="attendees">Attendees</a></h2>
|
|
|
|
<div class="intro">
|
|
<dl>
|
|
<dt>Present</dt>
|
|
|
|
<dd>Jacob, Jack, Yves, Raphael, Erik, davy, Wim, Franck,
|
|
Silvia</dd>
|
|
|
|
<dt>Regrets</dt>
|
|
|
|
<dd>Michael</dd>
|
|
|
|
<dt>Chair</dt>
|
|
|
|
<dd>Raphael, Erik</dd>
|
|
|
|
<dt>Scribe</dt>
|
|
|
|
<dd>raphael</dd>
|
|
</dl>
|
|
</div>
|
|
|
|
<h2>Contents</h2>
|
|
|
|
<ul>
|
|
<li>
|
|
<a href="#agenda">Topics</a>
|
|
|
|
<ol>
|
|
<li><a href="#item01">1. Administrative</a></li>
|
|
|
|
<li><a href="#item02">2. Firefox plugin demo</a></li>
|
|
|
|
<li><a href="#item03">3. Media Fragments URI
|
|
syntax</a></li>
|
|
|
|
<li><a href="#item04">4. Protocol Handling</a></li>
|
|
|
|
<li><a href="#item05">5. Other dimensions (track, id,
|
|
xywh)</a></li>
|
|
|
|
<li><a href="#item06">6. Handling track and id</a></li>
|
|
|
|
<li><a href="#item07">7. Housekeeping</a></li>
|
|
</ol>
|
|
</li>
|
|
|
|
<li><a href="#ActionSummary">Summary of Action Items</a></li>
|
|
</ul>
|
|
<hr />
|
|
|
|
<div class="meeting">
|
|
<p class='phone'></p>
|
|
|
|
<p class='phone'></p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Date: 15 June
|
|
2010</p>
|
|
|
|
<h3 id="item01">1. Administrative</h3>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> scribe: raphael</p>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> scribenick:
|
|
raphael</p>
|
|
|
|
<p class='phone'>The agenda is at <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda">
|
|
http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda</a></p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> agenda approved</p>
|
|
|
|
<h3 id="item02">2. Firefox plugin demo</h3>
|
|
|
|
<p class='phone'>Plugin and demos are available in the CVS
|
|
repository</p>
|
|
|
|
<p class='phone'>Jakub is presenting what the plugin can do</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> do temporal and spatial
|
|
fragments<br />
|
|
... compliant with the current spec, generate the good headers
|
|
and interact with the client media player<br />
|
|
... use of custom controls for the media player in the UA from
|
|
Davy<br />
|
|
... connect to the ninsuna proxy server</p>
|
|
|
|
<p class='phone'>Jakub showing HTTP traces</p>
|
|
|
|
<p class='phone'><cite>Jakub:</cite> first demo, <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/code/plugin/demos/temporal/demo_10-20.html">
|
|
http://www.w3.org/2008/WebVideo/Fragments/code/plugin/demos/temporal/demo_10-20.html</a><br />
|
|
|
|
... if you click elsewhere on the timeline, nothing happened
|
|
... we should fix this in the future<br />
|
|
... second demo, <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/code/plugin/demos/temporal/demo_5-15.html">
|
|
http://www.w3.org/2008/WebVideo/Fragments/code/plugin/demos/temporal/demo_5-15.html</a><br />
|
|
|
|
... what you get is the closest interval</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> let's keep this in mind,
|
|
since I think we should have the smallest interval, not
|
|
necesarily the closest<br />
|
|
... let's keep this open and decide later on, since we might
|
|
need more test cases</p>
|
|
|
|
<p class='phone'><cite>Jakub:</cite> third demo: <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/code/plugin/demos/spatial/demo_spatial1.html">
|
|
http://www.w3.org/2008/WebVideo/Fragments/code/plugin/demos/spatial/demo_spatial1.html</a><br />
|
|
|
|
... just an overlay on the UA player ... no request sent to the
|
|
server<br />
|
|
... problem here: the server does not send X-Content-Duration
|
|
header so no length written in the firefox timeline<br />
|
|
... fourth demo: not yet there, a combination of temporal and
|
|
spatial which nicely highlights the blackboard</p>
|
|
|
|
<p class='phone'>Jakub is using Fiddler, <a href=
|
|
"http://www.fiddler2.com/fiddler2/">http://www.fiddler2.com/fiddler2/</a></p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> but only on Windows<br />
|
|
... you can use any HTTP proxy<br />
|
|
... slightly more reliable than a firebug which is a firefox
|
|
extension</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> good stuff!</p>
|
|
|
|
<p class='phone'><cite>Jakub:</cite> now showing the plugin
|
|
options<br />
|
|
... you will see the settings, where you can put a proxy
|
|
address<br />
|
|
... by default: Ninsuna<br />
|
|
... so it can works for any video (e.g. YouTube) since they are
|
|
proxying to Ninsuna<br />
|
|
... Ninsuna can process on the fly any videos encoded in
|
|
MP4<br />
|
|
... ogg will follow soon</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> some questions regarding
|
|
how the plugin works</p>
|
|
|
|
<p class='phone'><cite>Jakub:</cite> the plugin uses the
|
|
Firefox javascript API ... nothing standardized for setting up
|
|
the headers</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> s/?Wim/Wim/</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> who should detect stupid
|
|
request? e.g. #t=30,20<br />
|
|
... currently, the plugin is sending a request</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> I think the plugin /
|
|
browser should detect such mal-formed requests</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Yes Silvia, as it is
|
|
written in <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/TemporalDimension">
|
|
http://www.w3.org/2008/WebVideo/Fragments/wiki/TemporalDimension</a>,
|
|
TC03</p>
|
|
|
|
<p class='phone'>Jakub showing a very interesting example ...
|
|
from the Mozilla web site, a video of Firefox 3.6</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> where at one point, we
|
|
get a 416 answer instead of a 200!</p>
|
|
|
|
<p class='phone'>Yves pretends that the server is wrong in this
|
|
case</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> what is the
|
|
request?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> EACCcc server seems to
|
|
be misbehaving</p>
|
|
|
|
<p class='irc'><<cite>jsendor</cite>> <a href=
|
|
"http://videos-cdn.mozilla.net/firefox/3.6/whatsnewin36.ogv">http://videos-cdn.mozilla.net/firefox/3.6/whatsnewin36.ogv</a></p>
|
|
|
|
<p class='irc'><<cite>hackerjack</cite>> Jakub, use this
|
|
URL for the non-mf-aware webserver example: <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.ogv">http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.ogv</a></p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> the issue is that when
|
|
Jakub is sending a valid range but unknown by the server, the
|
|
server is sending back a 416 instead of a 200</p>
|
|
|
|
<p class='irc'><<cite>jsendor</cite>> I am sending
|
|
exactly something like this: <a href=
|
|
"http://html5demos.com/assets/dizzy.ogv#t=0:00:05">http://html5demos.com/assets/dizzy.ogv#t=0:00:05</a>,0:00:20
|
|
+ proper headers</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> this is not the problem of
|
|
Apache<br />
|
|
... but a problem of this server</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> scribe: Raphael</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> ScribeNick:
|
|
Raphael</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> chair: Raphael,
|
|
Erik</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> agenda: <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda">
|
|
http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda</a></p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> Date: 15 June 2010</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> which recipes are
|
|
implemented ?</p>
|
|
|
|
<p class='phone'><cite>Jakub:</cite> the one with
|
|
;include-setup<br />
|
|
... I'm not playing with the cache currently</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> if you click on the seeking
|
|
bar, nothing is happening, right?</p>
|
|
|
|
<p class='phone'><cite>Jakub:</cite> yes</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> limitation of the plugin
|
|
= works in firefox, thus with theora codec (no h.264) ... will
|
|
talk about the Chrome plugin later</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> precision, if you click on
|
|
the seeking bar outside of the range the browsers knows
|
|
about</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> So only the recipe at
|
|
5.2.2 is implemented<br />
|
|
... Actually: 5.2.2.2</p>
|
|
|
|
<p class='phone'><cite>Jakub:</cite> I try to investigate how
|
|
to do a Chome plugin<br />
|
|
... it is much newer, so currently we can do less things<br />
|
|
... many requests from developers and Chrome is giving more and
|
|
more power to developers but currently buggy<br />
|
|
... might be difficult to have custom controls too on
|
|
Chrome<br />
|
|
... so rendering in UA will be difficult</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> Chrome has already
|
|
implemented some smart media retrieval<br />
|
|
... live demo: open <a href=
|
|
"http://ninsuna.elis.ugent.be/MediaFragmentsPlayerHTML?url=http%3A//ninsuna.elis.ugent.be/DownloadServlet/apple/10%2C000_BC_trailer_2.mp4%3Ftrack%3D1%3B2%23t%3D100%2C110%26xywh%3Dpercent%3A10%2C10%2C50%2C50&ajax=1&height=375&width=1180">
|
|
http://ninsuna.elis.ugent.be/MediaFragmentsPlayerHTML?url=http%3A//ninsuna.elis.ugent.be/DownloadServlet/apple/10%2C000_BC_trailer_2.mp4%3Ftrack%3D1%3B2%23t%3D100%2C110%26xywh%3Dpercent%3A10%2C10%2C50%2C50&ajax=1&height=375&width=1180</a>
|
|
on Chrome<br />
|
|
... even though the range is at the end, it plays immediately
|
|
!<br />
|
|
... chrome behaves differently with ogg, but just for
|
|
MP4!<br />
|
|
... the ability to jump immediately to a timepoint</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> last issue, our demo is
|
|
a HTML page that contains one video, is it or use case?<br />
|
|
... what's happening if multiple videos on the page?<br />
|
|
... what's happening if the URI is not an html document but a
|
|
ogg resource?</p>
|
|
|
|
<p class='phone'><cite>Jakub:</cite> the fragments is applied
|
|
to ALL <video> elements of the html page<br />
|
|
... for the plugin, it does not know if the video resource has
|
|
been directly requested or through a page</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> shouldn't the URI in
|
|
the video element contain the fragment rather than the html
|
|
page?</p>
|
|
|
|
<p class='phone'><cite>Jakub:</cite> it just adds headers<br />
|
|
... the browser is requesting all elements contained in a
|
|
page</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> each resource
|
|
separately, as it should</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I agree<br />
|
|
... what's happening when the URI in the browser bar is a media
|
|
resource</p>
|
|
|
|
<p class='phone'><cite>Jakub:</cite> Firefox treats this
|
|
separately, it is not a page<br />
|
|
... headers are modified, so it works<br />
|
|
... but we cannot have custom controls, so the UA cannot really
|
|
render the fragment</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> you mean: the plugin
|
|
cannot render the fragment?</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> it can ... with some
|
|
tricks<br />
|
|
... removing the default controls of firefox<br />
|
|
... and use the contextual menu to enforce custom
|
|
controls<br />
|
|
... the issue Silvia is that Firefox does not consider <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.ogv">http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.ogv</a>
|
|
as a page<br />
|
|
... you need to hide the default controls and enforce yours</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> yes, I understood
|
|
that - I was wondering how you managed to get around it</p>
|
|
|
|
<p class='phone'>Room applauses Jakub</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I applaud Jakub, too
|
|
:)</p>
|
|
|
|
<h3 id="item03">3. Media Fragments URI syntax</h3>
|
|
|
|
<p class='phone'>ACTION-152?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-152 -- Yves
|
|
Lafon to change the formal syntax to reflect that we don't need
|
|
a subdelim for selecting multiple tracks but we allow multiple
|
|
track= in the URI + change the top level part to reflect the
|
|
latest change on the mediasegment production -- due 2010-03-16
|
|
-- OPEN</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/152">
|
|
http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/152</a></p>
|
|
|
|
<p class='phone'>When the action has been given: <a href=
|
|
"http://www.w3.org/2010/03/09-mediafrag-minutes.html#action01">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action01</a></p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-track">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-track</a></p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> OK, I need to modify the
|
|
grammar</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> the semantics is a and,
|
|
right?</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> we need to look at the
|
|
prose to make sure that because of this, the media can get
|
|
'bigger', since we are collecting potentially many tracks</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I have an
|
|
announcement</p>
|
|
|
|
<p class='phone'>ACTION-119?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-119 -- Yves
|
|
Lafon to request admins to set up a cvs notifications mailing
|
|
list and notifications -- due 2009-10-14 -- OPEN</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/119">
|
|
http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/119</a></p>
|
|
|
|
<p class='phone'>The mailing list has been setup</p>
|
|
|
|
<p class='phone'>It is:
|
|
member-media-fragment-notifications@w3.org</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> you must subscribe to it
|
|
if you wish to get notifications in our repository</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> <a href=
|
|
"http://lists.w3.org/Archives/Member/member-media-fragment-notifications/">
|
|
http://lists.w3.org/Archives/Member/member-media-fragment-notifications/</a></p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> for example, get
|
|
notifications for all the demo files uploaded this
|
|
morning<br />
|
|
... but also chaanges in the spec<br />
|
|
... this is an opt-in mailing list, so far, only Yves and I are
|
|
subscribed</p>
|
|
|
|
<p class='phone'>close ACTION-119</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-119 Request
|
|
admins to set up a cvs notifications mailing list and
|
|
notifications closed</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Yves is working now on
|
|
the ACTION-152<br />
|
|
... formal grammar fixed now for the URI syntax<br />
|
|
... allow multiple 'track=' in the URI<br />
|
|
... nothing to change in the header syntax since Silvia has
|
|
already foreseen the case<br />
|
|
... i.e: track-ranges-specifier = trackprefix "=" trackparam *(
|
|
";" trackparam )</p>
|
|
|
|
<p class='phone'>close ACTION-152</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-152 Change
|
|
the formal syntax to reflect that we don't need a subdelim for
|
|
selecting multiple tracks but we allow multiple track= in the
|
|
URI + change the top level part to reflect the latest change on
|
|
the mediasegment production closed</p>
|
|
|
|
<p class='phone'>ACTION-160?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-160 -- Yves
|
|
Lafon to send an email reporting the issue for track names --
|
|
due 2010-04-14 -- OPEN</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/160">
|
|
http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/160</a></p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> mail has not been
|
|
sent<br />
|
|
... I will explain the issue</p>
|
|
|
|
<p class='phone'>we are seeing more and more IRIs, so what
|
|
should be the encoding of a fragment in a IRI?</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> how do we specify that
|
|
track names should be encoded in UTF-8 if the IRIs is encoded
|
|
differently ?</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> there are mappings between
|
|
IRIs and URIs<br />
|
|
... IRIs can be a different character set</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> <a href=
|
|
"http://www.ietf.org/rfc/rfc3987.txt">http://www.ietf.org/rfc/rfc3987.txt</a></p>
|
|
|
|
<p class='phone'>Jack is giving an example mixing latin2
|
|
(Polish with /L), utf8 and Big5 (Chinese) encoding</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> I think it is not a unique
|
|
problem for us<br />
|
|
... I'm pretty sure actually<br />
|
|
... so other groups must have faced this issue</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> suggest that Yves's
|
|
action is transformed into a mail to the Internationalization
|
|
WG cc-ing us to flag the issue we have</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> <a href=
|
|
"http://tools.ietf.org/wg/idnabis/">http://tools.ietf.org/wg/idnabis/</a></p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> suggest that Yves does
|
|
this action after lunch break</p>
|
|
|
|
<p class='phone'>ACTION-170?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-170 -- Yves
|
|
Lafon to send an email about metadata headers and 206 responses
|
|
-- due 2010-06-09 -- OPEN</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/170">
|
|
http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/170</a></p>
|
|
|
|
<p class='phone'>See Yves's email at <a href=
|
|
"http://lists.w3.org/Archives/Public/public-media-fragment/2010Jun/0007.html">
|
|
http://lists.w3.org/Archives/Public/public-media-fragment/2010Jun/0007.html</a></p>
|
|
|
|
<p class='phone'>See Silvia's understanding of the issue:
|
|
<a href=
|
|
"http://lists.w3.org/Archives/Public/public-media-fragment/2010Jun/0009.html">
|
|
http://lists.w3.org/Archives/Public/public-media-fragment/2010Jun/0009.html</a></p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> first issue, if you have
|
|
the header data of the media file, and try to get now a
|
|
fragment of it, you need to make sure the representation of the
|
|
resouce has not changed<br />
|
|
... works with if-range and etag</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> <a href=
|
|
"http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-09#section-5.3">
|
|
http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-09#section-5.3</a></p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> second issue, drawing on
|
|
the blackboard<br />
|
|
... request a first fragment (request 1) triggers a reply with
|
|
a Content-Range-Mapping header<br />
|
|
... request a second fragment (request 2) triggers another
|
|
reply with another Content-Range-Mapping header<br />
|
|
... the Content-Range-Mapping is an Entity Header ... so it
|
|
will be saved<br />
|
|
... that's why I think we should NOT add any new headers in the
|
|
spec<br />
|
|
... summary, IF-RANGE is an orthogonal issue ... it is just to
|
|
ensure that we have a fresh copy<br />
|
|
... headers apply to the full resource</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> I understand the issue ...
|
|
but we need paragraphs in the spec<br />
|
|
... perhaps a new section of how caches must work, similar to
|
|
section 7 for clients<br />
|
|
... drawing will put in the wiki in lunch</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> after lunch break,
|
|
continuing on ACTION-170<br />
|
|
... now, we have a drawing on the wiki<br />
|
|
... see <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/File:F2f-jun2010-cr-crm-caching.jpg">
|
|
http://www.w3.org/2008/WebVideo/Fragments/wiki/File:F2f-jun2010-cr-crm-caching.jpg</a><br />
|
|
|
|
... I think the discussion should now interest both Silvia and
|
|
Conrad ... we are discussing a proper use of the
|
|
Content-Range-Mapping header</p>
|
|
|
|
<p class='phone'>ACTION-170?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-170 -- Yves
|
|
Lafon to send an email about metadata headers and 206 responses
|
|
-- due 2010-06-09 -- OPEN</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/170">
|
|
http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/170</a></p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> further explanation ... in
|
|
the 3rd solution of the picture, the CR has just bytes ...
|
|
while the CRM has both bytes + seconds</p>
|
|
|
|
<p class='phone'><cite>Conrad:</cite> your problem is you have
|
|
just one request header (Range) and several reply headers (for
|
|
handling caching)</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> if you have a Vary header,
|
|
the cache will not cache anything at all</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> Req1: Get time range
|
|
0-5, reply bytes 0-2048 + crm 0-5, a nmf-aware cache will cache
|
|
this</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> req2: Get time range
|
|
5-10, reply byte 2048-4096 + crm 5-10. a nmf-aware cache will
|
|
cache it and update crm to be 5-10 only</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> req3: get byte range
|
|
0-4096, cache will reply with bytes 0-4096 with crm 5-10</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> so the client will
|
|
think that 5-10s == 0-4096 bytes which is wrong</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> the CRM header is a
|
|
solution for optimizing the case where old caches will be able
|
|
to cache media fragments expressed in seconds, but will be able
|
|
to serve it only when a subsequent request is expressed in
|
|
terms of byte ranges</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> hance the need to put
|
|
in CRM 2048-4096 = 5s-10s</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> so a UA or cache
|
|
that understands time ranges must be able to understand byte
|
|
ranges, and can effectively ignore the c-r-m response header
|
|
and just deal with byte ranges?</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> is it not a corner
|
|
case?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> conrad: yes, that's
|
|
the idea</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> an UA that understands
|
|
time ranges can do what it wants</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> an UA knowing only
|
|
byte ranges won't give misleading information</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> that's the only
|
|
point</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> well, a ua that only
|
|
understands byte ranges isn't going to make the time range
|
|
request in the first place</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> Adding a Vary: Range,
|
|
on each request, the cnon-mf aware cache will clear its current
|
|
entry</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> Yves, I don't
|
|
understand what you mean by "can do what it wants"</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> obviously the only
|
|
thing to do is to accept the body and play it</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> yes, i wouldn't vary
|
|
on range on this response</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> yes, i wouldn't vary
|
|
on range on this request</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> A mf-aware UA may
|
|
ignore the byte range, and take only the range in second form
|
|
the CRM, (but receiving a 206 means that the server understood
|
|
and sent the right fragment)</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> if a client has sent time
|
|
range request, and receives a 200 with a CRM because the cache
|
|
does not understand Media Fragments, then the client should not
|
|
cache the CRM that does not belong to the 200 response</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-server-mapped-default">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-server-mapped-default</a></p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> we are discussing now
|
|
recipes described in 5.2.2.1 and 5.2.2.2<br />
|
|
... headlines are wrong, since all 5.2.2.x solutions are
|
|
cacheable in some sense</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> CRM is useless in the case
|
|
of a 200 response<br />
|
|
... or if the UA makes a byte ranges request</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> we need to add a
|
|
paragraph for explaining this clearly in the spec<br />
|
|
... the rationale for the introduction of this new header</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Next to the
|
|
introduction of new dimensions for the HTTP Range request
|
|
header, we also introduce a new HTTP response header, called
|
|
Content-Range-Mapping, which provides the mapping of the
|
|
retrieved byte range to the original Range request, which was
|
|
not in bytes. It serves two purposes:</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> • It Indicates the
|
|
actual mapped range in terms of fragment dimensions. This is
|
|
necessary since the server might not be able to provide a byte
|
|
range mapping that corresponds exactly to the requested range.
|
|
Therefore, the User Agent needs to be aware of this
|
|
variance.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> It provides context
|
|
information regarding the parent resource in case the Range
|
|
request contained a temporal dimension. More specifically, the
|
|
header contains the start and end time of the parent resource.
|
|
This way, the User Agent is able to understand and visualize
|
|
the temporal context of the media fragment.</p>
|
|
|
|
<p class='phone'><strong class='resolution'>RESOLUTION: adopt
|
|
the third solution drawn on the wiki</strong></p><a name=
|
|
"action01" id="action01"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Yves to modify the ABNF syntax of the
|
|
Content-Range-Mapping header to take into account this
|
|
resolution [recorded in <a href=
|
|
"http://www.w3.org/2010/06/15-mediafrag-minutes.html#action01">http://www.w3.org/2010/06/15-mediafrag-minutes.html#action01</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-171
|
|
- Modify the ABNF syntax of the Content-Range-Mapping header to
|
|
take into account this resolution [on Yves Lafon - due
|
|
2010-06-22].</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> I support very much a
|
|
section for caches</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> I would suggest we rename
|
|
the section 7 into a "Note for Implementers"<br />
|
|
... with 7.1: For UA implementers ... how to render Media
|
|
Fragments<br />
|
|
... with 7.2: For cache implementers ... how to handle Media
|
|
Fragments</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> how about for each
|
|
example, you show how you would retrieve the first 10k of a
|
|
media fragment request, ie. the first 10k of "this video from
|
|
time 5-10min" ... then the next 10k ... then the next 10k ...
|
|
of that</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> if you can do that,
|
|
it's probably usefully cacheable, and streamable</p><a name=
|
|
"action02" id="action02"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Jack to work on the existing Section
|
|
7, and draft 7.2 [recorded in <a href=
|
|
"http://www.w3.org/2010/06/15-mediafrag-minutes.html#action02">http://www.w3.org/2010/06/15-mediafrag-minutes.html#action02</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-172
|
|
- Work on the existing Section 7, and draft 7.2 [on Jack Jansen
|
|
- due 2010-06-22].</p>
|
|
|
|
<p class='phone'>close ACTION-170</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-170 Send an
|
|
email about metadata headers and 206 responses closed</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> to conrad, bytes range are
|
|
absolute with respect to the original resource, so no
|
|
cascading</p>
|
|
|
|
<h3 id="item04">4. Protocol Handling</h3>
|
|
|
|
<p class='phone'><cite>Wim:</cite> issue for non multiplexed
|
|
file ... the video is in the beginning and the audio starts in
|
|
the middle<br />
|
|
... the time ranges correspond to multiple byte ranges<br />
|
|
... how this should be represented in the CRM header?</p>
|
|
|
|
<p class='phone'><cite>Erik:</cite> Wim, can you write an
|
|
example on IRC?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Wim: <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-server-mapped-setup">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-server-mapped-setup</a>
|
|
is your answer</p>
|
|
|
|
<p class='irc'><<cite>Wim</cite>> Content-Range-Mapping:
|
|
t:npt 10-20;include-setup=bytes 0-2000,4000-10000/20000</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> ah, yes, that needs
|
|
to be included in CRM with multiple byte ranges - that's
|
|
correct IMHO</p>
|
|
|
|
<p class='irc'><<cite>Wim</cite>> Content-Range-Mapping:
|
|
t:npt 10-20/0-38;include-setup=bytes
|
|
0-2000,4000-10000/20000</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> no, you cannot ask
|
|
for multiple time ranges</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> 0-38 is the total
|
|
duration</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> ah,ok, fine</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> how about this:</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>>
|
|
Content-Range-Mapping: t:npt 10-20/0-38;include-setup eq bytes
|
|
0-2000,4000-10000/20000</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> a keyword "eq" in
|
|
the middle with spaces around</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> in 5.2.2.3, can you
|
|
receive multiple byte-ranges in the Range-Redirect response
|
|
header?</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> ah yes you can
|
|
:)</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> (the example only
|
|
had one)</p>
|
|
|
|
<p class='irc'><<cite>FD</cite>> Assuming bytes 0-2000
|
|
correspond to include-setup, I would prefer:
|
|
Content-Range-Mapping: t:npt 10-20/0-38;include-setup eq bytes
|
|
4000-10000,0-2000/20000</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>>
|
|
Content-Range-Mapping: (t:npt 10-20/0-38;include-setup)
|
|
eq (bytes 0-2000,4000-10000/20000) ?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> let's use
|
|
<...></p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> then replace 'eq' by
|
|
'equal'?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>>
|
|
Content-Range-Mapping: <t:npt 10-20/0-38;include-setup>
|
|
eq <bytes 0-2000,4000-10000/20000></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Yves: it looks a bit
|
|
ugly, to be honest...</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> no need for
|
|
parenthesis</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> CRM: t:npt
|
|
10-20/0-38;include-setup = bytes 0-2000,4000-1000/2000</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>>
|
|
Content-Range-Mapping: t:npt 10-20/0-38;include-setup
|
|
equals bytes 0-2000,4000-10000/20000</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> a=b is usually
|
|
readable</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> CRM: (t:npt
|
|
10-20/0-38;include-setup) = (bytes 0-2000,4000-1000/2000)</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> and more efficient</p>
|
|
|
|
<p class='phone'><cite>Wim:</cite> '=' is better to parse</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> only one = is allowed
|
|
=> no need for parenthesis</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> remember that it has
|
|
to be parsed by machines</p>
|
|
|
|
<p class='phone'>We need a primary separator (e.g. =) and a
|
|
secondary one (the ';')</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> (and debugged only by
|
|
knowledgeable humans :) )</p>
|
|
|
|
<p class='irc'><<cite>hackerjack</cite>> Would this work?
|
|
CRM: t:npt 10-20/0-38;include-setup bytes
|
|
0-2000,4000-1000/2000</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> please let's have a
|
|
separator or some soft</p>
|
|
|
|
<p class='irc'><<cite>hackerjack</cite>> ok, you've
|
|
convinced me:-)</p>
|
|
|
|
<p class='phone'>First option: Content-Range-Mapping: t:npt
|
|
10-20;include-setup=bytes 0-2000,4000-10000/20000</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> why not removing
|
|
';'</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> Content-Range-Mapping:
|
|
t:npt 10-20 include-setup=bytes 0-2000,4000-10000/20000</p>
|
|
|
|
<p class='irc'><<cite>FD</cite>> Content-Range-Mapping:
|
|
t:npt 10-20,include-setup=bytes 0-2000,4000-10000/20000</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> CRM: (t:npt
|
|
10-20/0-38;include-setup) (bytes 0-2000,4000-1000/2000)</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> {} instead?</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> Content-Range-Mapping:
|
|
t:npt 10-20 include-setup>bytes 0-2000,4000-10000/20000
|
|
?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> if we remove ';' ,
|
|
we should just make it a series of statements:</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>>
|
|
Content-Range-Mapping: t:npt 10-20 include-setup bytes
|
|
0-2000,4000-10000/20000</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> silvia, yes hence the
|
|
{ token* }</p>
|
|
|
|
<p class='irc'><<cite>hackerjack</cite>> §, anyone?</p>
|
|
|
|
<p class='phone'><cite>PROPOSES:</cite> CRM: {t:npt
|
|
10-20/0-38;include-setup} {bytes 0-2000,4000-1000/2000}</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> better with an = in
|
|
the middle (clearer in the intend), but no big deal if it's not
|
|
there</p>
|
|
|
|
<p class='phone'><cite>PROPOSED:</cite> CRM: {t:npt
|
|
10-20/0-38;include-setup}={bytes 0-2000,4000-1000/2000}</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> sounds good to me</p>
|
|
|
|
<p class='irc'><<cite>Wim</cite>> +1</p>
|
|
|
|
<p class='phone'>+1</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>>
|
|
Content-Range-Mapping: t:npt 10-20; include-setup; bytes
|
|
0-2000,4000-10000/20000</p>
|
|
|
|
<p class='irc'><<cite>hackerjack</cite>> -0</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> based on:</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Set-Cookie:
|
|
UserID=JohnDoe; Max-Age=3600; Version=1</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I checked how other
|
|
headers work at <a href=
|
|
"http://en.wikipedia.org/wiki/List_of_HTTP_headers">http://en.wikipedia.org/wiki/List_of_HTTP_headers</a></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> ok</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> +1 on the above</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it's the talkative
|
|
header ;)</p>
|
|
|
|
<p class='phone'><strong class='resolution'>RESOLUTION: new
|
|
syntax for the Content-Range-Mapping header,
|
|
"Content-Range-Mapping: {t:npt 10-20/0-38;include-setup}={bytes
|
|
0-2000,4000-1000/2000}"</strong></p>
|
|
|
|
<p class='phone'>ACTION-166?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-166 -- Yves
|
|
Lafon to review the ABNF syntax of the HTTP headers introduced
|
|
by the Media Fragment URI spec -- due 2010-06-02 -- OPEN</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/166">
|
|
http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/166</a></p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> I will produce the code for
|
|
checking the grammar of the ABNF syntax of the headers as for
|
|
the URI syntax</p>
|
|
|
|
<p class='phone'>close ACTION-166</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-166 Review
|
|
the ABNF syntax of the HTTP headers introduced by the Media
|
|
Fragment URI spec closed</p><a name="action03" id=
|
|
"action03"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Yves to produce the code that will
|
|
check the grammar of both the URI syntax and the Headers syntax
|
|
[recorded in <a href=
|
|
"http://www.w3.org/2010/06/15-mediafrag-minutes.html#action03">http://www.w3.org/2010/06/15-mediafrag-minutes.html#action03</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-173
|
|
- Produce the code that will check the grammar of both the URI
|
|
syntax and the Headers syntax [on Yves Lafon - due
|
|
2010-06-22].</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> there is common bits
|
|
between the uri syntax and the header syntax<br />
|
|
... could we split this into 3 blocks: common syntax, uri
|
|
syntax and header syntax ?</p><a name="action04" id=
|
|
"action04"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Yves to produce the common syntax
|
|
block [recorded in <a href=
|
|
"http://www.w3.org/2010/06/15-mediafrag-minutes.html#action04">http://www.w3.org/2010/06/15-mediafrag-minutes.html#action04</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-174
|
|
- Produce the common syntax block [on Yves Lafon - due
|
|
2010-06-22].</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> we are also
|
|
repeating some code from the HTTP spec</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> so it's 4 blocks
|
|
really</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> we are importing some stuff
|
|
as a convenience ... but the normative is in the HTTP spec
|
|
referenced</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> except where we
|
|
extend it ;)</p>
|
|
|
|
<p class='phone'>ACTION-137?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-137 -- Jack
|
|
Jansen to check that section 5.2 is implementable using the
|
|
protocol -- due 2010-02-10 -- OPEN</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/137">
|
|
http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/137</a></p>
|
|
|
|
<p class='phone'>We found back what was the
|
|
<strong>ACTION:</strong>-)</p>
|
|
|
|
<p class='phone'>It is actually to read and review the
|
|
_current_ section 5.1!</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> I will put this into the
|
|
section 7!<br />
|
|
... I think the section 7 will not be normative ... but this
|
|
important stuff that needs to be said</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> ACTION-137 is
|
|
ongoing<br />
|
|
... now rephrased into: Merge the content of section 5.1in the
|
|
future section 7 (and check whether it is implementable using
|
|
the protocol?)</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> 3:13pm here</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> looking back at some past
|
|
actions we should close</p>
|
|
|
|
<p class='phone'>drop ACTION-34</p>
|
|
|
|
<p class='irc'><<cite>hackerjack</cite>> trackbot,
|
|
help</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> See <a href=
|
|
"http://www.w3.org/2005/06/tracker/irc">http://www.w3.org/2005/06/tracker/irc</a>
|
|
for help</p>
|
|
|
|
<p class='irc'><<cite>hackerjack</cite>> thanks!</p>
|
|
|
|
<p class='phone'>close ACTION-34</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-34 Look at
|
|
python-url library to see whether he could implement the logic
|
|
on client side closed</p>
|
|
|
|
<p class='phone'>comment ACTION-35 we might come back to these
|
|
if we are lacking implementations, but no resources on this
|
|
now</p>
|
|
|
|
<p class='phone'>close ACTION-35</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-35 Look at
|
|
curl and/or wget to see whether the logic could be implemented
|
|
on client side closed</p>
|
|
|
|
<h3 id="item05">5. Other dimensions (track, id, xywh)</h3>
|
|
|
|
<p class='phone'><cite>Jack:</cite> I would like to make a
|
|
disctinction between the URI syntax part and the HTTP handling
|
|
part<br />
|
|
... the first being well thought, sort-of<br />
|
|
... the second hasn't been enough discussed</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> let's talk first about
|
|
the xywh dimension<br />
|
|
... we have implementation on client (Jakub)<br />
|
|
... purely on client side<br />
|
|
... nothing transmitted over the wire</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I prefer it to stay
|
|
that way actually</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> xywh will only be
|
|
standardized in URI and not in protocol</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> yes silvia, question is
|
|
whether we put strong statements or not in the spec</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> reason being that
|
|
right now there are no codecs I believe where spatial cropping
|
|
can be done by byte ranges</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> but we should add a
|
|
note that it is possible to extend this in the future?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> well there is no need
|
|
to bind that to byte ranges</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> but not saying
|
|
anything means that the door is not closed</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> agreed</p>
|
|
|
|
<p class='phone'>OK, we have the text already written in the
|
|
spec</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> for the explanation</p>
|
|
|
|
<p class='phone'>"Note that the specification does not foresee
|
|
a Range dimension for spatial media fragments since they are
|
|
typically resolved and interpreted by the User Agent (i.e.,
|
|
spatial fragment extraction is not performed on server-side)
|
|
due to the following reasons: "</p>
|
|
|
|
<p class='phone'>Perfect!</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> two use cases for this, the
|
|
grey overlay and the sprite that CSS people want to do</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> track dimension<br />
|
|
... clear use cases in the accessibility community</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> implementation problem with
|
|
tracks when we want to cache it ... too many characters to
|
|
store!</p>
|
|
|
|
<p class='phone'><cite>Wim:</cite> we can always have the
|
|
problem, a time range yields too many byte ranges! ... but it
|
|
is rare for a time range, while it happens for a track
|
|
range</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> how Ninsuna currently
|
|
works, is via the '?' ... a redirect from a hash to the
|
|
query</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> should we write this in our
|
|
new section 7?</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> discussion how to handle
|
|
track and id ... appealing solution from Jack</p>
|
|
|
|
<p class='irc'><<cite>hackerjack</cite>> Silvia, you
|
|
still here?</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> do a redirect in the
|
|
HTTP sense (30x)<br />
|
|
... to a URI with a query</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> a redirect can
|
|
always be performed - I think we should describe this
|
|
generally</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> we are documenting the
|
|
solution ... which in a nutshell comes back to always do a
|
|
redirection when there is track or id selection<br />
|
|
... solution is cacheable but not 'mergeable'</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> "mergeable"?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> you can always
|
|
combine a query with a fragment request</p>
|
|
|
|
<p class='phone'>yeah yeah, we are not talking about this</p>
|
|
|
|
<h3 id="item06">6. Handling track and id</h3>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I'm giving a try to
|
|
describe what is the envisionned solution for parsing Media
|
|
Fragment URI that contains a track or an id selection<br />
|
|
... Case 1: URI requested is under the form: <a href=
|
|
"http://www.example.com/video.ogg#track=1">http://www.example.com/video.ogg#track=1</a>
|
|
or <a href=
|
|
"http://www.example.com/video.ogg#track=myaudio">http://www.example.com/video.ogg#track=myaudio</a><br />
|
|
|
|
... The UA sends a Range request to the server<br />
|
|
... this request has a Range header, "Range:
|
|
track=myaudio"<br />
|
|
... the server sends a 30x reply indicating a Redirect<br />
|
|
... this reply has a Location header, "Location: <a href=
|
|
"http://www.example.com/video.ogg?track=myaudio">http://www.example.com/video.ogg?track=myaudio</a>"<br />
|
|
|
|
... (where the # has been transformed by a ? per server
|
|
decision)<br />
|
|
... the UA sends another request, a normal one this time:
|
|
<a href=
|
|
"http://www.example.com/video.ogg?track=myaudio">http://www.example.com/video.ogg?track=myaudio</a><br />
|
|
|
|
... the server will serve a complete new resource (per the use
|
|
of the query parameter) with a 200 reply<br />
|
|
... in addition, we enforce that the second reply contains a
|
|
Link header, pointing to the original resource, i.e. <a href=
|
|
"http://www.example.com/video.ogg">http://www.example.com/video.ogg</a><br />
|
|
|
|
... Case 2: Combination of track selection and time
|
|
ranges<br />
|
|
... URI requested under the form: <a href=
|
|
"http://www.example.com/video.ogg#track=myaudio&t=20">http://www.example.com/video.ogg#track=myaudio&t=20</a>,50<br />
|
|
|
|
... The UA sends a Range request to the server<br />
|
|
... this request has again a Range header, e.g., "Range:
|
|
track=myaudio,t:npt=20-50"</p>
|
|
|
|
<p class='phone'>the server sends a 30x reply indicating a
|
|
Redirect because of the presence of the track selection</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> this reply has a Location
|
|
header that points to a Media Fragment URI, "Location: <a href=
|
|
"http://www.example.com/video.ogg?track=myaudio#t=20">http://www.example.com/video.ogg?track=myaudio#t=20</a>,50"<br />
|
|
|
|
... the UA sends another request, a RANGE request because of
|
|
the presence of the '#': <a href=
|
|
"http://www.example.com/video.ogg?track=myaudio#t=20">http://www.example.com/video.ogg?track=myaudio#t=20</a>,50<br />
|
|
|
|
... the server will serve a Partial Content reply (206) of a
|
|
newly constructed resource<br />
|
|
... in addition, we enforce that the second replu contains a
|
|
Link header, pointing to the original resource, i.e. <a href=
|
|
"http://www.example.com/video.ogg">http://www.example.com/video.ogg</a></p>
|
|
|
|
<p class='phone'>s/replu.reply</p>
|
|
|
|
<p class='phone'>s/replu/reply</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> In summary, we _always_
|
|
handle the track and id selections by a Redirection<br />
|
|
... we keep the original author intention of using a hash by
|
|
putting back a link to the original resource with the Link
|
|
header<br />
|
|
... this solution is cacheable by the current
|
|
infrastructure<br />
|
|
... This needs to be approved tomorrow</p>
|
|
|
|
<h3 id="item07">7. Housekeeping</h3>
|
|
|
|
<p class='phone'>close ACTION-169</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-169 Reserve
|
|
the bridge for 15&16 June mediafrag f2f closed</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> just finishedchanges
|
|
for Content-Range-Mapping, including examples</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> can someone check
|
|
this? (especially examples, the 307 case of remapping being of
|
|
interest)</p><a name="action05" id="action05"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Yves to update the grammar parsing
|
|
automatically generated code for the URI syntax [recorded in
|
|
<a href=
|
|
"http://www.w3.org/2010/06/15-mediafrag-minutes.html#action05">http://www.w3.org/2010/06/15-mediafrag-minutes.html#action05</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-175
|
|
- Update the grammar parsing automatically generated code for
|
|
the URI syntax [on Yves Lafon - due 2010-06-22].</p>
|
|
|
|
<p class='phone'>ACTION-70?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-70 -- Jack
|
|
Jansen to commit in CVS (code directory) his python code doing
|
|
the parsing on client side of the media fragment -- due
|
|
2009-10-14 -- OPEN</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/70">http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/70</a></p>
|
|
|
|
<p class='phone'>close ACTION-137</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-137 Merge
|
|
the content of section 5.1in the future section 7 (and check
|
|
whether it is implementable using the protocol?) closed</p>
|
|
|
|
<p class='phone'>close ACTION-172</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-172 Work on
|
|
the existing Section 7, and draft 7.2 closed</p>
|
|
|
|
<p class='phone'><cite>ALL:</cite> we need to review the
|
|
section 7</p>
|
|
|
|
<p class='phone'>close ACTION-70</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-70 Commit
|
|
in CVS (code directory) his python code doing the parsing on
|
|
client side of the media fragment closed</p>
|
|
|
|
<p class='phone'>close ACTION-160</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-160 Send an
|
|
email to the Internationalization WG + us reporting the issue
|
|
for track names closed</p>
|
|
|
|
<p class='phone'><cite>See:</cite> <a href=
|
|
"http://lists.w3.org/Archives/Public/public-media-fragment/2010Jun/0022.html">
|
|
http://lists.w3.org/Archives/Public/public-media-fragment/2010Jun/0022.html</a></p>
|
|
|
|
<p class='phone'>close ACTION-171</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-171 Modify
|
|
the ABNF syntax of the Content-Range-Mapping header to take
|
|
into account this resolution closed</p>
|
|
|
|
<p class='phone'><cite>Tomorrow:</cite> come back to the
|
|
discussion on handling tracks and id<br />
|
|
... go through all ISSUES<br />
|
|
... + demo of test cases framework from Davy / Wim</p>
|
|
|
|
<p class='phone'>[meeting adjourned]</p>
|
|
</div>
|
|
|
|
<h2><a name="ActionSummary" id="ActionSummary">Summary of Action
|
|
Items</a></h2><!-- Action Items -->
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Jack to work on
|
|
the existing Section 7, and draft 7.2 [recorded in <a href=
|
|
"http://www.w3.org/2010/06/15-mediafrag-minutes.html#action02">http://www.w3.org/2010/06/15-mediafrag-minutes.html#action02</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Yves to modify
|
|
the ABNF syntax of the Content-Range-Mapping header to take into
|
|
account this resolution [recorded in <a href=
|
|
"http://www.w3.org/2010/06/15-mediafrag-minutes.html#action01">http://www.w3.org/2010/06/15-mediafrag-minutes.html#action01</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Yves to produce
|
|
the code that will check the grammar of both the URI syntax and
|
|
the Headers syntax [recorded in <a href=
|
|
"http://www.w3.org/2010/06/15-mediafrag-minutes.html#action03">http://www.w3.org/2010/06/15-mediafrag-minutes.html#action03</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Yves to produce
|
|
the common syntax block [recorded in <a href=
|
|
"http://www.w3.org/2010/06/15-mediafrag-minutes.html#action04">http://www.w3.org/2010/06/15-mediafrag-minutes.html#action04</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Yves to update
|
|
the grammar parsing automatically generated code for the URI
|
|
syntax [recorded in <a href=
|
|
"http://www.w3.org/2010/06/15-mediafrag-minutes.html#action05">http://www.w3.org/2010/06/15-mediafrag-minutes.html#action05</a>]<br />
|
|
|
|
<br />
|
|
[End of minutes]<br />
|
|
<hr />
|
|
|
|
<address>
|
|
Minutes formatted by David Booth's <a href=
|
|
"http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm">
|
|
scribe.perl</a> version 1.135 (<a href=
|
|
"http://dev.w3.org/cvsweb/2002/scribe/">CVS log</a>)<br />
|
|
$Date: 2010/06/15 15:34:42 $
|
|
</address>
|
|
|
|
<div class="diagnostics">
|
|
<hr />
|
|
|
|
<h2>Scribe.perl diagnostic output</h2>[Delete this section
|
|
before finalizing the minutes.]<br />
|
|
<pre>
|
|
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20
|
|
Check for newer version at <a href=
|
|
"http://dev.w3.org/cvsweb/~checkout~/2002/scribe/">http://dev.w3.org/cvsweb/~checkout~/2002/scribe/</a>
|
|
|
|
Guessing input format: RRSAgent_Text_Format (score 1.00)
|
|
|
|
Succeeded: s/mediua/media/
|
|
Succeeded: s/showinf/showing/
|
|
FAILED: s/???/Wim/
|
|
Succeeded: s/that Apache/that the server/
|
|
Succeeded: s/sililar/similar/
|
|
Succeeded: s/??/Wim/
|
|
Succeeded: s/respnse/response/
|
|
Succeeded: s/or/of/
|
|
Succeeded: s/and server (Ninsuna)//
|
|
WARNING: Bad s/// command: s/replu.reply
|
|
FAILED: s/replu/reply/
|
|
Found Scribe: raphael
|
|
Inferring ScribeNick: raphael
|
|
Found ScribeNick: raphael
|
|
Found Scribe: Raphael
|
|
Found ScribeNick: Raphael
|
|
|
|
WARNING: Replacing list of attendees.
|
|
Old list: +33.4.93.00.aaaa Meeting_Room
|
|
New list: +61.2.801.2.aaaa silvia
|
|
|
|
Default Present: +61.2.801.2.aaaa, silvia
|
|
|
|
WARNING: Replacing previous Present list. (Old list: Jakub, Jack, Yves, Raphael, Erik, Davy, Wim, Franck, Silvia_(remote))
|
|
Use 'Present+ ... ' if you meant to add people without replacing the list,
|
|
such as: <dbooth> Present+ Jacob, Jack, Yves, Raphael, Erik, davy, Wim, Franck, Silvia
|
|
|
|
Present: Jacob Jack Yves Raphael Erik davy Wim Franck Silvia
|
|
Regrets: Michael
|
|
Agenda: <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda">http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda</a>
|
|
Found Date: 15 Jun 2010
|
|
Guessing minutes URL: <a href=
|
|
"http://www.w3.org/2010/06/15-mediafrag-minutes.html">http://www.w3.org/2010/06/15-mediafrag-minutes.html</a>
|
|
People with action items: jack yves
|
|
|
|
</pre>[End of <a href=
|
|
"http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm">
|
|
scribe.perl</a> diagnostic output]
|
|
</div>
|
|
</body>
|
|
</html>
|