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

Marton Balint cus at passwd.hu
Tue Aug 16 02:14:13 EEST 2016


>>> +        if (!fifo->overflow_flag)
>>> +            fifo->overflow_flag = overflow_set = 1;
>>> +        pthread_mutex_unlock(&fifo->overflow_flag_lock);
>>> +
>>> +        if (overflow_set)
>>> +            av_log(avf, AV_LOG_WARNING, "FIFO queue full\n");
>>> +        ret = 0;
>>> +        goto fail;

>> Can you explain why you do not just drop the packet here and now? If you do
>> that and move the discard until keyframe here, you can dispense with the
>> overflow flag and the lock. The consumer thread becomes much simpler and can
>> focus on the retries themselves. Plus, the whole process becomes slightly
>> more efficient since packets are discarded earlier.
>>
>> Also, why do you flush the whole 60 packets when it blocks? If the output is
>> only lagging a little, discarding a single packet could be enough. And if
>> not, it will discard the next packets.

> The current packet is discarded here. We discussed with Marton how to 
> drop packets and agreed that flushing the whole queue should be OK - it 
> is done within single critical section in av_thread_queue_flush(), 
> flushing just single packet might not be enough in some situations. The 
> reason why is it done in worker thread and not in this call is that 
> flushing the queue can get quite costly -> dereferencing larger number 
> of packets can lead to many free() calls which may be costly, the idea 
> was to move potentially costly operation to worker thread.

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.

- 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.

Regards,
Marton


More information about the ffmpeg-devel mailing list