[foms] Chunked/adaptative streaming at Dailymotion
jeroen at longtailvideo.com
Thu Nov 4 10:44:04 PDT 2010
Hello Pierre, all,
> This new version is a standalone event-driven HTTP server, with support for standard HTTP requests (regular
> and byte-ranges), Flash player (json + FLV remuxing), Apple HTTP Live Streaming (m3u8 + MPEG2-TS re-muxing).
> It supports the original containers from the previous version (MP4 and FLV), and we will probably support
> MKV (+ VP8/Vorbis) if the WebM initiative gains enough momentum.
I know some server modules (Code-shop, Adobe) need their MP4 files preprocessed into fragmented MP4 before playout can be done. You seem to simply use the MP4 files and do all on the fly? Is that fast enough, since I presume the server has to work pretty hard to extract a fragment from an MP4 file?
> We choose to base both manifests on JSON, because it's easily parsable and virtually all platforms and
> which are both ECMAScript derivatives). It's also easily extensible and not tied to any existing format
> (like Apple's M3U8, Microsoft/Adobe manifests files, DASH), so there no fear of infringing some vendor IP.
Awesome! Do you have an example of both formats - overarching and single bitrate?
> We choose to re-encapsulate/re-mux the A/V samples into the clients relevant "containers" at the server side.
> For Flash, it's FLV because the appendBytes() primitive expect this format, and it's really efficient as far
> container overhead is concerned (we may have send re-muxed MP4 fragments, but it's more complicated to synthesize
> on-the-fly, and you also need an MP4->FLV demuxing/remuxing library in the player itself, which is a little
> bit overkill IMHO (it's implemented in OSMF for instance)).
Getting chunks of FLV is so much easier in Flash than getting chunks of fragmented MP4 like OSMF does. Do you have more info on what you generate - or perhaps a test stream? And do you reset the pipe on a bitrate switch in Flash?
Second, I know e.g. Code-shop preferred Flash to read Fragmented MP4 over FLV because that's basically one less format to cache (better caching performance). What do you think on this caching-versus-demuxing tradeoff?
> As long as the bistream format is a simple "stream of samples" (with just enough time-coded information and
> decoders initialization to play those samples correctly and independently inside a particular fragment), I
> think it doesn't really matter which one is chosen. I don't know enough about MKV to determine if it's a good
> candidate or not. MP4 (even in its fragmented MOOF/TRAF version) is probably NOT, because of the way the samples
> are referenced inside a global index: it doesn't serve any purpose in the streaming case.
What parameters are different between the various bitrates of your videos? Video bitrate/dimensions/framerate/...? Audio bitrate/samplefrequency/channels/...?
More information about the foms