YouTube introduces horizontal microstuttering despite clean 60fps CFR sourc

[Migue12HD]

Hi, I'm working with gameplay footage from Geometry Dash, recorded at CFR 60.000 fps in 720p. I upscale to 1440p and encode using libx264 in order to force VP9 on YouTube and preserve motion fidelity, but YouTube keeps introducing microstuttering during horizontal scroll scenes, even though the original file is visually clean.

Here's my FFmpeg command:



ffmpeg -ss 00:00:41 -i "source.mp4" -t 00:00:30 -vf "scale=2560:1440:flags=lanczos" ^
-c:v libx264 -preset veryslow -crf 16 -profile:v high -level 4.2 -pix_fmt yuv420p ^
-g 60 -keyint_min 60 -sc_threshold 0 -bf 2 ^
-b:v 40M -minrate 40M -maxrate 40M -bufsize 80M ^
-color_primaries bt709 -color_trc bt709 -colorspace bt709 ^
-x264-params "no-scenecut=1:force-cfr=1:qpmin=16:qpmax=18" ^
-r 60 -movflags +faststart



The original file is not 100% flawless—it has some fixed, minor shutters—but overall scroll fluidity is clearly present and consistent in local playback. After uploading, however, the result is much worse. YouTube playback loses all that smoothness entirely, turning it into constant micro judders, even with VP9 confirmed and full bitrate enforcement.


·The original video:

·The uploaded video: https://youtu.be/8Hz6XvqWsAc?feature=shared


So my questions are:

·Why does YouTube still introduce stutter even with fixed GOP, CFR, and high bitrate?

·Is it possible YouTube injects hidden scene cuts or breaks GOP cadence internally?

·Are there any real, tested ways to preserve scroll fidelity for 60fps gameplay?

·Has anyone found a consistent method to avoid this issue, especially in horizontal scrolling games like GD?

Any insight or shared experience is truly appreciated.

[davexnet]

Unable to download your "attached file", it says bad browser request. Site error?
The youtube video shows 4 or 5 duplicate frames per second causing the stutter issue

[Alwyn]

Same here. When I tried to download your attachment, Chrome gave me this:

"Bad Request
Your browser sent a request that this server could not understand."

[Baldrick]

It must be something wrong with the file name. Try remove the 100% in the name and reupload the file.

[october262]

Hi, I'm working with gameplay footage from Geometry Dash, recorded at CFR 60.000 fps in 720p. I upscale to 1440p and encode using libx264 in order to force VP9 on YouTube and preserve motion fidelity, but YouTube keeps introducing microstuttering during horizontal scroll scenes, even though the original file is visually clean.

Here's my FFmpeg command:



ffmpeg -ss 00:00:41 -i "source.mp4" -t 00:00:30 -vf "scale=2560:1440:flags=lanczos" ^
-c:v libx264 -preset veryslow -crf 16 -profile:v high -level 4.2 -pix_fmt yuv420p ^
-g 60 -keyint_min 60 -sc_threshold 0 -bf 2 ^
-b:v 40M -minrate 40M -maxrate 40M -bufsize 80M ^
-color_primaries bt709 -color_trc bt709 -colorspace bt709 ^
-x264-params "no-scenecut=1:force-cfr=1:qpmin=16:qpmax=18" ^
-r 60 -movflags +faststart



The original file is not 100% flawless—it has some fixed, minor shutters—but overall scroll fluidity is clearly present and consistent in local playback. After uploading, however, the result is much worse. YouTube playback loses all that smoothness entirely, turning it into constant micro judders, even with VP9 confirmed and full bitrate enforcement.


·The original video:
[Attachment 87500 - Click to enlarge]

·The uploaded video: https://youtu.be/8Hz6XvqWsAc?feature=shared


So my questions are:

·Why does YouTube still introduce stutter even with fixed GOP, CFR, and high bitrate?

·Is it possible YouTube injects hidden scene cuts or breaks GOP cadence internally?

·Are there any real, tested ways to preserve scroll fidelity for 60fps gameplay?

·Has anyone found a consistent method to avoid this issue, especially in horizontal scrolling games like GD?

Any insight or shared experience is truly appreciated.

