[vlc-devel] Dropped frames despite ample CPU idle time?

Juha Jeronen juha.jeronen at jyu.fi
Thu Jun 13 09:29:58 CEST 2013


On 12.06.2013 18:41, Rémi Denis-Courmont wrote:
> On Wed, 12 Jun 2013 16:38:10 +0100, Finn Hughes <finn.hughes1 at gmail.com>
> wrote:
>> I'm not familiar enough with the vlc chain to know what's going on, the
>> decoder isn't reporting dumping any frames so I assume all frames are
>> being decoded and it's just that there is too much jitter in the
>> "decode" chain?
> It could be excessive jitter as the synchronization no longer seem to
> strictly obey the caching setting. It could be that the decoder outputs
> corrupt timestamps, or the packetizer, or the demuxer, or the source media.
> It could be that the video output renders too slowly. It could be a bug in
> the input synchronization or decoder code.

One more possibility: it could be the deinterlace filter. I don't know 
whether VLC calls filters as soon as new frames become available in the 
buffer, or whether filters are called just before each frame is to be 
displayed. If the latter, and if there is variation in the time it takes 
to deinterlace each frame, this could explain why frames are getting 
dropped, since Yadif2x is the CPU-heaviest deinterlacer in VLC.

But on the other hand, if the busiest core is 60% idle, maybe this isn't 
likely. Just a possibility.

The behaviour with the dummy output seems to rather point to the output 
side.

  -J




More information about the vlc-devel mailing list