VLC: Jerky MP4 playback

[terrypin]

Using VLC 2.0 I've recently realised that playback of many of my 1920 x 1080 MP4 files is jerky/stuttery. Not enough to be unusable, but disappointing nevertheless. Up until now I'd put it down to the files, perhaps poor export settings by me in my video editor (Magix Movie Edit Pro MX). But today I compared it with playback in WMP which was rock steady.

Anyone else seen similar please?

--
Terry, East Grinstead, UK

[Hoser Rob]

Depending on your hardware h.264 playback can stutter even with dvd res files. Seems to me a single core machine will have trouble in cany case unless it's an encode with the bit rate reduced.

vlc, as of v. 2.0, doesn't support file stream caching setup anymore. I find this a big problem. Caching is very important for good quality on computers that aren't gaming machines. I can't get high quality h.264 video (stuttering or not) on my dvd rips with 2.0 on my i3 box, let alone HD video.

Older versions of vlc that do let you set up a local file cache may work better, though if you use it for web streaming anything <= 1.05 isn't secure anymore.

I still use vlc in windows but almost always as a music player. My main video player is smplayer (with file cache set to 8192K). It gives me better quality video than anything else without ridiculously cockeyed setup (like mpchc) or needing codec packs.

[terrypin]

Thanks. I've now changed MP4 file association to WMP, as I find that jerkiness from VLC unacceptable (on this quad core XP PC)..

--
Terry, East Grinstead, UK

[natalia25]

terrypin, problem in VLC could be the choice of "Video Output Module" - under Prefs/Video/Output Modules/.
Depending on your GPU & installed drivers, there are difference choices under the drop box.

After upgrading my Nvidia drivers, VLC suddenly wouldn't play many higher res movies. My VLC video output module was on "Default," whatever that means. I chose OpenGL - one that the Nvidia drivers support. Problem solved.

Other output modules that may work (choices will vary depending on your system / GPU & driver version):
Direct 2D
Direct 3D
Possibly others - you can experiment.

Other excellent, open source players as substitutes for WMP-
Media Player Classic - Home Cinema & SMPlayer - both avail. from Sourceforge - both popular.
MPC-HC has simpler GUI; SMP is similar to VLC in configurability. Both played my few problem vids w/ default settings, but may still have video output module choices that give better (or at least different look / color) for vids.

[terrypin]

Many thanks, Natalia, I'll experiment with those promising suggestions.

--
Terry, UK

[Rick-in-TO]

I'm using VLC 2.2.1 and noticed this problem using only very large format (say <= 1800 by n). My display is set to 1920 x 1200. By experimentation, I solved it myself. I had checked on "Sharpen" under Video Effects (CTRL-E). I'm supposing that the CPU couldn't keep up with the large layout. Anyway, with Sharpen checked off, (and who needs it with this large a format?) the playback was smooth.

[svcdmaker]

Do you have deinterlace turned on? While you may not be dealing with a true deinterlace problem, turning on deinterlace and selecting a deinterlace mode will smooth out studder.

[Hoser Rob]

Actually newer VLC releases do support local file cache size adjustment again. I don't know when this happened since I almost always use SMplayer to watch video. But that's an essential feature IMO. It really makes a quality difference.

Go into vlc preferences, go to advanced, then it's under inputs/codecs -> advanced. The default when I checked was 300Msec local cache buffer. I'd increase that to at least 2000Msec. Too much cache will slow the program down but it's hard to predict when that happens.

[Rick-in-TO]

Do you have deinterlace turned on? While you may not be dealing with a true deinterlace problem, turning on deinterlace and selecting a deinterlace mode will smooth out studder.

Reply: I tried all the various settings on that panel including deinterlace. The only one that had an effect for me in eliminating the stutter was 'Sharpen', as I said above. I'm not saying that my solution is the solution but it's worthwhile trying for those who have problem with large-format movies. Thanks for your interest. R.

[Bigbird]

The MP4 video that I have taken on my Galaxy (Android) GS5 is smooth as silk during playback on the phone. When I upload the video to this computer and use VLC 2.2.1 to playback it is very jerky and choppy. Sometimes the video blanks out briefly. I have tried increasing the cache from 300 to 2000 and in between. Sharpen is off. Any more things that I can try? After I save a change do I need to close VLC and restart or reboot the computer?

[Rick-in-TO]

