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

Nicolas George george at nsup.org
Thu Aug 18 14:19:57 EEST 2016


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

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160818/fb3636b9/attachment.sig>


More information about the ffmpeg-devel mailing list