07:57:44 <RRSAgent> RRSAgent has joined #mediafrag
07:57:44 <RRSAgent> logging to http://www.w3.org/2010/11/01-mediafrag-irc
07:57:46 <trackbot> RRSAgent, make logs public
07:57:46 <Zakim> Zakim has joined #mediafrag
07:57:48 <trackbot> Zakim, this will be IA_MFWG
07:57:48 <Zakim> ok, trackbot; I see IA_MFWG(TPAC)3:00AM scheduled to start 57 minutes ago
07:57:49 <trackbot> Meeting: Media Fragments Working Group Teleconference
07:57:49 <trackbot> Date: 01 November 2010
07:58:04 <raphael> Chair: Raphael
07:58:15 <raphael> Regrets: Erik
07:58:36 <raphael> Presents: Davy, Jack, Raphael, Silvia (irc), Phillip (irc), Yves
07:58:48 <raphael> Meeting: Media Fragments F2F meeting @TPAC
07:58:54 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/01-mediafrag-minutes.html raphael
08:06:46 <Franck> Franck has joined #mediafrag
08:22:46 <raphael> Topic: 1. Quick round of introduction
08:22:54 <raphael> scribe: raphael
08:22:59 <raphael> scribenick: raphael
08:23:54 <raphael> Many observers ...
08:24:04 <raphael> Franēois: w3c staff
08:24:36 <raphael> Ben (Nokia): MAWG member
08:25:42 <raphael> Idetaca: developer of Mobile browser, interest in adaptation to small screen
08:26:02 <francois> francois has joined #mediafrag
08:26:15 <jackjansen> jackjansen has joined #mediafrag
08:26:46 <hidetaka> hidetaka has joined #mediafrag
08:26:51 <raphael> Nob (NRC ac rep): media analysis (face recognition), interest in standardising results of such analysis
08:27:01 <raphael> s/Idetaca/Idetaka
08:28:09 <hidetaka> s/Idetaka/Hidetaka/
08:28:51 <raphael> Hiroyuki (Toshipa ac rep): metadata standardisation
08:29:53 <raphael> Frank (Canon research France): I'm an "old" observer of this group, interest in media fragments standard for streaming media
08:30:26 <raphael> Pierre Antoine (LIRIS): Uni of Lyon, member of MAWG
08:33:01 <jackjansen> s/Frank/Franck
08:33:14 <raphael> Topic: 2. Topics to be discussed
08:33:16 <raphael> http://www.w3.org/2008/WebVideo/Fragments/wiki/SeventhF2FAgenda
08:36:38 <raphael> Raphael: time dimension
08:36:56 <raphael> ... Philip wonders if the hours should not be optional
08:37:09 <raphael> ... arguing that most video clips are less than an hour duration
08:37:16 <raphael> ... in WebSRT, hours are optional
08:37:21 <raphael> ... should we do the same?
08:37:57 <raphael> Jack: -0, I'm slightly against
08:39:06 <raphael> Raphael: the production rules are currently
08:39:07 <raphael> npt-sec       = 1*DIGIT [ "." *DIGIT ]                     ; definitions taken
08:39:07 <raphael> npt-hhmmss    = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT] ; from RFC 2326
08:39:07 <raphael> npt-hh        =   1*DIGIT     ; any positive number
08:39:07 <raphael> npt-mm        =   2DIGIT      ; 0-59
08:39:07 <raphael> npt-ss        =   2DIGIT      ; 0-59
08:41:45 <jackjansen> after some discussion I am now +0, slightly in favor
08:42:55 <aizu> aizu has joined #mediafrag
08:44:03 <pchampin> pchampin has joined #mediafrag
08:45:12 <raphael> Raphael: I do remember that Silvia and Philip was also for making the hours optional
08:45:33 <raphael> ... I suggest to edit the grammar this afternoon with Yves if he does not disagree
08:46:33 <raphael> ACTION: Yves to update the production rules of the time dimension with the npt format for making the hours optional
08:46:34 <trackbot> 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].
08:46:37 <silvia> I like the simplicity for the user of the more flexible format
08:46:51 <raphael> Raphael: smpte format
08:48:26 <raphael> Davy: the servers is always answering with the same unit than the client
08:49:28 <raphael> Jack: well, but if the UA sends a fragment in smpte-30-drop, and the media has another encoding, then should we do a conversion?
08:49:33 <hidetaka> s/Nob (NRC ac rep)/Nobu (NEC ac rep)/
08:49:54 <hidetaka> s/Toshipa/Toshiba/
08:50:01 <raphael> ... if the UA sends a npt format, it is clear what the server has to do
08:50:46 <silvia> note that the UA can convert what the user provides to the browser to a common format that can go over the wire
08:51:05 <raphael> ... 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
08:51:30 <raphael> Davy: the problem is that the UA might not understand the time format in which you are converting to
08:51:51 <raphael> Raphael: yes Silvia, but then we always convert to npt?
08:52:28 <silvia> hmm.. right - might be better to just hand it through
08:53:16 <raphael> Jack: we could raise an error, if the UA asks for smpte time codes but that smpte has not been used in the media item
08:54:08 <raphael> Davy: our current implementation works with a double conversion
08:54:28 <raphael> ... if the UA sends a smpte-30-drop media fragment and the media item is encoded in smpte-25
08:55:07 <raphael> ... then the servers will convert the smpte-30-drop into npt to get a position and convert it back in smpte-25
08:55:36 <raphael> Jack: the frame precision will be most used in the annotation area rather than the presentation area
08:55:55 <raphael> ... so we should not have the presentation (browsers) glasses to look at this issue
08:55:59 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/01-mediafrag-minutes.html raphael
08:56:48 <davy> s/back in smpte-25/back in smpte-30-drop
09:04:06 <raphael> Raphael: let's summarize the discussion
09:04:26 <raphael> ... smpte time codes are useful for a number of use cases, in particular for annotation use cases
09:04:56 <raphael> ... 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
09:05:34 <raphael> ... then the server should fallback to answering in npt if it has an understanding of the timeformat requested bu the UA
09:06:08 <raphael> ... 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
09:07:03 <raphael> Jack: ok, where this information should be written ? is this normative ?
09:08:04 <aizu_> aizu_ has joined #mediafrag
09:11:22 <raphael> ... section 5 seems appropriate, I'm tempted to say if should be normative
09:13:28 <raphael> Raphael: we might have to change the structure of section 5 to make it dimension dependent
09:14:07 <jackjansen> s/if should be normative/it should be normative
09:14:41 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/01-mediafrag-minutes.html davy
09:15:14 <raphael> ACTION: 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
09:15:14 <trackbot> 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].
09:16:37 <raphael> Raphael: let's discuss the space dimension
09:16:53 <raphael> ACTION-190?
09:16:53 <trackbot> ACTION-190 -- Raphaƫl Troncy to update our spec to talk about video intrinsic width -- due 2010-10-27 -- OPEN
09:16:53 <trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/190
09:17:28 <raphael> http://dev.w3.org/html5/spec/video.html#concept-video-intrinsic-width
09:21:01 <raphael> Room trying to understand the issue
09:24:22 <ishino_> ishino_ has joined #mediafrag
09:25:55 <raphael> Room having a laugh reading http://www.emdpi.com/csspixel.html
09:29:37 <raphael> Jack: in section 7, we could put a note for phrasing this issue. Philip is our HTML5 expert to do this phrasing
09:30:01 <raphael> Davy: we should have another section 7.x for browsers, how they should render media fragment
09:30:13 <raphael> ... different than 7.1 which is for general clients
09:31:02 <raphael> Jack: 7.1 should be browsers, 7.2 general clients, 7.3 servers
09:31:35 <raphael> ... + a note for stating that all sub-sections are not mutually exclusive
09:32:09 <raphael> Raphael: actually, 7.1 = browsers, 7.2 general display clients, 7.3 other clients, 7.4 servers
09:32:21 <jackjansen> s/other/all
09:34:06 <raphael> Jack: then in 7.1, we could have the result of the action 190, the mapping to css pixels
09:35:54 <raphael> Jack: I would be happy that Philip + Silvia draws a list of all things that matter to a HTML5 browser rendering client for media fragments
09:37:27 <raphael> Jack: perhaps put a warning that the content of this new section is based on the current state of HTML5 discussion as per ... <date>
09:38:42 <silvia> so, do you want a description that spatial fragments should be spliced in html5 elements?
09:38:52 <jackjansen> jackjansen has joined #mediafrag
09:38:55 <homata_> homata_ has joined #mediafrag
09:57:41 <foolip> foolip has joined #mediafrag
09:58:30 <foolip> anyone know when we're going to have the TPAC calls? I can't find anything definitive in my mail
10:07:56 <hidetaka> hidetaka has joined #mediafrag
10:15:25 <raphael> [back from coffee break]
10:15:45 <raphael> Silvia, I'm not sure I udnerstand your question
10:16:07 <raphael> Philip, we have started the Media Fragments WG f2f meeting at TPAC
10:16:07 <pchampin> pchampin has joined #mediafrag
10:16:33 <raphael> ... agenda is at http://www.w3.org/2008/WebVideo/Fragments/wiki/SeventhF2FAgenda (add your topics that you would like to be discussed)
10:16:38 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/01-mediafrag-minutes.html raphael
10:19:04 <raphael> s/udnerstand/understand
10:19:26 <Zakim> Zakim has left #mediafrag
10:22:34 <jackjansen> jackjansen has joined #mediafrag
10:25:55 <jackjansen> foolip, currently not
10:26:48 <silvia> raphael: my question was about what should be added to a browser section (html section?) in 7.1
10:27:04 <silvia> I wondered if it was ok to add spatial fragments as splicing the image
10:27:52 <raphael> Philip, we can setup the call now if you're ready
10:28:41 <foolip> ok, where are you in the agenda/
10:29:15 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/01-mediafrag-minutes.html raphael
10:29:48 <raphael> Silvia, we are exactly dicussing what should we add to this new section 7.1
10:29:53 <raphael> ... so far, the pixels discussion
10:30:34 <raphael> Raphael: Philip, we wonder whether you and Silvia could write down a list of items that (HTML5) browsers need to consider when implementing media fragments
10:30:59 <raphael> ... but notes that are not applicable to general rendering clients and already written
10:31:07 <raphael> ... for example, the pixels discussion
10:31:36 <raphael> ... could you phrase the issue of what mapping to CSS pixels should be done for example? 
10:31:56 <raphael> Silvia, by splicing, you mean cropping?
10:32:03 <silvia> yup
10:32:42 <foolip> 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
10:32:43 <raphael> Sylvia, we have a paragraph so far that talk about either highlighting or cropping
10:32:48 <raphael> ... which one makes more sense ?
10:33:33 <raphael> zakim, dial Roseraie_1
10:33:54 <jackjansen> invite zakim
10:34:31 <raphael> join zakim #mediafrag
10:35:01 <Zakim> Zakim has joined #mediafrag
10:35:08 <raphael> zakim, dial Roseraie_1
10:35:08 <Zakim> sorry, raphael, I don't know what conference this is
10:35:19 <raphael> zakim, which telecon?
10:35:19 <Zakim> I don't understand your question, raphael.
10:35:27 <raphael> zakim, which teleconference?
10:35:27 <Zakim> I don't understand your question, raphael.
10:35:38 <raphael> zakim, list telecon
10:35:38 <Zakim> I don't understand 'list telecon', raphael
10:36:11 <raphael> zakim, this is IA_MFWG(TPAC)3:00AM 
10:36:11 <Zakim> raphael, I see IA_MFWG(TPAC)3:00AM in the schedule but not yet started.  Perhaps you mean "this will be IA_MFWG(TPAC)3:00AM".
10:36:21 <raphael> zakim, this will be IA_MFWG(TPAC)3:00AM 
10:36:21 <Zakim> ok, raphael; I see IA_MFWG(TPAC)3:00AM scheduled to start 216 minutes ago
10:36:35 <raphael> zakim, dial Roseraie_1
10:36:35 <Zakim> ok, raphael; the call is being made
10:36:36 <Zakim> IA_MFWG(TPAC)3:00AM has now started
10:36:37 <Zakim> +Roseraie_1
10:38:14 <raphael> Silvia, Philip, you can now dial in and we will see if it works
10:38:42 <Zakim> +??P7
10:40:23 <raphael> Philip: this is not a CSS issue
10:41:07 <raphael> ... the question is when do we have a xywh dimension, does it apply before of after that there was a aspect ratio transform
10:42:49 <Zakim> +silvia
10:42:59 <silvia> zakim, mute me
10:42:59 <Zakim> silvia should now be muted
10:43:31 <raphael> Jack: the original media item is 1080, but the device is 720 width, so which pixels should be considered when applying a media fragment xywh?
10:44:40 <foolip> http://en.wikipedia.org/wiki/Anamorphic_format
10:44:56 <raphael> Jack: I think we have trouble to understand what exactly is the CSS pixel concept and therefore the issue
10:45:51 <raphael> Philip: the container format has tow information, the preferred display size and the real size
10:46:03 <homata> homata has joined #mediafrag
10:48:05 <silvia> q+
10:48:33 <foolip> For example, WebM has Pixel width/height and Display width/height. This is the same as Matroska: http://www.matroska.org/technical/specs/index.html
10:48:49 <foolip> Actually, Matroska also has PixelCropBottom, etc
10:48:57 <raphael> Jack: in QuickTime 7, open a movie you can choose between normal size and display size
10:49:07 <foolip> The point is that the physical pixels aren't always the same as the display size
10:49:37 <raphael> ok Philip, we understand now the issue
10:49:50 <raphael> Philip: CSS pixels are display pixels
10:50:16 <foolip> "information rich"?
10:50:53 <silvia> zakim, unmute me
10:50:53 <Zakim> silvia should no longer be muted
10:53:37 <silvia> zakim, mute me
10:53:37 <Zakim> silvia should now be muted
10:55:37 <silvia> 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
10:55:51 <foolip> silvia, isn't 1 and 2 the same?
10:55:54 <silvia> I think we should attach the pixel count to 2.
10:56:19 <silvia> not really - there is pixel crop in several formats - ogg does it, too
10:56:30 <silvia> I would suggest not to count those pixels that are cropped in the format
10:57:41 <foolip> silvia, I would consider the effect of crop+scaling as one step, but anyway...
10:57:55 <silvia> 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
10:58:36 <silvia> (when I said "cropped in the format", I meant PixelCropBottom and stuff like that)
10:58:56 <foolip> 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
10:59:18 <foolip> so, the dimension I suggest we use are the same as we see in HTMLVideoElement.videoWidth and .videoHeight
10:59:35 <foolip> I assume we agree but don't understand each other :)
11:00:17 <silvia> except that HTMLVideoElement.videoWidth and .videoHeight  have the @height and @width scaling of the <video> element executed on it
11:00:59 <foolip> silvia, no, it doesn't
11:01:07 <foolip> at least not in Opera or according to the spec
11:01:23 <silvia> ah, ok, then it is those width and height indeed
11:01:36 <foolip> right :)
11:02:17 <silvia> that's indeed what I meant with option 2
11:04:26 <raphael> Jack: my proposal is that when the container format has multiple interpretations of the width and height
11:04:48 <raphael> ... then we should fall back to the display width and height (aka CSS pixels)
11:05:14 <raphael> ... and we could give the example of the Anamorphic format versus the example of vector graphics
11:05:30 <foolip> http://dev.w3.org/html5/spec/video.html#concept-video-intrinsic-width
11:05:32 <silvia> we could just simply refer to the HTMLVideoElement.videoWidth and .videoHeight description
11:06:26 <foolip> I disagree, this is not a implementor note, we need to say precisely what to do, as with everything else.
11:07:15 <foolip> No need for new sections, just say it where we define xywh
11:07:58 <silvia> no, it's bad to leave such things open for interpretation
11:08:42 <silvia> I cannot think of a situation where it would be desirable to use a different meaning
11:08:57 <foolip> sorry, call dropped
11:08:59 <Zakim> -foolip
11:09:38 <silvia> at least write it into the HTML / browser section in this way as a requirement
11:10:22 <raphael> People in the room tends also to think that it should be specified when we talk about xywh
11:10:29 <raphael> Jack: fine
11:10:47 <foolip> 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
11:11:10 <silvia> I agree
11:11:16 <raphael> ... and if someone in the future is interested in physical pixels, then they should invent "xywh-physical" for addressing them
11:11:17 <jackjansen> I agree too. 
11:11:25 <raphael> ok, great consensus
11:11:27 <jackjansen> Section 7 is for "practicality beats purity"
11:11:31 <silvia> why not re-use the text from the HTML5 spec - or at least link to it?
11:12:51 <raphael> Raphael: 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
11:13:07 <raphael> ... no reference to HTML5 spec, sorry
11:13:15 <raphael> ... we cannot because we will be REC before them
11:13:53 <silvia> but we can copy the text
11:13:58 <raphael> Silvia, or Philip, could you add this sentence now?
11:14:08 <silvia> sureā€¦ give me a sec
11:14:11 <jackjansen> I don't think we want that exact text: it had us baffled this morngin
11:14:22 <raphael> phrase it differently, BECAUSE we haven't udnerstand the HTML5 text in a first place
11:14:30 <raphael> ... so the phrasing was not good enough
11:15:02 <silvia> oh - what text do you want then?
11:15:06 <silvia> why don't you add it then?
11:15:42 <foolip> If there's something wrong with the phrasing, have it changed in HTML5 first, please :)
11:16:17 <foolip> just file a bug and it will happen
11:16:22 <raphael> Philip, you're the one to make changes in the HTML5 spec :-)
11:16:29 <foolip> or, tell me what's difficult to understand and I'll make it happen
11:16:46 <raphael> let's edit this sentence in our spec on irc
11:16:54 <silvia> I really don't see how it can be formulated better
11:16:55 <raphael> First sentence reads:
11:16:56 <raphael> 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.
11:17:12 <silvia> it refers to CSS pixels and explains what needs to be taken care of
11:17:15 <raphael> I suggest we add afterwards a sentence talking about CSS pixels
11:17:48 <raphael> Which sentence do you want to re-use exactly?
11:18:09 <silvia> s/specified as pixel coordinates or pecentages/specified as CSS pixel coordinates or percentages/
11:18:32 <silvia> then explain CSS pixels for video the way that HTML5 does
11:19:14 <raphael> OK silvia, so you want to add this sentence afterwards?
11:19:16 <foolip> 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.
11:19:16 <raphael> "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
11:20:26 <raphael> Philip, currently, our syntax is: #xywh=160,120,320,240 or #xywh=pixel:160,120,320,240
11:21:42 <silvia> We could write:
11:21:47 <foolip> Yep. Never mind the syntax for now, that's easy to change later.
11:22:30 <silvia> "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."
11:23:18 <raphael> thanks Silvia
11:23:41 <foolip> I'm not joking at all, but let's focus on the issue at hand.
11:23:49 <raphael> The only issue for Jack is that we should perhaps not name them "CSS pixels", they have nothing to do with CSS
11:24:15 <silvia> foolip: does that sentence sound correct still? it's not quite what html5 says, but CSS pixels aren't defined there...
11:24:42 <silvia> Jack: in html5 they are relevant as CSS pixels, because CSS scaling and stuff is applied to them
11:24:57 <silvia> and we might as well make that link here
11:25:11 <foolip> 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.
11:25:48 <raphael> Philip, in a recommendation, you should avoid linking to a WD or any other document which is not a REC
11:25:52 <silvia> we should of course link to it to also say that we mean the same thing as HTML5
11:26:04 <raphael> ... because of dependency issue
11:26:23 <silvia> I would make an exception here
11:26:25 <foolip> I can see why that general policy exists, but clearly it's harmful in this instance.
11:26:32 <raphael> ... what's happened if the HTML5 spec removes this paragraph at REC stage after you have been rec? You need to publish an erratum
11:26:35 <raphael> ... too dangerous
11:26:46 <silvia> no, there's no chance that section will be removed
11:27:01 <raphael> Silvia, we can make exceptions for many things then, and this is simply not acceptable
11:27:10 <raphael> ... you know St Thomas
11:27:20 <silvia> no, I wouldn't make exceptions for many things - but in this instance I woudl
11:27:37 <raphael> Silvia, perhaps you want to make an exception, but the director will NOT
11:28:02 <raphael> ... this is the shortcut to get a veto from the W3C director (and many members by the way)
11:28:30 <silvia> maybe he would - it would be harmful not to make an exception here, because we want to mean the same thing as HTML5
11:28:40 <foolip> So there can't be any links to documents that aren't in REC?
11:28:47 <raphael> great, we make our own sentence, and that's fine
11:28:59 <raphael> not in normative part Philip
11:29:05 <raphael> and this is a 20 years old practice
11:29:17 <foolip> OK, so put it in a note then.
11:29:19 <jackjansen> "If the underlying media format has multiple interpretations of pixel dimensions, then MF pixels MUST be interpreted in the display dimension"
11:29:33 <jackjansen> s/dimension/coordinates
11:30:53 <Nobu> Nobu has joined #mediafrag
11:31:34 <raphael> Jack: "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."
11:31:34 <Zakim> +??P1
11:32:46 <silvia> 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
11:33:09 <raphael> Philip: 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." ?
11:33:19 <raphael> yes Silvia
11:38:42 <foolip> Note: this is equivalent to intrinsic width and height in HTML5 <http://dev.w3.org/html5/spec/video.html#concept-video-intrinsic-width>
11:38:52 <jackjansen> "The pixel coordinates defined in 4.3.2 are intended to be identical to the "CSS pixels" defined by HTML5"
11:39:00 <Nobu_> Nobu_ has joined #mediafrag
11:39:01 <foolip> different section?
11:41:04 <foolip> not "CSS pixels", intrinsic width and height
11:42:27 <jackjansen> filip, right
11:45:54 <raphael> close ACTION-190
11:45:54 <trackbot> ACTION-190 Update our spec to talk about video intrinsic width closed
11:46:19 <raphael> Changes have been made in section 4.3.2: http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-space
11:46:40 <raphael> ... and in section 7.1: http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#media-fragment-browser
11:46:52 <raphael> anyone UN-happy, please, speak
11:47:13 <foolip> yes
11:48:47 <foolip> I'd rather section 7.1 didn't exist, and the note being put directly after the copied text in http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-space
11:49:26 <silvia> ah, yes, I agree with Philip actually - seeing as it should be used everywhere to mean the same thing
11:50:38 <raphael> Raphael: highlight vs cropping
11:50:50 <raphael> ... should we say more than the current pararaph ?
11:51:09 <raphael> "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
11:51:41 <raphael> in particular, should we talk now with CSS?
11:52:54 <foolip> I think we should just rename xywh to crop.
11:53:12 <foolip> Annotations don't care about display anyway.
11:54:26 <raphael> Jack: for time, we have both, cropping (query) and highlihting (in context view), why you would like to make it different for space?
11:54:58 <raphael> Philip: because there is a good reason for time, I don't see it for space
11:55:21 <raphael> Jack: but annotation use case is about addressing pixels, not cropping or highlighting
11:55:23 <silvia> 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...)
11:57:16 <silvia> ninsuna does nothing on the server for regions
11:58:17 <silvia> I haven't seen the ninsuna client yet, I think...
11:58:32 <raphael> it is on the web silvia
11:58:38 <davy> http://ninsuna.elis.ugent.be/MediaFragmentsPlayer
11:58:38 <raphael> we have demoed it everywhere
12:00:24 <silvia> I had only seen the plugin
12:01:07 <raphael> 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 :-)
12:01:38 <silvia> so, xywh=247,156,129,206 already means highlighting to everyone?
12:01:54 <silvia> so, crop=247,156,129,206 could mean cropping - would be the easy way out actually...
12:02:08 <raphael> ... there are slides about it at the Barcelona F2F meeting, look at our meetings dir in our web space
12:02:45 <jackjansen> silvia, xywh doesn't mean highlighting nor cropping. It means addressing, nothing more.
12:02:58 <silvia> because it ends up in in-compatible interpretations of the URI
12:03:48 <silvia> when a Web developer cannot rely on what will be presented in all browsers the same way, it's in-compatible and under-specified
12:04:08 <raphael> Yes Silvia, but this is not our fault but the fault of HTML5
12:04:34 <raphael> ... what Jack is saying is that for us, it should be an implementation note, but for HTML5, the behavior should be normative
12:04:56 <raphael> ... I guess the issue is that rendering in browsers should be specified in HTML5 and not in Media Fragments
12:05:32 <raphael> ... media fragments is just about "addressing"
12:05:58 <silvia> we should put it into the browser section at minimum
12:06:00 <raphael> Philip: 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
12:06:21 <raphael> Yes silvia, this is what Jack proposes
12:06:22 <silvia> and if we want browsers to support both display mechanisms, we need two different means of addressing
12:06:52 <silvia> I'm warming to the thought of "crop"
12:07:00 <raphael> Slvia, you are adapting the display mechanism to the address while it should be the contrary
12:07:27 <silvia> no, I am saying that we are under-specifying the mechanism
12:07:29 <foolip> Anyway, can we take a step back and see what we're actually discussing?
12:07:39 <silvia> html fragments also always mean the same in all applications
12:07:42 <raphael> 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 ?
12:07:50 <davy> CSS descriptors could be used for displaying media fragments
12:08:54 <foolip> 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.
12:09:28 <silvia> I'm playing with the thought and I can only see advantages this far
12:12:07 <raphael> [lunch break]
12:12:30 <Zakim> -??P1
12:12:33 <Zakim> -silvia
12:12:45 <raphael> zakim, drop Roseraie_1
12:12:45 <Zakim> Roseraie_1 is being disconnected
12:12:47 <Zakim> IA_MFWG(TPAC)3:00AM has ended
12:12:49 <Zakim> Attendees were Roseraie_1, foolip, silvia
12:55:17 <homata> homata has joined #mediafrag
13:06:52 <aizu_> aizu_ has joined #mediafrag
13:08:50 <pchampin> pchampin has joined #mediafrag
13:12:45 <foolip> are we starting again soon?
13:12:47 <hidetaka> hidetaka has joined #mediafrag
13:15:11 <Nobu> Nobu has joined #mediafrag
13:16:51 <raphael> zakim, dial Roseraie_1
13:16:51 <Zakim> ok, raphael; the call is being made
13:16:54 <Zakim> IA_MFWG(TPAC)3:00AM has now started
13:16:54 <Zakim> +Roseraie_1
13:17:32 <Zakim> +[IPcaller]
13:18:05 <raphael> zakim, +[IPcaller] is Philip
13:18:05 <Zakim> sorry, raphael, I do not recognize a party named '+[IPcaller]'
13:18:09 <raphael> zakim, [IPcaller] is Philip
13:18:09 <Zakim> +Philip; got it
13:19:12 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/01-mediafrag-minutes.html raphael
13:19:45 <Zakim> -Philip
13:19:50 <jackjansen> jackjansen has joined #mediafrag
13:21:19 <Zakim> +??P9
13:22:03 <francois> francois has joined #mediafrag
13:25:11 <raphael> Philip: there will be no other people that will specify this except us
13:25:26 <raphael> ... so either we make it in our spec or we make it in the HTML5 spec, but it will be us
13:26:02 <raphael> Raphael: where the rendering of a media fragment according to the space dimension should be specified?
13:27:15 <foolip> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10723
13:29:58 <raphael> Philip: 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
13:31:27 <raphael> Jack: I think we should just have a 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
13:31:58 <raphael> s/normative/non normative
13:32:07 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/01-mediafrag-minutes.html raphael
13:32:24 <daniel> daniel has joined #mediafrag
13:34:43 <Franck> Franck has joined #mediafrag
13:37:30 <raphael> Jack: yes, cropping seems to be the best default solution for html browsers
13:38:25 <raphael> ... let's propose a crop only text to HTML5 and see WebApps or CSS complaint about
13:38:41 <raphael> Philip: this should not be something that goes towards mime type registration?
13:39:03 <raphael> ... So shouldn't we write something, a hook, for enabling such a mime type registration
13:39:10 <foolip> I said that I think I agree with Ian that this *should* go into MIME type registrations
13:39:30 <raphael> thanks for the reformulation
13:39:38 <foolip> but, I'm not sure
13:39:51 <foolip> it would be terrible if two different MIME types defined things differently
13:40:09 <foolip> In reality, browsers will just do the same thing for all types...
13:40:52 <silvia> 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?
13:41:28 <raphael> Yves has further discussed this with TAG and TimBL last weeks and this morning
13:41:40 <raphael> ... he will update us later today or tomorrow morning
13:44:19 <raphael> Jack is editing section 7 now, to clarify that browsers should crop spatial fragments
13:44:36 <foolip> Adding non-normative text doesn't change anything.
13:44:43 <foolip> There should be normative text *somewhere*.
13:44:45 <raphael> ... and that other clients can crop or highlight regions
13:44:56 <raphael> YES, Philip, this is the first part
13:45:13 <foolip> Also, special-casing browsers is very atypical.
13:45:15 <raphael> the second is to send this text being edited to HTML5 and see if they want it *normatively*
13:45:55 <raphael> if we do: s / browsers / HTML5 renderers,do you prefer ?
13:45:58 <silvia> if we are making a browser section, we might as well make our section normative
13:46:14 <raphael> why silvia ?
13:46:24 <raphael> this is implementation specific
13:47:03 <silvia> no, every HTML rendering UA must do the same thing - otherwise it's not much of a standard, right?
13:51:21 <jackjansen> please read and review: I tend to be somewhat terse in my prose...
13:52:00 <raphael> Jack: if we like this, how do we push this to HTML5 WG?
14:02:41 <silvia> it's not prescriptive enough for HTML5
14:03:13 <foolip> I don't think it's fruitful to try to work this out in real time, right now.
14:03:13 <silvia> 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
14:03:18 <davy> Is the rendering of the video timeline a similar issue?
14:03:21 <davy> e.g., http://dev.opera.com/articles/view/custom-html5-video-player-with-css3-and-jquery/
14:05:57 <foolip> 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.
14:06:09 <raphael> Raphael: Silvia, I'm proposing to edit the bug, but feel free to do it
14:06:21 <raphael> ... my plan was to add the paragraph in 7.2 in the bug entry
14:06:31 <raphael> ... and let HTML5 decides what to put in their spec
14:06:50 <silvia> 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
14:07:14 <silvia> think about as though you are the editor of the spec and you are proposing what text has to go in
14:07:25 <silvia> more like a patch
14:07:48 <foolip> We shouldn't suggest any specific text, let's just say what we want and let Ian figure out the details.
14:08:16 <raphael> What about saying Ian to make the text he wants from
14:08:18 <raphael> "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."
14:08:20 <silvia> really? he'll just say it doesn't belong there..
14:08:47 <foolip> If he's wrong, then we should tell him why :)
14:08:56 <foolip> I'm not sure myself, at this point.
14:08:59 <raphael> Silvia, Ian said it should belong to the mime type registration (not in HTML5, not in Media Fragment), but it will NOT appear there
14:09:28 <silvia> that's a second thing: we  need a good answer for why it's not going into mime type registrations
14:09:36 <raphael> ... and he made it appear in the HTML5 spec for the HTML media fragment spec ... not in a separate mime type registration document
14:09:55 <raphael> s/HTML media fragment/HTML fragment
14:10:19 <raphael> Silvia, do you want to edit the bug?
14:10:23 <raphael> ... so we can move on?
14:10:28 <silvia> at minimum there are these sections affected:
14:10:31 <silvia> http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-fragid and
14:10:45 <silvia> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video
14:10:57 <silvia> (sorry, but I prefer the whatwg version ;)
14:11:06 <raphael> fine
14:11:14 <silvia> (it's more up-to-date)
14:11:23 <foolip> and it's green :)
14:11:37 <francois> francois has joined #mediafrag
14:12:03 <silvia> I'll update the bug after we have an answer to the question about mime type registrations
14:12:19 <raphael> ok
14:12:39 <raphael> Raphael: we wait for the debrief of Yves regarding the discussion in TAG
14:12:40 <silvia> 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
14:12:57 <raphael> Silvia, I put it in the agenda too
14:12:58 <silvia> I think that may also be relevant
14:13:06 <raphael> ... and I observe we have already discussed this several times
14:13:11 <raphael> ... and already come to a conclusion
14:13:18 <raphael> ... but you want to re-open the can of worms :-)
14:13:22 <silvia> for now we can collect all these things in the "browser" section of "our" spec
14:13:50 <raphael> Topic: 3. Track and Name dimensions
14:13:53 <silvia> I do because we are moving closer to real-world use and we have to do more than initially intended
14:14:05 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/01-mediafrag-minutes.html raphael
14:14:46 <raphael> Davy: Regarding the track dimensions, it is almost always impossible to write all the byte ranges 
14:14:55 <raphael> ... so we will _always_ perform a redirect
14:15:08 <raphael> ... hence, if a media fragment URI uses a # with the track dimension
14:15:38 <raphael> ... we redirect to the '?' parameter
14:16:10 <raphael> ... see http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-UA-mapped-changed
14:16:31 <raphael> ACTION: Erik to make a schema for this recipe
14:16:31 <trackbot> Created ACTION-193 - Make a schema for this recipe [on Erik Mannens - due 2010-11-08].
14:21:07 <raphael> Raphael: the section 5 is organized per recipes
14:21:22 <raphael> ... but it is confusing when one looks at the dimension
14:21:36 <raphael> ... hence, spatial dimension has no dimension (no request is sent to the server)
14:21:57 <raphael> ... the track dimension is always in the case of server-redirect recipe
14:22:08 <raphael> ... most likely, the same for name dimension
14:22:21 <raphael> ... therefore, only the time dimension can use all these recipes
14:22:36 <raphael> ... should we not write this down up in the section 5?
14:23:02 <raphael> s/has no dimension/has no recipe
14:30:14 <raphael> Raphael: we have 3 types or recipes
14:31:29 <raphael> ... UA mapped byte ranges ... for the temporal dimension
14:31:43 <raphael> ... Server mapped byte ranges ... mainly for legacy formats
14:31:56 <raphael> ... Server triggered redirect ... for the track and name dimensions
14:32:11 <raphael> ... further, for the space dimension, no range request is issued
14:32:25 <raphael> ... I suggest to add this in the intro of Section 5
14:32:57 <raphael> ACTION: raphael to add an intro paragraph in the section 5 to explain which recipes is useful for which dimension
14:32:57 <trackbot> Sorry, couldn't find user - raphael
14:33:02 <raphael> ACTION: troncy to add an intro paragraph in the section 5 to explain which recipes is useful for which dimension
14:33:02 <trackbot> 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].
14:33:12 <raphael> [coffee break]
14:33:16 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/01-mediafrag-minutes.html raphael
14:45:38 <Zakim> -??P9
14:45:53 <foolip> let me know when you start again
14:46:27 <homata> homata has joined #mediafrag
14:55:12 <pchampin> pchampin has joined #mediafrag
15:05:00 <Zakim> disconnecting the lone participant, Roseraie_1, in IA_MFWG(TPAC)3:00AM
15:05:02 <Zakim> IA_MFWG(TPAC)3:00AM has ended
15:05:04 <Zakim> Attendees were Roseraie_1, Philip
15:05:38 <raphael> [back from Coffee break]
15:06:10 <homata> homata has joined #mediafrag
15:06:39 <raphael> Raphael: useful coffee break
15:06:51 <foolip> Should I call in?
15:07:03 <foolip> What's next?
15:07:19 <raphael> .. 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
15:07:29 <raphael> s/improivement/improvement
15:07:45 <raphael> zakim, dial Roseraie_1
15:07:45 <Zakim> sorry, raphael, I don't know what conference this is
15:08:00 <raphael> zakim, this is  IA_MFWG(TPAC)3:00AM 
15:08:00 <Zakim> sorry, raphael, I do not see a conference named 'IA_MFWG(TPAC)3:00AM' in progress or scheduled at this time
15:08:05 <raphael> zakim, this will be IA_MFWG(TPAC)3:00AM 
15:08:05 <Zakim> I do not see a conference matching that name scheduled within the next hour, raphael
15:08:12 <raphael> zakim, dial Roseraie_1
15:08:14 <Zakim> sorry, raphael, I don't know what conference this is
15:08:34 <raphael> zakim, this was IA_MFWG(TPAC)3:00AM
15:08:34 <Zakim> I don't understand 'this was IA_MFWG(TPAC)3:00AM', raphael
15:08:40 <raphael> zakim, this is IA_MFWG(TPAC)3:00AM
15:08:40 <Zakim> sorry, raphael, I do not see a conference named 'IA_MFWG(TPAC)3:00AM' in progress or scheduled at this time
15:08:47 <raphael> zakim, this will be IA_MFWG(TPAC)3:00AM
15:08:47 <Zakim> I do not see a conference matching that name scheduled within the next hour, raphael
15:09:40 <francois> zakim, this will be IA_MFWG
15:09:40 <Zakim> I do not see a conference matching that name scheduled within the next hour, francois
15:09:56 <francois> zakim, what conferences?
15:09:56 <Zakim> I see Team_(forms)13:00Z, T&S_XMLSEC(TPAC)3:00AM, XML_QueryWG(XQUERY)3:30AM, WAI_EOWG(EOWG)3:30AM, WAI_PFWG(WAIPF)3:00AM active
15:09:58 <Zakim> also scheduled at this time are Team_SysWeb()10:00AM, SW_HCLS(BioRDF)11:00AM, IA_WebApps(TPAC)4:00AM, MM_MMI()11:00AM
15:10:27 <francois> zakim, room for 3?
15:10:28 <Zakim> ok, francois; conference Team_(mediafrag)15:10Z scheduled with code 26631 (CONF1) for 60 minutes until 1610Z
15:10:34 <sgondo> sgondo has joined #mediafrag
15:10:43 <raphael> zakim, dial  Team_(mediafrag)15:10Z
15:10:43 <Zakim> I am sorry, raphael; I do not know a number for Team_(mediafrag)15:10Z
15:11:20 <raphael> zakim, dial Roseraie_1
15:11:20 <Zakim> ok, raphael; the call is being made
15:11:21 <Zakim> Team_(mediafrag)15:10Z has now started
15:11:22 <hidetaka> hidetaka has joined #mediafrag
15:11:22 <Zakim> +Roseraie_1
15:12:16 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/01-mediafrag-minutes.html raphael
15:12:54 <raphael> Raphael: further, after talking with other browser vendors, I will ask feedback from Chris Double (Mozilla), Eric Carlson (Apple) and Frank Olivier (Microsoft)
15:13:12 <Zakim> +??P1
15:13:15 <raphael> ... that all deal with the video elements in their browsers
15:14:37 <foolip> And what about Chrome developers?
15:14:54 <foolip> will search mail
15:15:12 <Seung-Jae> Seung-Jae has joined #mediafrag
15:16:38 <raphael> Raphael: I would like we discuss about the name dimension
15:16:53 <raphael> Davy: we see the name dimension as more general that what media containers could do
15:17:00 <raphael> ... but we have no implementation yet
15:19:11 <raphael> Philip: name dimension is really dependent on container formats
15:19:27 <raphael> ... we have chapter names in WebM (mkv)
15:19:34 <raphael> ... we have cue points in MP4
15:23:56 <foolip> Sorry, I can't find the Chrome developer's name...
15:24:11 <raphael> I will try to find out with corridor discussion this week
15:27:16 <raphael> Jack: perhaps this is tightly correlated to the extensibility discussion we have to do
15:33:59 <raphael> Jack asked frankly, if anyone feels bad in removing "id" dimension from the spec?
15:34:18 <raphael> Philip: no strong opinion about it, if not implemented, it should be out of the spec as a general principle
15:34:48 <raphael> Raphael: I like to have this feature in, but I'm aware we need implementation for this
15:34:50 <Seung-Jae> Seung-Jae has left #mediafrag
15:35:13 <raphael> Davy: our plan is to not rely on the container format but on media annotations
15:35:54 <foolip> Will we have time to discuss ISSUE-19 today? If not, I'll be heading home.
15:36:03 <raphael> ISSUE-19?
15:36:03 <trackbot> ISSUE-19 -- Parsing must be defined normatively in the MF spec itself -- open
15:36:03 <trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/19
15:40:15 <foolip> <video src="video.webm#t=10">
15:41:18 <Zakim> -??P1
15:41:30 <raphael> zakim, drop Roseraie_1
15:41:30 <Zakim> Roseraie_1 is being disconnected
15:41:31 <Zakim> Team_(mediafrag)15:10Z has ended
15:41:31 <Zakim> Attendees were Roseraie_1
15:45:25 <francois> francois has joined #mediafrag
15:53:19 <davy> media fragment identifiers are only meaningful for media resources, not for HTML documents
15:55:45 <davy> 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
15:56:31 <davy> The media fragments spec will say nothing about the meaning of ....html#t=10,20
16:14:36 <raphael> Raphael: but a range request will still be issued from the browser
16:14:47 <raphael> ... if the hash is used on the address bar of the browser
16:14:51 <raphael> ... in all cases
16:16:12 <raphael> ACTION: 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)
16:16:12 <trackbot> 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].
16:18:32 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/01-mediafrag-minutes.html raphael
16:22:09 <raphael> Topic: 4. Summary
16:22:16 <raphael> Raphael: tomorrow will be about
16:22:22 <raphael> ... 1/ TAG debrief from Yves
16:22:31 <raphael> ... 2/ Extensibility issue with everyone
16:22:43 <raphael> ... 3/ Test Cases presentation from Davy
16:23:31 <raphael> ... 30 min + 2 hours + 1 hour
16:26:42 <raphael> [meeting adjourned]
16:31:20 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/01-mediafrag-minutes.html raphael
17:26:08 <pchampin> pchampin has joined #mediafrag
17:56:56 <Zakim> Zakim has left #mediafrag