IRC Log of Adavtive Streaming Discussion

10:51:12 AM nessy1: Adaptive Streaming
10:52:39 AM nessy1: conrad: resource description to define the different available options, then parse that and request different resources?
10:52:55 AM nessy1: existing options: flash media server approach & apple's adaptive streaming
10:53:30 AM nessy1: Matthew: apple's spec is just serving chunks
10:53:44 AM nessy1: it's a playlist of "oggz-chopped" segments
10:53:59 AM nessy1: j^: with ogg we can do something more intelligent
10:54:37 AM nessy1: you have the Ogg indexes and you have the different qualities encoded in different files and you serve the byte ranges from those
10:54:46 AM nessy1: that's similar to the Microsoft implementation
10:55:09 AM nessy1: conrad: would we have ROE as the resource description, then do the byte range requests on the different files
10:55:33 AM nessy1: johnf: would it be better to have separate files or have them all as different tracks on the same resource?
10:55:47 AM nessy1: room: no, have separate files - makes it cachable
10:56:27 AM nessy1: rillian: you might want both - you can use fragment & query requests to segment out the tracks
10:57:06 AM nessy1: matthew: the most important case is edge caching, so you will want it cachable
10:57:19 AM nessy1: it'd be best if it works on a plain http server
10:57:42 AM nessy1: doublec: we're not going to be doing av sync across different files
10:57:58 AM nessy1: conrad: we don't want to reimplement SMIL indeed 
10:58:33 AM nessy1: johnf: ROE makes a lot of sense - it's a description of the different streams etc
10:58:55 AM nessy1: further: in a11y - how to describe the different available tracks
10:59:25 AM nessy1: in the extreme, a video element could just point to a ROE file
10:59:39 AM nessy1: doublec: if ROE was regarded as a new "video codec", then it might just work
11:00:23 AM nessy1: johnf: ROE should just describe the complete resource description
11:00:33 AM nessy1: s/describe/provide/
11:00:59 AM nessy1: http://wiki.xiph.org/index.php/ROE
11:01:09 AM nessy1: mdale: ROE should work across domains
11:01:32 AM nessy1: doublec: should follow the same approach as video from other domains
11:01:42 AM nessy1: if it's regarded as another codec, it would just work
11:03:22 AM nessy1: doublec: let's not bring in subtitles, but only talk about adaptive streaming
11:03:55 AM nessy1: doublec: I think we should have a file on the server that lists the different available bitrate encoded files
11:04:10 AM nessy1: the client would start serving one file
11:04:47 AM nessy1: if it notices that this is too low, you use byte ranges on a lower quality encoded file to switch
11:05:02 AM nessy1: you will need to download a certain amount of metadata
11:05:43 AM nessy1: you might want bitrate of the full resource, resolution of the screen to be noticed about the alternative resources
11:06:15 AM foolip: yes, you have media="(min-device-width: 800px)"
11:06:43 AM foolip: on <source>
11:07:14 AM nessy1: so, resolution is already solved in the existing spec
11:08:00 AM nessy1: through media queries
11:09:48 AM nessy1: mdale: but low bitrate streams tend to have less screen resolution as well
11:10:56 AM nessy1: conrad: the display should not jump around in size all the time
11:11:09 AM nessy1: mdale: maybe it should,  for debugging reasons 
11:11:57 AM foolip: concatenated Ogg files (horror) can already jump around in size...
11:12:55 AM nessy1: doublec: what we need is someone to sit down and make a spec
11:13:05 AM nessy1: needs to have: bitrate, resolution, frames per second
11:13:24 AM nessy1: relative quality
11:13:46 AM nessy1: good implementations will switch on keyframes 
11:14:12 AM nessy1: it would be best if a hosting implementation could encode all the files with keyframes in the same place
11:14:44 AM nessy1: j^: you only have to switch at the new resource's keyframe - doesn't matter where we are on the old resource
11:15:08 AM nessy1: doublec: someone needs to put together a proof of concept to see how smooth it can be done
11:15:15 AM derf: This is technically possible, right now, if you use two-pass encoding and use the same first pass file for multiple second passes at different bitrates.
11:15:53 AM mdale: derf: would be good to add a system for supporting that in ffmpeg2theora or some scripts that people could use
11:15:57 AM rillian: derf: reasonable idea
11:16:21 AM derf: This obviously goes out the window if you use different resolutions or framerates.
11:17:08 AM nessy1: need to write scripts to do it and create the best possible set of encoded files
11:18:59 AM nessy1: Adobe starts with a lower quality video and quickly scales up to adapt to the available bandwidth
11:19:03 AM nessy1: it works really well
11:20:22 AM nessy1: Nicholas: did a bit of work in javascript
11:20:32 AM nessy1: have a lot of experience with MS, Apple & Adobe implementations
11:20:48 AM nessy1: is there any intent to make this something that can work with live video?
11:21:28 AM nessy1: there's a trade off because if you specify an existing set of files it makes it simpler
11:21:35 AM nessy1: live is more complicated
11:22:06 AM nessy1: conrad: is the server creating multiple files in the live spec?
11:22:33 AM nessy1: nicholas: Apple's m3u8 file is constantly being update with the new files that are being created
11:22:51 AM nessy1: the streaming app  constantly creates new files
11:23:11 AM nessy1: by the time the index is update, the segments are already there
11:24:05 AM nessy1: rillian: icecast would need to write multiple files
11:24:38 AM nessy1: you'd need to constantly pull buffers on those files
11:25:29 AM nessy1: problem: icecast is a bit behind in time
11:25:50 AM nessy1: conrad: if we do it as a playlist thing it would be analogous to the Apple approach
11:26:18 AM nessy1: problem is you don't have the OggIndex on live content
11:26:32 AM nessy1: rillian: so you have to go back to granulepos
11:29:08 AM nessy1: let's not try to follow the Apple design with the many video files
11:29:49 AM nessy1: rillian: you could update the ROE file to link to temporal fragemnts
11:30:40 AM nessy1: doublec: let's just implement it on Friday 
11:30:48 AM nessy1: let's spec out the options
11:31:00 AM nessy1: what sequence of steps to go through
11:31:05 AM nessy1: how does a CMS work
11:31:28 AM nessy1: mdale: add a special preset to ffmpeg2theora to author a set of files would be great
11:33:44 AM nessy1: doublec: goal for a hack session with 3 videos and switching
11:33:59 AM nessy1: goal to make an analysis of this here
11:34:14 AM foolip: nessy: I'll have to say good night
11:34:18 AM nessy1: no worries
11:34:24 AM nessy1: I think Nicholas just dropped off too
11:34:25 AM foolip: nessy: same time tomorrow?
11:34:29 AM nessy1: thanks both of you for joining!
11:34:34 AM nessy1: goal:
11:34:41 AM foolip: thanks for patching me in
11:34:42 AM nessy1: * start concept at FOMS
11:34:45 AM nessy1: * spec the file format
11:34:48 AM nessy1: long-term:
11:34:54 AM foolip: *hacks a bit at MF spec before sleep*
11:35:16 AM nessy1: * implemented for live and CMS style approach
11:36:38 AM nessy1: doublec: we should focus on icecast?
11:36:55 AM nessy1: j^: they don't have OggIndex etc - a bit more difficult to handle
11:37:50 AM nessy1: johnf: it's possible to specify bitrates in media queries of video elements
11:38:27 AM nessy1: doublec: this for which resource to load first
11:38:31 AM nessy1: it is not for dynamic switching
11:40:41 AM nessy1: may be best to create a new spec - might reuse stuff from ROE
11:41:14 AM nessy1: johnf: as a sys admin I don't want ppl to request the same file over and over again