[vlc-devel] [PATCH] video_output: drop frames that take too much time to process

[Steve Lhomme]

On 2020-08-12 11:21, Thomas Guillem wrote:
> Hello,
> 
> On Tue, Aug 11, 2020, at 18:51, Rémi Denis-Courmont wrote:
>> Le maanantaina 10. elokuuta 2020, 14.32.31 EEST Steve Lhomme a écrit :
>>> If a frame arrives at the rendering step later than it's display time (plus
>>> the late threshold we allow), there's no way it will be displayed in time
>>> or even late with some tolerance.
>>>
>>> We can drop it and save some rendering/swap time for the next picture. We
>>> just didn't detect the lateness at an upper level.
>>
>> Typically, rendering/swapping is not what consumes CPU time.
>> This could help or it could make things worse.
>>
>> Not sure this is a good idea.
> 
> Not sure either. There is also the interactive filter chain that could use a lot of CPU time for nothing (cf. beginning of ThreadDisplayRenderPicture())

When we drop frames it's because it won't be displayed in time. With GPU 
direct rendering it means some pictures were too long to decode, so 
avoiding some more GPU calls will benefit the next frames. We could also 
drop after the filters, etc.

Again there's still the dubious case of dropping a picture when there 
isn't another pending. It may be late but there's probably time to show 
it before another one is on time.

It should also no drop frames when using --no-drop-late-frames.