The VideoLAN Forums

Not really a bug in VLC, more like MacOS itself, I notice perfectly smooth playback of .h264 files with Quicktime Player X, as opposed to using legacy Quicktime 7 or VLC (or any other media player for MacOS) on latest supported Mac mini, as well as 12" Macbook.

Using Quartz debug, I can monitor the fps of Quicktime Player X while it is actively playing a 29.97fps .m4v file, and the Quartz Debug Framemeter is sitting at about 40-44 fps, and the video is 100% smooth and stutter-free, perfect.

When I play the same file in VLC or legacy Quicktime, Quartz Debug Framemeter is at 30 fps, and the video on the screen has perceptible micro-stuttering.

Is there a way to configure VLC to use the same API that the latest Quicktime uses to interface with the GPU? It would really make the VLC experience so much better.

Something new I noticed. When playing any video file with Quicktime Player X, VTDecoderXPCService is invoked, as seen in Activity Monitor (CPU).

When I play any video with VLC, I notice that VTDecoderXPCService is NOT invoked. Is there a way to force VLC to use VTDecoderXPCService? I would like to see if there is a difference in video quality (smoothness).

edit: Nevermind. VTDecoderXPCService has more to do with sandboxing than decoding. So, I guess it wouldn't make a difference. Maybe I should be looking at how libsdl works instead?

edit: I thought I was on to something last night when I was experimenting with OpenGL Driver Monitor, but it turns out my results were flawed. Please disregard the test files I posted here earlier.

I ended up turning off Hardware Acceleration in VLC and I was getting the same micro-stutters every 16 seconds. So, using OpenGL Driver Monitor for troubleshooting is pointless if HW acceleration is off. Something else is going on.

Ok, I think I finally figured out what the problem is. All my mp4 files are sourced from NTSC DVD or North American Blu-rays. When I transcode the DVD/BD rips to mp4, I have been keeping the frame rate the same as the source, such as 23.98p, 24p, 29.97i/p, 30p.

When VLC plays these video source frame rates, there is very noticeable stutter because it does not match the 60hz refresh rate of my display.

Tonight I experimented by re-encoding one of these mp4 with a constant 60fps. VLC plays the 60fps video without any stutter! It looks just the same now as it does when Quicktime X plays back the file, nice and smooth, absolutely flawless.

So I guess Quicktime X is somehow able to play all these files with their original source frame rates without any stutter. It is able to sync the video frame rate to the monitor refresh automatically. This behavior is not happening with VLC though.

Is there anything else I can do besides re-encode my entire video library in order for VLC to playback these files smoothly? Is there anyway VLC can perform similar behavior to Quicktime X regarding synching frame rate to monitor refresh rate?

P.S., I also tried the same files (with original source frame rate) with the latest VLC in Windows 7, and they experience the same stutter, but they playback perfectly smooth with Windows Media Player (as smooth as they do in Quicktime X on MacOS). So I am thinking it is the same situation with monitor refresh rates with VLC on Windows.

Thank you for any advice you can give on this!

i think most monitors run at 60 Hz. the framerate of the video file shouldn't really matter. not sure what you're seeing exactly.

"not sure what you're seeing exactly."

Thanks for your reply. What I am seeing is a micro-stutter that lasts for 1-3 seconds and occurs about every 15 seconds.

This micro stutter does not occur when I use Quicktime X, Windows Media Player, or if I re-encode the video to a constant frame rate that matches the refresh rate of the display.

What I want to do to prove my case is to set up a side-by-side playback window of the same video file with VLC and Quicktime X, and record the screen to capture the comparison of the two. You will then be able to see a frame-by-frame comparison of the two and you will also see where VLC's window is skipping frames on the final output (when the micro-stutter occurs), where Quicktime X does not skip a single frame. I will try to set this up and upload to dropbox and paste the link here sometime this week.

Please share your logs.

Here is the log when playing back the mp4 video file with frame rate of 29.98. When the stuttering occurs, there is no log activity going on at the same instance, so I think whatever visual artifacts/stuttering is occuring, it is happening at a point in VLC's pipeline that is beyond what the log can capture. I really think there is a problem with the way VLC hands-off the video output to the OS.

For instance, if I record playback of the 29.97 fps file with VLC's record feature, and I play back that recording, I see absolutely no stutter. That is an important statement because it means that VLC itself is decoding and playing back the file without any error or perceptible stutter from within it's own "domain" (before the video goes to GPU). It is what happens to the video AFTER it leaves VLC and is handed to the OS to process, that is when the stuttering occurs.

