[vlc-devel] [PATCH 3/4] avformat mux: Mark keyframe blocks as such.

[Martin Storsjö]

On Mon, 19 Aug 2013, Steinar H. Gunderson wrote:

> On Mon, Aug 19, 2013 at 01:44:24AM +0300, Martin Storsjö wrote:
>> Btw, a different way of making streaming webm work reliably in all
>> browsers that support webm, that requires a bit more refactoring in
>> the server, is to create a separate muxer instance for each client,
>> so that each client gets a uniquely muxed stream for them from the
>> next keyframe after they connected.
>
> It also eats CPU to a completely different level, _and_ it requires your
> reflector to understand each and every format you want it to stream.
> It might be workable on a small scale, but it's certainly not an avenue I'd
> want to pursue myself; it sounds very painful performance-wise.

Yes, it's clearly not ideal, but it's technically possible.

>> I don't know the details of http streaming in VLC all that well though so
>> it might very well not be doable too easily there though. But as a general
>> concept it's easily doable and just wastes a little more memory.
>
> The HTTP server in VLC cannot do it; it pushes bytes from a common backlog,
> and nothing more.
>
> Also, “a little more memory” is probably relative; as I understand your
> suggestion, you'd need to keep one GOP (muxed or unmuxed) per client,
> and if your GOPs get large (10 seconds at 5Mbit/sec = 6.25MB) and your
> clients get many (my use-case is well above 1000), this can easily go up in
> the gigabytes...

I'm not sure why you'd need that much memory, but OTOH I might not have 
thought it through fully either. Basically you'd have an array of muxers 
that you feed the packets from the encoder into - once a new client joins 
you'd just add it into that array when you're writing the next keyframe. 
(Or keep one single copy of the current GOP that you'd immediately feed to 
new muxers.) But you do need individual instances of all buffers from the 
muxer onwards, and yes it's not nearly ideal.

// Martin