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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
