[FFmpeg-devel] [PATCH v8 01/11] avformat: Add fifo pseudo-muxer

[Marton Balint]

On Thu, 18 Aug 2016, Nicolas George wrote:

> Le decadi 30 thermidor, an CCXXIV, Marton Balint a écrit :
>> I remember some other advantages of flushing in blocks as well, which made
>> me suggest it to Jan:
>>
>> - It is a good thing if the consumer knows that there was a packet
>> discontinuity, it can decide what to do. If you drop packets early, the
>> consumer has no chance of knowing if there was a packet discontinuity.
>
> This is an interesting argument, but there is plenty of room in the message
> structure to add a boolean that says "this message is the first one after an
> overrun", or even a counter "n packets were discarded just before this one".
>
>> - Dropping packets in continous blocks, rather than one by one, will
>> probably cause less artifacts for the user, for example if you drop a
>> reference frame from every GOP, it can make the video glitchy for the whole
>> GOP. And exactly this can happen, if the output is only lagging a little.
>>
>> - When the output blocks for some reason, then starts to work, then instead
>> of one continous drop of packets you would get a continous drop, then
>> packets and drops alternating, and finally when there is enough space in the
>> fifo, continous packets. This is also ugly.
>>
>> - Also it is not healthy to operate with an almost full fifo, because of
>> the additional latency it causes. So if the queue fills up for any reason,
>> let's give us a fresh chance to operate normally, with as small latency as
>> possible.
>
> I think the proposal in my previous mail works for all these issue (which
> are, I believe, actually three wordings of the same one).

So you want to do the block flushes in the producer thread. That would 
probably cause half-full fifos when recovering from a full fifo, 
because the producer thread has no knowledge when the consumer actually 
returned from a single long blockage at the writing of one packet.

On the other hand, if the the flush happen in the consumer thread, it will 
happen exactly at the time, when the consumer thread is no longer blocked, 
therefore I find it superior. (and also cleaner, because the consumer does 
the consuming...)

An early version of Jan's code used flushes both at the producer and the 
consumer to work around this issue, but it become more complicated than 
doing the flushes in one place, in the consumer.

I hope I addressed your concerns, I'd like to commit the code as it is. 
Even if you still don't agree with everything, I think we should commit 
the code, because it works, and improvements can be done later.

Regards,
Marton