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

Steve Lhomme robux4 at videolabs.io
Fri Feb 27 10:33:44 CET 2015

On Fri, Feb 27, 2015 at 10:01 AM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le 2015-02-27 11:48, Steve Lhomme a écrit :
>> One of the odd things about this bug, that you can see in the issue:
>> https://trac.videolan.org/vlc/ticket/10114
>> Is that `main warning: picture is too late to be displayed (missing 54
>> ms)`
>> The renderer has the picture already decoded but refuses to show it.
>> Just because it's late. I understand it might just show some
>> desynchronization with the sound (this file has no sound) but is it
>> better to not display anything when your CPU is overloaded ?
> 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. 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.

> --
> Rémi Denis-Courmont
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel

More information about the vlc-devel mailing list