IRC log of mediafrag on 2010-03-09

Timestamps are in UTC.

08:10:02 [RRSAgent]
RRSAgent has joined #mediafrag
08:10:02 [RRSAgent]
logging to
08:10:04 [trackbot]
RRSAgent, make logs public
08:10:04 [Zakim]
Zakim has joined #mediafrag
08:10:06 [trackbot]
Zakim, this will be IA_MFWG
08:10:06 [Zakim]
ok, trackbot; I see IA_MFWG(F2F)2:00AM scheduled to start 70 minutes ago
08:10:07 [trackbot]
Meeting: Media Fragments Working Group Teleconference
08:10:07 [trackbot]
Date: 09 March 2010
08:10:26 [raphael]
08:11:08 [mhausenblas]
mhausenblas has joined #mediafrag
08:11:13 [raphael]
Present: Davy, Erik, Jack, Yves, Franck (observer), Raphael, Silvia (remote), Conrad (remote), Philip (remote), Michael (remote)
08:11:19 [raphael]
Chair: Erik, Raphael
08:12:26 [RRSAgent]
I have made the request to generate raphael
08:14:43 [raphael]
scribenick: raphael
08:14:48 [raphael]
Scribe: Raphael
08:15:54 [raphael]
Topic: 1. First day summary
08:17:49 [raphael]
Raphael: I would suggest to start today's agenda with 2 short discussion:
08:18:14 [raphael]
... a) What should be the delimiter in the URI for specifying multiple tracks: comma or semi-colon
08:19:15 [foolip]
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 [raphael]
... 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 [raphael]
Philip, no, the separator could be used in a track (or id) name if it is percent-encoded
08:21:11 [raphael]
Why would you you prevent to use it?
08:21:50 [foolip]
Because percent-decoding happens before matching against each syntax
08:23:28 [jackjansen]
jackjansen has joined #mediafrag
08:23:33 [foolip]
I sent a rather long mail about layering just now, somewhat related.
08:25:32 [FD]
FD has joined #mediafrag
08:25:32 [raphael]
Philip, the room agrees with what you just said ... there are 2 solutions
08:25:37 [raphael]
a) We quote :-)
08:25:49 [erik]
erik has joined #mediafrag
08:26:02 [raphael]
b) We forbid multiple tracks selection for the 1.0 version, so there is no delim and no problem
08:26:05 [Yves]
basically, the only bulletproof solution is: don't use names :)
08:26:09 [jackjansen]
zakim, minutes?
08:26:09 [Zakim]
I don't understand your question, jackjansen.
08:26:17 [jackjansen]
trackbot, minutes?
08:26:17 [trackbot]
Sorry, jackjansen, I don't understand 'trackbot, minutes?'. Please refer to for help
08:26:24 [foolip]
why was track=a&track=b not ok?
08:26:24 [jackjansen]
08:26:51 [raphael]
Philip, we will discuss this on the phone in 5 minutes, could you join?
08:27:27 [foolip]
wait a sec
08:27:34 [raphael]
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 [foolip]
phone number?
08:28:00 [raphael]
zakim, code?
08:28:00 [Zakim]
the conference code is 3724 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), raphael
08:28:09 [raphael]
Philip, hold on, phone in 5 minutes
08:28:15 [foolip]
08:28:23 [RRSAgent]
I have made the request to generate raphael
08:28:32 [foolip]
raphael: we can just make multiple occurences of track valid, can't we?
08:28:36 [Zakim]
IA_MFWG(F2F)2:00AM has now started
08:28:42 [Zakim]
08:30:31 [Zakim]
08:31:39 [jackjansen]
Philip, that would break for libraries that decode only the first of each name=value pairs
08:31:52 [erik]
erik has joined #mediafrag
08:32:27 [Zakim]
08:33:20 [Zakim]
+ +329331aaaa
08:33:22 [foolip]
jackjansen: yes, but so would t=1&t=2, which processing needs to handle (but it shouldn't be valid)
08:34:11 [raphael]
zakim, aaaa is WG-Room
08:34:11 [Zakim]
+WG-Room; got it
08:34:29 [raphael]
Philip, t=1&t=2 is indeed invalid per our syntax
08:34:53 [foolip]
raphael: invalid, but the result of processing it the same as if t=2 was used
08:34:56 [raphael]
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 [foolip]
yes, which is why there is a note in the spec warning about the issue
08:35:51 [foolip]
should I call in now?
08:35:52 [Yves]
what if somebody else decide that t=1&t=2 means something else? Like generate two streams, starting at different times?
08:35:59 [Yves]
somebody else, meaning out of our spec
08:36:35 [Yves]
we shouldn't define an uber-error-recovery mechanism that forbid all reuse and enhancements
08:36:36 [foolip]
Yves: they would simply be violating our spec
08:36:43 [raphael]
so this is not the same: in case of #t=10&t=20 ... invalid fragment, the complete resource is sent back
08:37:13 [Yves]
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 [foolip]
having country code troubles
08:39:23 [silvia]
zakim, code?
08:39:23 [Zakim]
the conference code is 3724 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), silvia
08:40:08 [Zakim]
08:41:42 [foolip]
I thought we had already discussed this enough times
08:42:20 [raphael]
Philip, what did we already discuss enough?
08:42:56 [silvia]
zakim, mute me
08:42:56 [Zakim]
silvia should now be muted
08:45:35 [foolip]
nope, dialing in gets me a busy tone or nothing at all
08:45:37 [raphael]
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 [silvia]
what jack just explained was how I understood it
08:46:05 [raphael]
... so #track=audio,video will work
08:46:17 [silvia]
we have the reserved characters exactly for the purpose of making sub-delimiters
08:46:30 [foolip]
raphael: tried +1 and +44
08:46:42 [silvia]
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 [silvia]
zakim, unmute me
08:46:53 [Zakim]
silvia should no longer be muted
08:47:38 [foolip]
raphael: just tried it, no luck
08:48:08 [raphael]
Philip, Silvia just contradicts your previous statement, re: we will not be able to have a comma in a track name
08:48:32 [silvia]
we just need to make the parsing & %encoding different
08:49:04 [foolip]
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 [raphael]
Yes Philip
08:49:40 [foolip]
another incompatability with existing languages, just to be clear
08:50:46 [foolip]
if the argument against track=a&track=b is that it breaks existing tools, using a new separator does the same
08:51:10 [foolip]
are there other problems with track=a&track=b?
08:52:30 [raphael]
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 [raphael]
... so not breaking existing tools
08:53:37 [foolip]
raphael: sure, but is it worth introducing more incompatibilities?
08:54:08 [foolip]
name-value lists already provides a way to repeat the same name
08:55:18 [raphael]
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 [raphael]
... 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 [raphael]
Silvia: yes, but in most of the case, there will be ASCII characters so we could ease implementers work
08:56:43 [raphael]
Jack: this is an invit for lazing coding
08:56:56 [raphael]
... I agree with you with the practical case, but we are editing a spec
08:57:12 [raphael]
... we should try to follow patterns set by other RFC spec
08:57:50 [Zakim]
08:57:57 [mhausenblas]
08:58:04 [mhausenblas]
I dropped ...
08:58:25 [raphael]
Silvia: i would not object on that ... you have a point
08:58:27 [Zakim]
08:59:09 [silvia]
zakim, mute me
08:59:09 [Zakim]
silvia should now be muted
09:00:26 [raphael]
Raphael: should we stand with yesterday's resolution, i.e. keep the semi-colon as separator?
09:00:38 [silvia]
zakim, unmute me
09:00:38 [Zakim]
silvia should no longer be muted
09:00:51 [raphael]
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 [foolip]
I disagree with using a separator
09:01:50 [Yves]
Yves is ok with multiple &track=
09:02:41 [Zakim]
09:03:07 [raphael]
zakim, +[IPcaller] is Philip
09:03:07 [Zakim]
sorry, raphael, I do not recognize a party named '+[IPcaller]'
09:03:12 [raphael]
zakim, +[IPcaller] is foolip
09:03:12 [Zakim]
sorry, raphael, I do not recognize a party named '+[IPcaller]'
09:03:20 [raphael]
zakim, IPcaller is foolip
09:03:20 [Zakim]
+foolip; got it
09:03:35 [silvia]
zakim, mute me
09:03:35 [Zakim]
silvia should now be muted
09:06:38 [foolip]
let's continue, enough time wasted on phones today :)
09:06:54 [raphael]
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 [jackjansen]
09:07:10 [raphael]
09:07:11 [Yves]
09:07:13 [foolip]
09:07:19 [mhausenblas]
09:07:21 [davy]
09:07:27 [jackjansen]
09:07:29 [jackjansen]
09:07:34 [erik]
09:07:42 [silvia]
09:07:54 [raphael]
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 [jackjansen]
perl..... brrr......
09:08:47 [foolip]
is the delimiter controversial?
09:09:04 [jackjansen]
09:10:07 [raphael]
Raphael: we need to apply many changes in the whole document
09:11:41 [raphael]
Philip: I have also edited the spec
09:11:46 [raphael]
Raphael: please check in
09:11:54 [foolip]
breaking up too much right now
09:12:10 [foolip]
silvia: which bridge did you use?
09:12:24 [foolip]
no, there's no CVS web interface that I know of
09:12:36 [raphael]
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 [trackbot]
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 [raphael]
ACTION: Raphael to review the complete document and check whether there are mroe references to uniqueness
09:13:02 [trackbot]
Sorry, couldn't find user - Raphael
09:13:08 [raphael]
ACTION: troncy to review the complete document and check whether there are mroe references to uniqueness
09:13:08 [trackbot]
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 [raphael]
09:13:29 [foolip]
Yves: I will commit now, as it conflicts with the action you just got
09:14:34 [raphael]
Short dicussion: re-visiting the use of comma in definition of temporal definition in URI
09:14:42 [raphael]
... Conrad proposed to use a dash
09:14:47 [raphael]
... Rejected by all the group
09:15:05 [raphael]
... it just introduces more problem, uri syntax is not correlated to header syntax anyway
09:15:12 [foolip]
why is the delimiter important?
09:15:19 [raphael]
Conrad, object formally if you're not satisfied with this answer
09:15:49 [raphael]
Topic: 2. HTTP headers discussion
09:17:24 [raphael]
Back to the other objection from Conrad, sent yesterday
09:17:35 [raphael]
... the use of the Range headers when there is another unit than bytes
09:17:51 [raphael]
... we miss so far in our discussion the fact that there is synthetic headers
09:18:00 [erik]
rrsagent, draft minutes
09:18:00 [RRSAgent]
I have made the request to generate erik
09:18:18 [raphael]
... see also:
09:18:56 [raphael]
Silvia, Philip: look at
09:19:14 [silvia]
zakim, unmute me
09:19:14 [Zakim]
silvia should no longer be muted
09:19:42 [conrad]
raphael, I'm ok with not using a dash for start-end specification
09:20:55 [raphael]
Conrad, in the URL?
09:21:17 [raphael]
Conrad, are you ok with using a comma in the URL?, i.e. #t=10,20
09:22:58 [foolip]
committed some stuff, should make some of you cringe in pain ;)
09:23:59 [foolip]
raphael: except CVS is so terrible, when will we switch to git?
09:25:15 [raphael]
Silvia: is the Content-Range in other units purely descriptive? ... I would think so
09:25:34 [Yves]
09:25:59 [silvia]
HTTP/1.1 206 blah
09:25:59 [silvia]
Content-Range: t:npt=10-20/60
09:25:59 [silvia]
Content-Range-Equivalent: bytes=16384-32768/65536
09:26:04 [silvia]
instead return:
09:26:20 [silvia]
HTTP/1.1 206 blah
09:26:20 [silvia]
Content-Range-Equivalent: t:npt=10-20/60
09:26:20 [silvia]
Content-Range: bytes=16384-32768/65536
09:26:57 [raphael]
Silvia: we are not sending 16 kB but 20 kB since they are also the synthetic headers
09:27:04 [raphael]
... so your change is just wrong
09:27:50 [conrad]
raphael, yes i am ok with using a comma in the url
09:28:00 [raphael]
Jack: we want to stop old-fashioned try to cache fragments
09:28:11 [raphael]
Silvia: NO NO NO, we don't send synthetic headers
09:28:24 [raphael]
... this is what we have discussed the last 1/2 year
09:28:34 [raphael]
... we return in the fragment only the bytes of the original resources
09:29:19 [conrad]
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 [raphael]
Jack: for queries, we must have synthetic headers, it is OK, this is a new resource
09:29:38 [conrad]
if we use some form of referral to byte ranges for the media data, fine, but that is optional
09:29:56 [conrad]
that is a different issue to the overloading of Range though
09:30:09 [raphael]
Silvia: indeed, we haven't taken yet a formal resolution
09:30:17 [raphael]
Raphael: perhaps it is now time for :-)
09:30:53 [raphael]
... so let's discuss whether there will be synthetic headers exchange in the case of fragments
09:31:19 [conrad]
i suggest that the response to a fragment url is a valid media file
09:31:24 [conrad]
09:32:03 [conrad]
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 [raphael]
Conrad, does it mean to send synthetic headers?
09:32:32 [conrad]
raphael, for some media types like a raw ogg stream, sure; but that is not something to be specified by mfwg
09:33:07 [conrad]
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 [RRSAgent]
I have made the request to generate raphael
09:34:08 [jackjansen]
silvia, you become unintelligeble
09:34:39 [foolip]
breaking up...
09:34:40 [Yves]
jack was talking about phone quality ;)
09:34:50 [foolip]
in short, Silvia is 100% right
09:35:26 [Zakim]
09:35:37 [silvia]
conrad: no, the response to a fragment is a byte range - no media file headers
09:35:41 [mhausenblas]
Michael: I can't hear you guys anymore
09:35:46 [silvia]
only the response to a query needs to headers
09:36:01 [raphael]
Raphael: indeed, there is a contradiction between Silvia and Conrad's view
09:36:02 [conrad]
so where do you get the headers (required for decode) from?
09:36:09 [Zakim]
09:36:17 [raphael]
Conrad, with another request
09:36:17 [silvia]
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 [mhausenblas]
hm ... I can't get in. damn ... trying other line
09:37:00 [conrad]
in that case there is no new http header transaction to be specified anyway
09:37:08 [conrad]
it is just a client-side seek
09:37:31 [Zakim]
09:38:14 [mhausenblas]
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 [foolip]
will try calling into another bridge when summoned the next time
09:39:17 [mhausenblas]
thanks raphael but I really really want to dail back in ASAP
09:39:36 [silvia]
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 [silvia]
all URI fragment requests have to be handled the same way - none will require re-retrieving artificial file headers
09:40:38 [foolip]
I agree with Silvia that it's unlikely any browser will implement these headers
09:40:44 [foolip]
if you have an index, there's just no need.
09:41:18 [silvia]
for old Ogg files without an index, it still makes sense
09:41:58 [silvia]
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 [foolip]
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 [foolip]
I of course only make guesses on behalf of Opera
09:42:42 [conrad]
silvia, sure, in the case of no server interaction that makes perfect sense
09:43:02 [silvia]
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 [silvia]
bah! but there *is* server interaction!
09:43:51 [raphael]
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 [silvia]
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 [foolip]
raphael: the original resource, without a shadow of a doubt.
09:44:47 [raphael]
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 [raphael]
Jack: synthetic headers gives us problem
09:46:01 [silvia]
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 [raphael]
... I'm also more and more convinced that we should not sent them on the wire in the fragment case
09:46:17 [silvia]
not dealing with synthetic headers solves sooo many problems
09:46:45 [silvia]
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 [silvia]
that should really be reserved for query only
09:47:04 [foolip]
09:47:49 [silvia]
it's the fundamental difference between fragments and queries: fragments === byte range requests, query === new resource
09:47:54 [Yves]
in that case we _never_ need anything else than byte ranges
09:48:07 [jackjansen]
silvia, the 5.2.1 case is different, it uses byte-ranges
09:48:14 [Yves]
and we always need 2 requests at minimum
09:48:17 [silvia]
other than in the case where the UA cannot resolve a time range to a byte range
09:48:21 [jackjansen]
but that doesn't invalidate the other points
09:48:45 [silvia]
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 [silvia]
that is what 5.2.2 expresses
09:49:09 [Yves]
no because it's not playable, so you need extra information beforehand
09:49:11 [Yves]
(or after)
09:49:15 [silvia]
5.2.2 and 5.2.3 also use byte ranges
09:49:29 [jackjansen]
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 [Yves]
but if you got the data before, you might be able to do the mapping yourself and ask for bytes directly
09:49:38 [silvia]
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 [silvia]
just as is the case with any other retrieval action that uses byte ranges
09:50:05 [silvia]
jack: I am assuming the headers have already been received earlier
09:50:05 [Yves]
it's playable if you have a-priori information about the data.
09:50:16 [silvia]
it not, then yes, you need to get the headers first
09:50:23 [Yves]
either you are mandating a specific container that have this characteristic, or you don't need this
09:50:27 [silvia]
only for OGG, actually - MPEG doesn't need that
09:50:51 [silvia]
Yves, with Ogg as it currently is, you cannot do the mapping yourself
09:50:55 [foolip]
sure it does, MPEG doesn't repeat the headers over and over does it?
09:51:05 [foolip]
at least not all versions
09:51:20 [Yves]
fix the container!
09:51:30 [raphael]
09:51:31 [foolip]
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 [silvia]
foolip: MPEG actually does repeat the headers over and over :)
09:51:35 [jackjansen]
Silvia, all newer formats have a header. So question is, do we do this work only for legacy formats?
09:51:49 [jackjansen]
(header: I mean one that includes enough info to seek)
09:52:03 [silvia]
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 [foolip]
silvia: even MPEG-4? always?
09:52:16 [silvia]
5.2.2 is only a minimal improvement over 5.2.1
09:53:04 [silvia]
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 [raphael]
09:53:38 [silvia]
foolip: IIUC yes, MPEG-4 has a way to do that, but you'd better ask Eric
09:53:53 [raphael]
I'm trying to summarize where do we stand
09:54:13 [foolip]
I don't have a strong opinion, but would avoid spending time on it.
09:54:32 [silvia]
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 [raphael]
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 [silvia]
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 [raphael]
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 [silvia]
except that getting the headers will only happen once and for all subsequence fragment requests it will only be one request
10:03:14 [raphael]
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 [raphael]
OK, so go back to 2 points from Silvia
10:03:49 [silvia]
5.2.3 does what 5.2.2 does, but in a proxy-cachable manner
10:04:40 [Yves]
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 [silvia]
i.e. the UA asks the server to send it the byte-range mapping and then does 5.2.1
10:04:45 [Yves]
but it has latency issues
10:05:06 [Yves]
the goal of having time ranges is to do everything in one exchange, to reduce latency
10:05:22 [Yves]
5.2.3 Proxy cacheable Server mapped byte ranges
10:05:27 [Yves]
is actually doing 3 exchanges
10:05:30 [Yves]
(but it's fine!)
10:05:39 [silvia]
indeed, and this is why 5.2.1 will realistically be all that UAs do
10:06:02 [raphael]
Jack: Silvia is right, 5.2.2 is just for legacy formats, it has no value overall
10:06:05 [silvia]
but there is optimisation along a different line for those that do 5.2.2: get proxy cachable requsts
10:06:16 [raphael]
... we can keep it just mentionning that this is for legacy formats
10:06:27 [silvia]
it already says so IIRC
10:06:29 [Yves]
note that even when asked for bytes only, we can send a header to indicate the mapping to time ranges
10:06:34 [silvia]
jut not in these words
10:07:17 [silvia]
Yves, we could, but the UA already knows that, so why would be bother destroying cachability in this way?
10:07:25 [Yves]
silvia, your solution for 5.2.2 is just helping bad container formats
10:07:32 [silvia]
indeed :)
10:08:27 [silvia]
for files that have been recorded live, getting an index is an extra effort
10:08:38 [silvia]
and thus, some files will never have that header
10:08:44 [silvia]
and I think that applies to both Ogg and MPEG
10:08:54 [silvia]
so it's not actually as unrealistic as one might think
10:09:54 [raphael]
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 [raphael]
Silvia, I agree, an action for you ?
10:10:17 [raphael]
I don't give it to you if do it now :-)
10:10:27 [raphael]
can you do a live edits to add this note?
10:10:30 [silvia]
agree on both
10:10:36 [silvia]
happy to make the change
10:10:44 [raphael]
ok, for the note, it is 2 min work
10:10:51 [silvia]
will do both now
10:11:01 [raphael]
for the other, it will require more work ... including changing the figures, you want a formal action?
10:11:19 [silvia]
I don't think we need to add a figure
10:11:28 [silvia]
those two retrieval actions are independent of each other
10:11:54 [silvia]
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 [silvia]
so, I can just add a description of it and refer to 5.2.1 with some byte range from 0
10:12:32 [silvia]
foolip: what byte range do you typically load for Ogg files?
10:13:47 [raphael]
Silvia, Yves objects on one thing (please listen)
10:13:51 [foolip]
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 [raphael]
Yves considers that 5.2.2 is useless and should be removed ... for legacy formats, 5.2.3 should be used
10:14:28 [raphael]
... BUT, he sketchs another 5.2.2
10:14:36 [foolip]
silvia: yes
10:14:59 [foolip]
I know, we have an open bug for it :)
10:15:04 [raphael]
... which is the original intention of the 2-ways handshake, where all data is sent
10:15:29 [raphael]
Jack is drawing on the board, pictures will come soon
10:18:07 [silvia]
zakim, code?
10:18:07 [Zakim]
the conference code is 3724 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), silvia
10:18:46 [Zakim]
10:18:55 [silvia]
zakim, mute me
10:18:55 [Zakim]
silvia should now be muted
10:19:22 [Zakim]
10:19:56 [erik]
rrsagent, draft minutes
10:19:56 [RRSAgent]
I have made the request to generate erik
10:23:07 [raphael]
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 [raphael]
... do you think you can do that in the next hour? or would you need more time?
10:23:51 [silvia]
I wonder about the result on 5.2.2
10:24:01 [silvia]
I didn't make changes because I was waiting for Yves' proposal
10:24:21 [silvia]
but maybe it's another proposal altogether and needs a 5.2.4 ?
10:24:44 [silvia]
I will start working on 5.2.1 now
10:25:05 [Yves]
5.2.2 as it is is useless, for legacy container 5.2.3 should be used
10:25:10 [foolip]
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 [Yves]
(server side mapping)
10:26:07 [raphael]
Sylvia, indeed, don't change 5.2.2 since Yves and Jack come with a new nice proposal
10:28:11 [silvia]
I've adapted 5.2.1
10:28:18 [silvia]
and committed :)
10:28:28 [raphael]
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 [silvia]
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 [silvia]
so I just made that first paragraph more concrete
10:30:18 [silvia]
raphael: I disagree that 5.2.3 is a requirement for legacy formats
10:30:28 [silvia]
it is a possibility to use this, but not a necessity
10:30:38 [raphael]
ok silvia
10:30:38 [silvia]
and also, you need a collaborating server, which will be hard to get
10:30:51 [raphael]
did you change the figures in 5.2.1 ? we are mainly looking at that :-)
10:31:07 [silvia]
no, as I said: they don't need changing
10:31:16 [silvia]
it doesn't matter where the information for the mapping comes from
10:31:23 [silvia]
it's up to the UA to sort this out
10:31:44 [silvia]
it could come from a index file that it was given by a third party server or anything else
10:31:51 [silvia]
it could even just be guessing
10:32:08 [silvia]
so, there is not necessarily an additional retrieval action
10:33:08 [silvia]
also, 3.2 already describes different means of how the UA could get to that information
10:33:42 [raphael]
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 [raphael]
... the proof being the misunderstanding of some members beforehand
10:34:07 [silvia]
there is no header retrieval for MPEG
10:34:45 [silvia]
some formats just have an index somewhere
10:34:51 [raphael]
Philip: why did you remove the production of Segment? this is the hat on top of query and fragment!
10:34:59 [silvia]
we have to describe the most general case, not just Ogg
10:35:38 [jackjansen]
silvia, technically correct., but you will do an initial exchange
10:35:49 [silvia]
not necessarily
10:36:11 [Yves]
well you need to know the compression level
10:36:13 [raphael]
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 [jackjansen]
Silvai, and more generally I would like to concentrate on modern formats.
10:36:26 [silvia]
I, the UA, may have received the information from a third party of how to map time to byte ranges
10:36:38 [silvia]
it doesn't need to come through an extra interaction with this particular media resource
10:36:42 [Yves]
so technically you request some bytes at the beginning, not file headers, just do have infrmation for doing the mapping
10:36:44 [raphael]
yes, but for clarity, we should write that down somewhere in the spec
10:36:59 [raphael]
and you could write that this info has been obtained from a third-party
10:37:04 [silvia]
Yves: I do that for Ogg, yes
10:37:08 [silvia]
but not for MPEG
10:37:30 [silvia]
I wrote that the UA has somehow obtained this information and I wrote an example
10:37:52 [silvia]
I don't think we need to add a graphic for it since, there are so many cases
10:37:54 [jackjansen]
Silvia, how do you guess where to do your first seek, for (say) t=10,20?
10:37:58 [raphael]
Silvia, you agree that even in the case of MPEG, you need to know the compressiojn rate
10:38:17 [silvia]
yep, could have been given to me in the HTML markup
10:38:40 [jackjansen]
hmm, don't see that as a common use (but correct me if I'm wrong)
10:38:55 [foolip]
jackjansen: bisection search, first guess is based on something like total size (bytes) amd total duration (seconds)
10:39:00 [silvia]
there are proposals to put such information into the HTML spec
10:40:38 [silvia]
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 [silvia]
we are prescribing something that people will need to ignore to actually make it work
10:41:07 [foolip]
hehe, I would simply ignore the spec if it said something like that
10:41:23 [silvia]
see :)
10:41:43 [foolip]
in fact I will ignore *anything* the spec says with regards to what requests to make, when to look in the cache, etc
10:41:46 [Yves]
there is an impact on latency
10:42:21 [silvia]
Yves, nothing that HTML5 doesn't already have
10:42:31 [Yves]
"I know just because it's a youtube URI that we have this format with this compression level" is a client-level hack that shouldn't be part of the discussion :)
10:42:32 [silvia]
there is no extra latency for a media fragment URI
10:42:33 [foolip]
yes, there is a latency problem, but I'd rather solve it with an index than by introducing special headers (which most headers won't understand)
10:42:42 [jackjansen]
Silvia, we are not saying it *has to* do this. We're saying it is probably going to be the common case.
10:42:55 [silvia]
which is what I described in words
10:43:07 [raphael]
WHich paragraph exactly Silvia?
10:43:08 [silvia]
no need for a graphic that would imply it always has to be done
10:43:16 [raphael]
First one in ?
10:43:31 [silvia]
10:43:32 [silvia]
As described in section, the most optimal case is a user agent that knows how to map media fragments to byte ranges. This is the case typically where a user agent has already downloaded those parts of a media resource that allow it to do or guess the mapping, e.g. headers or a resource, or an index of a resource.
10:44:51 [silvia]
Yves, if the UA already has a copy of the media resource in its local cache from a previous retrieval action days ago, it won't do another request either
10:44:55 [raphael]
OK, we seem to agree Silvia (you win a lot today)
10:45:04 [silvia]
it's hard work!
10:45:09 [silvia]
6 months!
10:45:16 [raphael]
... but in the existing figure, shows that the UA has already the headers
10:45:23 [raphael]
... we have a nice drawing on board
10:45:25 [jackjansen]
Suggestion: we add a little blob to the client timeline saying "header already available or not needed"
10:45:49 [silvia]
it's not a header
10:45:53 [jackjansen]
s/header/information needed for playback of the fragment
10:45:54 [silvia]
it's a mapping that is available
10:46:07 [silvia]
fragment to byte range mapping already available
10:46:25 [Yves]
we agree that header is bad usage of "enough information to do the mapping" :)
10:46:27 [raphael]
Yes Silvia, this is also what Davy who reads in your mind say
10:46:37 [silvia]
excellent :)
10:46:49 [silvia]
I trust Davy - he has implemented the bugger ;)
10:48:59 [raphael]
Jack, Yves: we change 5.2.2 to have just one round trip, similar to 5.2.1
10:49:07 [raphael]
... the request is epxressed in seconds for example
10:49:55 [raphael]
... the server sends back a playable resource, the only question is whether the data parts contains the original headers of the media (that need to be changed by the UA) or new synthetic headers made by the serve
10:50:16 [raphael]
... this is not cachable by legacy caches
10:50:22 [raphael]
... it might be by future caches
10:51:33 [raphael]
Philip, you reply to me only?
10:53:07 [silvia]
actually, your description of 5.2.2 is exactly what 5.2.2 is
10:53:15 [silvia]
no headers included
10:53:28 [silvia]
only one roundtrip, just like 5.2.1
10:53:54 [silvia]
why should that fragment request contain a header when 5.2.1 doesn't ?
10:54:22 [Yves]
it needs enough information to play the file
10:54:37 [silvia]
just like 5.2.1, it already has set up the pipeline
10:54:38 [Yves]
so in some cases it can have headers, in some other cases, not
10:55:06 [Yves]
no, in 5.2.2 you MUST NOT need to have the information magically before doing the request
10:55:10 [silvia]
life is so much easier if all fragment requests just map to byte range requests
10:55:20 [Yves]
but it's not needed!
10:55:24 [silvia]
why would 5.2.2 be different to 5.2.1 ?
10:55:27 [Yves]
you have byte ranges for that :)
10:55:42 [Yves]
5.2.2 as it stands has no value at all
10:55:59 [davy]
I agree with Yves
10:56:03 [Yves]
handling legacy formats is 5.2.3
10:56:19 [Yves]
handling legacy formats using server-based mapping is 5.2.3
10:56:19 [silvia]
no, it's also 5.2.2
10:56:27 [silvia]
5.2.3 is an improvement over 5.2.2
10:56:35 [silvia]
davy: why?
10:56:37 [Yves]
handling legacy content through byte ranges is 5.2.1
10:56:53 [silvia]
we haven't changed 5.2.2 yet
10:57:04 [raphael]
we are discussing it
10:57:14 [raphael]
you want to join on the phone ?
10:57:26 [silvia]
ok ...
10:57:27 [Yves]
but I agree that my vision of 5.2.2 might not be implemented _now_ (or ever :) ) but at least it has a value by reducing the latency and requiring only one exchange
10:57:31 [silvia]
zakim, code?
10:57:31 [Zakim]
the conference code is 3724 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), silvia
10:58:14 [Zakim]
11:01:52 [Yves],20
11:02:02 [Yves]
what do you know beforehand about this thing?
11:02:10 [Yves]
=> nothing apart that it may be a media fragment
11:02:23 [raphael]
Raphael: *new* 5.2.2 is different than 5.2.1 since we do not need to have the prior information of mapping the seconds to bytes or the original information to play the media
11:03:02 [raphael]
Silvia: it is another optimization
11:03:50 [raphael]
Yves: no, 5.2.3 has also (like 5.2.1) the same asumption than the UA has the information to play the media
11:04:12 [raphael]
... so 5.2.3 is the optimization of 5.2.1
11:04:21 [raphael]
... Range request always expressed in bytes
11:06:44 [raphael]
Jack: again, I see now the value of 5.2.2
11:07:07 [raphael]
... for example as follow on requests from the same media
11:07:25 [raphael]
... someone click on the timeline to request another segment, but does not request once more the headers
11:08:20 [raphael]
Raphael: I'm considerink asking Yves to write his new optimization in a section 5.2.4 and see later on if we can keep it or not
11:08:28 [silvia]
I would be happy if we introduced a request type that just gets us the setup information
11:08:46 [silvia]
then that plus the existing 5.2.2 would be what Yves is proposing now
11:09:14 [jackjansen]
silvia, that will require two roundtrips again.
11:09:56 [jackjansen]
silvia, I would suggest as 5.2.4 a request that gets us setup information PLUS data
11:10:01 [raphael]
Silvia, what this mean <silvia> I would be happy if we introduced a request type that just gets us the setup information ?
11:10:17 [Zakim]
11:10:46 [silvia]
jack is right: if we want to avoid a round trip, we need 5.2.4
11:11:25 [silvia]
incidentally, I am not sure how much browser vendors care about one additional round trip these days ;)
11:12:13 [silvia]
seeking on Ogg without an index typically requires several round trips (I've seen 7 and more) and that was bad, but once it was down to 3-4 it was acceptable
11:12:23 [raphael]
ACTION: Yves to add a section 5.2.4 describing his new optimization
11:12:24 [trackbot]
Created ACTION-154 - Add a section 5.2.4 describing his new optimization [on Yves Lafon - due 2010-03-16].
11:12:51 [silvia]
should I make some changes to 5.2.2 then?
11:12:57 [silvia]
as discussed before?
11:12:58 [raphael]
11:13:05 [raphael]
Raphael: Attempt summary
11:13:41 [raphael]
... 5.2.2 = request expressed in npt, anwers sent back in bytes + Content-Range equivalent
11:13:50 [raphael]
... mandatory
11:13:58 [raphael]
... or not :-)
11:14:24 [raphael]
... 5.2.3 = server-based bytes mapping, redirect involve, cachable
11:14:39 [silvia]
I think we can adapt the headers once Yves has done his 5.2.4 - we might want to harmonize
11:14:56 [Yves]
no need to adapt, we just reverse the use :)
11:15:17 [raphael]
... 5.2.4 = unlike the 3 other cases, we DON'T need to obtain first the mapping information (reduce latency), request expressed in npt, content-range expressed in the same unit, and content-range equivalent is in bytes
11:15:18 [raphael]
ok ?
11:15:57 [raphael]
... 5.2.4 is uncacheable for legacy caches, but might be cacheable with new ones
11:17:29 [silvia]
5.2.2 doesn't have the mapping either
11:17:59 [raphael]
Silvia, 5.2.2 has the mapping, otherwise, how the file is played since this information is not sent
11:18:23 [silvia]
no, there is a difference between having the fragment to byte mapping and having the decoding pipeline set up
11:18:33 [silvia]
if 5.2.2 had the mapping , it would be 5.2.1
11:18:49 [raphael]
Silvia, ok, i'm talking only about decoding pipeline set up
11:19:03 [raphael]
... I'm not talking about the mapping, different terminology
11:19:40 [silvia]
so, 5.2.4: unlike the other cases, doesn't have the decoding pipeline set up for the file yet and obtains with the request also the necessary background information (headers etc)
11:19:51 [raphael]
Yes silvia
11:20:10 [silvia]
this reduced the retrieval action by one round trip
11:20:14 [raphael]
yes silvia
11:20:23 [silvia]
now, let me consider the headers...
11:20:50 [silvia]
I think we need an extra header that says: send me the setup info, too
11:21:18 [silvia]
how else would the server know whether it has to just return the bytes or also the header bytes?
11:21:33 [silvia]
and … how does the UA know which bytes are header bytes and which are content bytes?
11:21:52 [jackjansen]
Feeling slightly confused for haviing to channel Silvia as well as myself:-)
11:22:25 [Yves]
like a 'transcode unit' flag
11:22:38 [Yves]
might be optional in range syntax
11:22:42 [raphael]
Raphael: indeed, we need to differenciate at the protocol level that 5.2.2 and 5.2.4 are different, most likely new headers?
11:23:05 [raphael]
... or different header syntax
11:23:17 [Yves]
Range: t:npt 10-20;convert
11:23:40 [silvia]
even if we ignored 5.2.2 and it use of HTTP header syntax: how would the server package the data in a way that the client knows it's just receiving the header info and some byte range later in the file?
11:23:48 [raphael]
... perhaps it is part of Yves's action when describing the new 5.2.4 making sure it does not collide with 5.2.2
11:24:48 [silvia]
we also need to remember that we have defined that media fragments provide for a subpart of the main resource and that e.g. a player would display the full timeline
11:24:51 [Yves]
silvia, through the CRE, or a new "here is data" paramter or header or whatever
11:25:05 [silvia]
so, the reply needs to signal to the UA exactly what data belongs to what
11:25:18 [silvia]
ok, I'll wait till you've written it
11:25:38 [silvia]
I just want to make sure we are on the same page in that this is NOT a new, shorter resource
11:25:41 [raphael]
Raphael: the WG thinks we should have a new name that Content-Range-Equivalent
11:25:43 [silvia]
that's what the query is for
11:25:45 [Yves]
the goal is not to send synthetic headed (well, metainformation needed to DTRT), but the orignal one
11:25:54 [Yves]
no, query is identifying new resources
11:26:06 [silvia]
ok, cool
11:26:19 [raphael]
Silvia, in 5.2.4 you will still have the context, the full timeline of the original media
11:26:24 [silvia]
this is where we may still need to discuss with Conrad ;)
11:26:37 [silvia]
I'm cool with it
11:27:54 [raphael]
OK, proposal for new header names?
11:28:10 [raphael]
Proposal: Range-Mapping ?
11:29:06 [raphael]
This new header will be used in 5.2.2 and 5.2.4
11:29:32 [raphael]
... in 5.2.2, Content-Ranges is expressed in bytes, and Range-Mapping in the unit of the original HTTP request
11:29:47 [raphael]
... in 5.2.4, this is exactly the other way around
11:30:13 [Yves]
s/other way around/other way round/
11:30:43 [raphael]
... that conflicts with Conrad's opinion who thinks we should not have the Range header used with another unit than bytes
11:31:11 [raphael]
Silvia, are we done with that?
11:31:23 [raphael]
... we think we can have lunck break, demo time, tc reviews now
11:31:25 [silvia]
are we calling it Range-Mapping?
11:31:31 [raphael]
are you against?
11:31:36 [raphael]
silence = approval :-)
11:31:40 [silvia]
I honestly don't care :)
11:31:43 [silvia]
but we didn't vote
11:32:09 [silvia]
Content-Range-Equivalent was also just signifying the mapping :)
11:32:22 [raphael]
Proposal: Call the only new introduced header 'Range-Mapping'
11:32:37 [conrad]
conrad has joined #mediafrag
11:33:01 [silvia]
ok, I will make the change
11:33:12 [raphael]
Proposal: call the only new introduced header: 'Content-Range-Mapping'
11:33:32 [erik]
rrsagent, draft minutes
11:33:32 [RRSAgent]
I have made the request to generate erik
11:34:31 [Yves]
11:34:35 [davy]
+1 for Content-Range-Mapping
11:34:40 [raphael]
+1 for Content-Range-Mapping
11:34:53 [erik]
+1 for 'Content-Range-mapping'
11:35:12 [silvia]
11:35:12 [Yves]
+1 for "Content-Range-mapping"
11:35:24 [jackjansen]
11:35:50 [raphael]
Jack: I may have opinion on the syntax of this new header
11:36:00 [raphael]
... I have no opinion on the name
11:37:36 [raphael]
RESOLUTION: (pending no objection from Conrad+Philippe) A new header named 'Content-Range-Mapping' will be introduced, used in sections 5.2.2 and 5.2.4 at least, which purpose is to expressed a mapping of a Content Range between 2 units (e.g. bytes and seconds)
11:39:04 [silvia]
note that 5.2.3 also uses Content-Range-Mapping to signal back to the UA which range the provided byte range maps to
11:39:21 [Yves]
even 5.2.1 may use CRM
11:39:25 [Yves]
as metainformation
11:39:56 [raphael]
Raphael: I agree with both remarks
11:39:58 [Yves]
but it reminds me that we should probably add a Cache-Control: no-store=" least, which purpose"
11:40:16 [Yves]
but it reminds me that we should probably add a Cache-Control: no-store="Content-Range-Mapping"
11:40:38 [silvia]
Yves: if we used CRM in 5.2.1, that would destroy cachability, right?
11:40:54 [Yves]
11:41:08 [Yves]
it's meta-information, nothing more
11:41:09 [silvia]
because of the extra header
11:41:13 [Yves]
and old caches will ignore it
11:41:23 [Yves]
no, see the cache-control directive ;)
11:41:36 [Yves]
"don't store the header"
11:42:41 [silvia]
ok, so is 5.2.2 cachable then?
11:43:38 [silvia]
I guess because we use the new fragment dimensions on the Range header, they are not?
11:43:41 [raphael]
Raphael: Conrad, I want to clarify one of your wrong asumption in one of your email for yesterday night
11:44:07 [raphael]
... you wrote, don't use comma separated value for selecting multiple tracks in the Content-Range headers
11:44:16 [raphael]
... but we can, since Content-Range header cannot be split
11:44:19 [Yves] (about the use of ',' in headers, and splitting)
11:44:28 [raphael]
... similar to Authorization
11:45:04 [raphael]
... so: "Content-Range: track audio1,audio2" will be valid
11:45:18 [raphael]
... hope it clarifies this objection you have
11:45:38 [raphael]
Yves: I will have some clarification about that from HTTPbis in our meeting in 2 weeks
11:45:58 [raphael]
... if this changes, I will warn you
11:46:47 [raphael]
Conrad, would you like an action to add your use case in the UC document?
11:48:21 [conrad]
raphael, yes
11:48:57 [raphael]
ACTION: davy to draw diagrams to include in the spec, similar to Yves's email, that shows which bytes from the headers and body of the media file are sent
11:48:57 [trackbot]
Created ACTION-155 - Draw diagrams to include in the spec, similar to Yves's email, that shows which bytes from the headers and body of the media file are sent [on Davy Van Deursen - due 2010-03-16].
11:49:19 [raphael]
ACTION: Conrad to add a "bandwidth conservation use case"
11:49:19 [trackbot]
Created ACTION-156 - Add a "bandwidth conservation use case" [on Conrad Parker - due 2010-03-16].
11:49:23 [conrad]
raphael, concerning the comma, i object more strongly to using Content-Range for that anyway :-)
11:49:58 [raphael]
Conrad, to use Content-range for track?
11:50:02 [conrad]
ie. i prefer a new header for time ranges etc., for which comma and header combining is allowed
11:50:37 [raphael]
Conrad, you want Range and Content-Range only used with the bytes unit?
11:50:38 [conrad]
raphael, to use Content-Range for bytes (no change to existing implementations) and to use a new header to advertise the time range of the representation
11:50:43 [conrad]
raphael, yes
11:50:53 [Yves]
206 requires a CR
11:51:05 [Yves]
11:51:55 [Yves]
(or a multipart byterange, that contains Content-Range headers)
11:52:40 [Yves]
in fact it's not even sure that we can do the range mapping in another header
11:52:52 [conrad]
generally i would like us to specify things so that the responses are cacheable with existing proxies, and i think that is well possible
11:53:12 [raphael]
Conrad, see section 5.2.3
11:53:14 [Yves]
yes, use byte ranges
11:54:11 [conrad]
ok, will review
11:59:11 [RRSAgent]
I have made the request to generate raphael
12:01:00 [tmichel]
tmichel has joined #mediafrag
12:01:56 [raphael]
ACTION: Silvia to propagate the changes in the spec document now we have the new header 'Content-Range-Mapping'
12:01:56 [trackbot]
Created ACTION-157 - Propagate the changes in the spec document now we have the new header 'Content-Range-Mapping' [on Silvia Pfeiffer - due 2010-03-16].
12:02:40 [raphael]
Jack: I'm warning everybody that it is likely we go in LC with the non-possibility of combining dimensions in a fragment URI
12:02:46 [RRSAgent]
I have made the request to generate raphael
12:03:35 [silvia]
my action has already been done and committed
12:03:35 [jackjansen]
s/in a fragement URI/in the HTTP protocol
12:03:51 [raphael]
close ACTION-157
12:03:51 [trackbot]
ACTION-157 Propagate the changes in the spec document now we have the new header 'Content-Range-Mapping' closed
12:03:54 [foolip]
raphael: why add them back?
12:05:11 [foolip]
we cannot define the syntax in one single layer unless we can come up with the syntax for expressing "any string that after percent-decoding and decoding UTF-8 is equal to the unicode string x"
12:06:22 [Yves]
12:06:40 [silvia]
Jack confused me :)
12:07:16 [raphael]
and then LC in June as expected
12:10:20 [foolip]
Yves: can you explain what changes you want to revert and why?
12:10:49 [foolip]
It is obvious that there is no common understanding of how things ought to work
12:11:46 [silvia]
maybe he has a syntax
12:12:31 [foolip]
that would be great, but I'd like to know or we'll just do this all over again later.
12:14:14 [Yves]
I want to have generic syntax + serialization ones
12:14:35 [Yves]
so for the URI serialization, it shouldn't contradict your algorithm
12:14:42 [foolip]
ok, what is the generic syntax?
12:15:06 [Yves]
basically, unencoded name=value
12:15:27 [foolip]
12:15:38 [Yves]
well, raw strings in utf-8
12:16:19 [Yves]
I'll do that tonight
12:16:26 [Yves]
probably by email first
12:17:25 [foolip]
on the URI fragment/query component level the data is percent-encoded bytes, how can a generic syntax be in terms of something unencoded?
12:19:56 [foolip]
is the mediafragment production I added not the generic syntax? even though we should perhaps rename it to something like namevalues to avoid confusion
12:20:58 [Yves]
URI fragment/query is part of the URI serialization
12:21:14 [Yves]
so it will be encoded
12:21:38 [foolip]
Yes, sure
12:21:50 [foolip]
but can that be expressed in declarative syntax?
12:22:40 [foolip]
I just want to know that there is actually some change and not just putting back the old syntax which doesn't match what we want implementations to match against.
12:26:40 [raphael]
Raphael: I suggest Yves send by email tonight what he intends to change to finalize the discussion
12:30:46 [raphael]
Topic: 3. Implementation Report
12:30:51 [RRSAgent]
I have made the request to generate raphael
12:31:03 [raphael]
Raphael: we will first start with a demo from Davy
12:33:10 [Zakim]
12:33:11 [Zakim]
IA_MFWG(F2F)2:00AM has ended
12:33:12 [Zakim]
Attendees were WG_room, mhausenblas, +329331aaaa, silvia, foolip, Raphael, Jack, Franck, Yves, Davy
12:33:48 [raphael]
Davy: I will first show slides
12:34:03 [raphael]
... URL to be provided soon
12:34:33 [raphael]
... room laughing at the title
12:34:56 [raphael]
..." Development of a flash player supporting media fragments: frustrations and results"
12:36:12 [raphael]
... requirements: flash media frgaments player, could be used in any browser supporting Flash, communication with Ninsuna or any Media Fragments compliant server
12:36:23 [raphael]
... we want to finally play the media fragments in the UA
12:36:51 [raphael]
... how to integrate Flash video player with Media Fragments servers, 3 possible solutions
12:37:02 [raphael]
12:37:37 [raphael]
... 1st approach: trivial use of the Flash video component
12:37:50 [raphael]
... takes an input a URI pointing to a MP4 file
12:38:03 [raphael]
... problem: no possibility to change the HTTP headers, so does not work
12:38:21 [raphael]
... 2nd approach: use the HTTP communication component
12:38:45 [raphael]
... make use of URLLoader component, possibility to add/set HTTP headers
12:39:17 [raphael]
... problem: browsers only allow modifications of non-standard HTTP headers
12:39:32 [raphael]
... it might be different with JavaScript (Philip, HELP !!!)
12:40:13 [raphael]
... URLLoader and video component are not integrated
12:40:47 [raphael]
... workaround: save received byte stram in a file ... not possible in an AIR application, no progressive play possible
12:43:17 [raphael]
... IE, Firefox and Safari all show the same behavior, communication between the flash api and the browser, my parameters are blocked and the browser prohibit to change the standard HTTP header
12:43:48 [raphael]
... 3rd approach: write an own flash video component, take as input the URLLoader component, requires a huge effort
12:44:06 [raphael]
... or modify existing flash video component
12:44:15 [raphael]
... only possible with help from Adobe
12:45:17 [raphael]
Raphael: Philip, it would be very great if you could react on that, based on your experience with Opera, is this possible at all for a browser plugin to interact with the browser and change the HTTP headers
12:45:42 [raphael]
... e.g. a plugin that catchs up the media fragment URI syntax, and just send a bytes range request
12:46:13 [raphael]
... that is NOT possible for sure with a Flash component interacting with a browser according to Davy experiment
12:46:14 [foolip]
No, it's not possible to add arbitrary HTTP headers, and as far as I know not any headers at all, not via the netscape plugin API at least.
12:46:40 [raphael]
Raphael: Davy said you can add non standard headers, you cannot modify the default ones!
12:47:27 [foolip]
Perhaps flash has its own HTTP stack that completely bypasses the browser, or there is more to the netscape API than I have seen.
12:47:30 [raphael]
Davy: conclusion is in order to support Media Fragments, players MUST be modified
12:47:32 [silvia]
foolip: XMLHttpRequest allows setting HTTP headers
12:48:07 [raphael]
Raphael: Silvia, can you override the ones from browser?
12:48:20 [raphael]
Davy: Media Fragments flash player
12:48:29 [silvia]
raphael: yes
12:48:30 [foolip]
silvia: Is that actually implemented by most browsers? In either case, this shouldn't be available to plugins.
12:48:30 [raphael]
... able to play any mp4 file
12:48:59 [silvia]
foolip: I don't know if plugins can use it, but you can write it in a Web page
12:49:00 [raphael]
Raphael: Philip, are you suggesting then that the code of the browsers will need to be modified?
12:49:56 [raphael]
Davy: demo =
12:50:38 [foolip]
I doubt it will ever be possible from plugins if it doesn't already work. I'm sure it doesn't work in Opera via plugins because byte ranges weren't very well supported before <video>
12:51:35 [raphael]
Raphael: Philip, then how do you think UA should become media fragment aware? Does Opera plan to change the browser code in order to generate Range request?
12:52:18 [foolip]
We have already done it for <video>, supporting media fragments is just a matter of parsing a string and seeking to an offset (more or less)
12:52:29 [silvia]
foolip: I think setRequestHeader is implemented by all browsers, even as early as this <- it is available
12:52:49 [foolip]
silvia: XHR?
12:53:02 [silvia]
yes, part of that
12:53:27 [foolip]
then it isn't available to plugins (Flash), if that's the problem Davy had
12:53:28 [raphael]
Raphael: Philip, the whole point of Media Fragment URI is not to seek to an offset, but generate a Range Request to get portions of video clips
12:53:38 [silvia] <- see setRequestHeader
12:54:40 [foolip]
raphael: seeking is implemented with range requests, that's what I mean.
12:55:32 [foolip]
internally it will be the same thing, with some fluff for the UI presentation perhaps and special behavior when looping
12:55:55 [raphael]
Raphael: philip, ok, thanks for the clarification, so I understand that we can use Javascript to simulate now new headers generation based on a parsing of the Media Fragment URI
12:56:31 [foolip]
yes, that's possible today, but you'll get to see the first frame of the video for a while until the seek is finished.
12:56:48 [foolip]
which the browser would hide in a native implementation
12:56:49 [raphael]
... and that browsers, such as Opera, will change their code to support media fragment?
12:56:55 [raphael]
... or am I hoping too much?
12:57:22 [foolip]
I can't promise anything, it depends on our priorities and how sane we can get the processing of media fragments to be
12:57:50 [raphael]
Raphael: amazing demo from Davy
12:58:04 [foolip]
(which is the reason I joined the group)
12:58:17 [raphael]
... supports already t, track and xywh dimensions !!!
12:58:27 [Yves]
nice job, Davy!
12:58:31 [raphael]
... even the space dimension nicely rendered in the UA
12:58:34 [foolip]
Yves: not really, I'd like the spec to be good as a whole too :)
12:58:44 [Yves]
foolip :)
13:00:30 [foolip]
to repeat, I don't care how things are defined as they allow sane implementation that allows future spec changes and progressive implementation.
13:00:56 [foolip]
... as long as ...
13:01:23 [raphael]
Raphael: I agree with this goal too :-)
13:03:03 [raphael]
Give it a try with
13:03:49 [raphael]
... we not have a cropping on only Silvia on the screen, all the rest is black
13:03:58 [raphael]
... spatial selection + temporal selection done
13:04:11 [silvia]
take a photo!
13:06:14 [raphael]
Raphael: Philip, could you explain us WHY flash cannot set headers and Javascript can using the XMLHttpRequest
13:06:15 [raphael]
13:06:33 [raphael]
... why browsers block one way and not the other way?
13:07:27 [foolip]
I think there's just no API for it, but it's been a while since I looked at the netscape plugin API.
13:08:19 [raphael]
Raphael: pointing to
13:08:21 [foolip]
I really don't know what Flash does, if it has a separate cache, if it bypasses the browsers HTTP stack, etc etc.
13:08:23 [raphael]
Jack: it is from 2002 !!!
13:08:35 [raphael]
Davy: yes, my code would also have worked few years ago
13:08:38 [raphael]
... the blocking is recent
13:09:00 [raphael]
Raphael: we are not sure we will not get blocked with Javascript either!
13:09:08 [raphael]
... we need to test
13:09:16 [raphael]
Silvia, do you follow tis?
13:09:20 [raphael]
13:09:23 [silvia]
Davy: did you try FlashXMLHttpRequest?
13:09:48 [silvia]
13:10:01 [davy]
no, that is another possibility to sort out
13:10:07 [foolip]
In any case using XMLHttpRequest to get the video data sounds a bit... creative.
13:10:37 [silvia]
it is - and only useful when you're trying to demonstrate the use without touching player code
13:10:55 [raphael]
Raphael: exactly :-)
13:10:55 [silvia]
foolip: I'd much prefer you put native support into Opera!
13:11:36 [raphael]
Raphael: indeed Silvia, Philip the goal is to convince browsers vendors to change their code showing them prototypes, but we ALL prefer native support
13:12:11 [foolip]
silvia: I'd like that too :) Still, I don't set the priorities so I can't make promises.
13:12:28 [foolip]
The only reason I'm here is of course because I think doing MF is worthwhile.
13:13:09 [Zakim]
Zakim has left #mediafrag
13:13:55 [silvia]
Davy: also make sure to take care of the crossdomain stuff, e.g.
13:14:20 [raphael]
Jack: I will have a look at having a pythong+Gstreamer implementation
13:14:30 [raphael]
13:14:43 [raphael]
... similar to what Davy did client side but in python
13:14:57 [foolip]
GStreamer :)
13:15:50 [mhausenblas]
Michael: many excuses - system still seems not to work, can't dial in (but doesn't matter now as I have to drop in 15 min, anyway)
13:16:28 [guillaume]
13:16:49 [foolip]
Is the room actually doing "Review all actions and issues and discuss / close as appropriate"?
13:17:10 [mhausenblas]
Michael: My take on the TC would be - review them and I'll update then in the Wiki (see also
13:17:31 [raphael]
13:17:31 [trackbot]
ACTION-147 -- Michael Hausenblas to add all MF WG members to corrib -- due 2010-03-05 -- OPEN
13:17:31 [trackbot]
13:18:12 [mhausenblas]
yes, as I wrote - having issues with corrib; unsure if it is wise to continue with it
13:18:41 [jackjansen]
michael, for the time being or forever?
13:19:02 [mhausenblas]
well, depends on when I have some spare time to fix it, jackjansen ;)
13:19:19 [mhausenblas]
I'd recommend to keep it in the Wiki for the time being
13:19:30 [mhausenblas]
I can still add it to corrib later on
13:19:37 [mhausenblas]
important action is to review them, now
13:19:39 [raphael]
Davy: I think corrib is a very useful tool for us, shame we cannot use it
13:19:55 [mhausenblas]
Michael: agree with Davy
13:20:50 [raphael]
Michael, are you suggesting we just review all test cases, and the you take the burden to: 1/ update wiki pages, 2/ update corrib if this is necessary one day, etc. ?
13:21:06 [mhausenblas]
yes, raphael
13:21:28 [mhausenblas]
please just make sure that you do RESOLUTION: for each TC
13:21:49 [mhausenblas]
so that I can point to it
13:21:50 [FD]
FD has joined #mediafrag
13:21:52 [raphael]
Michael, can you show us the RDF generated by corrib ?
13:21:59 [mhausenblas]
13:22:04 [raphael]
is it somewhere in the group directory in cvs?
13:22:12 [mhausenblas]
13:22:17 [mhausenblas]
go to
13:22:19 [raphael]
a url pointer?
13:22:24 [mhausenblas]
click Dashboard ...
13:22:33 [mhausenblas]
under export ...
13:22:42 [mhausenblas]
13:22:48 [mhausenblas]
RDF/XML for example
13:22:56 [mhausenblas]
but also in RDFa or via SPARQL endpoint
13:23:13 [jackjansen]
Michael, is there an import as well?
13:23:23 [mhausenblas]
not at the moment, jackjansen
13:23:32 [mhausenblas]
but I planed to do it
13:23:40 [mhausenblas]
worth an issue/feature request
13:24:07 [mhausenblas]
13:25:00 [mhausenblas]
ok, chaps, sorry - gotta run now. will catch up later, reading minutes and anticipating some actions for /me
13:27:25 [raphael]
Topic: 4. Test Cases review
13:27:30 [RRSAgent]
I have made the request to generate raphael
14:13:26 [raphael]
Raphael: WG room made great progress in listing all test cases we want for the temporal dimension
14:13:39 [raphael]
... that makes 32 test cases
14:15:06 [raphael]
... 2 full boards, pictures taken, need to be filled within a table
14:15:21 [raphael]
ACTION: Raphael to enter this big table in the wiki
14:15:21 [trackbot]
Sorry, couldn't find user - Raphael
14:15:35 [foolip]
are there test cases for e.g. #t=1&t=2, or #%74=%6ept%3A%310 ?
14:15:38 [raphael]
ACTION: Troncy to enter the big table of all test cases for the temporal dimension in the wiki
14:15:38 [trackbot]
Created ACTION-158 - Enter the big table of all test cases for the temporal dimension in the wiki [on Raphaël Troncy - due 2010-03-16].
14:16:07 [dvdeurse]
dvdeurse has joined #mediafrag
14:16:32 [raphael]
#t=1&t=2 ... not yet, since we just did temporal dimension, syntax and semantic test, and not yet combination
14:16:50 [raphael]
#%74=10 is included
14:17:05 [raphael]
so #t=%31%30 is also
14:17:11 [raphael]
... wait for the table to see that fully :-)
14:18:18 [raphael]
Oh, if the unit is %-encoded ... need to add these ones too
14:19:40 [foolip]
ok, sounds good, we should be testing all kinds of weird input
14:20:01 [raphael]
14:21:43 [raphael]
Topic: 5. Wrap Up
14:21:56 [raphael]
Raphael: we need one more F2F meeting
14:22:08 [raphael]
... possibility in Raleigh with WWW, who can be there?
14:23:11 [raphael]
... Raphael, Davy, (Yves = no), (Jack = no?)
14:23:18 [foolip]
Raleigh, North Carolina?
14:23:21 [raphael]
... Michael (likely)
14:23:29 [raphael]
Yes Philip, at WWW 2010, in April
14:23:41 [raphael]
... Conrad and Silvia: not impossible
14:24:06 [foolip]
oh, can't make it, I'm (very willingly) stuck in Beijing until June
14:24:14 [raphael]
Raphael: what are the other possibilities?
14:24:44 [raphael]
... Sophia Antipolis, host by Yves
14:25:35 [raphael]
... Hot topic net telecon
14:25:39 [raphael]
14:25:56 [raphael]
Erik: beginning of June may be the best time
14:26:59 [raphael]
... around June 10 ?
14:28:11 [raphael]
Raphael: I will send summary of today's meeting in few hours
14:29:00 [RRSAgent]
I have made the request to generate raphael
14:29:07 [raphael]
[meeting adjourned]
14:29:09 [RRSAgent]
I'm logging. I don't understand 'draft minutes*', raphael. Try /msg RRSAgent help
14:29:12 [RRSAgent]
I have made the request to generate raphael
14:30:03 [raphael]
ScribeOptions: -final -noEmbedDiagnostics
14:30:05 [RRSAgent]
I have made the request to generate raphael
14:30:52 [RRSAgent]
I see 9 open action items saved in :
14:30:52 [RRSAgent]
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 [1]
14:30:52 [RRSAgent]
recorded in
14:30:52 [RRSAgent]
ACTION: Raphael to review the complete document and check whether there are mroe references to uniqueness [2]
14:30:52 [RRSAgent]
recorded in
14:30:52 [RRSAgent]
ACTION: troncy to review the complete document and check whether there are mroe references to uniqueness [3]
14:30:52 [RRSAgent]
recorded in
14:30:52 [RRSAgent]
ACTION: Yves to add a section 5.2.4 describing his new optimization [4]
14:30:52 [RRSAgent]
recorded in
14:30:52 [RRSAgent]
ACTION: davy to draw diagrams to include in the spec, similar to Yves's email, that shows which bytes from the headers and body of the media file are sent [5]
14:30:52 [RRSAgent]
recorded in
14:30:52 [RRSAgent]
ACTION: Conrad to add a "bandwidth conservation use case" [6]
14:30:52 [RRSAgent]
recorded in
14:30:52 [RRSAgent]
ACTION: Silvia to propagate the changes in the spec document now we have the new header 'Content-Range-Mapping' [7]
14:30:52 [RRSAgent]
recorded in
14:30:52 [RRSAgent]
ACTION: Raphael to enter this big table in the wiki [8]
14:30:52 [RRSAgent]
recorded in
14:30:52 [RRSAgent]
ACTION: Troncy to enter the big table of all test cases for the temporal dimension in the wiki [9]
14:30:52 [RRSAgent]
recorded in