[vlc-devel] [vlc-commits] commit: stream_filter/httplive.c:?HTTP Live Streaming (Jean-Paul Saman )

[Rémi Denis-Courmont]

On Wed, 13 Oct 2010 09:41:01 +0200, Jean-Baptiste Kempf <jb at videolan.org>
wrote:
> On Wed, Oct 13, 2010 at 09:36:19AM +0200, Rémi Denis-Courmont wrote :
>> The whole design assumes a /continuously streamable/ format. Except for
>> a Transport Stream or a raw MPEG Audio elementary stream, not much can
>> ever work with that protocol.
> You should be able to do the same with .mkv. Most of them are not ok,
> but it should be ok if correctly streamed.

Bah, I mean you can sync a TS stream from virtually anywhere within itself
- even if you missed the first bytes. That's why JPS managed to implement
it with a stream_filter.

>> On top of that, Apple HTTP streaming is useless for VoD. It has no
>> benefits over normal HTTP, at least w.r.t. properly indexed file
formats.
>> Agreeably, TS is NOT a properly indexed file format. But I expect MKV
is,
>> so Apple HTTP would be useless there.
> MKV isn't always indexed.

You can find broken files. But those files won't work with Apple HTTP any
better than with plain HTTP. They just won't work. The point is, if you
_can_ index properly, you should do that rather than use Apple HTTP.

You don't need Apple HTTP to provide alternate URLs for alternate
bandwidths either - any normal playlist could do that. Or you could simply
put multiple links on an HTML page. IMHO, this was really designed with TS
in mind and is kinda misfit for other formats.

>> Then for live streaming, you cannot use MKV in any case, can you?
>> Why not? See the fix from robux on mkv demuxer to be able to play
>> infinite live streams. I can show a stream sample, off-list

Even if the VLC stream output could do that (it can't due to limitations of
the mux/access_out interface), there would still be no benefit of Apple
HTTP over plain HTTP.

-- 
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis