The VideoLAN Forums

I have been using VLC on Linux for about 8 years, and I always get screen glitches (mostly grey screen with huge pixel chunks, that last for about ~5 seconds, or until the scene shown on screen changes) whenever the file bitrate is too high and the video is very active (as in, there is action happeing, or in the worse case, the scene is panning view). I always thought that it was just something I have to accept when using VLC on Linux but today, I saw the "Inputs / Codec > File Cache" setting, and saw that the default cache of 300 milliseconds worth of data is on the small side, so I tried increasing it (tried 10 seconds or 10000 milliseconds) and to my surprise, the problem is fixed! This proves that the 300 milliseconds cache is too small (so when the scene suddenly becomes active, the bitrate also increases, so the cache is depleted early, but when VLC requests from more data from hard disk (I don't have an SSD), the hard disk can't give data in a short time so VLC glitches. Also, another proof that disk cache is the problem is that my CPU is far from 100% (just around 25%) while playing even 1080p H265 (HEVC) 10-bit videos, so it's definitely not a CPU issue. The only thing I had to do is increase the file cache to a reasonable amount (10 seconds works fine to me, but I didn't try finding the lower value that doesn't glitch. 10 seconds works, and I'll just leave it at that.) 8 years of keeping up with screen glitches, only because the file cache is too small.

I highly suggest changing the default file cache size to more than 300 milliseconds--I suggest 5 to 10 seconds. Let's avoid having someone else waiting 8 years before he/she realizes the fix to the problem.

I tried to increase it to 1 and 10 seconds, it doesn't help to resolve choppy sound issue on VCD (https://forum.videolan.org/viewtopic.php?f=2&t=144262).

More over, when the cache is at 10 secs, it becomes very difficult for me to fast forward/backward the video and gives hang impression (freezing for about 10 seconds) as the video does not instantaneously play when it jumps to the specific time.

I would second the suggestion that the default cache size is too small.

Problem:
Video output freezes while audio keeps going after using the "jump around" keys on a DVD.

Steps to reproduce:

1. Play a DVD (select a "chapter" from the menu)

2. Use the various "jump around" keyboard shortcuts to find a specific spot in the "chapter".

3. Observe playback. The problem occurs. (The video output may eventually recover; I did not have a lot of time to wait and see if it would.)

Solution/Workaround:

Increase the "Disk Chaching (ms)" setting to 20000. Problem solved. Perhaps there is the occasional slight pause (which is expected with a lager cache), but it generally plays as it should.

I suspect that increasing the cache size is a "try this first" solution for many video output issues. Also, maybe the default cache size is reasonable (at least theoretically) for "the average" system. In this case, having to increase the cache may reflect a deeper deficiency, which may have to do with the input itself (i.e. the DVD, video file, etc), VLC, or the individual computer's hardware. But if increasing the cache size works for most of the "average Joes" who just want proper video playback, maybe the default cache size should be increased?

More over, when the cache is at 10 secs, it becomes very difficult for me to fast forward/backward the video and gives hang impression (freezing for about 10 seconds) as the video does not instantaneously play when it jumps to the specific time.

This delay is an expected possible consequence of increasing the cache. The computer will wait until it has a full 10 seconds of video read off of the disc before it will resume playback after a fast forward/backward.

CDs are read at a lower speed than DVDs. This is probably a significant part of the reason why I can get away with a 20 second cache (no playback until 20 seconds of video copied) with a DVD, but yet mchsmith sees a delay (freezing) with only a 10 second cache with a VCD (CD).

Solution/Workaround:
Increase the "Disk Chaching (ms)" setting to 20000. Problem solved.

I did not check to see how little cache you could get away with; all I know is that 20 seconds works for me.

"File caching" and "Disc caching" should be set to 5000 ms at least in default settings. 5 seconds spin-up time is reasonable amount for optical disks and platter hard disks with energy saving features. This would prevent lots of stutter complaints.

This sounds like a good change to have.

With default settings, I noticed massive amounts (almost 1%) of 'lost frames' while playing FHD videos on hardware/platform conditions that should easily have handled them (PM981 SSD which can read the full video file into RAM in less than 200ms, free RAM that can host tens of those video files, 6 core modern CPU under load average numbers less than 0.3, and an iGPU that can decode UHD).

After mucking around with real-time scheduling, decoders, priorities and many others settings which didn't resolve the issue, I finally stumped upon this thread and surely a 1000ms cache solved it (even 600ms would make lost frames go to 0).

300ms is probably too aggressive or too dependent on an ideal world. It might have already caused and will continue to cause many to believe that their issues are ' just something they have to accept when using VLC ' and subsequently move on to other players (for good).

On the other hand, this is such an easy change in terms of coding, and a slightly higher default cache amount like 1000ms wouldn't be very noticeable in today's world, as even HDDs nowadays can read sequentially at fairly high speeds.