[foms] Chunks

[Pierre-Yves KEREMBELLEC]

Hi Steve, all,

> When you say range-requests could be used, I assume you mean in the
> same file ? Given you know where exactly in the stream you want to
> seek (via the manifest file). In MPEG TS that should not be much of a
> problem as there is no header. In Matroska/WebM the server would need
> some remuxing intelligence to provide the header before the actual
> data requested. That's of course considering the file was not encoded
> in "chunks". But adding that kind of intelligence to web server is not
> a good thing.

Well, if carefully designed, such intelligence can prove very useful to reduce the number
of files effectively. See here for an example of such implementation:

http://lists.annodex.net/cgi-bin/mailman/private/foms/2010-November/000894.html

As you pointed out, some containers are seen as streams (like FLV for instance), where
A/V data is interleaved with a low-overhead signaling protocol (basically convoying data
types, tracks mapping, PTS/DTS, PCR, ...), and may even re-synchronize themselves (like
MPEG2-TS). They are good candidates for keyframes-ranges/time-ranges to bytes-ranges
mapping.

MP4 (and in a certain extent MKV) are good examples of non-streamable container
(in their basic/naive form, not when remuxing in chunks).

> Matroska can have Segments (chunks) concatenated and it should play
> fine as long as the channel parameters remain the same between chunks.
> That has the advantage of having chunks and still dealing with a
> single file. VLC and DirectShow based players should be able to handle
> these type of files. I think browsers supporting WebM should also
> ensure they support this feature. After all compared to loading chunks
> separately you avoid some latency for each new HTTP connection. In the
> hand any software that supports this can support chunked videos,
> whether they come from a single file or various files virtually
> concatenated (in which case resolution changes should be allowed and
> handled as a single output resolution).

Agreed. In practice, chunked MP4 (MOOF/TRAF) fail to play in most media players
(including VLC).

> So the resolution (width/height) should also be known beforehand. When
> integrated in a web page it's important to know exactly how much a
> video will take. Even if at some point during playback the actual
> frames are much smaller. What is the plan here ? Let the m3u8 files
> tell the max/default dimension expected or making the width/height
> mandatory in the <video> element ?

Either solution is good I guess, but since manifests already contains other information,
putting the framesize along seems preferable to me.

> The paragraph also says that there's currently no ecosystem to produce
> such files. From what I see, it may be easy enough to encode the same
> stream the usual way in as many files per bandwidth. And then have a
> tool simply make the splits where the keyframes match in all these
> files. That means encoders are not modified and you're assured all
> chunks are in sync (it's a little trickier on the audio side as Vorbis
> doesn't always have the same amount of sample per frames, but that can
> be resolved on the player side). The only trick is to tell the video
> encoder the max allowed amount of frames before a keyframe is issued.
> I think most encoders support that. And from the same source, the
> keyframes should happen more or less at the same locations for all
> bandwidths.

Even when encoded independently (but from the same source), different versions exhibit
almost the same keyframes positions (because the scene-change detection algorithm - 
present in most ME-based implementations - does not really depend on the encoder output
settings).

> I've seen mentioned in a discussion that switching to JSON could be an
> option. I think it would be a good move. It's a little more flexible
> (arrays) and would use code already present in all browsers and many
> programming languages, especially the ones made for the web (easier
> than XML on Android for example)


Exactly my point, JSON is flexible and natively parsed by browsers, see here for an example
of a JSON implementation:

http://lists.annodex.net/cgi-bin/mailman/private/foms/2010-November/000936.html

More 2 cents,
Pierre-Yves