IRC Log of Media Fragment URI discussion

9:41:30 AM nessy1: Let's get started
9:41:35 AM nessy1: Present:
9:41:44 AM nessy1: Michael Dale
9:41:46 AM nessy1: Jan Gerber
9:41:48 AM nessy1: Conrad Parker
9:41:51 AM nessy1: Andy Nichols
9:41:57 AM nessy1: Matthew Gregan
9:42:00 AM nessy1: Chris Double
9:42:02 AM nessy1: Chris Pearce
9:42:07 AM nessy1: Tim Terriberry
9:42:13 AM nessy1: Douglas Bagnall
9:42:15 AM nessy1: John Ferlito
9:42:17 AM nessy1: Silvia Pfeiffer
9:42:29 AM nessy1: and on irc active: Philip Jaegenstadt
9:42:38 AM foolip: oh, so many people
derf [i=ptolemy@pool-173-73-173-84.washdc.fios.verizon.net] entered the room. (9:43:07 AM)
9:44:19 AM j^: http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/
9:44:31 AM foolip: yes
9:45:45 AM mdale: Siliva is presenting the url fragments spec
9:46:14 AM mdale: comparing ? vs # mark .. ? creates a new resource ... # is client side byte range approach 
dbagnall [n=douglas@schubert.halo.gen.nz] entered the room. (9:46:52 AM)
nbrookins [i=8cef02a2@gateway/web/freenode/x-buiinbnmfoppovkg] entered the room. (9:46:58 AM)
9:47:41 AM mdale: request for questions can be made on the irc channel
9:48:13 AM foolip: Firefox has already implemented #t=5 ?
9:48:32 AM cpearce: No
kfish [n=conrad@ip-210-185-20-158.internet.co.nz] entered the room. (9:48:32 AM)
9:49:13 AM foolip: didn't think so
9:49:13 AM mdale: different implementations: Client side byte range mapping vs server side time to byte range translation
9:50:23 AM mdale: section 4:
9:50:26 AM foolip: silvia wen't offline and took audio with her 
9:50:27 AM mdale: describes syntax
9:51:39 AM foolip: audio back
9:52:26 AM mdale: http://www.w3.org/TR/2009/WD-media-frags-20091217/#media-fragment-syntax
9:55:09 AM j^: http://annodex.net/~silvia/itext/mediafrag.html
9:56:04 AM mdale: siliva is showing a itext demo
9:57:04 AM foolip: hehe, quite a bit more indeed 
9:58:38 AM foolip: ok, I've seen the demo
9:58:47 AM mdale: more demos putting different times into the input box
10:02:00 AM foolip: it's a long way to NZ, amazing this works at all
10:02:29 AM mdale: Silvia: comparing uri handling ... ? creates a new video resource it has a header its self contained
10:03:47 AM foolip: browsers must not mess with the query part
10:04:14 AM mdale: correct
10:04:49 AM foolip: no, it should start from the beginning
10:05:25 AM mdale: ?start/end creates a new resource starting at zero and duration of end-start
10:05:32 AM mdale: with #
10:06:53 AM foolip: yes, you'd want to loop the addressed fragment
10:10:09 AM mdale: talking about how implementation should work
10:12:46 AM foolip: if you want to break out, just set src without the fragment part
rillian [n=giles@ip-210-185-20-158.internet.co.nz] entered the room. (10:12:58 AM)
10:14:53 AM foolip: really, this problem will be solved by the first implementation, it's not the biggest one... 
10:15:12 AM foolip: (e.g. breaking out if the user ever seeks outside the fragment)
10:16:49 AM mdale: comparing how youtube works
10:19:32 AM j^: http://annodex.net/~silvia/itext/mediafrag_multiple_servers.html
johnf [n=johnf@ip-210-185-20-158.internet.co.nz] entered the room. (10:21:44 AM)
10:29:13 AM foolip: that depends on implementation
10:29:20 AM foolip: it can be cached
10:29:35 AM foolip: but you always have to go through the different states
10:29:45 AM foolip: even if you don't change the source
10:29:59 AM foolip: just set .currentTime=0
10:30:25 AM kfish: cool
10:30:26 AM foolip: *realizes this IRC log will be completely unreadable afterwards*
10:33:32 AM foolip: obviously you have to get the beginning of the resource if you want to play it, media fragment or not
10:35:06 AM mdale: looking at the mime type and how browsers would request the fragment. 
10:36:17 AM mdale: there is a gab in the spec
10:36:22 AM foolip: I'm pretty sure browsers will only try interpreting the fragment component as MF if it's used in <audio> or <video>
10:37:14 AM mdale: the spec does not speficy the fact that you need to start loading the resource before you can do the byterange request
10:39:16 AM mdale: we are closing up and should move on to adaptive streaming 
10:39:56 AM mdale: doublec: asking if its safe for initial implementation
10:40:48 AM mdale: Worries that the time request part would change... The hash time request is "stable"
10:41:36 AM mdale: doublec: does not think it will be difficult for browser vendors to implement base profile of time hash requests 
10:42:07 AM mdale: kfish: can focus on the client side first, the spec is simple on hash and media independent 
10:42:58 AM mdale: * Should recommend splitting up the spec from Time from all the other stuff ( temporal spaces ) ... 1.0 is client side fragments
10:43:07 AM mdale: then 1.1 is all the rest of stuff
10:43:27 AM mdale: get a 1.0 version "stable"
johnf left the room (quit: Read error: 54 (Connection reset by peer)). (10:43:42 AM)
10:43:46 AM foolip: I'm here
10:43:57 AM foolip: I just want to add that the biggest blocker is parsing
10:44:04 AM foolip: as in, it's still undefined
johnf [n=johnf@ip-210-185-20-158.internet.co.nz] entered the room. (10:44:08 AM)
10:44:12 AM foolip: the rest is pretty simple if you can seek
10:45:04 AM foolip: Silvia summarizes correctly
10:45:39 AM rillian: but for just the temporal fragments, you could do a direct parsing specification, no?
10:45:43 AM foolip: nope, I'm just waiting for CVS access
10:46:02 AM foolip: rillian: how "direct"?
10:46:14 AM foolip: I'll listen until the connection fails again
10:47:34 AM rillian: document the grammar for the temporal fragments directly, just like the HTTP spec does for standard message headers
10:47:47 AM rillian: foolip: maybe I'm misunderstanding the intent
10:48:06 AM foolip: the individual syntaxes (time, xywh, etc) are documented fine
kinetik [n=kinetik@121.98.132.55] entered the room. (10:48:18 AM)
10:48:40 AM foolip: the quite simple problem that isn't solved is how to split "query strings" into name-value pairs
10:49:04 AM foolip: I can hear
10:49:10 AM rillian: but the temporal fragments are more limited than that
thaytan [n=jan@ip-210-185-20-158.internet.co.nz] entered the room. (10:49:13 AM)
10:49:50 AM foolip: a browser that did that would break as soon as someone added a second parameter
10:50:40 AM rillian: foolip: well, if you want to solve it in a general way, that's fine
10:51:04 AM rillian: it just doesn't seem necessary if the 1.0 spec doesn't actually define a second parameter