01-mediafrag-minutes.html 56.4 KB

Raw Blame History Permalink

<!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'>&lt;<cite>trackbot</cite>&gt; Date: 01 November
    2010</p>

    <p class='phone'><cite>Presents:</cite> Davy, Jack, Raphael,
    Silvia (irc), Phillip (irc), Yves</p>

    <p class='irc'>&lt;<cite>scribe</cite>&gt; Meeting: Media
    Fragments F2F meeting @TPAC</p>

    <h3 id="item01">1. Quick round of introduction</h3>

    <p class='irc'>&lt;<cite>scribe</cite>&gt; scribe: raphael</p>

    <p class='irc'>&lt;<cite>scribe</cite>&gt; 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'>&lt;<cite>jackjansen</cite>&gt; 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'>&lt;<cite>scribe</cite>&gt;
    <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'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>scribe</cite>&gt;
    <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'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>trackbot</cite>&gt; ACTION-190 --
    Raphaël Troncy to update our spec to talk about video intrinsic
    width -- due 2010-10-27 -- OPEN</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; <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 ...
    &lt;date&gt;</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; so, do you want a
    description that spatial fragments should be spliced in html5
    elements?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>jackjansen</cite>&gt; foolip,
    currently not</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; raphael: my question
    was about what should be added to a browser section (html
    section?) in 7.1</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; yup</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>jackjansen</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; <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'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; "information
    rich"?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; silvia, isn't 1 and
    2 the same?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I think we should
    attach the pixel count to 2.</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; not really - there
    is pixel crop in several formats - ogg does it, too</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I would suggest not
    to count those pixels that are cropped in the format</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; silvia, I would
    consider the effect of crop+scaling as one step, but
    anyway...</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; (when I said
    "cropped in the format", I meant PixelCropBottom and stuff like
    that)</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; so, the dimension I
    suggest we use are the same as we see in
    HTMLVideoElement.videoWidth and .videoHeight</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; I assume we agree
    but don't understand each other :)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; except that
    HTMLVideoElement.videoWidth and .videoHeight have the @height
    and @width scaling of the &lt;video&gt; element executed on
    it</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; silvia, no, it
    doesn't</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; at least not in
    Opera or according to the spec</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; ah, ok, then it is
    those width and height indeed</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; right :)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; <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'>&lt;<cite>silvia</cite>&gt; we could just simply
    refer to the HTMLVideoElement.videoWidth and .videoHeight
    description</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; I disagree, this is
    not a implementor note, we need to say precisely what to do, as
    with everything else.</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; No need for new
    sections, just say it where we define xywh</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; no, it's bad to
    leave such things open for interpretation</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I cannot think of a
    situation where it would be desirable to use a different
    meaning</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; sorry, call
    dropped</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>jackjansen</cite>&gt; I agree too.</p>

    <p class='phone'>ok, great consensus</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; Section 7 is for
    "practicality beats purity"</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; but we can copy the
    text</p>

    <p class='phone'>Silvia, or Philip, could you add this sentence
    now?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; sure… give me a
    sec</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; oh - what text do
    you want then?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; why don't you add it
    then?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; If there's something
    wrong with the phrasing, have it changed in HTML5 first, please
    :)</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; s/specified as pixel
    coordinates or pecentages/specified as CSS pixel coordinates or
    percentages/</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; We could write:</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; Yep. Never mind the
    syntax for now, that's easy to change later.</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; "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'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; Jack: in html5 they
    are relevant as CSS pixels, because CSS scaling and stuff is
    applied to them</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; and we might as well
    make that link here</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; I would make an
    exception here</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; OK, so put it in a
    note then.</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; "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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; Note: this is
    equivalent to intrinsic width and height in HTML5 &lt;<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&gt;</a></p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; "The pixel
    coordinates defined in 4.3.2 are intended to be identical to
    the "CSS pixels" defined by HTML5"</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; different
    section?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; not "CSS pixels",
    intrinsic width and height</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; filip, right</p>

    <p class='phone'>close ACTION-190</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; yes</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; I think we should
    just rename xywh to crop.</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; ninsuna does nothing
    on the server for regions</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I haven't seen the
    ninsuna client yet, I think...</p>

    <p class='phone'>it is on the web silvia</p>

    <p class='irc'>&lt;<cite>davy</cite>&gt; <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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; so,
    xywh=247,156,129,206 already means highlighting to
    everyone?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>jackjansen</cite>&gt; silvia, xywh
    doesn't mean highlighting nor cropping. It means addressing,
    nothing more.</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; because it ends up
    in in-compatible interpretations of the URI</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; and if we want
    browsers to support both display mechanisms, we need two
    different means of addressing</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; no, I am saying that
    we are under-specifying the mechanism</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; Anyway, can we take
    a step back and see what we're actually discussing?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>davy</cite>&gt; CSS descriptors could
    be used for displaying media fragments</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; I'm playing with the
    thought and I can only see advantages this far</p>

    <p class='phone'>[lunch break]</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; <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'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; but, I'm not
    sure</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; it would be terrible
    if two different MIME types defined things differently</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; In reality, browsers
    will just do the same thing for all types...</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; Adding non-normative
    text doesn't change anything.</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; no, every HTML
    rendering UA must do the same thing - otherwise it's not much
    of a standard, right?</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; it's not
    prescriptive enough for HTML5</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; I don't think it's
    fruitful to try to work this out in real time, right now.</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>davy</cite>&gt; Is the rendering of
    the video timeline a similar issue?</p>

    <p class='irc'>&lt;<cite>davy</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; more like a
    patch</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; really? he'll just
    say it doesn't belong there..</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; If he's wrong, then
    we should tell him why :)</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; at minimum there are
    these sections affected:</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; <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'>&lt;<cite>silvia</cite>&gt; <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'>&lt;<cite>silvia</cite>&gt; (sorry, but I prefer
    the whatwg version ;)</p>

    <p class='phone'>fine</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; (it's more
    up-to-date)</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; and it's green
    :)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>scribe</cite>&gt;
    <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'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>scribe</cite>&gt;
    <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'>&lt;<cite>trackbot</cite>&gt; Sorry, couldn't
    find user - raphael</p><a name="action05" id="action05"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <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'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; Should I call
    in?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; And what about
    Chrome developers?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>foolip</cite>&gt; 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'>&lt;<cite>trackbot</cite>&gt; ISSUE-19 --
    Parsing must be defined normatively in the MF spec itself --
    open</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; <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'>&lt;<cite>foolip</cite>&gt; &lt;video
    src="video.webm#t=10"&gt;</p>

    <p class='irc'>&lt;<cite>davy</cite>&gt; media fragment
    identifiers are only meaningful for media resources, not for
    HTML documents</p>

    <p class='irc'>&lt;<cite>davy</cite>&gt; 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'>&lt;<cite>davy</cite>&gt; 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'>&lt;<cite>scribe</cite>&gt;
    <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'>&lt;<cite>trackbot</cite>&gt; 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 />

  &nbsp;<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>