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.
1473 lines
56 KiB
1473 lines
56 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 -- 01 Nov
|
|
2010</title>
|
|
<link type="text/css" rel="STYLESHEET" href=
|
|
"http://www.w3.org/StyleSheets/base.css" />
|
|
<link type="text/css" rel="STYLESHEET" href=
|
|
"http://www.w3.org/StyleSheets/public.css" />
|
|
<link type="text/css" rel="STYLESHEET" href=
|
|
"http://www.w3.org/2004/02/minutes-style.css" />
|
|
<meta content="Media Fragments Working Group Teleconference"
|
|
name="Title" />
|
|
<meta content="text/html; charset=utf-8" http-equiv=
|
|
"Content-Type" />
|
|
</head>
|
|
|
|
<body>
|
|
<p><a href="http://www.w3.org/"><img src=
|
|
"http://www.w3.org/Icons/w3c_home" alt="W3C" border="0" height=
|
|
"48" width="72" /></a></p>
|
|
|
|
<h1>- DRAFT -</h1>
|
|
|
|
<h1>Media Fragments Working Group Teleconference</h1>
|
|
|
|
<h2>01 Nov 2010</h2>
|
|
|
|
<p>See also: <a href=
|
|
"http://www.w3.org/2010/11/01-mediafrag-irc">IRC log</a></p>
|
|
|
|
<h2><a name="attendees" id="attendees">Attendees</a></h2>
|
|
|
|
<div class="intro">
|
|
<dl>
|
|
<dt>Present</dt>
|
|
|
|
<dd>Roseraie_1</dd>
|
|
|
|
<dt>Regrets</dt>
|
|
|
|
<dd>Erik</dd>
|
|
|
|
<dt>Chair</dt>
|
|
|
|
<dd>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. Quick round of
|
|
introduction</a></li>
|
|
|
|
<li><a href="#item02">2. Topics to be discussed</a></li>
|
|
|
|
<li><a href="#item03">3. Track and Name dimensions</a></li>
|
|
|
|
<li><a href="#item04">4. Summary</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: 01 November
|
|
2010</p>
|
|
|
|
<p class='phone'><cite>Presents:</cite> Davy, Jack, Raphael,
|
|
Silvia (irc), Phillip (irc), Yves</p>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> Meeting: Media
|
|
Fragments F2F meeting @TPAC</p>
|
|
|
|
<h3 id="item01">1. Quick round of introduction</h3>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> scribe: raphael</p>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> scribenick:
|
|
raphael</p>
|
|
|
|
<p class='phone'>Many observers ...</p>
|
|
|
|
<p class='phone'>Fran�ois: w3c staff</p>
|
|
|
|
<p class='phone'>Ben (Nokia): MAWG member</p>
|
|
|
|
<p class='phone'><cite>Hidetaka:</cite> developer of Mobile
|
|
browser, interest in adaptation to small screen</p>
|
|
|
|
<p class='phone'>Nobu (NEC ac rep): media analysis (face
|
|
recognition), interest in standardising results of such
|
|
analysis</p>
|
|
|
|
<p class='phone'>Hiroyuki (Toshiba ac rep): metadata
|
|
standardisation</p>
|
|
|
|
<p class='phone'>Franck (Canon research France): I'm an "old"
|
|
observer of this group, interest in media fragments standard
|
|
for streaming media</p>
|
|
|
|
<p class='phone'>Pierre Antoine (LIRIS): Uni of Lyon, member of
|
|
MAWG</p>
|
|
|
|
<h3 id="item02">2. Topics to be discussed</h3>
|
|
|
|
<p class='phone'><a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/SeventhF2FAgenda">
|
|
http://www.w3.org/2008/WebVideo/Fragments/wiki/SeventhF2FAgenda</a></p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> time dimension<br />
|
|
... Philip wonders if the hours should not be optional<br />
|
|
... arguing that most video clips are less than an hour
|
|
duration<br />
|
|
... in WebSRT, hours are optional<br />
|
|
... should we do the same?</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> -0, I'm slightly
|
|
against</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> the production rules are
|
|
currently</p>
|
|
|
|
<p class='phone'>npt-sec = 1*DIGIT [ "." *DIGIT ] ; definitions
|
|
taken</p>
|
|
|
|
<p class='phone'>npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [
|
|
"." *DIGIT] ; from RFC 2326</p>
|
|
|
|
<p class='phone'>npt-hh = 1*DIGIT ; any positive number</p>
|
|
|
|
<p class='phone'>npt-mm = 2DIGIT ; 0-59</p>
|
|
|
|
<p class='phone'>npt-ss = 2DIGIT ; 0-59</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> after some
|
|
discussion I am now +0, slightly in favor</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I do remember that
|
|
Silvia and Philip was also for making the hours optional<br />
|
|
... I suggest to edit the grammar this afternoon with Yves if
|
|
he does not disagree</p><a name="action01" id="action01"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Yves to update the production rules of
|
|
the time dimension with the npt format for making the hours
|
|
optional [recorded in <a href=
|
|
"http://www.w3.org/2010/11/01-mediafrag-minutes.html#action01">http://www.w3.org/2010/11/01-mediafrag-minutes.html#action01</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-191
|
|
- Update the production rules of the time dimension with the
|
|
npt format for making the hours optional [on Yves Lafon - due
|
|
2010-11-08].</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I like the
|
|
simplicity for the user of the more flexible format</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> smpte format</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> the servers is always
|
|
answering with the same unit than the client</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> well, but if the UA sends a
|
|
fragment in smpte-30-drop, and the media has another encoding,
|
|
then should we do a conversion?<br />
|
|
... if the UA sends a npt format, it is clear what the server
|
|
has to do</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> note that the UA can
|
|
convert what the user provides to the browser to a common
|
|
format that can go over the wire</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> but if the UA sends one of
|
|
the smpte definition, and the media happens to use a different
|
|
format for defining time, then we might have a problem</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> the problem is that the UA
|
|
might not understand the time format in which you are
|
|
converting to</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> yes Silvia, but then we
|
|
always convert to npt?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> hmm.. right - might
|
|
be better to just hand it through</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> we could raise an error, if
|
|
the UA asks for smpte time codes but that smpte has not been
|
|
used in the media item</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> our current implementation
|
|
works with a double conversion<br />
|
|
... if the UA sends a smpte-30-drop media fragment and the
|
|
media item is encoded in smpte-25<br />
|
|
... then the servers will convert the smpte-30-drop into npt to
|
|
get a position and convert it back in smpte-30-drop</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> the frame precision will be
|
|
most used in the annotation area rather than the presentation
|
|
area<br />
|
|
... so we should not have the presentation (browsers) glasses
|
|
to look at this issue</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> let's summarize the
|
|
discussion<br />
|
|
... smpte time codes are useful for a number of use cases, in
|
|
particular for annotation use cases<br />
|
|
... when generally a UA sends a media fragment request with a
|
|
time format which is different than the time format used in the
|
|
media item<br />
|
|
... then the server should fallback to answering in npt if it
|
|
has an understanding of the timeformat requested bu the
|
|
UA<br />
|
|
... if the server does not understand the time format requested
|
|
by the UA, the default fallback is to ignore the media fragment
|
|
and send the whole resource</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> ok, where this information
|
|
should be written ? is this normative ?<br />
|
|
... section 5 seems appropriate, I'm tempted to say it should
|
|
be normative</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> we might have to change
|
|
the structure of section 5 to make it dimension
|
|
dependent</p><a name="action02" id="action02"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Davy to update the specification to
|
|
state what the processing should do when media fragments
|
|
request (time dimension) does not match exactly how the media
|
|
item has been encoded [recorded in <a href=
|
|
"http://www.w3.org/2010/11/01-mediafrag-minutes.html#action02">http://www.w3.org/2010/11/01-mediafrag-minutes.html#action02</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-192
|
|
- Update the specification to state what the processing should
|
|
do when media fragments request (time dimension) does not match
|
|
exactly how the media item has been encoded [on Davy Van
|
|
Deursen - due 2010-11-08].</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> let's discuss the space
|
|
dimension</p>
|
|
|
|
<p class='phone'>ACTION-190?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-190 --
|
|
Raphaël Troncy to update our spec to talk about video intrinsic
|
|
width -- due 2010-10-27 -- OPEN</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/190">
|
|
http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/190</a></p>
|
|
|
|
<p class='phone'><a href=
|
|
"http://dev.w3.org/html5/spec/video.html#concept-video-intrinsic-width">
|
|
http://dev.w3.org/html5/spec/video.html#concept-video-intrinsic-width</a></p>
|
|
|
|
<p class='phone'>Room trying to understand the issue</p>
|
|
|
|
<p class='phone'>Room having a laugh reading <a href=
|
|
"http://www.emdpi.com/csspixel.html">http://www.emdpi.com/csspixel.html</a></p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> in section 7, we could put
|
|
a note for phrasing this issue. Philip is our HTML5 expert to
|
|
do this phrasing</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> we should have another
|
|
section 7.x for browsers, how they should render media
|
|
fragment<br />
|
|
... different than 7.1 which is for general clients</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> 7.1 should be browsers, 7.2
|
|
general clients, 7.3 servers<br />
|
|
... + a note for stating that all sub-sections are not mutually
|
|
exclusive</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> actually, 7.1 =
|
|
browsers, 7.2 general display clients, 7.3 all clients, 7.4
|
|
servers</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> then in 7.1, we could have
|
|
the result of the action 190, the mapping to css pixels<br />
|
|
... I would be happy that Philip + Silvia draws a list of all
|
|
things that matter to a HTML5 browser rendering client for
|
|
media fragments<br />
|
|
... perhaps put a warning that the content of this new section
|
|
is based on the current state of HTML5 discussion as per ...
|
|
<date></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> so, do you want a
|
|
description that spatial fragments should be spliced in html5
|
|
elements?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> anyone know when
|
|
we're going to have the TPAC calls? I can't find anything
|
|
definitive in my mail</p>
|
|
|
|
<p class='phone'>[back from coffee break]</p>
|
|
|
|
<p class='phone'>Silvia, I'm not sure I understand your
|
|
question</p>
|
|
|
|
<p class='phone'>Philip, we have started the Media Fragments WG
|
|
f2f meeting at TPAC</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> agenda is at <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/SeventhF2FAgenda">
|
|
http://www.w3.org/2008/WebVideo/Fragments/wiki/SeventhF2FAgenda</a>
|
|
(add your topics that you would like to be discussed)</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> foolip,
|
|
currently not</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> raphael: my question
|
|
was about what should be added to a browser section (html
|
|
section?) in 7.1</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I wondered if it was
|
|
ok to add spatial fragments as splicing the image</p>
|
|
|
|
<p class='phone'>Philip, we can setup the call now if you're
|
|
ready</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> ok, where are you in
|
|
the agenda/</p>
|
|
|
|
<p class='phone'>Silvia, we are exactly dicussing what should
|
|
we add to this new section 7.1</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> so far, the pixels
|
|
discussion</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Philip, we wonder
|
|
whether you and Silvia could write down a list of items that
|
|
(HTML5) browsers need to consider when implementing media
|
|
fragments<br />
|
|
... but notes that are not applicable to general rendering
|
|
clients and already written<br />
|
|
... for example, the pixels discussion<br />
|
|
... could you phrase the issue of what mapping to CSS pixels
|
|
should be done for example?</p>
|
|
|
|
<p class='phone'>Silvia, by splicing, you mean cropping?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> yup</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> the issue of aspect
|
|
ratio isn't browser-specific, all UAs would have to deal with
|
|
the issue. "CSS-pixels" is actually just the size after
|
|
applying aspect ratio scaling in one dimension</p>
|
|
|
|
<p class='phone'>Sylvia, we have a paragraph so far that talk
|
|
about either highlighting or cropping</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> which one makes more
|
|
sense ?</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> invite zakim</p>
|
|
|
|
<p class='phone'>join zakim #mediafrag</p>
|
|
|
|
<p class='phone'>Silvia, Philip, you can now dial in and we
|
|
will see if it works</p>
|
|
|
|
<p class='phone'><cite>Philip:</cite> this is not a CSS
|
|
issue<br />
|
|
... the question is when do we have a xywh dimension, does it
|
|
apply before of after that there was a aspect ratio
|
|
transform</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> the original media item is
|
|
1080, but the device is 720 width, so which pixels should be
|
|
considered when applying a media fragment xywh?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> <a href=
|
|
"http://en.wikipedia.org/wiki/Anamorphic_format">http://en.wikipedia.org/wiki/Anamorphic_format</a></p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> I think we have trouble to
|
|
understand what exactly is the CSS pixel concept and therefore
|
|
the issue</p>
|
|
|
|
<p class='phone'><cite>Philip:</cite> the container format has
|
|
tow information, the preferred display size and the real
|
|
size</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> For example, WebM
|
|
has Pixel width/height and Display width/height. This is the
|
|
same as Matroska: <a href=
|
|
"http://www.matroska.org/technical/specs/index.html">http://www.matroska.org/technical/specs/index.html</a></p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Actually, Matroska
|
|
also has PixelCropBottom, etc</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> in QuickTime 7, open a
|
|
movie you can choose between normal size and display size</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> The point is that
|
|
the physical pixels aren't always the same as the display
|
|
size</p>
|
|
|
|
<p class='phone'>ok Philip, we understand now the issue</p>
|
|
|
|
<p class='phone'><cite>Philip:</cite> CSS pixels are display
|
|
pixels</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> "information
|
|
rich"?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I would suggest that
|
|
there are three levels: 1. what is encoded in the stream, 2.
|
|
what the browser receives after decoding, 3. what the browser
|
|
displays after scaling etc</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> silvia, isn't 1 and
|
|
2 the same?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I think we should
|
|
attach the pixel count to 2.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> not really - there
|
|
is pixel crop in several formats - ogg does it, too</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I would suggest not
|
|
to count those pixels that are cropped in the format</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> silvia, I would
|
|
consider the effect of crop+scaling as one step, but
|
|
anyway...</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> a media fragment URI
|
|
that is used by itself in the browser address bar has no
|
|
scaling applied to the video - it's that display to which I
|
|
would attach the cropping</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> (when I said
|
|
"cropped in the format", I meant PixelCropBottom and stuff like
|
|
that)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> the scaling I'm
|
|
talking about is horizontal OR vertical scaling to get the
|
|
correct aspect ratio, not scaling to fit the video in a
|
|
webpage</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> so, the dimension I
|
|
suggest we use are the same as we see in
|
|
HTMLVideoElement.videoWidth and .videoHeight</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I assume we agree
|
|
but don't understand each other :)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> except that
|
|
HTMLVideoElement.videoWidth and .videoHeight have the @height
|
|
and @width scaling of the <video> element executed on
|
|
it</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> silvia, no, it
|
|
doesn't</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> at least not in
|
|
Opera or according to the spec</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> ah, ok, then it is
|
|
those width and height indeed</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> right :)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> that's indeed what I
|
|
meant with option 2</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> my proposal is that when
|
|
the container format has multiple interpretations of the width
|
|
and height<br />
|
|
... then we should fall back to the display width and height
|
|
(aka CSS pixels)<br />
|
|
... and we could give the example of the Anamorphic format
|
|
versus the example of vector graphics</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> <a href=
|
|
"http://dev.w3.org/html5/spec/video.html#concept-video-intrinsic-width">
|
|
http://dev.w3.org/html5/spec/video.html#concept-video-intrinsic-width</a></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> we could just simply
|
|
refer to the HTMLVideoElement.videoWidth and .videoHeight
|
|
description</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I disagree, this is
|
|
not a implementor note, we need to say precisely what to do, as
|
|
with everything else.</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> No need for new
|
|
sections, just say it where we define xywh</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> no, it's bad to
|
|
leave such things open for interpretation</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I cannot think of a
|
|
situation where it would be desirable to use a different
|
|
meaning</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> sorry, call
|
|
dropped</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> at least write it
|
|
into the HTML / browser section in this way as a
|
|
requirement</p>
|
|
|
|
<p class='phone'>People in the room tends also to think that it
|
|
should be specified when we talk about xywh</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> fine</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I think that in
|
|
general we should have as few "implementor notes" as possible,
|
|
if we're not sure about how to implement something then that's
|
|
a very dangerous thing, IMO</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I agree</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> and if someone in the
|
|
future is interested in physical pixels, then they should
|
|
invent "xywh-physical" for addressing them</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> I agree too.</p>
|
|
|
|
<p class='phone'>ok, great consensus</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Section 7 is for
|
|
"practicality beats purity"</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> why not re-use the
|
|
text from the HTML5 spec - or at least link to it?</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I need someone to edit
|
|
the section 4.3.2 to state about which pixels we are talking
|
|
about (actually CSS pixels) and refer to HTML5 spec<br />
|
|
... no reference to HTML5 spec, sorry<br />
|
|
... we cannot because we will be REC before them</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> but we can copy the
|
|
text</p>
|
|
|
|
<p class='phone'>Silvia, or Philip, could you add this sentence
|
|
now?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> sure… give me a
|
|
sec</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> I don't think we
|
|
want that exact text: it had us baffled this morngin</p>
|
|
|
|
<p class='phone'>phrase it differently, BECAUSE we haven't
|
|
udnerstand the HTML5 text in a first place</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> so the phrasing was not
|
|
good enough</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> oh - what text do
|
|
you want then?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> why don't you add it
|
|
then?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> If there's something
|
|
wrong with the phrasing, have it changed in HTML5 first, please
|
|
:)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> just file a bug and
|
|
it will happen</p>
|
|
|
|
<p class='phone'>Philip, you're the one to make changes in the
|
|
HTML5 spec :-)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> or, tell me what's
|
|
difficult to understand and I'll make it happen</p>
|
|
|
|
<p class='phone'>let's edit this sentence in our spec on
|
|
irc</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I really don't see
|
|
how it can be formulated better</p>
|
|
|
|
<p class='phone'>First sentence reads:</p>
|
|
|
|
<p class='phone'>Spatial clipping selects an area of pixels
|
|
from visual media streams. For this release of the media
|
|
fragment specification, only rectangular selections are
|
|
supported. The rectangle can be specified as pixel coordinates
|
|
or percentages.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it refers to CSS
|
|
pixels and explains what needs to be taken care of</p>
|
|
|
|
<p class='phone'>I suggest we add afterwards a sentence talking
|
|
about CSS pixels</p>
|
|
|
|
<p class='phone'>Which sentence do you want to re-use
|
|
exactly?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> s/specified as pixel
|
|
coordinates or pecentages/specified as CSS pixel coordinates or
|
|
percentages/</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> then explain CSS
|
|
pixels for video the way that HTML5 does</p>
|
|
|
|
<p class='phone'>OK silvia, so you want to add this sentence
|
|
afterwards?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> It seems to me
|
|
things would be less confusing if we actually used CSS syntax
|
|
here, i.e. 10px or 10%. Then it's more obvious that px refers
|
|
to the same thing that it would in CSS.</p>
|
|
|
|
<p class='phone'>"The intrinsic width and intrinsic height of
|
|
the media resource are the dimensions of the resource in CSS
|
|
pixels after taking into account the resource's dimensions,
|
|
aspect ratio, clean aperture, resolution, and so forth, as
|
|
defined for the format used by the resource. If an anamorphic
|
|
format does not define how to apply the aspect ratio to the
|
|
video data's dimensions to obtain the "correct" dimensions,
|
|
then the user agent must apply the ratio by increas</p>
|
|
|
|
<p class='phone'>Philip, currently, our syntax is:
|
|
#xywh=160,120,320,240 or #xywh=pixel:160,120,320,240</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> We could write:</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Yep. Never mind the
|
|
syntax for now, that's easy to change later.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> "CSS pixels are
|
|
pixels as calculated after taking into account the resource's
|
|
dimensions, aspect ratio, clean aperture, resolution, and so
|
|
forth, as defined for the format used by the resource. If an
|
|
anamorphic format does not define how to apply the aspect ratio
|
|
to the video data's dimensions to obtain the "correct"
|
|
dimensions, then the user agent must apply the ratio by
|
|
increasing one dimension and leaving the other unchanged."</p>
|
|
|
|
<p class='phone'>thanks Silvia</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I'm not joking at
|
|
all, but let's focus on the issue at hand.</p>
|
|
|
|
<p class='phone'>The only issue for Jack is that we should
|
|
perhaps not name them "CSS pixels", they have nothing to do
|
|
with CSS</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> foolip: does that
|
|
sentence sound correct still? it's not quite what html5 says,
|
|
but CSS pixels aren't defined there...</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Jack: in html5 they
|
|
are relevant as CSS pixels, because CSS scaling and stuff is
|
|
applied to them</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> and we might as well
|
|
make that link here</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Uh, I think copying
|
|
the text at all is a pretty bad idea, especially if we don't
|
|
link to where it was copied from.</p>
|
|
|
|
<p class='phone'>Philip, in a recommendation, you should avoid
|
|
linking to a WD or any other document which is not a REC</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> we should of course
|
|
link to it to also say that we mean the same thing as HTML5</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> because of dependency
|
|
issue</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I would make an
|
|
exception here</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I can see why that
|
|
general policy exists, but clearly it's harmful in this
|
|
instance.</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> what's happened if the
|
|
HTML5 spec removes this paragraph at REC stage after you have
|
|
been rec? You need to publish an erratum<br />
|
|
... too dangerous</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> no, there's no
|
|
chance that section will be removed</p>
|
|
|
|
<p class='phone'>Silvia, we can make exceptions for many things
|
|
then, and this is simply not acceptable</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> you know St Thomas</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> no, I wouldn't make
|
|
exceptions for many things - but in this instance I woudl</p>
|
|
|
|
<p class='phone'>Silvia, perhaps you want to make an exception,
|
|
but the director will NOT</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> this is the shortcut to
|
|
get a veto from the W3C director (and many members by the
|
|
way)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> maybe he would - it
|
|
would be harmful not to make an exception here, because we want
|
|
to mean the same thing as HTML5</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> So there can't be
|
|
any links to documents that aren't in REC?</p>
|
|
|
|
<p class='phone'>great, we make our own sentence, and that's
|
|
fine</p>
|
|
|
|
<p class='phone'>not in normative part Philip</p>
|
|
|
|
<p class='phone'>and this is a 20 years old practice</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> OK, so put it in a
|
|
note then.</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> "If the
|
|
underlying media format has multiple interpretations of pixel
|
|
dimensions, then MF pixels MUST be interpreted in the display
|
|
coordinates"</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> "Pixels coordinates are
|
|
interpreted after taking into account the resource's
|
|
dimensions, aspect ratio, clean aperture, resolution, and so
|
|
forth, as defined for the format used by the resource."</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> maybe the note can
|
|
say that it means the same as what is defined as intrinsic
|
|
width/height on the video in the draft HTML5 spec</p>
|
|
|
|
<p class='phone'><cite>Philip:</cite> could we add as well " If
|
|
an anamorphic format does not define how to apply the aspect
|
|
ratio to the video data's dimensions to obtain the "correct"
|
|
dimensions, then the user agent must apply the ratio by
|
|
increasing one dimension and leaving the other unchanged."
|
|
?</p>
|
|
|
|
<p class='phone'>yes Silvia</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Note: this is
|
|
equivalent to intrinsic width and height in HTML5 <<a href=
|
|
"http://dev.w3.org/html5/spec/video.html#concept-video-intrinsic-width%3E">http://dev.w3.org/html5/spec/video.html#concept-video-intrinsic-width></a></p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> "The pixel
|
|
coordinates defined in 4.3.2 are intended to be identical to
|
|
the "CSS pixels" defined by HTML5"</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> different
|
|
section?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> not "CSS pixels",
|
|
intrinsic width and height</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> filip, right</p>
|
|
|
|
<p class='phone'>close ACTION-190</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-190 Update
|
|
our spec to talk about video intrinsic width closed</p>
|
|
|
|
<p class='phone'>Changes have been made in section 4.3.2:
|
|
<a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-space">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-space</a></p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> and in section 7.1:
|
|
<a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#media-fragment-browser">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#media-fragment-browser</a></p>
|
|
|
|
<p class='phone'>anyone UN-happy, please, speak</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> yes</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I'd rather section
|
|
7.1 didn't exist, and the note being put directly after the
|
|
copied text in <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-space">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-space</a></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> ah, yes, I agree
|
|
with Philip actually - seeing as it should be used everywhere
|
|
to mean the same thing</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> highlight vs
|
|
cropping<br />
|
|
... should we say more than the current pararaph ?</p>
|
|
|
|
<p class='phone'>"For a spatial URI fragment, we foresee two
|
|
distinct use cases: highlighting the spatial region in-context
|
|
and cropping to the region. In the first case, the spatial
|
|
region could be indicated by means of a bounding box or the
|
|
background (i.e., all the pixels that are not contained within
|
|
the region) could be blurred or darkened. In the second case,
|
|
the region alone would be presented as a cropped area. How a
|
|
document author specifies which use case is in</p>
|
|
|
|
<p class='phone'>in particular, should we talk now with
|
|
CSS?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I think we should
|
|
just rename xywh to crop.</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Annotations don't
|
|
care about display anyway.</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> for time, we have both,
|
|
cropping (query) and highlihting (in context view), why you
|
|
would like to make it different for space?</p>
|
|
|
|
<p class='phone'><cite>Philip:</cite> because there is a good
|
|
reason for time, I don't see it for space</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> but annotation use case is
|
|
about addressing pixels, not cropping or highlighting</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> maybe for the visual
|
|
domain it might make sense to have them explicitly different -
|
|
then annotation ppl can use xywh and browsers can use crop?
|
|
(not sure...)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> ninsuna does nothing
|
|
on the server for regions</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I haven't seen the
|
|
ninsuna client yet, I think...</p>
|
|
|
|
<p class='phone'>it is on the web silvia</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> <a href=
|
|
"http://ninsuna.elis.ugent.be/MediaFragmentsPlayer">http://ninsuna.elis.ugent.be/MediaFragmentsPlayer</a></p>
|
|
|
|
<p class='phone'>we have demoed it everywhere</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I had only seen the
|
|
plugin</p>
|
|
|
|
<p class='phone'>Silvia, 2 F2F ago, we already showed the Flash
|
|
client from Davy, I'm sure you have commented on it, so you
|
|
must have seen it :-)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> so,
|
|
xywh=247,156,129,206 already means highlighting to
|
|
everyone?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> so,
|
|
crop=247,156,129,206 could mean cropping - would be the easy
|
|
way out actually...</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> there are slides about it
|
|
at the Barcelona F2F meeting, look at our meetings dir in our
|
|
web space</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> silvia, xywh
|
|
doesn't mean highlighting nor cropping. It means addressing,
|
|
nothing more.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> because it ends up
|
|
in in-compatible interpretations of the URI</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> when a Web developer
|
|
cannot rely on what will be presented in all browsers the same
|
|
way, it's in-compatible and under-specified</p>
|
|
|
|
<p class='phone'>Yes Silvia, but this is not our fault but the
|
|
fault of HTML5</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> what Jack is saying is
|
|
that for us, it should be an implementation note, but for
|
|
HTML5, the behavior should be normative<br />
|
|
... I guess the issue is that rendering in browsers should be
|
|
specified in HTML5 and not in Media Fragments<br />
|
|
... media fragments is just about "addressing"</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> we should put it
|
|
into the browser section at minimum</p>
|
|
|
|
<p class='phone'><cite>Philip:</cite> then, if it is the case,
|
|
we should remove all the section 7 implementers note, rather
|
|
than having half in our spec and half in other documents</p>
|
|
|
|
<p class='phone'>Yes silvia, this is what Jack proposes</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> and if we want
|
|
browsers to support both display mechanisms, we need two
|
|
different means of addressing</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I'm warming to the
|
|
thought of "crop"</p>
|
|
|
|
<p class='phone'>Slvia, you are adapting the display mechanism
|
|
to the address while it should be the contrary</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> no, I am saying that
|
|
we are under-specifying the mechanism</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Anyway, can we take
|
|
a step back and see what we're actually discussing?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> html fragments also
|
|
always mean the same in all applications</p>
|
|
|
|
<p class='phone'>if you can "style" what you address, then you
|
|
don't need to invent 10 terms for 10 different displays of the
|
|
same region addressed, right ?</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> CSS descriptors could
|
|
be used for displaying media fragments</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I really doubt we'll
|
|
see CSS extensions specifically for xywh, because it'd have to
|
|
be very complicated to do things that are simple to do without
|
|
it.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I'm playing with the
|
|
thought and I can only see advantages this far</p>
|
|
|
|
<p class='phone'>[lunch break]</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> are we starting
|
|
again soon?</p>
|
|
|
|
<p class='phone'><cite>Philip:</cite> there will be no other
|
|
people that will specify this except us<br />
|
|
... so either we make it in our spec or we make it in the HTML5
|
|
spec, but it will be us</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> where the rendering of a
|
|
media fragment according to the space dimension should be
|
|
specified?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=10723">http://www.w3.org/Bugs/Public/show_bug.cgi?id=10723</a></p>
|
|
|
|
<p class='phone'><cite>Philip:</cite> I don't care what should
|
|
happen and where, I care about having this specified somewhere
|
|
so that there is no interoperability or different behaviors in
|
|
various browsers</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> I think we should just have
|
|
a non normative text in the Media Fragment spec. We should
|
|
rather propose a text to HTML5, and they vote if they want to
|
|
include it or not<br />
|
|
... yes, cropping seems to be the best default solution for
|
|
html browsers<br />
|
|
... let's propose a crop only text to HTML5 and see WebApps or
|
|
CSS complaint about</p>
|
|
|
|
<p class='phone'><cite>Philip:</cite> this should not be
|
|
something that goes towards mime type registration?<br />
|
|
... So shouldn't we write something, a hook, for enabling such
|
|
a mime type registration</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I said that I think
|
|
I agree with Ian that this *should* go into MIME type
|
|
registrations</p>
|
|
|
|
<p class='phone'>thanks for the reformulation</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> but, I'm not
|
|
sure</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> it would be terrible
|
|
if two different MIME types defined things differently</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> In reality, browsers
|
|
will just do the same thing for all types...</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> we never really
|
|
finished the discussion about how to get uptake by the media
|
|
formats on this - IIRC Raphael or Yves had a discussion with
|
|
TBL about how that could be done without having to update every
|
|
single mime type registration - can somebody clarify where
|
|
we're at with that?</p>
|
|
|
|
<p class='phone'>Yves has further discussed this with TAG and
|
|
TimBL last weeks and this morning</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> he will update us later
|
|
today or tomorrow morning</p>
|
|
|
|
<p class='phone'>Jack is editing section 7 now, to clarify that
|
|
browsers should crop spatial fragments</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Adding non-normative
|
|
text doesn't change anything.</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> There should be
|
|
normative text *somewhere*.</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> and that other clients
|
|
can crop or highlight regions</p>
|
|
|
|
<p class='phone'>YES, Philip, this is the first part</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Also, special-casing
|
|
browsers is very atypical.</p>
|
|
|
|
<p class='phone'>the second is to send this text being edited
|
|
to HTML5 and see if they want it *normatively*</p>
|
|
|
|
<p class='phone'>if we do: s / browsers / HTML5 renderers,do
|
|
you prefer ?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> if we are making a
|
|
browser section, we might as well make our section
|
|
normative</p>
|
|
|
|
<p class='phone'>why silvia ?</p>
|
|
|
|
<p class='phone'>this is implementation specific</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> no, every HTML
|
|
rendering UA must do the same thing - otherwise it's not much
|
|
of a standard, right?</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> please read and
|
|
review: I tend to be somewhat terse in my prose...</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> if we like this, how do we
|
|
push this to HTML5 WG?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it's not
|
|
prescriptive enough for HTML5</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I don't think it's
|
|
fruitful to try to work this out in real time, right now.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> but I'd be happy to
|
|
make a proposal through that bug - it's as simple as adding the
|
|
spec text to the bug to start a discussion and get a change</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> Is the rendering of
|
|
the video timeline a similar issue?</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> e.g., <a href=
|
|
"http://dev.opera.com/articles/view/custom-html5-video-player-with-css3-and-jquery/">
|
|
http://dev.opera.com/articles/view/custom-html5-video-player-with-css3-and-jquery/</a></p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> It's similar, people
|
|
won't use browser-native highlighting for the same reason they
|
|
won't use native controls, because you can't customize how it
|
|
looks, and no one is working on any CSS extensions to fix
|
|
it.</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Silvia, I'm proposing to
|
|
edit the bug, but feel free to do it<br />
|
|
... my plan was to add the paragraph in 7.2 in the bug
|
|
entry<br />
|
|
... and let HTML5 decides what to put in their spec</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> no, not that way -
|
|
it's got to be terse and it has to be addressed at a specific
|
|
section in the spec where it should go</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> think about as
|
|
though you are the editor of the spec and you are proposing
|
|
what text has to go in</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> more like a
|
|
patch</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> We shouldn't suggest
|
|
any specific text, let's just say what we want and let Ian
|
|
figure out the details.</p>
|
|
|
|
<p class='phone'>What about saying Ian to make the text he
|
|
wants from</p>
|
|
|
|
<p class='phone'>"For a spatial URI fragment, we foresee two
|
|
distinct use cases: highlighting the spatial region in-context
|
|
and cropping to the region. In the first case, the spatial
|
|
region could be indicated by means of a bounding box or the
|
|
background (i.e., all the pixels that are not contained within
|
|
the region) could be blurred or darkened. In the second case,
|
|
the region alone would be presented as a cropped area."</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> really? he'll just
|
|
say it doesn't belong there..</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> If he's wrong, then
|
|
we should tell him why :)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I'm not sure myself,
|
|
at this point.</p>
|
|
|
|
<p class='phone'>Silvia, Ian said it should belong to the mime
|
|
type registration (not in HTML5, not in Media Fragment), but it
|
|
will NOT appear there</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> that's a second
|
|
thing: we need a good answer for why it's not going into mime
|
|
type registrations</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> and he made it appear in
|
|
the HTML5 spec for the HTML fragment spec ... not in a separate
|
|
mime type registration document</p>
|
|
|
|
<p class='phone'>Silvia, do you want to edit the bug?</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> so we can move on?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> at minimum there are
|
|
these sections affected:</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> <a href=
|
|
"http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-fragid">
|
|
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-fragid</a>
|
|
and</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> <a href=
|
|
"http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video">
|
|
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video</a></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> (sorry, but I prefer
|
|
the whatwg version ;)</p>
|
|
|
|
<p class='phone'>fine</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> (it's more
|
|
up-to-date)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> and it's green
|
|
:)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I'll update the bug
|
|
after we have an answer to the question about mime type
|
|
registrations</p>
|
|
|
|
<p class='phone'>ok</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> we wait for the debrief
|
|
of Yves regarding the discussion in TAG</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I also added a topic
|
|
to our discussion list about what to do for video fragment
|
|
addressing when it's about videos on a web page</p>
|
|
|
|
<p class='phone'>Silvia, I put it in the agenda too</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I think that may
|
|
also be relevant</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> and I observe we have
|
|
already discussed this several times<br />
|
|
... and already come to a conclusion<br />
|
|
... but you want to re-open the can of worms :-)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> for now we can
|
|
collect all these things in the "browser" section of "our"
|
|
spec</p>
|
|
|
|
<h3 id="item03">3. Track and Name dimensions</h3>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I do because we are
|
|
moving closer to real-world use and we have to do more than
|
|
initially intended</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> Regarding the track
|
|
dimensions, it is almost always impossible to write all the
|
|
byte ranges<br />
|
|
... so we will _always_ perform a redirect<br />
|
|
... hence, if a media fragment URI uses a # with the track
|
|
dimension<br />
|
|
... we redirect to the '?' parameter<br />
|
|
... see <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-UA-mapped-changed">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-UA-mapped-changed</a></p><a name="action03"
|
|
id="action03"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Erik to make a schema for this recipe
|
|
[recorded in <a href=
|
|
"http://www.w3.org/2010/11/01-mediafrag-minutes.html#action03">http://www.w3.org/2010/11/01-mediafrag-minutes.html#action03</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-193
|
|
- Make a schema for this recipe [on Erik Mannens - due
|
|
2010-11-08].</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> the section 5 is
|
|
organized per recipes<br />
|
|
... but it is confusing when one looks at the dimension<br />
|
|
... hence, spatial dimension has no dimension (no request is
|
|
sent to the server)<br />
|
|
... the track dimension is always in the case of
|
|
server-redirect recipe<br />
|
|
... most likely, the same for name dimension<br />
|
|
... therefore, only the time dimension can use all these
|
|
recipes<br />
|
|
... should we not write this down up in the section 5?</p>
|
|
|
|
<p class='phone'>s/has no dimension/has no recipe</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> we have 3 types or
|
|
recipes<br />
|
|
... UA mapped byte ranges ... for the temporal dimension<br />
|
|
... Server mapped byte ranges ... mainly for legacy
|
|
formats<br />
|
|
... Server triggered redirect ... for the track and name
|
|
dimensions<br />
|
|
... further, for the space dimension, no range request is
|
|
issued<br />
|
|
... I suggest to add this in the intro of Section 5</p><a name=
|
|
"action04" id="action04"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> raphael to add an intro paragraph in
|
|
the section 5 to explain which recipes is useful for which
|
|
dimension [recorded in <a href=
|
|
"http://www.w3.org/2010/11/01-mediafrag-minutes.html#action04">http://www.w3.org/2010/11/01-mediafrag-minutes.html#action04</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Sorry, couldn't
|
|
find user - raphael</p><a name="action05" id="action05"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> troncy to add an intro paragraph in
|
|
the section 5 to explain which recipes is useful for which
|
|
dimension [recorded in <a href=
|
|
"http://www.w3.org/2010/11/01-mediafrag-minutes.html#action05">http://www.w3.org/2010/11/01-mediafrag-minutes.html#action05</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-194
|
|
- Add an intro paragraph in the section 5 to explain which
|
|
recipes is useful for which dimension [on Raphaël Troncy - due
|
|
2010-11-08].</p>
|
|
|
|
<p class='phone'>[coffee break]</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> let me know when you
|
|
start again</p>
|
|
|
|
<p class='phone'>[back from Coffee break]</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> useful coffee break</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Should I call
|
|
in?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> What's next?</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Regarding CSS styling of
|
|
media fragment in the spatial dimension for rendering, CSS
|
|
co-chair Daniel Glazman suggested me to write our text to their
|
|
mailing list for improivement</p>
|
|
|
|
<p class='phone'>s/improivement/improvement</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> further, after talking
|
|
with other browser vendors, I will ask feedback from Chris
|
|
Double (Mozilla), Eric Carlson (Apple) and Frank Olivier
|
|
(Microsoft)<br />
|
|
... that all deal with the video elements in their browsers</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> And what about
|
|
Chrome developers?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> will search mail</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I would like we discuss
|
|
about the name dimension</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> we see the name dimension
|
|
as more general that what media containers could do<br />
|
|
... but we have no implementation yet</p>
|
|
|
|
<p class='phone'><cite>Philip:</cite> name dimension is really
|
|
dependent on container formats<br />
|
|
... we have chapter names in WebM (mkv)<br />
|
|
... we have cue points in MP4</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Sorry, I can't find
|
|
the Chrome developer's name...</p>
|
|
|
|
<p class='phone'>I will try to find out with corridor
|
|
discussion this week</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> perhaps this is tightly
|
|
correlated to the extensibility discussion we have to do</p>
|
|
|
|
<p class='phone'>Jack asked frankly, if anyone feels bad in
|
|
removing "id" dimension from the spec?</p>
|
|
|
|
<p class='phone'><cite>Philip:</cite> no strong opinion about
|
|
it, if not implemented, it should be out of the spec as a
|
|
general principle</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I like to have this
|
|
feature in, but I'm aware we need implementation for this</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> our plan is to not rely on
|
|
the container format but on media annotations</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Will we have time to
|
|
discuss ISSUE-19 today? If not, I'll be heading home.</p>
|
|
|
|
<p class='phone'>ISSUE-19?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ISSUE-19 --
|
|
Parsing must be defined normatively in the MF spec itself --
|
|
open</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/19">http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/19</a></p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> <video
|
|
src="video.webm#t=10"></p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> media fragment
|
|
identifiers are only meaningful for media resources, not for
|
|
HTML documents</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> if sites like YouTube
|
|
want to give a meaning to #t=10 applied to an HTML document
|
|
containing a video, then it is the responsibility of these
|
|
sites to make sure that the media fragment identifier applied
|
|
to the HTML document is appended to the media resource URI</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> The media fragments
|
|
spec will say nothing about the meaning of ....html#t=10,20</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> but a range request will
|
|
still be issued from the browser<br />
|
|
... if the hash is used on the address bar of the browser<br />
|
|
... in all cases</p><a name="action06" id="action06"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> davy to add a paragraph in the section
|
|
7.1 to specify that video, audio, img or any href is all
|
|
treated similarly (range request issued when facing a media
|
|
fragment) [recorded in <a href=
|
|
"http://www.w3.org/2010/11/01-mediafrag-minutes.html#action06">http://www.w3.org/2010/11/01-mediafrag-minutes.html#action06</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-195
|
|
- Add a paragraph in the section 7.1 to specify that video,
|
|
audio, img or any href is all treated similarly (range request
|
|
issued when facing a media fragment) [on Davy Van Deursen - due
|
|
2010-11-08].</p>
|
|
|
|
<h3 id="item04">4. Summary</h3>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> tomorrow will be
|
|
about<br />
|
|
... 1/ TAG debrief from Yves<br />
|
|
... 2/ Extensibility issue with everyone<br />
|
|
... 3/ Test Cases presentation from Davy<br />
|
|
... 30 min + 2 hours + 1 hour</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> davy to add a
|
|
paragraph in the section 7.1 to specify that video, audio, img or
|
|
any href is all treated similarly (range request issued when
|
|
facing a media fragment) [recorded in <a href=
|
|
"http://www.w3.org/2010/11/01-mediafrag-minutes.html#action06">http://www.w3.org/2010/11/01-mediafrag-minutes.html#action06</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Davy to update
|
|
the specification to state what the processing should do when
|
|
media fragments request (time dimension) does not match exactly
|
|
how the media item has been encoded [recorded in <a href=
|
|
"http://www.w3.org/2010/11/01-mediafrag-minutes.html#action02">http://www.w3.org/2010/11/01-mediafrag-minutes.html#action02</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Erik to make a
|
|
schema for this recipe [recorded in <a href=
|
|
"http://www.w3.org/2010/11/01-mediafrag-minutes.html#action03">http://www.w3.org/2010/11/01-mediafrag-minutes.html#action03</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> raphael to add an
|
|
intro paragraph in the section 5 to explain which recipes is
|
|
useful for which dimension [recorded in <a href=
|
|
"http://www.w3.org/2010/11/01-mediafrag-minutes.html#action04">http://www.w3.org/2010/11/01-mediafrag-minutes.html#action04</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> troncy to add an
|
|
intro paragraph in the section 5 to explain which recipes is
|
|
useful for which dimension [recorded in <a href=
|
|
"http://www.w3.org/2010/11/01-mediafrag-minutes.html#action05">http://www.w3.org/2010/11/01-mediafrag-minutes.html#action05</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Yves to update
|
|
the production rules of the time dimension with the npt format
|
|
for making the hours optional [recorded in <a href=
|
|
"http://www.w3.org/2010/11/01-mediafrag-minutes.html#action01">http://www.w3.org/2010/11/01-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/11/01 16:31:26 $
|
|
</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/Idetaca/Idetaka/
|
|
Succeeded: s/Idetaka/Hidetaka/
|
|
Succeeded: s/Frank/Franck/
|
|
Succeeded: s/Nob (NRC ac rep)/Nobu (NEC ac rep)/
|
|
Succeeded: s/Toshipa/Toshiba/
|
|
Succeeded: s/back in smpte-25/back in smpte-30-drop/
|
|
Succeeded: s/if should be normative/it should be normative/
|
|
Succeeded: s/other/all/
|
|
Succeeded: s/udnerstand/understand/
|
|
FAILED: s/specified as pixel coordinates or pecentages/specified as CSS pixel coordinates or percentages/
|
|
Succeeded: s/dimension/coordinates/
|
|
Succeeded: s/normative/non normative/
|
|
Succeeded: s/HTML media fragment/HTML fragment/
|
|
FAILED: s/has no dimension/has no recipe/
|
|
FAILED: s/improivement/improvement/
|
|
Found Scribe: raphael
|
|
Inferring ScribeNick: raphael
|
|
Found ScribeNick: raphael
|
|
|
|
WARNING: Replacing list of attendees.
|
|
Old list: Roseraie_1 foolip silvia
|
|
New list: Roseraie_1 Philip
|
|
|
|
|
|
WARNING: Replacing list of attendees.
|
|
Old list: Roseraie_1 Philip
|
|
New list: Roseraie_1
|
|
|
|
Default Present: Roseraie_1
|
|
Present: Roseraie_1
|
|
|
|
WARNING: Fewer than 3 people found for Present list!
|
|
|
|
Regrets: Erik
|
|
Found Date: 01 Nov 2010
|
|
Guessing minutes URL: <a href=
|
|
"http://www.w3.org/2010/11/01-mediafrag-minutes.html">http://www.w3.org/2010/11/01-mediafrag-minutes.html</a>
|
|
People with action items: davy erik raphael troncy yves
|
|
|
|
</pre>[End of <a href=
|
|
"http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm">
|
|
scribe.perl</a> diagnostic output]
|
|
</div>
|
|
</body>
|
|
</html>
|