This same stuttering behavior occurs (with the same file) using other media players as well, such as LEGACY-Quicktime (version 7 and prior), Elmedia, mpv, Mplayerx, basically anything OTHER than the modern Quicktime X (or Windows Media Player on Windows). However, that statement should not be used as excuse as to why VLC exhibits this behavior. Because I know that the file plays back in smooth in native OS apps, such as Quicktime X, and I know that reencoding the file with constant FPS to match the monitor refresh shows that VLC is capable of playing the file 100% smooth.
VLC 3.0.4
MacOS 10.13.6

quicktime x likely utilizes frameworks or private APIs to access the gpu hardware directly. if the stuttering is happening with other media players, then it's probably not an issue specific to vlc. the fact that it happens every 15 seconds also seems like it's a system issue, not vlc.

i'm still curious to see what this stuttering looks like though. instead of recording with screen capture tool, could you maybe record the monitor using an iphone or video camera pointed at the screen and recording at 60fps.

also might help to post more details regarding your video file (bitrate, codecs, etc.)

i use a 2011 mac mini with intel hd 3000 with 60Hz monitor and have no issues playing back 1080p h264/hevc with hardware acceleration setting disabled. currently using this nightly version:
https://nightlies.videolan.org/build/ma ... 8-0711.dmg

I’ve uploaded a few files to dropbox to help provide evidence of the stuttering I am seeing, with hopes that you can see it too, so that we can all agree that the issue exists and we can move forward with a fix action.

The files contain a short clip (02:38) of a documentary on early 1930’s animation history. I know it may not be the most exciting subject matter to watch, but I chose it because it contains a lot of panning scenes and Ken Burns effects, which provide a more effective way to positively identify the visual anomaly that I am seeing.

There are two source files of the same content. One is produced in it’s native 480p 29.97 fps, and the other is produced at 720p 60fps. See Dropbox files “Stutter Test 480p 2997” and “Stutter Test 720p 60” here:
https://www.dropbox.com/s/y42ldoabyxh1c ... 7.mp4?dl=0
https://www.dropbox.com/s/7jjd0u1ly3ybo ... p.mp4?dl=0

I used Quicktime Player X’s Screen Recording feature to record the playback of the 29.97 fps file in separate VLC and Quicktime X windows for side-by-side comparison. There is no audio during playback of the recording as it is only a video capture of the screen. Also visible on the MacOS desktop are two text documents; one containing my system specs, and another containing a list of predicted instances of the stuttering based on 16-second intervals. With the help of a timer in the upper right of the menu bar, I started the clock from the first instance of the stutter as seen in VLC’s window. After 16 seconds, another occurrence of stutter is observed, and this phenomena repeats every 16 seconds until the end of the video. You can follow along with the text document in the lower right of the desktop in the screen capture to see when the stuttering is predicted to occur, and you can compare that to the actual stutter you see during that timeframe. I tried to highlight the times in the text document as they coincided with the timer and the stutter. Comparatively, there is no stutter in Quicktime X’s window. Playback with Quicktime Player X is completely smooth from start to finish. See Dropbox file "Comparison Stutter Test 480p 2997 1” here:
https://www.dropbox.com/s/9zw7g5fhdtlgr ... 1.mov?dl=0

I repeated this same exact experiment two more times so as to show that the stutter happens in VLC once every 16 seconds no matter when the video is started. In other words, the stutter is observed at different parts of the same video window no matter how many times the file is played, and therefore proves that there is no defect with the source video file itself (there are no missing frames). See Dropbox files “Comparison Stutter Test 480p 2997 2” and “Comparison Stutter Test 480p 2997 3” here:
https://www.dropbox.com/s/k0z5nz76l1f92 ... 2.mov?dl=0
https://www.dropbox.com/s/gxaugpp31vh0q ... 3.mov?dl=0

Lastly, I recorded the screen again as above, but this time using the 720p 60fps source file. The file played back completely smooth in both VLC and Quicktime Player X. See Dropbox file “Comparison Stutter Test 720p 60” here:
https://www.dropbox.com/s/kx66jhv8l6w9g ... 0.mov?dl=0

Conclusion: VLC playback produces stutter on final video output unless the source video fps matches the display refresh rate. VLC should have the inherent ability to playback industry standard video frame rates without causing stutter or other artifacts as a basic feature of any modern day media player.

Has there been any update or solution to this?

---

edit: V1.0.0 does not have this problem, all version thereafter do.