[foms] Chunks

[Andoni Morales]

2010/11/11 Pierre-Yves KEREMBELLEC <pierre-yves.kerembellec at dailymotion.com>:
> 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).

But not in GStreamer anymore :)
https://bugzilla.gnome.org/show_bug.cgi?id=596321

Andoni
>
>> 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
>
> _______________________________________________
> foms mailing list
> foms at lists.annodex.net
> http://lists.annodex.net/cgi-bin/mailman/listinfo/foms
>



-- 
Andoni Morales Alastruey

LongoMatch:The Digital Coach
http://www.longomatch.ylatuya.es