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