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.
1019 lines
38 KiB
1019 lines
38 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/x86 (vers 12 April 2005), see www.w3.org" />
|
|
|
|
<title>Media Fragments Working Group Teleconference -- 17 Sep
|
|
2009</title>
|
|
<link type="text/css" rel="STYLESHEET" href=
|
|
"http://www.w3.org/StyleSheets/base.css" />
|
|
<link type="text/css" rel="STYLESHEET" href=
|
|
"http://www.w3.org/StyleSheets/public.css" />
|
|
<link type="text/css" rel="STYLESHEET" href=
|
|
"http://www.w3.org/2004/02/minutes-style.css" />
|
|
<meta content="Media Fragments Working Group Teleconference"
|
|
name="Title" />
|
|
<meta content="text/html; charset=utf-8" http-equiv=
|
|
"Content-Type" />
|
|
</head>
|
|
|
|
<body>
|
|
<p><a href="http://www.w3.org/"><img src=
|
|
"http://www.w3.org/Icons/w3c_home" alt="W3C" border="0" height=
|
|
"48" width="72" /></a></p>
|
|
|
|
<h1>- DRAFT -</h1>
|
|
|
|
<h1>Media Fragments Working Group Teleconference</h1>
|
|
|
|
<h2>17 Sep 2009</h2>
|
|
|
|
<p><a href=
|
|
'http://www.w3.org/2008/WebVideo/Fragments/wiki/FourthF2FAgenda'>Agenda</a></p>
|
|
|
|
<p>See also: <a href=
|
|
"http://www.w3.org/2009/09/17-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, Michael, Raphael, Yves, Silvia, Franck_(irc),
|
|
Jack_(irc), Conrad</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">Specification discussion</a></li>
|
|
|
|
<li><a href="#item02">2. Protocol discussion</a></li>
|
|
|
|
<li><a href="#item03">3. AOB</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: 17 September
|
|
2009</p>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> Meeting: Media
|
|
Fragments Working Group 4th F2F Meeting (Virtual)</p>
|
|
|
|
<h3 id="item01">Specification discussion</h3>
|
|
|
|
<p class='phone'><cite>Erik:</cite> let's discuss first the
|
|
aspect ratio issue</p>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> Scribe: raphael</p>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> Scribenick:
|
|
raphael</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> in my opinion, the aspect
|
|
is just another representation of the video, this is not a part
|
|
of the video</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> I barely agree with the
|
|
fact that aspect is a different thing, but from the processing
|
|
point of view, this is also something that requires
|
|
transcoding<br />
|
|
... I'm happy to remove this use case if people are not
|
|
comfortable with it</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> I just respond to Yves,
|
|
this is the server who does the clipping, but I think that in
|
|
the case of the ratio, the server should do nothing ... this is
|
|
up to the client to add the black parts<br />
|
|
... so I see no reason for a use case, this is a presentation
|
|
issue and not a fragment issue</p>
|
|
|
|
<p class='irc'><<cite>franck</cite>> hi all, will try to
|
|
make the call (romm issue!)</p>
|
|
|
|
<p class='phone'>PROPOSED RESOLUTION: take the aspect feature
|
|
out of the spec and of our requirements</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> +1</p>
|
|
|
|
<p class='phone'>+1</p>
|
|
|
|
<p class='irc'><<cite>Gui</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> +1 (and explain
|
|
why in the doc)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> apect ratio changes
|
|
between what the server can provide and what the client wants
|
|
to present are a presentation issue; one could either clip the
|
|
video or add black bars; this should be up to the client to
|
|
decide, not the server</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> +1</p>
|
|
|
|
<p class='phone'><strong class='resolution'>RESOLUTION: we
|
|
agree that aspect ratio is not a fragment and will not be
|
|
something that we can address with a Media Fragment
|
|
URI</strong></p><a name="action01" id="action01"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Erik and Davy to write a paragraph in
|
|
the documents to explain why we don't include this feature in
|
|
the spec (rationale) based on the group analysis [recorded in
|
|
<a href=
|
|
"http://www.w3.org/2009/09/17-mediafrag-minutes.html#action01">http://www.w3.org/2009/09/17-mediafrag-minutes.html#action01</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-109
|
|
- And Davy to write a paragraph in the documents to explain why
|
|
we don't include this feature in the spec (rationale) based on
|
|
the group analysis [on Erik Mannens - due 2009-09-24].</p>
|
|
|
|
<p class='phone'>Now, let's discuss the role of the ? vs #</p>
|
|
|
|
<p class='phone'>Silvia summary: <a href=
|
|
"http://blog.gingertech.net/2009/09/08/uri-fragments-vs-uri-queries-for-media-fragment-addressing/">
|
|
http://blog.gingertech.net/2009/09/08/uri-fragments-vs-uri-queries-for-media-fragment-addressing/</a></p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> I look at what Yves
|
|
suggested, query and fragment are different depending on the
|
|
need of trascoding or not<br />
|
|
... fragments, as it is defined currently, is something that
|
|
needs to be resolved locally by the UA<br />
|
|
... any comments ?</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> if we have transcoding,
|
|
then URI queries should be used?</p>
|
|
|
|
<p class='irc'><<cite>Gui</cite>> I agree on
|
|
differentiation # for client nav ? for server transcoding</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> yes to Michael
|
|
question</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> my only concern is the
|
|
extra complexity introduced for the implementors</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> we are looking at various
|
|
dimensions, we are pretty sure that for the temporal dimension,
|
|
there will be often no transcoding required for most of the
|
|
formats<br />
|
|
... so no problem<br />
|
|
... the problem will happen for the spatial dimension<br />
|
|
... where are not sure yet, when transcoding will be required ?
|
|
always ?<br />
|
|
... I think therefore it is necessary to have solution for both
|
|
cases when we need transcoding and we don't need</p>
|
|
|
|
<p class='phone'><cite>Conrad:</cite> with /query/ we can
|
|
always go back to the server, with fragments the UA has to do
|
|
something</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> conrad yes or no, yes if it
|
|
receive the whole thing back, no if the server just send what's
|
|
needed</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> look at the example I
|
|
post today, everytime you click, it refresh the pages, this is
|
|
very painful ...<br />
|
|
... this is what we want to change</p>
|
|
|
|
<p class='irc'><<cite>Gui</cite>> saw that. The
|
|
clickthrough in the youtube example uses 2 separate videos that
|
|
interlink each others</p>
|
|
|
|
<p class='phone'>No Gui, see that <a href=
|
|
"http://lists.w3.org/Archives/Public/public-media-fragment/2009Sep/0087.html">
|
|
http://lists.w3.org/Archives/Public/public-media-fragment/2009Sep/0087.html</a></p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> Michael: I
|
|
follow silvia's argumentation, though, for the sake of a simple
|
|
standard I'd opt for # only</p>
|
|
|
|
<p class='irc'><<cite>Gui</cite>> Raphael, yes, that's
|
|
the one I'm referring to. According to what I read, there were
|
|
two similar looking videos involved to provide the linking
|
|
effect for time offsetting.</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> my concern is then what
|
|
will happen with the spatial dimension ... since it requires
|
|
transcoding most of the time</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> the whole document will be
|
|
served<br />
|
|
... since the server cannot satisfy the range request</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> I agree</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> what about
|
|
JPEG2000?</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I have the feeling then
|
|
that we are specifying a feature, #xhwh=100,100,400,400 that
|
|
will never been satisfiable !</p>
|
|
|
|
<p class='phone'>Davy argues that JPEG2000 might do it?</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> in the future, some
|
|
codecs can do it ...</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> normal jpg can do this
|
|
with block elvel as well, no?</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> I think this is not a new
|
|
issue that comes up, we have discussed that a long time ago
|
|
...</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> we will need to document
|
|
that, and particularly add many test cases, when the server
|
|
needs to transcode to satisfy the range request</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I think what we have
|
|
to do in our standard is to provide means for any kind of
|
|
resource to allow creation of a media fragment URI that can
|
|
request access to a fragment; some will be able to satisfy it
|
|
from the local resource, others only with transcoding; thus we
|
|
need to specify our addressing scheme for both possiblities: ?
|
|
and #</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> this is not an out of range
|
|
case<br />
|
|
... this is something that is forbidden</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> +1 to Silvia</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> 416 is only used when it is
|
|
possible to do a range request, but you have a out of bond
|
|
case</p>
|
|
|
|
<p class='irc'><<cite>Gui</cite>> I agree with Silvia :
|
|
"? AND #"</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> here, we have something
|
|
that cannot be applied<br />
|
|
... in the case of transcoding, the server will then must serve
|
|
the whole content with a 200</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> I also agree that we
|
|
need to define both ? and #</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> so the server needs to
|
|
identify whether transcoding is necessary or not, and then rely
|
|
on the default HTTP rules</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> +1 to Silvia too</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> +1 to Silvia</p>
|
|
|
|
<p class='irc'><<cite>Gui</cite>> ? and # 1. Gives more
|
|
control to the user 2. Makes our syntax specification usable by
|
|
current server side implementations</p>
|
|
|
|
<p class='phone'>+1 to silvia</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> I hesitate to make a big
|
|
+1, because of the complexity<br />
|
|
... but I can live with it ... I would prefer to care about #
|
|
now, and work on ? later on</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> from an implementation
|
|
point of view, I think the server has not a lot of extra
|
|
work<br />
|
|
... the query thing comes almost for free when you implement
|
|
the hash</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> I'm thinking on both the
|
|
UA and the server sides<br />
|
|
... principle thing, the more options you have, the more test
|
|
cases and things to think about<br />
|
|
... but I understand the need and the arguments from the
|
|
others</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> I think you're totally
|
|
right, we don't want to add complexity we don't need<br />
|
|
... focus is on the hash, I see the ? as an optimization ...
|
|
the communication aspect is already here anyway<br />
|
|
... for query, we need to specify nothing almost, this is
|
|
already handled<br />
|
|
... in fact, we only specify the communication for the #, so to
|
|
some extent you're ight<br />
|
|
... we are saying that the URI syntax can also be used for
|
|
?</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> we are requiring that
|
|
both are normative ? this is MUST or a SHOULD ?</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> the specification of a
|
|
URL does not say anything about the implementation<br />
|
|
... we open the possibility to create URL in a standard
|
|
format<br />
|
|
... correct me if I'm wrong, but I think we specify just the
|
|
syntax of the URL and the way we should parse it<br />
|
|
... the hash resolution part must be normative</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> an implementation
|
|
that claims to support # must do it this way</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> an implementation
|
|
that claims to support ? must do it that way</p>
|
|
|
|
<p class='irc'><<cite>Gui</cite>> ? and # - 3. Also
|
|
precise if the user wants data in or out of context ?</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> for the query, we could
|
|
suggest to use the same way</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> if this is not
|
|
normative, does that have an incident on interoperability<br />
|
|
... are we after a MUST or a SHOULD?</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> i suggest that an
|
|
implementation must state what it claims to support (eg.
|
|
through http headers, uri parameters or whatever) -- and if it
|
|
makes that claim, it must do it as described</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> +1</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> in the case of ?, I
|
|
think the MUST is a strong constraint</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> whereas if it
|
|
doesn't make that claim (eg. all existing urls) then this
|
|
standard does not apply</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I'm well aware of the
|
|
terminology</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> we specify a MUST on
|
|
the method of advertising that this standard applies to this
|
|
URL</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> as conrad says: if I
|
|
claim conformance, I must follow the protocol - otherwise the
|
|
communication cannot be resolved</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> we need to specify
|
|
how conformance is claimed</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> am I the only one who
|
|
doesn't really get what will be specified normatively in the
|
|
case of the ?</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> are you talking about the
|
|
communication between the UA and the server ?</p>
|
|
|
|
<p class='irc'><<cite>FD</cite>> when using query '?' you
|
|
may have to specify the communication to get context info (Link
|
|
header for example)</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> oups, you're right
|
|
Frank, thanks for the heads up :-)</p>
|
|
|
|
<p class='phone'><cite>Frank:</cite> I just wanted to remember
|
|
the point of using the link header in the response of the
|
|
server ... so the UA gets the context of the parent
|
|
resource</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> Frank, can you
|
|
please be more specific? Are you referring to LRDD?</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> are you suggesting we
|
|
write a MAY use instead of a MUST use?</p>
|
|
|
|
<p class='irc'><<cite>Gui</cite>> Is the difference
|
|
between ? and # introduce a difference between secondary
|
|
resource and a derived resource?</p>
|
|
|
|
<p class='phone'><cite>Frank:</cite> I have no precise idea of
|
|
how the link header semantics should be used</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> I agree with
|
|
Frank. Context should be done via LRDD (<a href=
|
|
"http://tools.ietf.org/html/draft-hammer-discovery-03)">http://tools.ietf.org/html/draft-hammer-discovery-03)</a></p>
|
|
|
|
<p class='phone'><cite>Frank:</cite> but the communication
|
|
between the server and the UA must be alterated because of the
|
|
addition of the link header</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> for me, the link header
|
|
should always be used in the query case<br />
|
|
... we could mandate that<br />
|
|
... I don't think there is a current property / value for that
|
|
already, we might look for it<br />
|
|
... invent a part-of ?</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> i think the link
|
|
header is useful, but should not be MUST</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> perhaps there is already
|
|
something already</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> LRDD specifies the
|
|
semantics for relating a resource and its description via
|
|
describedBy for three cases (link element, Link: header, and
|
|
well-known location)</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> we may have a separate RFC
|
|
for that ...</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> problem of timeline, it
|
|
will be ready on time ?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I agree with conrad
|
|
- if the resource has all the information about the offsetting
|
|
etc inside it, it doesn't need to be accompanied by parent
|
|
information</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> I don't exactly when the
|
|
RFC will be ready ... but I believe the time frame is
|
|
correct</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> <a href=
|
|
"http://tools.ietf.org/id/draft-nottingham-http-link-header-06.txt">
|
|
http://tools.ietf.org/id/draft-nottingham-http-link-header-06.txt</a></p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> <a href=
|
|
"http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt">
|
|
http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt</a></p>
|
|
|
|
<p class='phone'><cite>Conrad:</cite> I think the header is
|
|
useful, but why mandating to send the whole context ?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> +1 with conrad</p>
|
|
|
|
<p class='irc'><<cite>FD</cite>> Agree with Conrad,
|
|
required mainly for display/clipping</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> time to summarize ...
|
|
who wants to give it a try?</p>
|
|
|
|
<p class='phone'>[silence]</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> isn't the summary
|
|
that both are useful in different situations?</p>
|
|
|
|
<p class='phone'>[dead silence]</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> resolution draft: we
|
|
agree that there is a need for allowing both a ? and a #
|
|
specification for media fragments</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> we further agree
|
|
that our main focus is #, but that the communication that we
|
|
define between client and server will be adapted also to the ?
|
|
case</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> I still have a
|
|
question<br />
|
|
... what's happen when there is both ? there is a hierarchy,
|
|
query first and then fragment</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> such that for media
|
|
fragment URIs that cannot be resolved with # because it needs
|
|
transcoding, ? can be used</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> what's happen when:
|
|
?t=10,30#15</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> the ? defines a URL,
|
|
the # is a relative offset</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> I think this is obvious
|
|
to what happens ...<br />
|
|
... the query generates a new resource, and the fragment is a
|
|
new relative offset to this new resource<br />
|
|
... in raphael's case, it will start at 25s</p>
|
|
|
|
<p class='phone'>+1</p>
|
|
|
|
<p class='irc'><<cite>Gui</cite>> +1 that makes sense</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> since a URI with a ?
|
|
part creates a new resource, we have to do the fragment offset
|
|
on the new resource, which in this case means it will start at
|
|
25s</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> +1 to the
|
|
proposal. I'm fine with silvia's explanation</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> our starting point is
|
|
<a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#fragment-query">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#fragment-query</a></p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> does someone have any
|
|
issue in my blog post?<br />
|
|
... if not, then we can give an action to someone to draft a
|
|
good exaplanation based on my post and this discussion on
|
|
irc</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> wondering if there is a
|
|
type in silvia's example at <a href=
|
|
"http://blog.gingertech.net/2009/09/08/uri-fragments-vs-uri-queries-for-media-fragment-addressing/">
|
|
http://blog.gingertech.net/2009/09/08/uri-fragments-vs-uri-queries-for-media-fragment-addressing/</a><br />
|
|
|
|
... Range: seconds=20- and then Content-Range: seconds
|
|
11.85-21.16/3600<br />
|
|
... shouldn't this be seconds=12- ...?</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> no, the server works in a
|
|
best effort<br />
|
|
... I am trying to explain that content may not be able to be
|
|
resolved to the required resolution depending on the
|
|
codec<br />
|
|
... this is an example of what a server might only be able to
|
|
do ...<br />
|
|
... as a server, you ask for a time range, but I can only serve
|
|
you that, and then the UA needs to throw away what's in
|
|
extra<br />
|
|
... no way of doing that differently, since the UA will not be
|
|
able to decode it otherwise</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> the client requests
|
|
t=20, the previous keyframe is t=12 so the server sends from
|
|
there</p>
|
|
|
|
<p class='phone'>Raphael; this 8s is odd :-) there are more
|
|
I-Frames in the middle :-)</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> I'm just suggesting
|
|
there is a typo</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> ignore my keyframe
|
|
explanation here :)</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> check apple movie
|
|
trailers: very few I Frames ...</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> the remaining of the post
|
|
talks about the headers, but this is for next half of the
|
|
meeting</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> one thing at the
|
|
time</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> my guess is that Silvia
|
|
is the best volunteer to draft the summary</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> ok :)</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> zakim unmute
|
|
me</p><a name="action02" id="action02"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Silvia to draft a summary starting
|
|
from her blog post and these IRC minutes in the document
|
|
[recorded in <a href=
|
|
"http://www.w3.org/2009/09/17-mediafrag-minutes.html#action02">http://www.w3.org/2009/09/17-mediafrag-minutes.html#action02</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-110
|
|
- Draft a summary starting from her blog post and these IRC
|
|
minutes in the document [on Silvia Pfeiffer - due
|
|
2009-09-24].</p>
|
|
|
|
<h3 id="item02">2. Protocol discussion</h3>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> ACTION-69?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-69 --
|
|
Conrad Parker to draw a representation of the general structure
|
|
of a media resource, for streamable formats (H/H' + K + D1 + D2
|
|
+ D3) -- due 2009-04-24 -- OPEN</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/69">http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/69</a></p>
|
|
|
|
<p class='phone'><cite>Conrad:</cite> I wanted to describe how
|
|
ogg files are structured<br />
|
|
... and if one is a sub part of another, then which parts
|
|
changed or not</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> if you have an
|
|
original file H D1 D2 D3</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> is this drawing
|
|
available somewhere ?</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> and you make a
|
|
subview that goes H' D2 D3</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> raphael - no,
|
|
it is not available, hence my comment</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> Michael: I
|
|
think conrad needs to draw it (even just with pencil and scan
|
|
it in - and we postpone it to tomorrow ...)</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> with keyframes, you
|
|
might end up with something like H' D2' D3</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I'd also like to
|
|
point out that different containers/codecs work differently and
|
|
have different challenges</p>
|
|
|
|
<p class='phone'><cite>Conrad:</cite> I will draw it tonight,
|
|
postpone the visualization tomorrow morning</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> two more things to
|
|
discuss, headers and range syntax<br />
|
|
... should we start with the Range syntax ?</p>
|
|
|
|
<p class='phone'>[silence]</p>
|
|
|
|
<p class='phone'>Yves's proposal: <a href=
|
|
"http://lists.w3.org/Archives/Public/public-media-fragment/2009Sep/0035.html">
|
|
http://lists.w3.org/Archives/Public/public-media-fragment/2009Sep/0035.html</a></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> let's not mix
|
|
formats</p>
|
|
|
|
<p class='phone'>Yves made 2 suggestions</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> 1: unit and then
|
|
values<br />
|
|
... 2: unit can be mixed</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> second option seems more
|
|
complex</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> we don't need to mix
|
|
units, anyway, the URI syntax does not permit it</p>
|
|
|
|
<p class='phone'>Yves proposal just concerns the time dimension
|
|
... more issue with other dimensions</p>
|
|
|
|
<p class='phone'><cite>Frank:</cite> what will be the duration
|
|
of the track dimension?</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> Michael: track
|
|
and ID do not have dimensions</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> track is identified by a
|
|
name, full stop</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> is track and id a Range
|
|
request?<br />
|
|
... if yes, then what is the Content Range ?<br />
|
|
... if this is: Content-Range: track 'video' / what is behind
|
|
the '/' ?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> you could talk about
|
|
the number of labels</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> track does not
|
|
belong in Range</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> rssagent, draft
|
|
minutes</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> yes, good point from
|
|
Conrad, why does he think track and id are not range
|
|
request?</p>
|
|
|
|
<p class='phone'><cite>Conrad:</cite> I think a track is not
|
|
something one can see as a range</p>
|
|
|
|
<p class='irc'><<cite>Gui</cite>> Track is not a time
|
|
range, at best, Track is a Byte range which correspond to this
|
|
piece of the media only holding the track, at worste, its muxed
|
|
and interleaved and has no range</p>
|
|
|
|
<p class='phone'><cite>Conrad:</cite> i admit, tricky issue</p>
|
|
|
|
<p class='irc'><<cite>Zakim</cite>> mhausenblas, you
|
|
wanted to talk about orthogonal addressing concept continuos
|
|
(time/spatial) and discrete (track/ID)</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> range should be for
|
|
continuous addressing</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Guillaume, we are not
|
|
talking about time range ... but range request, expressed in
|
|
bytes or other units</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> Orthogonal addressing
|
|
concepts: time / spatial (continuous) vs track / id
|
|
(discrete)</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I would say "id" is even
|
|
different, since this is a combination of the others<br />
|
|
... I would put id aside</p>
|
|
|
|
<p class='irc'><<cite>Gui</cite>> raphael: I was
|
|
answering to michael mentioning that track COULD be a time
|
|
range, and I think it just can't</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> you can't define a
|
|
distance metric over track ;-)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> so do we need
|
|
different mechanisms to resolve id and track?</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> so this is why i was
|
|
suggesting a Fragment header</p>
|
|
|
|
<p class='irc'><<cite>Gui</cite>> Michael & Raphael :
|
|
Ok</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> maybe track can only
|
|
ever be used with ?</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/Server-parsed_Fragments">
|
|
http://www.w3.org/2008/WebVideo/Fragments/wiki/Server-parsed_Fragments</a></p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_Examples#Track.2BTime_Fragment_URI">
|
|
http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_Examples#Track.2BTime_Fragment_URI</a></p>
|
|
|
|
<p class='irc'><<cite>Gui</cite>> There is a case where
|
|
what's behind the track video / 1 could be an index in case
|
|
many audio or video tracks</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> when we started to talk
|
|
about fragments, we were talking about continous set of
|
|
bytes<br />
|
|
... for temporal, it was a reasonable assumption<br />
|
|
... for spatial, it starts to be a problem in most of the
|
|
coding format<br />
|
|
... for track, as Conrad said, it is difficult<br />
|
|
... is it a case of transcoding that can be resolved only with
|
|
transcoding ?</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> if an adaptation can
|
|
be expressed in terms of byte ranges, it is not transcoding</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> I'm not sure about that
|
|
either ... I'm very uncertain so far, I need to make my
|
|
mind</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> I'm afraid we are
|
|
introducing something too complex with the ID concept; track
|
|
might be sufficient</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> accessibility is the
|
|
main use case for tracks and it is very important</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> a track request
|
|
without transcoding may result in thousands of byte ranges for
|
|
concatenation</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> our focus is on time ...
|
|
this needs to get more thoughts</p>
|
|
|
|
<p class='irc'><<cite>Gui</cite>> Gui agrees with
|
|
Conrad</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> what's wrong with that
|
|
if the server joines these byte ranges?</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> expectation is to have a
|
|
2nd WD ready by the end of the month to be published</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> would suggest to focus on
|
|
temporal domain for this next version of the WD, such that
|
|
people can start using it - the browser vendors and HTML5 are
|
|
keen to get into it</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> I don't think this is an
|
|
issue for the server to do the join of the bytes ranges and
|
|
serve the joint part</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> davy, yes, that case
|
|
is not an issue</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> for this resolution
|
|
we would need to specify an exact set of range names</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> time for
|
|
resolution<br />
|
|
... I see 2 proposals on the table<br />
|
|
... Proposal 1: Content-Range <timeformat> ' ' <real
|
|
start time> '-' <real end time> '/' <total
|
|
duration><br />
|
|
... actually, <timeformat> is <unit><br />
|
|
... Proposal 2: Content-Range <dimension> ':'
|
|
<unit> ' ' <real start time> '-' <real end
|
|
time> '/' <total duration></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> no quite - this is
|
|
correct for proposal 2: Content-Range: time:<timeformat>
|
|
' ' <real start time> '-' <real end time> '/'
|
|
<total duration></p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> in the second proposal,
|
|
<dimension> will be 'time', 'xywh', etc.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> yeah, but <total
|
|
duration> may change depending on the <unit></p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> what is the added value
|
|
of having the dimension ?<br />
|
|
... smpte unit means we are in the time dimension, no confusion
|
|
possible</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> the value of
|
|
specifying dimension is to simplify the standardization</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> it is more readable, and
|
|
the total duration can be unit dependent and NOT unit
|
|
dependent</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> +1 to Silvia</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> ie. "the advantage
|
|
of being more flexible, but less robust to the introduction of
|
|
new units"</p>
|
|
|
|
<p class='phone'><cite>Erik:</cite> the proposal 2 here is NOT
|
|
the proposal 2 of Yves<br />
|
|
... Proposal 2 is an amendment from Silvia from Proposal 1 from
|
|
Yves</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> advantages as I see
|
|
them: (1) can use default unit per dimension with only
|
|
dimension (2) can be more easily extended with new units since
|
|
<total duration> won't change (3) is more like url
|
|
specification</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> if the duration
|
|
includes a frameno it is timeformat dependent</p>
|
|
|
|
<p class='phone'>correct conrad</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> <total duration> is
|
|
not correct<br />
|
|
... we need to be more generic</p>
|
|
|
|
<p class='irc'><<cite>FD</cite>> Rename <total
|
|
duration> into <total-dimension> ?</p>
|
|
|
|
<p class='phone'>other suggestion ?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Proposal 2:
|
|
Content-Range <dimension> [':' <unit>] ' ' <real
|
|
start time> '-' <real end time> '/' <total
|
|
dimension></p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> +1 to Silvia's
|
|
"Proposal 2" here</p>
|
|
|
|
<p class='phone'>PROPOSED RESOLUTION: Content-Range
|
|
<dimension> [':' <unit>] ' ' <real start
|
|
time> '-' <real end time> '/' <total
|
|
dimension></p>
|
|
|
|
<p class='phone'>+1</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>Gui</cite>> looking</p>
|
|
|
|
<p class='irc'><<cite>Gui</cite>> +1</p>
|
|
|
|
<p class='phone'><strong class='resolution'>RESOLUTION:
|
|
Content-Range <dimension> [':' <unit>] ' ' <real
|
|
start time> '-' <real end time> '/' <total
|
|
dimension> is the syntax to be used for a Range Request for
|
|
the temporal dimension</strong></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> yay</p>
|
|
|
|
<p class='irc'><<cite>Gui</cite>> great!</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> :)</p>
|
|
|
|
<p class='irc'><<cite>FD</cite>> not only temporal!</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> well, we have to see
|
|
if it works for all dimensions</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> right now we're sure
|
|
it works for time</p>
|
|
|
|
<h3 id="item03">3. AOB</h3>
|
|
|
|
<p class='irc'><<cite>FD</cite>> I think <real start
|
|
time> and <real end time> should also be
|
|
generalized</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> FD, so right!</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> bye</p>
|
|
|
|
<p class='phone'>Thanks all for the engagement</p>
|
|
|
|
<p class='irc'><<cite>FD</cite>> quit</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> bye</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> rssagent, draft
|
|
minutes</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> I wish we have the same
|
|
productivity tomorrow morning</p>
|
|
</div>
|
|
|
|
<h2><a name="ActionSummary" id="ActionSummary">Summary of Action
|
|
Items</a></h2><!-- Action Items -->
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Erik and Davy to
|
|
write a paragraph in the documents to explain why we don't
|
|
include this feature in the spec (rationale) based on the group
|
|
analysis [recorded in <a href=
|
|
"http://www.w3.org/2009/09/17-mediafrag-minutes.html#action01">http://www.w3.org/2009/09/17-mediafrag-minutes.html#action01</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Silvia to draft a
|
|
summary starting from her blog post and these IRC minutes in the
|
|
document [recorded in <a href=
|
|
"http://www.w3.org/2009/09/17-mediafrag-minutes.html#action02">http://www.w3.org/2009/09/17-mediafrag-minutes.html#action02</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: 2009/09/17 10:03:42 $
|
|
</address>
|
|
|
|
<div class="diagnostics">
|
|
<hr />
|
|
|
|
<h2>Scribe.perl diagnostic output</h2>[Delete this section
|
|
before finalizing the minutes.]<br />
|
|
<pre>
|
|
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20
|
|
Check for newer version at <a href=
|
|
"http://dev.w3.org/cvsweb/~checkout~/2002/scribe/">http://dev.w3.org/cvsweb/~checkout~/2002/scribe/</a>
|
|
|
|
Guessing input format: RRSAgent_Text_Format (score 1.00)
|
|
|
|
Succeeded: s/anyways/anyway/
|
|
Succeeded: s/LRDD specifies only [to complete]/LRDD specifies the semantics for relating a resource and its description via describedBy for three cases (link element, Link: header, and well-known location)/
|
|
Succeeded: s/type/typo/
|
|
Succeeded: s/suggestion/suggesting/
|
|
Succeeded: s/comple/complex/
|
|
Succeeded: s/something too complex/something too complex with the ID concept; track might be sufficient/
|
|
Succeeded: s/genreic/generic/
|
|
Found Scribe: raphael
|
|
Inferring ScribeNick: raphael
|
|
Found ScribeNick: raphael
|
|
Default Present: +0329331aaaa, mhausenblas, +61.2.801.2.aabb, raphael, silvia, erik, Yves, +2712841aacc, Gui, tmichel, conrad, +aadd, FD
|
|
Present: Davy Erik Michael Raphael Yves Silvia Franck_(irc) Jack_(irc) Conrad
|
|
Agenda: <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/FourthF2FAgenda">http://www.w3.org/2008/WebVideo/Fragments/wiki/FourthF2FAgenda</a>
|
|
Found Date: 17 Sep 2009
|
|
Guessing minutes URL: <a href=
|
|
"http://www.w3.org/2009/09/17-mediafrag-minutes.html">http://www.w3.org/2009/09/17-mediafrag-minutes.html</a>
|
|
People with action items: davy erik silvia
|
|
|
|
</pre>[End of <a href=
|
|
"http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm">
|
|
scribe.perl</a> diagnostic output]
|
|
</div>
|
|
</body>
|
|
</html>
|