[vlc-devel] [PATCH] rework the video frame skipping/dropping strategy in the avcodec decoder

[Steve Lhomme]

On Fri, Feb 27, 2015 at 11:08 AM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le 2015-02-27 12:33, Steve Lhomme a écrit :
>>>
>>> This may be less prevalent now than when the code was written, but
>>> rendering
>>> a picture can consume a lot of CPU (for filters and conversions) and/or a
>>> lot of time (if the video output is slow). Also 50ms is already longer
>>> than
>>> the typical frame period (assuming more than 20 fps), so there should
>>> already be a newer picture to render.
>>
>>
>> Yes, but in the case of CPU overload each coming frame is later than
>> the previous one.
>
>
> Who cares about that case? If the delay keeps increasing, palliation at the
> video output is impossible anyway.

I just think it's a waste of CPU to have the data ready to be
displayed and just drop it because it was a tiny bit late. At least in
the case we know we're not going to do any more memory copies/heavy
processing to render.

>> And in the end nothing is displayed at all. Maybe if
>> nothing has been displayed in 100ms or we dropped 5 frames we could
>> decided to display it anyway ? It's better than having the file being
>> decoded and never showing anything. That could improve the playback
>> experience on low spec devices.
>
>
> And rendering late frames will make recovery from transient hiccups more
> difficult and less likely. That seems like a terrible idea.

If this is about CPU usage, that could be a blocker. But if we know
it's not going to be heavy, we should do it. I don't know if there are
flags or way to tell that, but that could be handy.