try what is in this reddit thread - https://www.reddit.com/r/ffmpeg/comments/1h2y711/using_ffmpeg_to_remove_slight_stuttering_effect/

[Selur]

About the link: seems to be a bug in the board software.
Board creates:

https://forum.videohelp.com/attachments/87501-1750351558/OLD%20TRAP%20100%%20-%20Proyecto_09-02_Full%20HD%201080p.mp4

as link, but it doesn't escape the '%', working url is:

https://forum.videohelp.com/attachments/87501-1750351558/OLD%20TRAP%20100%25%20-%20Proyecto_09-02_Full%20HD%201080p.mp4

Cu Selur

Ps.: In Vapoursynth or Avisynth, one could 'fix' it by replacing the duplicates with interpolations. (no clue whether this can be done with ffmpeg)

[Alwyn]

It looks to me like the ORIG 1080 file and the YT file are exactly the same, to the frame. Here they are, side by side.

[Migue12HD]

With this link you can get the original video: https://forum.videohelp.com/attachment.php?attachmentid=87501&stc=1&d=1750351558

[Migue12HD]

Now I'm only an enthusiastic amateur at this game so I could have it wrong but it looks to me like the ORIG 1080 file and the YT file are exactly the same, to the frame, so the issue must be with the YT server or the YT browser player. Here they are, side by side.

There’s something I need to point out, because I’ve noticed a weird exception in my case.
Out of all the videos I’ve uploaded to YouTube using the exact same FFmpeg command, only one of them looks perfect and smooth on my PC, just like the original file. No extra microshutters, completely clean playback.

But every other video I upload looks bad on PC, with visible stuttering that isn’t present in the source file.

So my question is: How is it possible that one video was uploaded and preserved perfectly, but the rest, using the same encoding process, are all affected?
Same settings, same resolution, same bitrate, same encoder.

This single exception makes no sense, and I’m trying to figure out what YouTube did differently for that one upload.

Do you have any idea why something this strange could happen?

[davexnet]

That 336mb video just uploaded matches the youtube download for the first 2 or 3 seconds (that's all I checked),
there is a duplicate frame causing a stutter at frames 13-14, 45-46, 52-53, 61-62, 89-90.
It can be seen clearly by dropping the video into vdub2 and using the right arrow key to advance one frame at a time.

The problem may have occurred during the capture

[Alwyn]

The attached file in post 8 is the same as the initial one. I should have been more explicit in my post #7: as Dave has pointed out, there are duplicates/jumps in your original file, and YT has simply replicated them. If you step through my comparison file, you will see the jumps in the original are replicated in the YT version. I have amended my earlier post to remove reference to the YT server.

[jagabo]

Both davexnet and Alwyn are right. The source and the file downloaded from youtube are the same, frame for frame (aside from compression artifacts, obviously). The jerkiness problem is in your source.

Since we can't see what's on your monitor: it's also possible you have a playback issue with the streamed video. For example, your browser might be playing a VP9 version of the video and having problems keeping up.

[Migue12HD]

The attached file in post 8 is the same as the initial one. I should have been more explicit in my post #7: as Dave has pointed out, there are duplicates/jumps in your original file, and YT has simply replicated them. If you step through my comparison file, you will see the jumps in the original are replicated in the YT version. I have amended my earlier post to remove reference to the YT server.

The original video has shutters in the horizontal scroll, and the goal is to upload it without adding more shutters.
Although I have noticed that the video looks better and even almost the same or almost the same as the original if viewed on the YouTube app from a good phone or tablet. At least, testing I've seen that.

[Migue12HD]

Both davexnet and Alwyn are right. The source and the file downloaded from youtube are the same, frame for frame (aside from compression artifacts, obviously). The jerkiness problem is in your source.

Since we can't see what's on your monitor: it's also possible you have a playback issue with the streamed video. For example, your browser might be playing a VP9 version of the video and having problems keeping up.

That's what I think it is. I had a lot of doubts, but honestly I think it's most likely to be the cause of the shuttering, because it's displayed in the browser.
I watched the videos from the tablet on YouTube and the fluidity was much better.

[jagabo]

Try different browsers: Edge, FireFox, Chrome... Try turning off/on hardware acceleration within the browsers. Try different computers (ie, different CPUs,graphics devices, monitors).