[foms] Adaptive streaming

[Mark Watson]

Just to clear up one point of confusion: a regular mp4 file has a large header, but a Fragmented mp4 file, as used in MS Smooth Streaming, Flash adapt HTTP Streaming and MPEG DASH does not.

Regular mp4 files have all the sample framing data in the header (MOOV box). It can get big. In a Fragmented mp4 this information is distributed through the file, closer to the samples themselves, in MOOF boxes.

There is still a header, containing codec initialization data, but it should be small (a few KB at most)

...Mark

Sent from my iPhone

On Oct 29, 2010, at 8:13 AM, "John Luther" <johnluther at webmproject.org<mailto:johnluther at webmproject.org>> wrote:

Wow, cool. I'd love to see a demo. 436K is a lot of data, you could do 30 or 40 seconds of mobile-rate video with that!

--JL



On Fri, Oct 29, 2010 at 10:43 AM, Jeroen Wijering <<mailto:jeroen at longtailvideo.com>jeroen at longtailvideo.com<mailto:jeroen at longtailvideo.com>> wrote:

On Oct 27, 2010, at 5:51 PM, Mark Watson wrote:

>> Do files with a compacted index still play on devices that do not expect it? Think current mobile phones.
>
> In DASH its just a fragmented MP4 file with an extra box ("Segment Index") near the beginning. Existing players would ignore the new box.

Do you have an example video? I'm curious to see one and do a few tests.


>> If WebM / Ogg by its nature already has much smaller headers, one of the big drawbacks of range-request streaming would not be valid for these containers.
>
> I need to read up on the WebM format (bit of a confession, being on this list, sorry!). But I understood you have the framing information with the samples and therefore smaller headers and probably no need for any kind of formal fragmentation. So your "fragment" would just be a notional concept of a group of samples spanning some time period. Your index would provide time and byte offsets for these fragments. If you already have something which provides time and byte offsets for Random Access Points (for seeking) you could probably re-use that. (Re-using Movie Fragment Random Access box in mp4 was discussed instead of creating the new Segment Index. Segment Index was chosen for some slightly obscure technical reasons).

Just did a quick test with a 15-minute WebM video (keyframes 2-6s):

<http://content.bitsontherun.com/videos/a95zAVN1-710492.webm>http://content.bitsontherun.com/videos/a95zAVN1-710492.webm

The first Clusterheader appeared at 44k.

That's pretty nice compared to an MP4 conversion with the same keyframe interval, where the MOOV box is 480k:

<http://content.bitsontherun.com/videos/a95zAVN1-600332.mp4>http://content.bitsontherun.com/videos/a95zAVN1-600332.mp4

So it looks like my concern with range requests (startup delays due to big headers) is not valid for WebM files....

----

If the videoElement would expose a callback with valid range-requests to javascript, the scripting layer would be aware of the valid ranges in a quality level. For example something like "onSeekpoints" that returns:

[
 {position: 0,000,start: 8839, end:9957},
 {position: 1,287,start: 9957, end:10994},
 {position: 3,071,start: 10995, end:19840}
]

Next, this info can be used to do adaptive streaming using the appendVideo function:

videoElement.appendVideo("<http://example.com/video_800.webm>http://example.com/video_800.webm", 8839, 9957);

With this, plús some way to retrieve the bandwidth / bytesLoaded, it should be possible to build a fully functional WebM adaptive streaming demo in javascript - using existing WebM files.

Would this work? Are there oversights? What do the FOMS browser developers think of such a first step?

Kind regards,

Jeroen
_______________________________________________
foms mailing list
<mailto:foms at lists.annodex.net>foms at lists.annodex.net<mailto:foms at lists.annodex.net>
<http://lists.annodex.net/cgi-bin/mailman/listinfo/foms>http://lists.annodex.net/cgi-bin/mailman/listinfo/foms

_______________________________________________
foms mailing list
foms at lists.annodex.net<mailto:foms at lists.annodex.net>
http://lists.annodex.net/cgi-bin/mailman/listinfo/foms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.annodex.net/cgi-bin/mailman/private/foms/attachments/20101029/85c4c7cd/attachment.htm