Sorry. Can't help you, BigBird. I'm just another user and I've already said everything I know. Play around with it. I did not have to reboot but that doesn't mean you might not have to.

[Bigbird]

I just learned a lot and I'm going to share. The MP4 that I loaded from my GS5 to this computer was 181mb. It would not play without a lot of crap in it. I even downloaded SMPlayer and tried it. Video played great but the audio would stop stutter and start again. No good. I then remembered that I had Freemake Video Converter. I converted the original MP4 file to another MP4 file. Played the new MP4 file in VLC and SMPlayer and WOW, smooth as glass. In the process of converting from MP4 to MP4 it went from 181mb to 21mb. The new file is DVD quality.

[Interpolator]

This is likely an x265 issue, but I'll chime in anyways, as it's a jerky video playback issue.

Regarding VLC performance, I've tried adjusting to the cache as described above, and I'm having a "jerky" playback problem with one transcode from x264 to x265. I thought it might be playback, so I did a lossless x265 -> HuffYUV transcode, lowering the resolution by 70% in both scales. Same results. The containers are both MKV. The source drive is an SSD (Win7 64bit, quad-core 3.0Ghz), and there's plenty of CPU and memory available, at least per taskmgr. Were resources an issue, the source would likely chop, too.

This leads me to believe using x265 ultrafast presets, or possibly x265 entirely may result in the choppy playback, but that's just a marginally-educated guess. I'll do some more testing and try playing with other media players and see what the results are.

Bigbird, you mention the containers and playbacks, but not any specifics such as source and destination codec, bitrate, frame rate, resolution, encoder settings, etc. if the source and destination are the same codec, a 21mb file will play far smoother one would think than a 181mb, but there is likely some kind of quality loss, somewhere along the line, unless there's a big inefficiency in the 181mb source.

21mb is not typically enough for much quality except for short clips (such as a music video), probably at moderate resolution, such as on a phone, but that's a generalization. Actual mileage may vary.

[Interpolator]

...update. I have yet to verify it through testing, but I realized the problem not long after posting the last msg. Variable Frame Rate (VFR) source. The original video source is Constant Frame Rate (CFR) and I'm working with an x264 transcode where some idiot decided it would be a good idea to convert the MPEG2 source it to VFR. I opted to bring it back to what I thought was the correct original frame rate (23.976) but it's almost certainly 29.970 since the original is NTSC.

Bigbird, you might check your frame rates and see if there's a VFR problem somewhere.

Friends don't let friends:
1) Encode CFR sources to VFR (with rare exceptions for certain types of source material)
2) Use "packed bitstreams" in Xvid (not much of an issue anymore, it's an old codec)
3) Use VBR MP3 audio in .AVI containers (audio sync, also a legacy issue)
4) Use auto-correct in their text editors.

[Bigbird]

This is likely an x265 issue, but I'll chime in anyways, as it's a jerky video playback issue.

Regarding VLC performance, I've tried adjusting to the cache as described above, and I'm having a "jerky" playback problem with one transcode from x264 to x265. I thought it might be playback, so I did a lossless x265 -> HuffYUV transcode, lowering the resolution by 70% in both scales. Same results. The containers are both MKV. The source drive is an SSD (Win7 64bit, quad-core 3.0Ghz), and there's plenty of CPU and memory available, at least per taskmgr. Were resources an issue, the source would likely chop, too.

This leads me to believe using x265 ultrafast presets, or possibly x265 entirely may result in the choppy playback, but that's just a marginally-educated guess. I'll do some more testing and try playing with other media players and see what the results are.

Bigbird, you mention the containers and playbacks, but not any specifics such as source and destination codec, bitrate, frame rate, resolution, encoder settings, etc. if the source and destination are the same codec, a 21mb file will play far smoother one would think than a 181mb, but there is likely some kind of quality loss, somewhere along the line, unless there's a big inefficiency in the 181mb source.

21mb is not typically enough for much quality except for short clips (such as a music video), probably at moderate resolution, such as on a phone, but that's a generalization. Actual mileage may vary.

Thanks for the comments. I am not a video techie as you obviously are. I don't understand much of what you are talking about. The 21mb video did suffer a small amount of resolution and sharpness loss but the trade off from the ragged playback of the 181mb file is very easy to deal with. The file is only 1:28 minutes. I turned on video Sharpen in Effects and the file looks as good as the brief good parts of the 181mb file.

