08:10:02 RRSAgent has joined #mediafrag 08:10:02 logging to http://www.w3.org/2010/03/09-mediafrag-irc 08:10:04 RRSAgent, make logs public 08:10:04 Zakim has joined #mediafrag 08:10:06 Zakim, this will be IA_MFWG 08:10:06 ok, trackbot; I see IA_MFWG(F2F)2:00AM scheduled to start 70 minutes ago 08:10:07 Meeting: Media Fragments Working Group Teleconference 08:10:07 Date: 09 March 2010 08:10:26 Agenda: http://www.w3.org/2008/WebVideo/Fragments/wiki/FifthF2FAgenda 08:11:08 mhausenblas has joined #mediafrag 08:11:13 Present: Davy, Erik, Jack, Yves, Franck (observer), Raphael, Silvia (remote), Conrad (remote), Philip (remote), Michael (remote) 08:11:19 Chair: Erik, Raphael 08:12:26 I have made the request to generate http://www.w3.org/2010/03/09-mediafrag-minutes.html raphael 08:14:43 scribenick: raphael 08:14:48 Scribe: Raphael 08:15:54 Topic: 1. First day summary 08:17:49 Raphael: I would suggest to start today's agenda with 2 short discussion: 08:18:14 ... a) What should be the delimiter in the URI for specifying multiple tracks: comma or semi-colon 08:19:15 was it understood and found acceptable that whatever separator we use can then not be part of the track name, even if it's percent-encoded? 08:19:42 ... b) Whether we should revisit the delimiter in the URI for specifying the time dimension and use the dash instead of the comma 08:21:02 Philip, no, the separator could be used in a track (or id) name if it is percent-encoded 08:21:11 Why would you you prevent to use it? 08:21:50 Because percent-decoding happens before matching against each syntax 08:23:28 jackjansen has joined #mediafrag 08:23:33 I sent a rather long mail about layering just now, somewhat related. 08:25:32 FD has joined #mediafrag 08:25:32 Philip, the room agrees with what you just said ... there are 2 solutions 08:25:37 a) We quote :-) 08:25:49 erik has joined #mediafrag 08:26:02 b) We forbid multiple tracks selection for the 1.0 version, so there is no delim and no problem 08:26:05 basically, the only bulletproof solution is: don't use names :) 08:26:09 zakim, minutes? 08:26:09 I don't understand your question, jackjansen. 08:26:17 trackbot, minutes? 08:26:17 Sorry, jackjansen, I don't understand 'trackbot, minutes?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help 08:26:24 why was track=a&track=b not ok? 08:26:24 pointer 08:26:51 Philip, we will discuss this on the phone in 5 minutes, could you join? 08:27:27 wait a sec 08:27:34 Philip, track=a&track=b is not valid since any fragment with multiple occurrence of 't' or 'xywh' or 'track' or 'id' will be invalid 08:27:55 phone number? 08:28:00 zakim, code? 08:28:00 the conference code is 3724 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), raphael 08:28:09 Philip, hold on, phone in 5 minutes 08:28:15 ok 08:28:23 I have made the request to generate http://www.w3.org/2010/03/09-mediafrag-minutes.html raphael 08:28:32 raphael: we can just make multiple occurences of track valid, can't we? 08:28:36 IA_MFWG(F2F)2:00AM has now started 08:28:42 +WG_room 08:30:31 +mhausenblas 08:31:39 Philip, that would break for libraries that decode only the first of each name=value pairs 08:31:52 erik has joined #mediafrag 08:32:27 -WG_room 08:33:20 + +329331aaaa 08:33:22 jackjansen: yes, but so would t=1&t=2, which processing needs to handle (but it shouldn't be valid) 08:34:11 zakim, aaaa is WG-Room 08:34:11 +WG-Room; got it 08:34:29 Philip, t=1&t=2 is indeed invalid per our syntax 08:34:53 raphael: invalid, but the result of processing it the same as if t=2 was used 08:34:56 the problem is that if you have multiple occurences of key=value with the same key, is that some libraries just take the last one 08:35:37 yes, which is why there is a note in the spec warning about the issue 08:35:51 should I call in now? 08:35:52 what if somebody else decide that t=1&t=2 means something else? Like generate two streams, starting at different times? 08:35:59 somebody else, meaning out of our spec 08:36:35 we shouldn't define an uber-error-recovery mechanism that forbid all reuse and enhancements 08:36:36 Yves: they would simply be violating our spec 08:36:43 so this is not the same: in case of #t=10&t=20 ... invalid fragment, the complete resource is sent back 08:37:13 foolip, yes, so if you implement only mediafrag, you'll get all the data, if you implement their spec, you'll do the "right thing" 08:38:59 having country code troubles 08:39:23 zakim, code? 08:39:23 the conference code is 3724 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), silvia 08:40:08 +silvia 08:41:42 I thought we had already discussed this enough times 08:42:20 Philip, what did we already discuss enough? 08:42:56 zakim, mute me 08:42:56 silvia should now be muted 08:45:35 nope, dialing in gets me a busy tone or nothing at all 08:45:37 Philip, on the phone Silvia argues, based on section 2.2 of the URI draft, that all reserved characters are treated equally 08:46:02 what jack just explained was how I understood it 08:46:05 ... so #track=audio,video will work 08:46:17 we have the reserved characters exactly for the purpose of making sub-delimiters 08:46:30 raphael: tried +1 and +44 08:46:42 the percent-encoding should not happen on the complete content value, but only on the segmented values (after separating on sub-delimiters) 08:46:53 zakim, unmute me 08:46:53 silvia should no longer be muted 08:47:38 raphael: just tried it, no luck 08:48:08 Philip, Silvia just contradicts your previous statement, re: we will not be able to have a comma in a track name 08:48:32 we just need to make the parsing & %encoding different 08:49:04 we can make it work, but then we will also have to change how name-value processing works and make percent decoding happen later 08:49:15 Yes Philip 08:49:40 another incompatability with existing languages, just to be clear 08:50:46 if the argument against track=a&track=b is that it breaks existing tools, using a new separator does the same 08:51:10 are there other problems with track=a&track=b? 08:52:30 Philip, the WG_Room + Silvia thinks that using one of the subdelim as defined in URI spec is the right thing to do ... subdelim are made for that 08:53:08 ... so not breaking existing tools 08:53:37 raphael: sure, but is it worth introducing more incompatibilities? 08:54:08 name-value lists already provides a way to repeat the same name 08:55:18 Jack: as soon as there is a UTF-8 character, you will need to decode the string and re-encode the string according to RFC2047 08:56:13 ... so we don't need to have a correlation between what is in the URI and what ends-up in the HTPP headers 08:56:35 Silvia: yes, but in most of the case, there will be ASCII characters so we could ease implementers work 08:56:43 Jack: this is an invit for lazing coding 08:56:56 ... I agree with you with the practical case, but we are editing a spec 08:57:12 ... we should try to follow patterns set by other RFC spec 08:57:50 -mhausenblas 08:57:57 hu? 08:58:04 I dropped ... 08:58:25 Silvia: i would not object on that ... you have a point 08:58:27 +mhausenblas 08:59:09 zakim, mute me 08:59:09 silvia should now be muted 09:00:26 Raphael: should we stand with yesterday's resolution, i.e. keep the semi-colon as separator? 09:00:38 zakim, unmute me 09:00:38 silvia should no longer be muted 09:00:51 Jack: I have checked 2 cgi libraries and indeed, Philip is right, that makes in practice the use of ';' forbidden in track names 09:00:55 I disagree with using a separator 09:01:50 Yves is ok with multiple &track= 09:02:41 +[IPcaller] 09:03:07 zakim, +[IPcaller] is Philip 09:03:07 sorry, raphael, I do not recognize a party named '+[IPcaller]' 09:03:12 zakim, +[IPcaller] is foolip 09:03:12 sorry, raphael, I do not recognize a party named '+[IPcaller]' 09:03:20 zakim, IPcaller is foolip 09:03:20 +foolip; got it 09:03:35 zakim, mute me 09:03:35 silvia should now be muted 09:06:38 let's continue, enough time wasted on phones today :) 09:06:54 Proposal: a new resolution that contradicts yesterday's resolution. Multiple tracks selection will be possible using multiple occurrence of the keyword 'track' (e.g.: #track=audio&track=video) 09:07:07 +1 09:07:10 +1 09:07:11 +1 09:07:13 +42 09:07:19 +1 09:07:21 +1 09:07:27 s/42/1/ 09:07:29 :-) 09:07:34 +1 09:07:42 +1 09:07:54 RESOLUTION: a new resolution that contradicts yesterday's resolution. Multiple tracks selection will be possible using multiple occurrence of the keyword 'track' (e.g.: #track=audio&track=video) 09:08:02 perl..... brrr...... 09:08:47 is the delimiter controversial? 09:09:04 hihi 09:10:07 Raphael: we need to apply many changes in the whole document 09:11:41 Philip: I have also edited the spec 09:11:46 Raphael: please check in 09:11:54 breaking up too much right now 09:12:10 silvia: which bridge did you use? 09:12:24 no, there's no CVS web interface that I know of 09:12:36 ACTION: Yves to change the formal syntax to reflect that we don't need a subdelim for selecting multiple tracks but we allow multiple track= in the URI 09:12:36 Created ACTION-152 - Change the formal syntax to reflect that we don't need a subdelim for selecting multiple tracks but we allow multiple track= in the URI [on Yves Lafon - due 2010-03-16]. 09:13:02 ACTION: Raphael to review the complete document and check whether there are mroe references to uniqueness 09:13:02 Sorry, couldn't find user - Raphael 09:13:08 ACTION: troncy to review the complete document and check whether there are mroe references to uniqueness 09:13:08 Created ACTION-153 - Review the complete document and check whether there are mroe references to uniqueness [on Raphaël Troncy - due 2010-03-16]. 09:13:18 s/mroe/more 09:13:29 Yves: I will commit now, as it conflicts with the action you just got 09:14:34 Short dicussion: re-visiting the use of comma in definition of temporal definition in URI 09:14:42 ... Conrad proposed to use a dash 09:14:47 ... Rejected by all the group 09:15:05 ... it just introduces more problem, uri syntax is not correlated to header syntax anyway 09:15:12 why is the delimiter important? 09:15:19 Conrad, object formally if you're not satisfied with this answer 09:15:49 Topic: 2. HTTP headers discussion 09:17:24 Back to the other objection from Conrad, sent yesterday 09:17:35 ... the use of the Range headers when there is another unit than bytes 09:17:51 ... we miss so far in our discussion the fact that there is synthetic headers 09:18:00 rrsagent, draft minutes 09:18:00 I have made the request to generate http://www.w3.org/2010/03/09-mediafrag-minutes.html erik 09:18:18 ... see also: http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0084.html 09:18:56 Silvia, Philip: look at http://www.w3.org/2008/WebVideo/Fragments/wiki/MediaFragmentHeaders 09:19:14 zakim, unmute me 09:19:14 silvia should no longer be muted 09:19:42 raphael, I'm ok with not using a dash for start-end specification 09:20:55 Conrad, in the URL? 09:21:17 Conrad, are you ok with using a comma in the URL?, i.e. #t=10,20 09:22:58 committed some stuff, should make some of you cringe in pain ;) 09:23:59 raphael: except CVS is so terrible, when will we switch to git? 09:25:15 Silvia: is the Content-Range in other units purely descriptive? ... I would think so 09:25:34 http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0084.html 09:25:59 HTTP/1.1 206 blah 09:25:59 Content-Range: t:npt=10-20/60 09:25:59 Content-Range-Equivalent: bytes=16384-32768/65536 09:26:04 instead return: 09:26:20 HTTP/1.1 206 blah 09:26:20 Content-Range-Equivalent: t:npt=10-20/60 09:26:20 Content-Range: bytes=16384-32768/65536 09:26:57 Silvia: we are not sending 16 kB but 20 kB since they are also the synthetic headers 09:27:04 ... so your change is just wrong 09:27:50 raphael, yes i am ok with using a comma in the url 09:28:00 Jack: we want to stop old-fashioned try to cache fragments 09:28:11 Silvia: NO NO NO, we don't send synthetic headers 09:28:24 ... this is what we have discussed the last 1/2 year 09:28:34 ... we return in the fragment only the bytes of the original resources 09:29:19 i don't recall that we agreed not to send synthetic headers, obviously we need to supply both the headers required for decode ("synthetic") and the media data 09:29:19 Jack: for queries, we must have synthetic headers, it is OK, this is a new resource 09:29:38 if we use some form of referral to byte ranges for the media data, fine, but that is optional 09:29:56 that is a different issue to the overloading of Range though 09:30:09 Silvia: indeed, we haven't taken yet a formal resolution 09:30:17 Raphael: perhaps it is now time for :-) 09:30:53 ... so let's discuss whether there will be synthetic headers exchange in the case of fragments 09:31:19 i suggest that the response to a fragment url is a valid media file 09:31:24 s/file/stream 09:32:03 whether that does or doesn't require generating new headers, tailer data, intermediate data, referral files (.m3u, adaptive streaming etc.) or whatever is media-dependent 09:32:07 Conrad, does it mean to send synthetic headers? 09:32:32 raphael, for some media types like a raw ogg stream, sure; but that is not something to be specified by mfwg 09:33:07 here we can propose a mechanism for optimising that transfer, like an optional way of saying that some part of the representation can equivalently be gotten by a byte range retrieval 09:33:20 I have made the request to generate http://www.w3.org/2010/03/09-mediafrag-minutes.html raphael 09:34:08 silvia, you become unintelligeble 09:34:39 breaking up... 09:34:40 jack was talking about phone quality ;) 09:34:50 in short, Silvia is 100% right 09:35:26 -silvia 09:35:37 conrad: no, the response to a fragment is a byte range - no media file headers 09:35:41 Michael: I can't hear you guys anymore 09:35:46 only the response to a query needs to headers 09:36:01 Raphael: indeed, there is a contradiction between Silvia and Conrad's view 09:36:02 so where do you get the headers (required for decode) from? 09:36:09 -mhausenblas 09:36:17 Conrad, with another request 09:36:17 e.g. a Web browser has already set itself up for decoding a media file when it is asking for a later byte range 09:36:59 hm ... I can't get in. damn ... trying other line 09:37:00 in that case there is no new http header transaction to be specified anyway 09:37:08 it is just a client-side seek 09:37:31 -foolip 09:38:14 oh - just got a mail from admins. seems like they have to reboot out (VoIP-based) phone system ... will try again as soon as the system is up again 09:38:16 will try calling into another bridge when summoned the next time 09:39:17 thanks raphael but I really really want to dail back in ASAP 09:39:36 conrad: no, the idea of 5.2.2 is to make an improvement over 5.2.1: e.g. instead of having to do bisection search with Ogg over network, you get to simply ask the server for the right byte ranges by asking for the time range or track .. 09:40:37 all URI fragment requests have to be handled the same way - none will require re-retrieving artificial file headers 09:40:38 I agree with Silvia that it's unlikely any browser will implement these headers 09:40:44 if you have an index, there's just no need. 09:41:18 for old Ogg files without an index, it still makes sense 09:41:58 we will not ever have all Ogg files with index and thus this is a way to improve on the bisection search problem 09:41:58 yes, but that's probably not reason enough to spend resources on it, we'd just tell people to use footool to add an index 09:42:23 I of course only make guesses on behalf of Opera 09:42:42 silvia, sure, in the case of no server interaction that makes perfect sense 09:43:02 well, it was the original motiviation for section 5.2.2 - but it may not be relevant much longer (unless the video element starts supporting other such file formats) 09:43:26 bah! but there *is* server interaction! 09:43:51 Raphael: Silvia, Conrad and Philip, we are discussing in the room whether a fragment request should retrieve a playable resource (with synthetic headers) or just bytes from the original resource, or a multi-part reply 09:44:11 anyway - the situation for query is a different one and we can still use all of the above arguments to sort out the query case, which will indeed need to return a full media resource 09:44:44 raphael: the original resource, without a shadow of a doubt. 09:44:47 Yes, Silvia, we don't talk about query, since it is easy and we don't need to specify headers anyway ... it already works 09:45:40 Jack: synthetic headers gives us problem 09:46:01 if we introduce header retrieval into media fragments now, we have to also change the way in which 5.2.1 works - and that doesn't make sense, because that's how browser vendors right now work 09:46:02 ... I'm also more and more convinced that we should not sent them on the wire in the fragment case 09:46:17 not dealing with synthetic headers solves sooo many problems 09:46:45 if we introduce synthetic headers, we get a new media resource with a different start and end time - which will result in a different presentation 09:46:55 that should really be reserved for query only 09:47:04 indeed 09:47:49 it's the fundamental difference between fragments and queries: fragments === byte range requests, query === new resource 09:47:54 in that case we _never_ need anything else than byte ranges 09:48:07 silvia, the 5.2.1 case is different, it uses byte-ranges 09:48:14 and we always need 2 requests at minimum 09:48:17 other than in the case where the UA cannot resolve a time range to a byte range 09:48:21 but that doesn't invalidate the other points 09:48:45 no, Yves, the UA can send a request to the server for a time range and the server can reply with the appropriate byte range 09:48:50 that is what 5.2.2 expresses 09:49:09 no because it's not playable, so you need extra information beforehand 09:49:11 (or after) 09:49:15 5.2.2 and 5.2.3 also use byte ranges 09:49:29 silvia, so you expect 2 exchanges (for 522): one in bytes to get the header, then one in npt to get the video data. Correct? 09:49:31 but if you got the data before, you might be able to do the mapping yourself and ask for bytes directly 09:49:38 Yves, yes, it is playable: it assumes the UA already has all the information to do something useful with the byte range 09:49:47 just as is the case with any other retrieval action that uses byte ranges 09:50:05 jack: I am assuming the headers have already been received earlier 09:50:05 it's playable if you have a-priori information about the data. 09:50:16 it not, then yes, you need to get the headers first 09:50:23 either you are mandating a specific container that have this characteristic, or you don't need this 09:50:27 only for OGG, actually - MPEG doesn't need that 09:50:51 Yves, with Ogg as it currently is, you cannot do the mapping yourself 09:50:55 sure it does, MPEG doesn't repeat the headers over and over does it? 09:51:05 at least not all versions 09:51:20 fix the container! 09:51:30 :-) 09:51:31 in any event: before spending lots of time trying to optimize away one network roundtrip, perhaps we should see if any implementor actually wants to solve this problem. 09:51:32 foolip: MPEG actually does repeat the headers over and over :) 09:51:35 Silvia, all newer formats have a header. So question is, do we do this work only for legacy formats? 09:51:49 (header: I mean one that includes enough info to seek) 09:52:03 Yves: we have fixed it and there is now a possibilty to put an Index into Ogg, which is why foolip said above that 5.2.2 will not be used very often 09:52:04 silvia: even MPEG-4? always? 09:52:16 5.2.2 is only a minimal improvement over 5.2.1 09:53:04 well, we've already done the work and it is a solution for any media format that has that problem, so I'd say we can safely leave it in the spec 09:53:33 OK 09:53:38 foolip: IIUC yes, MPEG-4 has a way to do that, but you'd better ask Eric 09:53:53 I'm trying to summarize where do we stand 09:54:13 I don't have a strong opinion, but would avoid spending time on it. 09:54:32 1. we need a decision that URI fragments always just retrieve a byte range and assume that the UA already knows how to decode that byte range 09:55:25 5.2.1: The UA is very clever, can do the mapping between seconds and bytes, send a Range request in bytes, almost no implementation is needed! 09:55:38 2. we need a decision if we want to remove 5.2.2 and 5.2.3 from the spec or leave it there for legacy formats 09:57:11 5.2.2: tiny optimiziation, the UA connot do the mapping, but there are still 2 requests, the first one, the UA got all the headers, the second one, the bytes of the data, the UA can play the file because of the first request with the headers, the Range request is expressed in seconds for example 09:57:47 except that getting the headers will only happen once and for all subsequence fragment requests it will only be one request 10:03:14 5.2.3: has actuallly 3 exchanges, the first is the same than for 5.2.2 where the UA has requested the headers to be able to play the resource later on 10:03:48 OK, so go back to 2 points from Silvia 10:03:49 5.2.3 does what 5.2.2 does, but in a proxy-cachable manner 10:04:40 my interpretation is that byte ranges should be good enough for anyone provided the container is ok, for clients that will do 2 or more requests to get the data 10:04:44 i.e. the UA asks the server to send it the byte-range mapping and then does 5.2.1 10:04:45 but it has latency issues 10:05:06 the goal of having time ranges is to do everything in one exchange, to reduce latency 10:05:22 5.2.3 Proxy cacheable Server mapped byte ranges 10:05:27 is actually doing 3 exchanges 10:05:30 (but it's fine!) 10:05:39 indeed, and this is why 5.2.1 will realistically be all that UAs do 10:06:02 Jack: Silvia is right, 5.2.2 is just for legacy formats, it has no value overall 10:06:05 but there is optimisation along a different line for those that do 5.2.2: get proxy cachable requsts 10:06:16 ... we can keep it just mentionning that this is for legacy formats 10:06:27 it already says so IIRC 10:06:29 note that even when asked for bytes only, we can send a header to indicate the mapping to time ranges 10:06:34 jut not in these words 10:07:17 Yves, we could, but the UA already knows that, so why would be bother destroying cachability in this way? 10:07:25 silvia, your solution for 5.2.2 is just helping bad container formats 10:07:32 indeed :) 10:08:27 for files that have been recorded live, getting an index is an extra effort 10:08:38 and thus, some files will never have that header 10:08:44 and I think that applies to both Ogg and MPEG 10:08:54 so it's not actually as unrealistic as one might think 10:09:54 Raphael: Silvia, perhaps we should document the VERY first request for 5.2.2 and 5.2.3, the one where the UA got the headers of the media 10:10:11 Silvia, I agree, an action for you ? 10:10:17 I don't give it to you if do it now :-) 10:10:27 can you do a live edits to add this note? 10:10:30 agree on both 10:10:36 happy to make the change 10:10:44 ok, for the note, it is 2 min work 10:10:51 will do both now 10:11:01 for the other, it will require more work ... including changing the figures, you want a formal action? 10:11:19 I don't think we need to add a figure 10:11:28 those two retrieval actions are independent of each other 10:11:54 they may need to occur together, but if the UA already has the header, it will not need to do that first retrieval action 10:12:22 so, I can just add a description of it and refer to 5.2.1 with some byte range from 0 10:12:32 foolip: what byte range do you typically load for Ogg files? 10:13:47 Silvia, Yves objects on one thing (please listen) 10:13:51 silvia: start from the beginning and load until we need to seek to the end, where we get 8500 bytes, then back to wherever data is needed next 10:14:17 Yves considers that 5.2.2 is useless and should be removed ... for legacy formats, 5.2.3 should be used 10:14:28 ... BUT, he sketchs another 5.2.2 10:14:36 silvia: yes 10:14:59 I know, we have an open bug for it :) 10:15:04 ... which is the original intention of the 2-ways handshake, where all data is sent 10:15:29 Jack is drawing on the board, pictures will come soon 10:18:07 zakim, code? 10:18:07 the conference code is 3724 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), silvia 10:18:46 +silvia 10:18:55 zakim, mute me 10:18:55 silvia should now be muted 10:19:22 -silvia 10:19:56 rrsagent, draft minutes 10:19:56 I have made the request to generate http://www.w3.org/2010/03/09-mediafrag-minutes.html erik 10:23:07 Silvia, in 5.2.1, there is also this VERY first request to do, where the UA got the headers, so more things to add in the spec 10:23:22 ... do you think you can do that in the next hour? or would you need more time? 10:23:51 I wonder about the result on 5.2.2 10:24:01 I didn't make changes because I was waiting for Yves' proposal 10:24:21 but maybe it's another proposal altogether and needs a 5.2.4 ? 10:24:44 I will start working on 5.2.1 now 10:25:05 5.2.2 as it is is useless, for legacy container 5.2.3 should be used 10:25:10 does the spec need to go into detail about what byte ranges may or may not be needed? it can't be normative anyway 10:25:11 (server side mapping) 10:26:07 Sylvia, indeed, don't change 5.2.2 since Yves and Jack come with a new nice proposal 10:28:11 I've adapted 5.2.1 10:28:18 and committed :) 10:28:28 Silvia, the note for legacy format should go in the section 5.2.3, phrased slightly differently, where we said, legacy formats that cannot do the mappping (give examples, such as the old ogg file) need to use 5.2.3 description 10:29:08 it's actually irrelevant to the spec where the UA gets the information from how to map the fragment to byte ranges - it could come from previously stored information or a previous retrieval action or from guessing - it doesn't matter 10:29:19 so I just made that first paragraph more concrete 10:30:18 raphael: I disagree that 5.2.3 is a requirement for legacy formats 10:30:28 it is a possibility to use this, but not a necessity 10:30:38 ok silvia 10:30:38 and also, you need a collaborating server, which will be hard to get 10:30:51 did you change the figures in 5.2.1 ? we are mainly looking at that :-) 10:31:07 no, as I said: they don't need changing 10:31:16 it doesn't matter where the information for the mapping comes from 10:31:23 it's up to the UA to sort this out 10:31:44 it could come from a index file that it was given by a third party server or anything else 10:31:51 it could even just be guessing 10:32:08 so, there is not necessarily an additional retrieval action 10:33:08 also, 3.2 already describes different means of how the UA could get to that information 10:33:42 Silvia, the WG room thinks that it will be much clearer to add this information, and perhaps mark it specifically as header retrieval 10:34:04 ... the proof being the misunderstanding of some members beforehand 10:34:07 there is no header retrieval for MPEG 10:34:45 some formats just have an index somewhere 10:34:51 Philip: why did you remove the production of Segment? this is the hat on top of query and fragment! 10:34:59 we have to describe the most general case, not just Ogg 10:35:38 silvia, technically correct., but you will do an initial exchange 10:35:49 not necessarily 10:36:11 well you need to know the compression level 10:36:13 Exatly Silvia, that's why we think we should document how the information to be able to play the file has been obtained 10:36:14 Silvai, and more generally I would like to concentrate on modern formats. 10:36:26 I, the UA, may have received the information from a third party of how to map time to byte ranges 10:36:38 it doesn't need to come through an extra interaction with this particular media resource 10:36:42 so technically you request some bytes at the beginning, not file headers, just do have infrmation for doing the mapping 10:36:44 yes, but for clarity, we should write that down somewhere in the spec 10:36:59 and you could write that this info has been obtained from a third-party 10:37:04 Yves: I do that for Ogg, yes 10:37:08 but not for MPEG 10:37:30 I wrote that the UA has somehow obtained this information and I wrote an example 10:37:52 I don't think we need to add a graphic for it since, there are so many cases 10:37:54 Silvia, how do you guess where to do your first seek, for (say) t=10,20? 10:37:58 Silvia, you agree that even in the case of MPEG, you need to know the compressiojn rate 10:38:17 yep, could have been given to me in the HTML markup 10:38:40 hmm, don't see that as a common use (but correct me if I'm wrong) 10:38:55 jackjansen: bisection search, first guess is based on something like total size (bytes) amd total duration (seconds) 10:39:00 there are proposals to put such information into the HTML spec 10:40:38 if we write into the spec that a first retrieval action has to retrieve the resource headers, interpret them, and thus extract the mapping of fragment addressing to byte range, then we are severely restricting how this spec can be used 10:41:06 we are prescribing something that people will need to ignore to actually make it work 10:41:07 hehe, I would simply ignore the spec if it said something like that 10:41:23