[foms] Adaptive streaming

Mon Nov 1 10:53:13 PDT 2010

Right I was talking about VP8 specifically. And your right even if the
player does not need data at the codec level for video it most likely will
need it at file and stream scope. So it would probably be best to generalize
that across all streams and files. I was trying to say that in my first
email but maybe I didn't write it clear enough.

Frank

On Mon, Nov 1, 2010 at 1:38 PM, Mark Watson <watsonm at netflix.com> wrote:

>
> On Nov 1, 2010, at 10:05 AM, Frank Galligan wrote:
>
> Sorry for coming late to the party. Just trying to read up on what everyone
> else had talked about.
>
> On Fri, Oct 29, 2010 at 4:17 PM, Mark Watson <watsonm at netflix.com> wrote:
>
>>
>> On Oct 29, 2010, at 7:43 AM, Jeroen Wijering 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
>> >
>> > 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
>> >
>> > 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", 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?
>>
>> The one additional thing I think is needed is that you need also to give
>> the player the file headers for each variant (Header/Segment/Track for WebM,
>> Movie Header and Segment Index for DASH mp4). Maybe also the Cueing Data in
>> WebM can be used as an index ?
>>
> Each Vorbis stream has its own setup data that would be needed before you
> decode that stream. VP8 streams do not have any setup data to decode a
> specific stream. As long as you start on a key frame you should be ok. But
> there might be other characteristics of the video that will be different per
> stream that the player would need to know about. I.E. The duration might be
> a little different depending if the fps changed. Also if other streams are
> added such as captions then players might need setup data per stream. This
> setup data should probably be speced to be generic per stream.
>
>
> Here you are talking about initialization data (or rather absence of) for
> the VP8 codec itself, right ? I was referring to the file format level
> information in the WebM Header, Segment and Track objects -aren't these
> needed to play the rest of the file and couldn't they differ between
> different encodings ?
>
> ...Mark
>
> The cues element is speced to be the seek index. The spec says that
> you should have one cue entry for every video key frame. Depending on the
> encoding parameters you should have >= 3600 entries at 2sec chunks for a 2
> our movie.
>
>>
>> There are various ways to do this and those more expert in HTML5 than me
>> can suggest the best, but one way might be:
>>
>> tag = videoElement.initializeVideo( "http://example.com/video_800.webm" )
>>
>> then onSeekpoints returns { tag: 1, seekpoints = [ { position: 0, start:
>> 8839, end: 9957 }, ... ] }
>>
>> then videoElement.appendVideo( tag, "http://example.com/video_800.webm",
>> 8839, 9957 )
>>
>> You are still appending to a single common playout buffer, the tag is
>> about where the information comes from, or rather how to understand it, not
>> where it is appended to.
>>
>> Same, independently, for audio.
>>
>> ...Mark
>>
>>
>> >
>> > Kind regards,
>> >
>> > Jeroen
>> > _______________________________________________
>> > foms mailing list
>> > foms at lists.annodex.net
>> > http://lists.annodex.net/cgi-bin/mailman/listinfo/foms
>> >
>>
>> _______________________________________________
>> foms mailing list
>> foms at lists.annodex.net
>> http://lists.annodex.net/cgi-bin/mailman/listinfo/foms
>>
>
> <ATT00001..txt>
>
>
>
> _______________________________________________
> foms mailing list
> 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/20101101/0834a80a/attachment.htm 