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.
2432 lines
91 KiB
2432 lines
91 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 -- 09 Mar
|
|
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>Media Fragments Working Group Teleconference</h1>
|
|
|
|
<h2>09 Mar 2010</h2>
|
|
|
|
<p><a href=
|
|
'http://www.w3.org/2008/WebVideo/Fragments/wiki/FifthF2FAgenda'>Agenda</a></p>
|
|
|
|
<p>See also: <a href=
|
|
"http://www.w3.org/2010/03/09-mediafrag-irc">IRC log</a></p>
|
|
|
|
<h2><a name="attendees" id="attendees">Attendees</a></h2>
|
|
|
|
<div class="intro">
|
|
<dl>
|
|
<dt>Present</dt>
|
|
|
|
<dd>Davy, Erik, Jack, Yves, Franck_(observer), Raphael,
|
|
Silvia_(remote), Conrad_(remote), Philip_(remote),
|
|
Michael_(remote)</dd>
|
|
|
|
<dt>Regrets</dt>
|
|
|
|
<dt>Chair</dt>
|
|
|
|
<dd>Erik, Raphael</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. First day summary</a></li>
|
|
|
|
<li><a href="#item02">2. HTTP headers discussion</a></li>
|
|
|
|
<li><a href="#item03">3. Implementation Report</a></li>
|
|
|
|
<li><a href="#item04">4. Test Cases review</a></li>
|
|
|
|
<li><a href="#item05">5. Wrap Up</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: 09 March
|
|
2010</p>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> scribenick:
|
|
raphael</p>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> Scribe: Raphael</p>
|
|
|
|
<h3 id="item01">1. First day summary</h3>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I would suggest to start
|
|
today's agenda with 2 short discussion:<br />
|
|
... a) What should be the delimiter in the URI for specifying
|
|
multiple tracks: comma or semi-colon</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> was it understood
|
|
and found acceptable that whatever separator we use can then
|
|
not be part of the track name, even if it's
|
|
percent-encoded?</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> b) Whether we should
|
|
revisit the delimiter in the URI for specifying the time
|
|
dimension and use the dash instead of the comma</p>
|
|
|
|
<p class='phone'>Philip, no, the separator could be used in a
|
|
track (or id) name if it is percent-encoded</p>
|
|
|
|
<p class='phone'>Why would you you prevent to use it?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Because
|
|
percent-decoding happens before matching against each
|
|
syntax</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I sent a rather long
|
|
mail about layering just now, somewhat related.</p>
|
|
|
|
<p class='phone'>Philip, the room agrees with what you just
|
|
said ... there are 2 solutions</p>
|
|
|
|
<p class='phone'>a) We quote :-)</p>
|
|
|
|
<p class='phone'>b) We forbid multiple tracks selection for the
|
|
1.0 version, so there is no delim and no problem</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> basically, the only
|
|
bulletproof solution is: don't use names :)</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> trackbot,
|
|
minutes?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Sorry, jackjansen,
|
|
I don't understand 'trackbot, minutes?'. Please refer to
|
|
<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>foolip</cite>> why was
|
|
track=a&track=b not ok?</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> pointer</p>
|
|
|
|
<p class='phone'>Philip, we will discuss this on the phone in 5
|
|
minutes, could you join?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> wait a sec</p>
|
|
|
|
<p class='phone'>Philip, track=a&track=b is not valid since
|
|
any fragment with multiple occurrence of 't' or 'xywh' or
|
|
'track' or 'id' will be invalid</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> phone number?</p>
|
|
|
|
<p class='phone'>Philip, hold on, phone in 5 minutes</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> ok</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> raphael: we can just
|
|
make multiple occurences of track valid, can't we?</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Philip, that
|
|
would break for libraries that decode only the first of each
|
|
name=value pairs</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> jackjansen: yes, but
|
|
so would t=1&t=2, which processing needs to handle (but it
|
|
shouldn't be valid)</p>
|
|
|
|
<p class='phone'>Philip, t=1&t=2 is indeed invalid per our
|
|
syntax</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> raphael: invalid,
|
|
but the result of processing it the same as if t=2 was used</p>
|
|
|
|
<p class='phone'>the problem is that if you have multiple
|
|
occurences of key=value with the same key, is that some
|
|
libraries just take the last one</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> yes, which is why
|
|
there is a note in the spec warning about the issue</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> should I call in
|
|
now?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> what if somebody else
|
|
decide that t=1&t=2 means something else? Like generate two
|
|
streams, starting at different times?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> somebody else, meaning
|
|
out of our spec</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> we shouldn't define an
|
|
uber-error-recovery mechanism that forbid all reuse and
|
|
enhancements</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Yves: they would
|
|
simply be violating our spec</p>
|
|
|
|
<p class='phone'>so this is not the same: in case of
|
|
#t=10&t=20 ... invalid fragment, the complete resource is
|
|
sent back</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> foolip, yes, so if you
|
|
implement only mediafrag, you'll get all the data, if you
|
|
implement their spec, you'll do the "right thing"</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> having country code
|
|
troubles</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I thought we had
|
|
already discussed this enough times</p>
|
|
|
|
<p class='phone'>Philip, what did we already discuss
|
|
enough?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> nope, dialing in
|
|
gets me a busy tone or nothing at all</p>
|
|
|
|
<p class='phone'>Philip, on the phone Silvia argues, based on
|
|
section 2.2 of the URI draft, that all reserved characters are
|
|
treated equally</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> what jack just
|
|
explained was how I understood it</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> so #track=audio,video
|
|
will work</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> we have the reserved
|
|
characters exactly for the purpose of making sub-delimiters</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> raphael: tried +1
|
|
and +44</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> the percent-encoding
|
|
should not happen on the complete content value, but only on
|
|
the segmented values (after separating on sub-delimiters)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> raphael: just tried
|
|
it, no luck</p>
|
|
|
|
<p class='phone'>Philip, Silvia just contradicts your previous
|
|
statement, re: we will not be able to have a comma in a track
|
|
name</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> we just need to make
|
|
the parsing & %encoding different</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> we can make it work,
|
|
but then we will also have to change how name-value processing
|
|
works and make percent decoding happen later</p>
|
|
|
|
<p class='phone'>Yes Philip</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> another
|
|
incompatability with existing languages, just to be clear</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> if the argument
|
|
against track=a&track=b is that it breaks existing tools,
|
|
using a new separator does the same</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> are there other
|
|
problems with track=a&track=b?</p>
|
|
|
|
<p class='phone'>Philip, the WG_Room + Silvia thinks that using
|
|
one of the subdelim as defined in URI spec is the right thing
|
|
to do ... subdelim are made for that</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> so not breaking existing
|
|
tools</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> raphael: sure, but
|
|
is it worth introducing more incompatibilities?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> name-value lists
|
|
already provides a way to repeat the same name</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> as soon as there is a UTF-8
|
|
character, you will need to decode the string and re-encode the
|
|
string according to RFC2047<br />
|
|
... so we don't need to have a correlation between what is in
|
|
the URI and what ends-up in the HTPP headers</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> yes, but in most of the
|
|
case, there will be ASCII characters so we could ease
|
|
implementers work</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> this is an invit for lazing
|
|
coding<br />
|
|
... I agree with you with the practical case, but we are
|
|
editing a spec<br />
|
|
... we should try to follow patterns set by other RFC spec</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> hu?</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> I dropped
|
|
...</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> i would not object on
|
|
that ... you have a point</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> should we stand with
|
|
yesterday's resolution, i.e. keep the semi-colon as
|
|
separator?</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> I have checked 2 cgi
|
|
libraries and indeed, Philip is right, that makes in practice
|
|
the use of ';' forbidden in track names</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I disagree with
|
|
using a separator</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> Yves is ok with
|
|
multiple &track=</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> let's continue,
|
|
enough time wasted on phones today :)</p>
|
|
|
|
<p class='phone'><cite>Proposal:</cite> a new resolution that
|
|
contradicts yesterday's resolution. Multiple tracks selection
|
|
will be possible using multiple occurrence of the keyword
|
|
'track' (e.g.: #track=audio&track=video)</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> +1</p>
|
|
|
|
<p class='phone'>+1</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> :-)</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> +1</p>
|
|
|
|
<p class='phone'><strong class='resolution'>RESOLUTION: a new
|
|
resolution that contradicts yesterday's resolution. Multiple
|
|
tracks selection will be possible using multiple occurrence of
|
|
the keyword 'track' (e.g.:
|
|
#track=audio&track=video)</strong></p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> perl.....
|
|
brrr......</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> is the delimiter
|
|
controversial?</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> hihi</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> we need to apply many
|
|
changes in the whole document</p>
|
|
|
|
<p class='phone'><cite>Philip:</cite> I have also edited the
|
|
spec</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> please check in</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> breaking up too much
|
|
right now</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> silvia: which bridge
|
|
did you use?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> no, there's no CVS
|
|
web interface that I know of</p><a name="action01" id=
|
|
"action01"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Yves 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 [recorded in
|
|
<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>trackbot</cite>> Created 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 [on Yves Lafon - due 2010-03-16].</p><a name=
|
|
"action02" id="action02"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Raphael to review the complete
|
|
document and check whether there are mroe references to
|
|
uniqueness [recorded in <a href=
|
|
"http://www.w3.org/2010/03/09-mediafrag-minutes.html#action02">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action02</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Sorry, couldn't
|
|
find user - Raphael</p><a name="action03" id="action03"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> troncy to review the complete document
|
|
and check whether there are mroe references to uniqueness
|
|
[recorded in <a href=
|
|
"http://www.w3.org/2010/03/09-mediafrag-minutes.html#action03">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action03</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-153
|
|
- Review the complete document and check whether there are more
|
|
references to uniqueness [on Raphaël Troncy - due
|
|
2010-03-16].</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Yves: I will commit
|
|
now, as it conflicts with the action you just got</p>
|
|
|
|
<p class='phone'>Short dicussion: re-visiting the use of comma
|
|
in definition of temporal definition in URI</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> Conrad proposed to use a
|
|
dash<br />
|
|
... Rejected by all the group<br />
|
|
... it just introduces more problem, uri syntax is not
|
|
correlated to header syntax anyway</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> why is the delimiter
|
|
important?</p>
|
|
|
|
<p class='phone'>Conrad, object formally if you're not
|
|
satisfied with this answer</p>
|
|
|
|
<h3 id="item02">2. HTTP headers discussion</h3>
|
|
|
|
<p class='phone'>Back to the other objection from Conrad, sent
|
|
yesterday</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> the use of the Range
|
|
headers when there is another unit than bytes<br />
|
|
... we miss so far in our discussion the fact that there is
|
|
synthetic headers<br />
|
|
... see also: <a href=
|
|
"http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0084.html">
|
|
http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0084.html</a></p>
|
|
|
|
<p class='phone'>Silvia, Philip: look at <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/MediaFragmentHeaders">
|
|
http://www.w3.org/2008/WebVideo/Fragments/wiki/MediaFragmentHeaders</a></p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> raphael, I'm ok with
|
|
not using a dash for start-end specification</p>
|
|
|
|
<p class='phone'>Conrad, in the URL?</p>
|
|
|
|
<p class='phone'>Conrad, are you ok with using a comma in the
|
|
URL?, i.e. #t=10,20</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> committed some
|
|
stuff, should make some of you cringe in pain ;)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> raphael: except CVS
|
|
is so terrible, when will we switch to git?</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> is the Content-Range in
|
|
other units purely descriptive? ... I would think so</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> <a href=
|
|
"http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0084.html">
|
|
http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0084.html</a></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> HTTP/1.1 206
|
|
blah</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Content-Range:
|
|
t:npt=10-20/60</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>>
|
|
Content-Range-Equivalent: bytes=16384-32768/65536</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> instead return:</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> HTTP/1.1 206
|
|
blah</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>>
|
|
Content-Range-Equivalent: t:npt=10-20/60</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Content-Range:
|
|
bytes=16384-32768/65536</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> we are not sending 16 kB
|
|
but 20 kB since they are also the synthetic headers<br />
|
|
... so your change is just wrong</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> raphael, yes i am ok
|
|
with using a comma in the url</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> we want to stop
|
|
old-fashioned try to cache fragments</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> NO NO NO, we don't send
|
|
synthetic headers<br />
|
|
... this is what we have discussed the last 1/2 year<br />
|
|
... we return in the fragment only the bytes of the original
|
|
resources</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> i don't recall that
|
|
we agreed not to send synthetic headers, obviously we need to
|
|
supply both the headers required for decode ("synthetic") and
|
|
the media data</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> for queries, we must have
|
|
synthetic headers, it is OK, this is a new resource</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> if we use some form
|
|
of referral to byte ranges for the media data, fine, but that
|
|
is optional</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> that is a different
|
|
issue to the overloading of Range though</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> indeed, we haven't taken
|
|
yet a formal resolution</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> perhaps it is now time
|
|
for :-)<br />
|
|
... so let's discuss whether there will be synthetic headers
|
|
exchange in the case of fragments</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> i suggest that the
|
|
response to a fragment url is a valid media stream</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> whether that does or
|
|
doesn't require generating new headers, tailer data,
|
|
intermediate data, referral files (.m3u, adaptive streaming
|
|
etc.) or whatever is media-dependent</p>
|
|
|
|
<p class='phone'>Conrad, does it mean to send synthetic
|
|
headers?</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> raphael, for some
|
|
media types like a raw ogg stream, sure; but that is not
|
|
something to be specified by mfwg</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> here we can propose
|
|
a mechanism for optimising that transfer, like an optional way
|
|
of saying that some part of the representation can equivalently
|
|
be gotten by a byte range retrieval</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> silvia, you
|
|
become unintelligeble</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> breaking up...</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> jack was talking about
|
|
phone quality ;)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> in short, Silvia is
|
|
100% right</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> conrad: no, the
|
|
response to a fragment is a byte range - no media file
|
|
headers</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> Michael: I
|
|
can't hear you guys anymore</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> only the response to
|
|
a query needs to headers</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> indeed, there is a
|
|
contradiction between Silvia and Conrad's view</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> so where do you get
|
|
the headers (required for decode) from?</p>
|
|
|
|
<p class='phone'>Conrad, with another request</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> e.g. a Web browser
|
|
has already set itself up for decoding a media file when it is
|
|
asking for a later byte range</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> hm ... I can't
|
|
get in. damn ... trying other line</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> in that case there
|
|
is no new http header transaction to be specified anyway</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> it is just a
|
|
client-side seek</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> oh - just got a
|
|
mail from admins. seems like they have to reboot out
|
|
(VoIP-based) phone system ... will try again as soon as the
|
|
system is up again</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> will try calling
|
|
into another bridge when summoned the next time</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> thanks raphael
|
|
but I really really want to dail back in ASAP</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> conrad: no, the idea
|
|
of 5.2.2 is to make an improvement over 5.2.1: e.g. instead of
|
|
having to do bisection search with Ogg over network, you get to
|
|
simply ask the server for the right byte ranges by asking for
|
|
the time range or track ..</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> all URI fragment
|
|
requests have to be handled the same way - none will require
|
|
re-retrieving artificial file headers</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I agree with Silvia
|
|
that it's unlikely any browser will implement these headers</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> if you have an
|
|
index, there's just no need.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> for old Ogg files
|
|
without an index, it still makes sense</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> we will not ever
|
|
have all Ogg files with index and thus this is a way to improve
|
|
on the bisection search problem</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> yes, but that's
|
|
probably not reason enough to spend resources on it, we'd just
|
|
tell people to use footool to add an index</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I of course only
|
|
make guesses on behalf of Opera</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> silvia, sure, in the
|
|
case of no server interaction that makes perfect sense</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> well, it was the
|
|
original motiviation for section 5.2.2 - but it may not be
|
|
relevant much longer (unless the video element starts
|
|
supporting other such file formats)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> bah! but there *is*
|
|
server interaction!</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Silvia, Conrad and
|
|
Philip, we are discussing in the room whether a fragment
|
|
request should retrieve a playable resource (with synthetic
|
|
headers) or just bytes from the original resource, or a
|
|
multi-part reply</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> anyway - the
|
|
situation for query is a different one and we can still use all
|
|
of the above arguments to sort out the query case, which will
|
|
indeed need to return a full media resource</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> raphael: the
|
|
original resource, without a shadow of a doubt.</p>
|
|
|
|
<p class='phone'>Yes, Silvia, we don't talk about query, since
|
|
it is easy and we don't need to specify headers anyway ... it
|
|
already works</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> synthetic headers gives us
|
|
problem</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> if we introduce
|
|
header retrieval into media fragments now, we have to also
|
|
change the way in which 5.2.1 works - and that doesn't make
|
|
sense, because that's how browser vendors right now work</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> I'm also more and more
|
|
convinced that we should not sent them on the wire in the
|
|
fragment case</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> not dealing with
|
|
synthetic headers solves sooo many problems</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> if we introduce
|
|
synthetic headers, we get a new media resource with a different
|
|
start and end time - which will result in a different
|
|
presentation</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> that should really
|
|
be reserved for query only</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> indeed</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it's the fundamental
|
|
difference between fragments and queries: fragments === byte
|
|
range requests, query === new resource</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> in that case we
|
|
_never_ need anything else than byte ranges</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> silvia, the
|
|
5.2.1 case is different, it uses byte-ranges</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> and we always need 2
|
|
requests at minimum</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> other than in the
|
|
case where the UA cannot resolve a time range to a byte
|
|
range</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> but that doesn't
|
|
invalidate the other points</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> no, Yves, the UA can
|
|
send a request to the server for a time range and the server
|
|
can reply with the appropriate byte range</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> that is what 5.2.2
|
|
expresses</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> no because it's not
|
|
playable, so you need extra information beforehand</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> (or after)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> 5.2.2 and 5.2.3 also
|
|
use byte ranges</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> silvia, so you
|
|
expect 2 exchanges (for 522): one in bytes to get the header,
|
|
then one in npt to get the video data. Correct?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> but if you got the
|
|
data before, you might be able to do the mapping yourself and
|
|
ask for bytes directly</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Yves, yes, it is
|
|
playable: it assumes the UA already has all the information to
|
|
do something useful with the byte range</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> just as is the case
|
|
with any other retrieval action that uses byte ranges</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> jack: I am assuming
|
|
the headers have already been received earlier</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> it's playable if you
|
|
have a-priori information about the data.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it not, then yes,
|
|
you need to get the headers first</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> either you are
|
|
mandating a specific container that have this characteristic,
|
|
or you don't need this</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> only for OGG,
|
|
actually - MPEG doesn't need that</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Yves, with Ogg as it
|
|
currently is, you cannot do the mapping yourself</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> sure it does, MPEG
|
|
doesn't repeat the headers over and over does it?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> at least not all
|
|
versions</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> fix the container!</p>
|
|
|
|
<p class='phone'>:-)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> in any event: before
|
|
spending lots of time trying to optimize away one network
|
|
roundtrip, perhaps we should see if any implementor actually
|
|
wants to solve this problem.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> foolip: MPEG
|
|
actually does repeat the headers over and over :)</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Silvia, all
|
|
newer formats have a header. So question is, do we do this work
|
|
only for legacy formats?</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> (header: I mean
|
|
one that includes enough info to seek)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Yves: we have fixed
|
|
it and there is now a possibilty to put an Index into Ogg,
|
|
which is why foolip said above that 5.2.2 will not be used very
|
|
often</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> silvia: even MPEG-4?
|
|
always?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> 5.2.2 is only a
|
|
minimal improvement over 5.2.1</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> well, we've already
|
|
done the work and it is a solution for any media format that
|
|
has that problem, so I'd say we can safely leave it in the
|
|
spec</p>
|
|
|
|
<p class='phone'>OK</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> foolip: IIUC yes,
|
|
MPEG-4 has a way to do that, but you'd better ask Eric</p>
|
|
|
|
<p class='phone'>I'm trying to summarize where do we stand</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I don't have a
|
|
strong opinion, but would avoid spending time on it.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> 1. we need a
|
|
decision that URI fragments always just retrieve a byte range
|
|
and assume that the UA already knows how to decode that byte
|
|
range</p>
|
|
|
|
<p class='phone'>5.2.1: The UA is very clever, can do the
|
|
mapping between seconds and bytes, send a Range request in
|
|
bytes, almost no implementation is needed!</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> 2. we need a
|
|
decision if we want to remove 5.2.2 and 5.2.3 from the spec or
|
|
leave it there for legacy formats</p>
|
|
|
|
<p class='phone'>5.2.2: tiny optimiziation, the UA connot do
|
|
the mapping, but there are still 2 requests, the first one, the
|
|
UA got all the headers, the second one, the bytes of the data,
|
|
the UA can play the file because of the first request with the
|
|
headers, the Range request is expressed in seconds for
|
|
example</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> except that getting
|
|
the headers will only happen once and for all subsequence
|
|
fragment requests it will only be one request</p>
|
|
|
|
<p class='phone'>5.2.3: has actuallly 3 exchanges, the first is
|
|
the same than for 5.2.2 where the UA has requested the headers
|
|
to be able to play the resource later on</p>
|
|
|
|
<p class='phone'>OK, so go back to 2 points from Silvia</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> 5.2.3 does what
|
|
5.2.2 does, but in a proxy-cachable manner</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> my interpretation is
|
|
that byte ranges should be good enough for anyone provided the
|
|
container is ok, for clients that will do 2 or more requests to
|
|
get the data</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> i.e. the UA asks the
|
|
server to send it the byte-range mapping and then does
|
|
5.2.1</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> but it has latency
|
|
issues</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> the goal of having
|
|
time ranges is to do everything in one exchange, to reduce
|
|
latency</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> 5.2.3 Proxy cacheable
|
|
Server mapped byte ranges</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> is actually doing 3
|
|
exchanges</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> (but it's fine!)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> indeed, and this is
|
|
why 5.2.1 will realistically be all that UAs do</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> Silvia is right, 5.2.2 is
|
|
just for legacy formats, it has no value overall</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> but there is
|
|
optimisation along a different line for those that do 5.2.2:
|
|
get proxy cachable requsts</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> we can keep it just
|
|
mentionning that this is for legacy formats</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it already says so
|
|
IIRC</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> note that even when
|
|
asked for bytes only, we can send a header to indicate the
|
|
mapping to time ranges</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> jut not in these
|
|
words</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Yves, we could, but
|
|
the UA already knows that, so why would be bother destroying
|
|
cachability in this way?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> silvia, your solution
|
|
for 5.2.2 is just helping bad container formats</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> indeed :)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> for files that have
|
|
been recorded live, getting an index is an extra effort</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> and thus, some files
|
|
will never have that header</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> and I think that
|
|
applies to both Ogg and MPEG</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> so it's not actually
|
|
as unrealistic as one might think</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Silvia, perhaps we
|
|
should document the VERY first request for 5.2.2 and 5.2.3, the
|
|
one where the UA got the headers of the media</p>
|
|
|
|
<p class='phone'>Silvia, I agree, an action for you ?</p>
|
|
|
|
<p class='phone'>I don't give it to you if do it now :-)</p>
|
|
|
|
<p class='phone'>can you do a live edits to add this note?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> agree on both</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> happy to make the
|
|
change</p>
|
|
|
|
<p class='phone'>ok, for the note, it is 2 min work</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> will do both now</p>
|
|
|
|
<p class='phone'>for the other, it will require more work ...
|
|
including changing the figures, you want a formal action?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I don't think we
|
|
need to add a figure</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> those two retrieval
|
|
actions are independent of each other</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> they may need to
|
|
occur together, but if the UA already has the header, it will
|
|
not need to do that first retrieval action</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> so, I can just add a
|
|
description of it and refer to 5.2.1 with some byte range from
|
|
0</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> foolip: what byte
|
|
range do you typically load for Ogg files?</p>
|
|
|
|
<p class='phone'>Silvia, Yves objects on one thing (please
|
|
listen)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> silvia: start from
|
|
the beginning and load until we need to seek to the end, where
|
|
we get 8500 bytes, then back to wherever data is needed
|
|
next</p>
|
|
|
|
<p class='phone'>Yves considers that 5.2.2 is useless and
|
|
should be removed ... for legacy formats, 5.2.3 should be
|
|
used</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> BUT, he sketchs another
|
|
5.2.2</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> silvia: yes</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I know, we have an
|
|
open bug for it :)</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> which is the original
|
|
intention of the 2-ways handshake, where all data is sent</p>
|
|
|
|
<p class='phone'>Jack is drawing on the board, pictures will
|
|
come soon</p>
|
|
|
|
<p class='phone'>Silvia, in 5.2.1, there is also this VERY
|
|
first request to do, where the UA got the headers, so more
|
|
things to add in the spec</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> do you think you can do
|
|
that in the next hour? or would you need more time?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I wonder about the
|
|
result on 5.2.2</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I didn't make
|
|
changes because I was waiting for Yves' proposal</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> but maybe it's
|
|
another proposal altogether and needs a 5.2.4 ?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I will start working
|
|
on 5.2.1 now</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> 5.2.2 as it is is
|
|
useless, for legacy container 5.2.3 should be used</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> does the spec need
|
|
to go into detail about what byte ranges may or may not be
|
|
needed? it can't be normative anyway</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> (server side
|
|
mapping)</p>
|
|
|
|
<p class='phone'>Sylvia, indeed, don't change 5.2.2 since Yves
|
|
and Jack come with a new nice proposal</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I've adapted
|
|
5.2.1</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> and committed :)</p>
|
|
|
|
<p class='phone'>Silvia, the note for legacy format should go
|
|
in the section 5.2.3, phrased slightly differently, where we
|
|
said, legacy formats that cannot do the mappping (give
|
|
examples, such as the old ogg file) need to use 5.2.3
|
|
description</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it's actually
|
|
irrelevant to the spec where the UA gets the information from
|
|
how to map the fragment to byte ranges - it could come from
|
|
previously stored information or a previous retrieval action or
|
|
from guessing - it doesn't matter</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> so I just made that
|
|
first paragraph more concrete</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> raphael: I disagree
|
|
that 5.2.3 is a requirement for legacy formats</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it is a possibility
|
|
to use this, but not a necessity</p>
|
|
|
|
<p class='phone'>ok silvia</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> and also, you need a
|
|
collaborating server, which will be hard to get</p>
|
|
|
|
<p class='phone'>did you change the figures in 5.2.1 ? we are
|
|
mainly looking at that :-)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> no, as I said: they
|
|
don't need changing</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it doesn't matter
|
|
where the information for the mapping comes from</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it's up to the UA to
|
|
sort this out</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it could come from a
|
|
index file that it was given by a third party server or
|
|
anything else</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it could even just
|
|
be guessing</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> so, there is not
|
|
necessarily an additional retrieval action</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> also, 3.2 already
|
|
describes different means of how the UA could get to that
|
|
information</p>
|
|
|
|
<p class='phone'>Silvia, the WG room thinks that it will be
|
|
much clearer to add this information, and perhaps mark it
|
|
specifically as header retrieval</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> the proof being the
|
|
misunderstanding of some members beforehand</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> there is no header
|
|
retrieval for MPEG</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> some formats just
|
|
have an index somewhere</p>
|
|
|
|
<p class='phone'><cite>Philip:</cite> why did you remove the
|
|
production of Segment? this is the hat on top of query and
|
|
fragment!</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> we have to describe
|
|
the most general case, not just Ogg</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> silvia,
|
|
technically correct., but you will do an initial exchange</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> not necessarily</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> well you need to know
|
|
the compression level</p>
|
|
|
|
<p class='phone'>Exatly Silvia, that's why we think we should
|
|
document how the information to be able to play the file has
|
|
been obtained</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Silvai, and more
|
|
generally I would like to concentrate on modern formats.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I, the UA, may have
|
|
received the information from a third party of how to map time
|
|
to byte ranges</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it doesn't need to
|
|
come through an extra interaction with this particular media
|
|
resource</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> so technically you
|
|
request some bytes at the beginning, not file headers, just do
|
|
have infrmation for doing the mapping</p>
|
|
|
|
<p class='phone'>yes, but for clarity, we should write that
|
|
down somewhere in the spec</p>
|
|
|
|
<p class='phone'>and you could write that this info has been
|
|
obtained from a third-party</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Yves: I do that for
|
|
Ogg, yes</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> but not for MPEG</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I wrote that the UA
|
|
has somehow obtained this information and I wrote an
|
|
example</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I don't think we
|
|
need to add a graphic for it since, there are so many cases</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Silvia, how do
|
|
you guess where to do your first seek, for (say) t=10,20?</p>
|
|
|
|
<p class='phone'>Silvia, you agree that even in the case of
|
|
MPEG, you need to know the compressiojn rate</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> yep, could have been
|
|
given to me in the HTML markup</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> hmm, don't see
|
|
that as a common use (but correct me if I'm wrong)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> jackjansen:
|
|
bisection search, first guess is based on something like total
|
|
size (bytes) amd total duration (seconds)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> there are proposals
|
|
to put such information into the HTML spec</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> if we write into the
|
|
spec that a first retrieval action has to retrieve the resource
|
|
headers, interpret them, and thus extract the mapping of
|
|
fragment addressing to byte range, then we are severely
|
|
restricting how this spec can be used</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> we are prescribing
|
|
something that people will need to ignore to actually make it
|
|
work</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> hehe, I would simply
|
|
ignore the spec if it said something like that</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> see :)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> in fact I will
|
|
ignore *anything* the spec says with regards to what requests
|
|
to make, when to look in the cache, etc</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> there is an impact on
|
|
latency</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Yves, nothing that
|
|
HTML5 doesn't already have</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> "I know just because
|
|
it's a youtube URI that we have this format with this
|
|
compression level" is a client-level hack that shouldn't be
|
|
part of the discussion :)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> there is no extra
|
|
latency for a media fragment URI</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> yes, there is a
|
|
latency problem, but I'd rather solve it with an index than by
|
|
introducing special headers (which most headers won't
|
|
understand)</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Silvia, we are
|
|
not saying it *has to* do this. We're saying it is probably
|
|
going to be the common case.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> which is what I
|
|
described in words</p>
|
|
|
|
<p class='phone'>WHich paragraph exactly Silvia?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> no need for a
|
|
graphic that would imply it always has to be done</p>
|
|
|
|
<p class='phone'>First one in <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-frag">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-frag</a>
|
|
?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> 5.2.1</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> As described in
|
|
section <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#URIfragment-user-agent">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#URIfragment-user-agent</a>,
|
|
the most optimal case is a user agent that knows how to map
|
|
media fragments to byte ranges. This is the case typically
|
|
where a user agent has already downloaded those parts of a
|
|
media resource that allow it to do or guess the mapping, e.g.
|
|
headers or a resource, or an index of a resource.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Yves, if the UA
|
|
already has a copy of the media resource in its local cache
|
|
from a previous retrieval action days ago, it won't do another
|
|
request either</p>
|
|
|
|
<p class='phone'>OK, we seem to agree Silvia (you win a lot
|
|
today)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it's hard work!</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> 6 months!</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> but in the existing
|
|
figure, shows that the UA has already the headers<br />
|
|
... we have a nice drawing on board</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Suggestion: we
|
|
add a little blob to the client timeline saying "header already
|
|
available or not needed"</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it's not a
|
|
information needed for playback of the fragment</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it's a mapping that
|
|
is available</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> fragment to byte
|
|
range mapping already available</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> we agree that header
|
|
is bad usage of "enough information to do the mapping" :)</p>
|
|
|
|
<p class='phone'>Yes Silvia, this is also what Davy who reads
|
|
in your mind say</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> excellent :)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I trust Davy - he
|
|
has implemented the bugger ;)</p>
|
|
|
|
<p class='phone'>Jack, Yves: we change 5.2.2 to have just one
|
|
round trip, similar to 5.2.1</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> the request is epxressed
|
|
in seconds for example<br />
|
|
... the server sends back a playable resource, the only
|
|
question is whether the data parts contains the original
|
|
headers of the media (that need to be changed by the UA) or new
|
|
synthetic headers made by the serve<br />
|
|
... this is not cachable by legacy caches<br />
|
|
... it might be by future caches</p>
|
|
|
|
<p class='phone'>Philip, you reply to me only?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> actually, your
|
|
description of 5.2.2 is exactly what 5.2.2 is</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> no headers
|
|
included</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> only one roundtrip,
|
|
just like 5.2.1</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> why should that
|
|
fragment request contain a header when 5.2.1 doesn't ?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> it needs enough
|
|
information to play the file</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> just like 5.2.1, it
|
|
already has set up the pipeline</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> so in some cases it
|
|
can have headers, in some other cases, not</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> no, in 5.2.2 you MUST
|
|
NOT need to have the information magically before doing the
|
|
request</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> life is so much
|
|
easier if all fragment requests just map to byte range
|
|
requests</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> but it's not
|
|
needed!</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> why would 5.2.2 be
|
|
different to 5.2.1 ?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> you have byte ranges
|
|
for that :)</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> 5.2.2 as it stands has
|
|
no value at all</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> I agree with Yves</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> handling legacy
|
|
formats is 5.2.3</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> handling legacy
|
|
formats using server-based mapping is 5.2.3</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> no, it's also
|
|
5.2.2</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> 5.2.3 is an
|
|
improvement over 5.2.2</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> davy: why?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> handling legacy
|
|
content through byte ranges is 5.2.1</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> we haven't changed
|
|
5.2.2 yet</p>
|
|
|
|
<p class='phone'>we are discussing it</p>
|
|
|
|
<p class='phone'>you want to join on the phone ?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> ok ...</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> but I agree that my
|
|
vision of 5.2.2 might not be implemented _now_ (or ever :) )
|
|
but at least it has a value by reducing the latency and
|
|
requiring only one exchange</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> <a href=
|
|
"http://www.example.com/foo#t=10">http://www.example.com/foo#t=10</a>,20</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> what do you know
|
|
beforehand about this thing?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> => nothing apart
|
|
that it may be a media fragment</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> *new* 5.2.2 is different
|
|
than 5.2.1 since we do not need to have the prior information
|
|
of mapping the seconds to bytes or the original information to
|
|
play the media</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> it is another
|
|
optimization</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> no, 5.2.3 has also (like
|
|
5.2.1) the same asumption than the UA has the information to
|
|
play the media<br />
|
|
... so 5.2.3 is the optimization of 5.2.1<br />
|
|
... Range request always expressed in bytes</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> again, I see now the value
|
|
of 5.2.2<br />
|
|
... for example as follow on requests from the same media<br />
|
|
... someone click on the timeline to request another segment,
|
|
but does not request once more the headers</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I'm considerink asking
|
|
Yves to write his new optimization in a section 5.2.4 and see
|
|
later on if we can keep it or not</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I would be happy if
|
|
we introduced a request type that just gets us the setup
|
|
information</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> then that plus the
|
|
existing 5.2.2 would be what Yves is proposing now</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> silvia, that
|
|
will require two roundtrips again.</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> silvia, I would
|
|
suggest as 5.2.4 a request that gets us setup information PLUS
|
|
data</p>
|
|
|
|
<p class='phone'>Silvia, what this mean <silvia> I would
|
|
be happy if we introduced a request type that just gets us the
|
|
setup information ?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> jack is right: if we
|
|
want to avoid a round trip, we need 5.2.4</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> incidentally, I am
|
|
not sure how much browser vendors care about one additional
|
|
round trip these days ;)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> seeking on Ogg
|
|
without an index typically requires several round trips (I've
|
|
seen 7 and more) and that was bad, but once it was down to 3-4
|
|
it was acceptable</p><a name="action04" id="action04"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Yves to add a section 5.2.4 describing
|
|
his new optimization [recorded in <a href=
|
|
"http://www.w3.org/2010/03/09-mediafrag-minutes.html#action04">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action04</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-154
|
|
- Add a section 5.2.4 describing his new optimization [on Yves
|
|
Lafon - due 2010-03-16].</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> should I make some
|
|
changes to 5.2.2 then?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> as discussed
|
|
before?</p>
|
|
|
|
<p class='phone'>NO</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Attempt summary<br />
|
|
... 5.2.2 = request expressed in npt, anwers sent back in bytes
|
|
+ Content-Range equivalent<br />
|
|
... mandatory<br />
|
|
... or not :-)<br />
|
|
... 5.2.3 = server-based bytes mapping, redirect involve,
|
|
cachable</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I think we can adapt
|
|
the headers once Yves has done his 5.2.4 - we might want to
|
|
harmonize</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> no need to adapt, we
|
|
just reverse the use :)</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> 5.2.4 = unlike the 3
|
|
other cases, we DON'T need to obtain first the mapping
|
|
information (reduce latency), request expressed in npt,
|
|
content-range expressed in the same unit, and content-range
|
|
equivalent is in bytes</p>
|
|
|
|
<p class='phone'>ok ?</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> 5.2.4 is uncacheable for
|
|
legacy caches, but might be cacheable with new ones</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> 5.2.2 doesn't have
|
|
the mapping either</p>
|
|
|
|
<p class='phone'>Silvia, 5.2.2 has the mapping, otherwise, how
|
|
the file is played since this information is not sent</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> no, there is a
|
|
difference between having the fragment to byte mapping and
|
|
having the decoding pipeline set up</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> if 5.2.2 had the
|
|
mapping , it would be 5.2.1</p>
|
|
|
|
<p class='phone'>Silvia, ok, i'm talking only about decoding
|
|
pipeline set up</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> I'm not talking about the
|
|
mapping, different terminology</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> so, 5.2.4: unlike
|
|
the other cases, doesn't have the decoding pipeline set up for
|
|
the file yet and obtains with the request also the necessary
|
|
background information (headers etc)</p>
|
|
|
|
<p class='phone'>Yes silvia</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> this reduced the
|
|
retrieval action by one round trip</p>
|
|
|
|
<p class='phone'>yes silvia</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> now, let me consider
|
|
the headers...</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I think we need an
|
|
extra header that says: send me the setup info, too</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> how else would the
|
|
server know whether it has to just return the bytes or also the
|
|
header bytes?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> and … how does the
|
|
UA know which bytes are header bytes and which are content
|
|
bytes?</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Feeling slightly
|
|
confused for haviing to channel Silvia as well as myself:-)</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> like a 'transcode
|
|
unit' flag</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> might be optional in
|
|
range syntax</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> indeed, we need to
|
|
differenciate at the protocol level that 5.2.2 and 5.2.4 are
|
|
different, most likely new headers?<br />
|
|
... or different header syntax</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> Range: t:npt
|
|
10-20;convert</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> even if we ignored
|
|
5.2.2 and it use of HTTP header syntax: how would the server
|
|
package the data in a way that the client knows it's just
|
|
receiving the header info and some byte range later in the
|
|
file?</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> perhaps it is part of
|
|
Yves's action when describing the new 5.2.4 making sure it does
|
|
not collide with 5.2.2</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> we also need to
|
|
remember that we have defined that media fragments provide for
|
|
a subpart of the main resource and that e.g. a player would
|
|
display the full timeline</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> silvia, through the
|
|
CRE, or a new "here is data" paramter or header or whatever</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> so, the reply needs
|
|
to signal to the UA exactly what data belongs to what</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> ok, I'll wait till
|
|
you've written it</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I just want to make
|
|
sure we are on the same page in that this is NOT a new, shorter
|
|
resource</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> the WG thinks we should
|
|
have a new name that Content-Range-Equivalent</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> that's what the
|
|
query is for</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> the goal is not to
|
|
send synthetic headed (well, metainformation needed to DTRT),
|
|
but the orignal one</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> no, query is
|
|
identifying new resources</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> ok, cool</p>
|
|
|
|
<p class='phone'>Silvia, in 5.2.4 you will still have the
|
|
context, the full timeline of the original media</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> this is where we may
|
|
still need to discuss with Conrad ;)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I'm cool with it</p>
|
|
|
|
<p class='phone'>OK, proposal for new header names?</p>
|
|
|
|
<p class='phone'><cite>Proposal:</cite> Range-Mapping ?</p>
|
|
|
|
<p class='phone'>This new header will be used in 5.2.2 and
|
|
5.2.4</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> in 5.2.2, Content-Ranges
|
|
is expressed in bytes, and Range-Mapping in the unit of the
|
|
original HTTP request<br />
|
|
... in 5.2.4, this is exactly the other way around</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> s/other way
|
|
around/other way round/</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> that conflicts with
|
|
Conrad's opinion who thinks we should not have the Range header
|
|
used with another unit than bytes</p>
|
|
|
|
<p class='phone'>Silvia, are we done with that?</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> we think we can have
|
|
lunck break, demo time, tc reviews now</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> are we calling it
|
|
Range-Mapping?</p>
|
|
|
|
<p class='phone'>are you against?</p>
|
|
|
|
<p class='phone'>silence = approval :-)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I honestly don't
|
|
care :)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> but we didn't
|
|
vote</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>>
|
|
Content-Range-Equivalent was also just signifying the mapping
|
|
:)</p>
|
|
|
|
<p class='phone'><cite>Proposal:</cite> Call the only new
|
|
introduced header 'Range-Mapping'</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> ok, I will make the
|
|
change</p>
|
|
|
|
<p class='phone'><cite>Proposal:</cite> call the only new
|
|
introduced header: 'Content-Range-Mapping'</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> +1 for
|
|
Content-Range-Mapping</p>
|
|
|
|
<p class='phone'>+1 for Content-Range-Mapping</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> +1 for
|
|
'Content-Range-mapping'</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> +1 for
|
|
"Content-Range-mapping"</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> +0</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> I may have opinion on the
|
|
syntax of this new header<br />
|
|
... I have no opinion on the name</p>
|
|
|
|
<p class='phone'><strong class='resolution'>RESOLUTION:
|
|
(pending no objection from Conrad+Philippe) A new header named
|
|
'Content-Range-Mapping' will be introduced, used in sections
|
|
5.2.2 and 5.2.4 at least, which purpose is to expressed a
|
|
mapping of a Content Range between 2 units (e.g. bytes and
|
|
seconds)</strong></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> note that 5.2.3 also
|
|
uses Content-Range-Mapping to signal back to the UA which range
|
|
the provided byte range maps to</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> even 5.2.1 may use
|
|
CRM</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> as metainformation</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I agree with both
|
|
remarks</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> but it reminds me that
|
|
we should probably add a Cache-Control: no-store=" least, which
|
|
purpose"</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> but it reminds me that
|
|
we should probably add a Cache-Control:
|
|
no-store="Content-Range-Mapping"</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Yves: if we used CRM
|
|
in 5.2.1, that would destroy cachability, right?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> why?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> it's meta-information,
|
|
nothing more</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> because of the extra
|
|
header</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> and old caches will
|
|
ignore it</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> no, see the
|
|
cache-control directive ;)</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> "don't store the
|
|
header"</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> ok, so is 5.2.2
|
|
cachable then?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I guess because we
|
|
use the new fragment dimensions on the Range header, they are
|
|
not?</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Conrad, I want to
|
|
clarify one of your wrong asumption in one of your email for
|
|
yesterday night<br />
|
|
... you wrote, don't use comma separated value for selecting
|
|
multiple tracks in the Content-Range headers<br />
|
|
... but we can, since Content-Range header cannot be split</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> <a href=
|
|
"http://www.ietf.org/rfc/rfc2617.txt">http://www.ietf.org/rfc/rfc2617.txt</a>
|
|
(about the use of ',' in headers, and splitting)</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> similar to
|
|
Authorization<br />
|
|
... so: "Content-Range: track audio1,audio2" will be
|
|
valid<br />
|
|
... hope it clarifies this objection you have</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> I will have some
|
|
clarification about that from HTTPbis in our meeting in 2
|
|
weeks<br />
|
|
... if this changes, I will warn you</p>
|
|
|
|
<p class='phone'>Conrad, would you like an action to add your
|
|
use case in the UC document?</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> raphael,
|
|
yes</p><a name="action05" id="action05"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> davy to draw diagrams to include in
|
|
the spec, similar to Yves's email, that shows which bytes from
|
|
the headers and body of the media file are sent [recorded in
|
|
<a href=
|
|
"http://www.w3.org/2010/03/09-mediafrag-minutes.html#action05">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action05</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-155
|
|
- Draw diagrams to include in the spec, similar to Yves's
|
|
email, that shows which bytes from the headers and body of the
|
|
media file are sent [on Davy Van Deursen - due
|
|
2010-03-16].</p><a name="action06" id="action06"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Conrad to add a "bandwidth
|
|
conservation use case" [recorded in <a href=
|
|
"http://www.w3.org/2010/03/09-mediafrag-minutes.html#action06">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action06</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-156
|
|
- Add a "bandwidth conservation use case" [on Conrad Parker -
|
|
due 2010-03-16].</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> raphael, concerning
|
|
the comma, i object more strongly to using Content-Range for
|
|
that anyway :-)</p>
|
|
|
|
<p class='phone'>Conrad, to use Content-range for track?</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> ie. i prefer a new
|
|
header for time ranges etc., for which comma and header
|
|
combining is allowed</p>
|
|
|
|
<p class='phone'>Conrad, you want Range and Content-Range only
|
|
used with the bytes unit?</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> raphael, to use
|
|
Content-Range for bytes (no change to existing implementations)
|
|
and to use a new header to advertise the time range of the
|
|
representation</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> raphael, yes</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> 206 requires a CR</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>>
|
|
s/CR/Content-Range/</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> (or a multipart
|
|
byterange, that contains Content-Range headers)</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> in fact it's not even
|
|
sure that we can do the range mapping in another header</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> generally i would
|
|
like us to specify things so that the responses are cacheable
|
|
with existing proxies, and i think that is well possible</p>
|
|
|
|
<p class='phone'>Conrad, see section 5.2.3</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> yes, use byte
|
|
ranges</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> ok, will
|
|
review</p><a name="action07" id="action07"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Silvia to propagate the changes in the
|
|
spec document now we have the new header
|
|
'Content-Range-Mapping' [recorded in <a href=
|
|
"http://www.w3.org/2010/03/09-mediafrag-minutes.html#action07">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action07</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-157
|
|
- Propagate the changes in the spec document now we have the
|
|
new header 'Content-Range-Mapping' [on Silvia Pfeiffer - due
|
|
2010-03-16].</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> I'm warning everybody that
|
|
it is likely we go in LC with the non-possibility of combining
|
|
dimensions in a fragment URI</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> my action has
|
|
already been done and committed</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> s/in a fragement
|
|
URI/in the HTTP protocol</p>
|
|
|
|
<p class='phone'>close ACTION-157</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-157
|
|
Propagate the changes in the spec document now we have the new
|
|
header 'Content-Range-Mapping' closed</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> raphael: why add
|
|
them back?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> we cannot define the
|
|
syntax in one single layer unless we can come up with the
|
|
syntax for expressing "any string that after percent-decoding
|
|
and decoding UTF-8 is equal to the unicode string x"</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> WD</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Jack confused me
|
|
:)</p>
|
|
|
|
<p class='phone'>and then LC in June as expected</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Yves: can you
|
|
explain what changes you want to revert and why?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> It is obvious that
|
|
there is no common understanding of how things ought to
|
|
work</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> maybe he has a
|
|
syntax</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> that would be great,
|
|
but I'd like to know or we'll just do this all over again
|
|
later.</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> I want to have generic
|
|
syntax + serialization ones</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> so for the URI
|
|
serialization, it shouldn't contradict your algorithm</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> ok, what is the
|
|
generic syntax?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> basically, unencoded
|
|
name=value</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> unencoded?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> well, raw strings in
|
|
utf-8</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> I'll do that
|
|
tonight</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> probably by email
|
|
first</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> on the URI
|
|
fragment/query component level the data is percent-encoded
|
|
bytes, how can a generic syntax be in terms of something
|
|
unencoded?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> is the mediafragment
|
|
production I added not the generic syntax? even though we
|
|
should perhaps rename it to something like namevalues to avoid
|
|
confusion</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> URI fragment/query is
|
|
part of the URI serialization</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> so it will be
|
|
encoded</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Yes, sure</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> but can that be
|
|
expressed in declarative syntax?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I just want to know
|
|
that there is actually some change and not just putting back
|
|
the old syntax which doesn't match what we want implementations
|
|
to match against.</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I suggest Yves send by
|
|
email tonight what he intends to change to finalize the
|
|
discussion</p>
|
|
|
|
<h3 id="item03">3. Implementation Report</h3>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> we will first start with
|
|
a demo from Davy</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> I will first show
|
|
slides<br />
|
|
... URL to be provided soon<br />
|
|
... room laughing at the title<br />
|
|
... " Development of a flash player supporting media fragments:
|
|
frustrations and results"<br />
|
|
... requirements: flash media frgaments player, could be used
|
|
in any browser supporting Flash, communication with Ninsuna or
|
|
any Media Fragments compliant server<br />
|
|
... we want to finally play the media fragments in the UA<br />
|
|
... how to integrate Flash video player with Media Fragments
|
|
servers, 3 possible solutions</p>
|
|
|
|
<p class='phone'>s/frgaments/fragments</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> 1st approach: trivial use
|
|
of the Flash video component<br />
|
|
... takes an input a URI pointing to a MP4 file<br />
|
|
... problem: no possibility to change the HTTP headers, so does
|
|
not work<br />
|
|
... 2nd approach: use the HTTP communication component<br />
|
|
... make use of URLLoader component, possibility to add/set
|
|
HTTP headers<br />
|
|
... problem: browsers only allow modifications of non-standard
|
|
HTTP headers<br />
|
|
... it might be different with JavaScript (Philip, HELP
|
|
!!!)<br />
|
|
... URLLoader and video component are not integrated<br />
|
|
... workaround: save received byte stram in a file ... not
|
|
possible in an AIR application, no progressive play
|
|
possible<br />
|
|
... IE, Firefox and Safari all show the same behavior,
|
|
communication between the flash api and the browser, my
|
|
parameters are blocked and the browser prohibit to change the
|
|
standard HTTP header<br />
|
|
... 3rd approach: write an own flash video component, take as
|
|
input the URLLoader component, requires a huge effort<br />
|
|
... or modify existing flash video component<br />
|
|
... only possible with help from Adobe</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Philip, it would be very
|
|
great if you could react on that, based on your experience with
|
|
Opera, is this possible at all for a browser plugin to interact
|
|
with the browser and change the HTTP headers<br />
|
|
... e.g. a plugin that catchs up the media fragment URI syntax,
|
|
and just send a bytes range request<br />
|
|
... that is NOT possible for sure with a Flash component
|
|
interacting with a browser according to Davy experiment</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> No, it's not
|
|
possible to add arbitrary HTTP headers, and as far as I know
|
|
not any headers at all, not via the netscape plugin API at
|
|
least.</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Davy said you can add
|
|
non standard headers, you cannot modify the default ones!</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Perhaps flash has
|
|
its own HTTP stack that completely bypasses the browser, or
|
|
there is more to the netscape API than I have seen.</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> conclusion is in order to
|
|
support Media Fragments, players MUST be modified</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> foolip:
|
|
XMLHttpRequest allows setting HTTP headers</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Silvia, can you override
|
|
the ones from browser?</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> Media Fragments flash
|
|
player</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> raphael: yes</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> silvia: Is that
|
|
actually implemented by most browsers? In either case, this
|
|
shouldn't be available to plugins.</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> able to play any mp4
|
|
file</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> foolip: I don't know
|
|
if plugins can use it, but you can write it in a Web page</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Philip, are you
|
|
suggesting then that the code of the browsers will need to be
|
|
modified?</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> demo = <a href=
|
|
"http://ninsuna.elis.ugent.be/MediaFragmentsPlayer">http://ninsuna.elis.ugent.be/MediaFragmentsPlayer</a></p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I doubt it will ever
|
|
be possible from plugins if it doesn't already work. I'm sure
|
|
it doesn't work in Opera via plugins because byte ranges
|
|
weren't very well supported before <video></p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Philip, then how do you
|
|
think UA should become media fragment aware? Does Opera plan to
|
|
change the browser code in order to generate Range request?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> We have already done
|
|
it for <video>, supporting media fragments is just a
|
|
matter of parsing a string and seeking to an offset (more or
|
|
less)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> foolip: I think
|
|
setRequestHeader is implemented by all browsers, even as early
|
|
as this <a href=
|
|
"http://www.jibbering.com/2002/4/httprequest.html">http://www.jibbering.com/2002/4/httprequest.html</a>
|
|
<- it is available</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> silvia: XHR?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> yes, part of
|
|
that</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> then it isn't
|
|
available to plugins (Flash), if that's the problem Davy
|
|
had</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Philip, the whole point
|
|
of Media Fragment URI is not to seek to an offset, but generate
|
|
a Range Request to get portions of video clips</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> <a href=
|
|
"http://en.wikipedia.org/wiki/XMLHttpRequest">http://en.wikipedia.org/wiki/XMLHttpRequest</a>
|
|
<- see setRequestHeader</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> raphael: seeking is
|
|
implemented with range requests, that's what I mean.</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> internally it will
|
|
be the same thing, with some fluff for the UI presentation
|
|
perhaps and special behavior when looping</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> philip, ok, thanks for
|
|
the clarification, so I understand that we can use Javascript
|
|
to simulate now new headers generation based on a parsing of
|
|
the Media Fragment URI</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> yes, that's possible
|
|
today, but you'll get to see the first frame of the video for a
|
|
while until the seek is finished.</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> which the browser
|
|
would hide in a native implementation</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> and that browsers, such
|
|
as Opera, will change their code to support media
|
|
fragment?<br />
|
|
... or am I hoping too much?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I can't promise
|
|
anything, it depends on our priorities and how sane we can get
|
|
the processing of media fragments to be</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> amazing demo from
|
|
Davy</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> (which is the reason
|
|
I joined the group)</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> supports already t,
|
|
track and xywh dimensions !!!</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> nice job, Davy!</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> even the space dimension
|
|
nicely rendered in the UA</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Yves: not really,
|
|
I'd like the spec to be good as a whole too :)</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> foolip :)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> to repeat, I don't
|
|
care how things are defined as they allow sane implementation
|
|
that allows future spec changes and progressive
|
|
implementation.</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> ... as long as
|
|
...</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I agree with this goal
|
|
too :-)</p>
|
|
|
|
<p class='phone'>Give it a try with <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4">http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4</a></p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> we not have a cropping on
|
|
only Silvia on the screen, all the rest is black<br />
|
|
... spatial selection + temporal selection done</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> take a photo!</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Philip, could you
|
|
explain us WHY flash cannot set headers and Javascript can
|
|
using the XMLHttpRequest</p>
|
|
|
|
<p class='phone'>?</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> why browsers block one
|
|
way and not the other way?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I think there's just
|
|
no API for it, but it's been a while since I looked at the
|
|
netscape plugin API.</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> pointing to <a href=
|
|
"http://www.jibbering.com/2002/4/httprequest.html">http://www.jibbering.com/2002/4/httprequest.html</a></p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I really don't know
|
|
what Flash does, if it has a separate cache, if it bypasses the
|
|
browsers HTTP stack, etc etc.</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> it is from 2002 !!!</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> yes, my code would also
|
|
have worked few years ago<br />
|
|
... the blocking is recent</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> we are not sure we will
|
|
not get blocked with Javascript either!<br />
|
|
... we need to test</p>
|
|
|
|
<p class='phone'>Silvia, do you follow tis?</p>
|
|
|
|
<p class='phone'>s/tis/this</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Davy: did you try
|
|
FlashXMLHttpRequest?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> <a href=
|
|
"http://blog.monstuff.com/archives/000294.html">http://blog.monstuff.com/archives/000294.html</a></p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> no, that is another
|
|
possibility to sort out</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> In any case using
|
|
XMLHttpRequest to get the video data sounds a bit...
|
|
creative.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it is - and only
|
|
useful when you're trying to demonstrate the use without
|
|
touching player code</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> exactly :-)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> foolip: I'd much
|
|
prefer you put native support into Opera!</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> indeed Silvia, Philip
|
|
the goal is to convince browsers vendors to change their code
|
|
showing them prototypes, but we ALL prefer native support</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> silvia: I'd like
|
|
that too :) Still, I don't set the priorities so I can't make
|
|
promises.</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> The only reason I'm
|
|
here is of course because I think doing MF is worthwhile.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Davy: also make sure
|
|
to take care of the crossdomain stuff, e.g. <a href=
|
|
"http://ejohn.org/blog/cross-site-xmlhttprequest/">http://ejohn.org/blog/cross-site-xmlhttprequest/</a></p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> I will have a look at
|
|
having a pythong+Gstreamer implementation</p>
|
|
|
|
<p class='phone'>s/pythong/python</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> similar to what Davy did
|
|
client side but in python</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> GStreamer :)</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> Michael: many
|
|
excuses - system still seems not to work, can't dial in (but
|
|
doesn't matter now as I have to drop in 15 min, anyway)</p>
|
|
|
|
<p class='irc'><<cite>guillaume</cite>> ref: <a href=
|
|
"http://lists.w3.org/Archives/Public/public-media-fragment/2009Aug/0004.html">
|
|
http://lists.w3.org/Archives/Public/public-media-fragment/2009Aug/0004.html</a></p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Is the room actually
|
|
doing "Review all actions and issues and discuss / close as
|
|
appropriate"?</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> Michael: My
|
|
take on the TC would be - review them and I'll update then in
|
|
the Wiki (see also <a href=
|
|
"http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0086.html)">
|
|
http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0086.html)</a></p>
|
|
|
|
<p class='phone'>ACTION-147?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-147 --
|
|
Michael Hausenblas to add all MF WG members to corrib -- due
|
|
2010-03-05 -- OPEN</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/147">
|
|
http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/147</a></p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> yes, as I wrote
|
|
- having issues with corrib; unsure if it is wise to continue
|
|
with it</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> michael, for the
|
|
time being or forever?</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> well, depends
|
|
on when I have some spare time to fix it, jackjansen ;)</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> I'd recommend
|
|
to keep it in the Wiki for the time being</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> I can still add
|
|
it to corrib later on</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> important
|
|
action is to review them, now</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> I think corrib is a very
|
|
useful tool for us, shame we cannot use it</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> Michael: agree
|
|
with Davy</p>
|
|
|
|
<p class='phone'>Michael, are you suggesting we just review all
|
|
test cases, and the you take the burden to: 1/ update wiki
|
|
pages, 2/ update corrib if this is necessary one day, etc.
|
|
?</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> yes,
|
|
raphael</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> please just
|
|
make sure that you do RESOLUTION: for each TC</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> so that I can
|
|
point to it</p>
|
|
|
|
<p class='phone'>Michael, can you show us the RDF generated by
|
|
corrib ?</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> yes</p>
|
|
|
|
<p class='phone'>is it somewhere in the group directory in
|
|
cvs?</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> no</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> go to <a href=
|
|
"http://ld2sd.deri.org/corrib/">http://ld2sd.deri.org/corrib/</a></p>
|
|
|
|
<p class='phone'>a url pointer?</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> click Dashboard
|
|
...</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> under export
|
|
...</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> <a href=
|
|
"http://ld2sd.deri.org/corrib/corrib.php?export=v1-mediafrag&format=rdf-xml">
|
|
http://ld2sd.deri.org/corrib/corrib.php?export=v1-mediafrag&format=rdf-xml</a></p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> RDF/XML for
|
|
example</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> but also in
|
|
RDFa or via SPARQL endpoint</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Michael, is
|
|
there an import as well?</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> not at the
|
|
moment, jackjansen</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> but I planed to
|
|
do it</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> worth an
|
|
issue/feature request</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> <a href=
|
|
"http://bitbucket.org/mhausenblas/corrib/issues/">http://bitbucket.org/mhausenblas/corrib/issues/</a></p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> ok, chaps,
|
|
sorry - gotta run now. will catch up later, reading minutes and
|
|
anticipating some actions for /me</p>
|
|
|
|
<h3 id="item04">4. Test Cases review</h3>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> WG room made great
|
|
progress in listing all test cases we want for the temporal
|
|
dimension<br />
|
|
... that makes 32 test cases<br />
|
|
... 2 full boards, pictures taken, need to be filled within a
|
|
table</p><a name="action08" id="action08"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Raphael to enter this big table in the
|
|
wiki [recorded in <a href=
|
|
"http://www.w3.org/2010/03/09-mediafrag-minutes.html#action08">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action08</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Sorry, couldn't
|
|
find user - Raphael</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> are there test cases
|
|
for e.g. #t=1&t=2, or #%74=%6ept%3A%310 ?</p><a name=
|
|
"action09" id="action09"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Troncy to enter the big table of all
|
|
test cases for the temporal dimension in the wiki [recorded in
|
|
<a href=
|
|
"http://www.w3.org/2010/03/09-mediafrag-minutes.html#action09">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action09</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-158
|
|
- Enter the big table of all test cases for the temporal
|
|
dimension in the wiki [on Raphaël Troncy - due 2010-03-16].</p>
|
|
|
|
<p class='phone'>#t=1&t=2 ... not yet, since we just did
|
|
temporal dimension, syntax and semantic test, and not yet
|
|
combination</p>
|
|
|
|
<p class='phone'>#%74=10 is included</p>
|
|
|
|
<p class='phone'>so #t=%31%30 is also</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> wait for the table to see
|
|
that fully :-)</p>
|
|
|
|
<p class='phone'>Oh, if the unit is %-encoded ... need to add
|
|
these ones too</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> ok, sounds good, we
|
|
should be testing all kinds of weird input</p>
|
|
|
|
<p class='phone'>yep</p>
|
|
|
|
<h3 id="item05">5. Wrap Up</h3>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> we need one more F2F
|
|
meeting<br />
|
|
... possibility in Raleigh with WWW, who can be there?<br />
|
|
... Raphael, Davy, (Yves = no), (Jack = no?)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Raleigh, North
|
|
Carolina?</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Michael (likely)</p>
|
|
|
|
<p class='phone'>Yes Philip, at WWW 2010, in April</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> Conrad and Silvia: not
|
|
impossible</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> oh, can't make it,
|
|
I'm (very willingly) stuck in Beijing until June</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> what are the other
|
|
possibilities?<br />
|
|
... Sophia Antipolis, host by Yves<br />
|
|
... Hot topic net telecon</p>
|
|
|
|
<p class='phone'>s/net/next</p>
|
|
|
|
<p class='phone'><cite>Erik:</cite> beginning of June may be
|
|
the best time<br />
|
|
... around June 10 ?</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I will send summary of
|
|
today's meeting in few hours</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> Conrad to add a
|
|
"bandwidth conservation use case" [recorded in <a href=
|
|
"http://www.w3.org/2010/03/09-mediafrag-minutes.html#action06">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action06</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> davy to draw
|
|
diagrams to include in the spec, similar to Yves's email, that
|
|
shows which bytes from the headers and body of the media file are
|
|
sent [recorded in <a href=
|
|
"http://www.w3.org/2010/03/09-mediafrag-minutes.html#action05">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action05</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Raphael to enter
|
|
this big table in the wiki [recorded in <a href=
|
|
"http://www.w3.org/2010/03/09-mediafrag-minutes.html#action08">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action08</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Raphael to review
|
|
the complete document and check whether there are mroe references
|
|
to uniqueness [recorded in <a href=
|
|
"http://www.w3.org/2010/03/09-mediafrag-minutes.html#action02">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action02</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Silvia to
|
|
propagate the changes in the spec document now we have the new
|
|
header 'Content-Range-Mapping' [recorded in <a href=
|
|
"http://www.w3.org/2010/03/09-mediafrag-minutes.html#action07">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action07</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Troncy to enter
|
|
the big table of all test cases for the temporal dimension in the
|
|
wiki [recorded in <a href=
|
|
"http://www.w3.org/2010/03/09-mediafrag-minutes.html#action09">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action09</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> troncy to review
|
|
the complete document and check whether there are mroe references
|
|
to uniqueness [recorded in <a href=
|
|
"http://www.w3.org/2010/03/09-mediafrag-minutes.html#action03">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action03</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Yves to add a
|
|
section 5.2.4 describing his new optimization [recorded in
|
|
<a href=
|
|
"http://www.w3.org/2010/03/09-mediafrag-minutes.html#action04">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action04</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Yves 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
|
|
[recorded in <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>]<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/03/09 14:30:11 $
|
|
</address>
|
|
|
|
<div class="diagnostics"></div>
|
|
</body>
|
|
</html>
|