One more comment. The audio problem that I mentioned when using SMPlayer completely cleared up on the 21mb file. I can't tell any difference when playing back on VLC or SMPlayer.

[Hoser Rob]

... The audio problem that I mentioned when using SMPlayer completely cleared up on the 21mb file. I can't tell any difference when playing back on VLC or SMPlayer.

Have you tried different audio output modules in SMplayer settings? I used to use SMplayer as me default for Windows 7. I still do but I just use Linux now so I forget the exact details. But both VLC and SMplayer are linux ports and they have their own codec libraries. That's why I used them both in Windows. They don't need or use codec packs.

[Bigbird]

... The audio problem that I mentioned when using SMPlayer completely cleared up on the 21mb file. I can't tell any difference when playing back on VLC or SMPlayer.

Have you tried different audio output modules in SMplayer settings? I used to use SMplayer as me default for Windows 7. I still do but I just use Linux now so I forget the exact details. But both VLC and SMplayer are linux ports and they have their own codec libraries. That's why I used them both in Windows. They don't need or use codec packs.

No, I haven't tried other audio output modules since I am very satisfied with the video is now working. I'm still running Vista.

[Hoser Rob]

... The audio problem that I mentioned when using SMPlayer completely cleared up on the 21mb file. I can't tell any difference when playing back on VLC or SMPlayer.

Have you tried different audio output modules in SMplayer settings? I used to use SMplayer as me default for Windows 7. I still do but I just use Linux now so I forget the exact details. But both VLC and SMplayer are linux ports and they have their own codec libraries. That's why I used them both in Windows. They don't need or use codec packs.

No, I haven't tried other audio output modules since I am very satisfied with the video is now working. I'm still running Vista.

Changing the audio output module won't affect the video performance.

[Interpolator]

No worries on not being too familiar with video compression, everyone has to start somewhere. Others here may be able to suggest a good guide for educating yourself on the basics, and there's the "Guides" menu at the top here.

The things to keep in mind are what you're asking your video player - and hardware - to do. Higher bitrates mean more data in a shorter amount of time, but demand more CPU. Newer codecs are generally more efficient than older ones, within each codec, there's various settings that will also affect decoder-demands. Higher resolution is more demanding than lower resolution. 30fps is more demanding than 24fps.

Obviously the audio can be choppy if there's not enough CPU to decode the video and audio both, and the player is not designed well enough to prioritize smooth audio. Lots of factors.

This is likely an x265 issue, but I'll chime in anyways, as it's a jerky video playback issue.

Regarding VLC performance, I've tried adjusting to the cache as described above, and I'm having a "jerky" playback problem with one transcode from x264 to x265. I thought it might be playback, so I did a lossless x265 -> HuffYUV transcode, lowering the resolution by 70% in both scales. Same results. The containers are both MKV. The source drive is an SSD (Win7 64bit, quad-core 3.0Ghz), and there's plenty of CPU and memory available, at least per taskmgr. Were resources an issue, the source would likely chop, too.

This leads me to believe using x265 ultrafast presets, or possibly x265 entirely may result in the choppy playback, but that's just a marginally-educated guess. I'll do some more testing and try playing with other media players and see what the results are.

Bigbird, you mention the containers and playbacks, but not any specifics such as source and destination codec, bitrate, frame rate, resolution, encoder settings, etc. if the source and destination are the same codec, a 21mb file will play far smoother one would think than a 181mb, but there is likely some kind of quality loss, somewhere along the line, unless there's a big inefficiency in the 181mb source.

21mb is not typically enough for much quality except for short clips (such as a music video), probably at moderate resolution, such as on a phone, but that's a generalization. Actual mileage may vary.

Thanks for the comments. I am not a video techie as you obviously are. I don't understand much of what you are talking about. The 21mb video did suffer a small amount of resolution and sharpness loss but the trade off from the ragged playback of the 181mb file is very easy to deal with. The file is only 1:28 minutes. I turned on video Sharpen in Effects and the file looks as good as the brief good parts of the 181mb file.

One more comment. The audio problem that I mentioned when using SMPlayer completely cleared up on the 21mb file. I can't tell any difference when playing back on VLC or SMPlayer.

[gijoe50000]

Ok so what works for me is to disable Hardware-Accelerated Decoding in Inputs/Codecs.

I have 2 GTX 970s but they don't seem to work correctly with VLC at all. Just because you have good hardware doesn't mean it's going to work properly with vlc.

I usually disable Sharpening too.