ffmpeg is creating stutter in the video

[Chrushev]

I am recording off of Plex DVR, which then transcodes the video into x265 via ffmpeg. This randomly happens for a few seconds in each episode. At this particular time it is around 10min 30sec mark. Some episodes its pretty constant. Anyone know whats causing it and how to solve it?

Sample here- https://mega.nz/file/e9UiiTaI#9KHalVeb1k948wsZuyq_QDg9aCBXcikDgj-6kdVzOW8

[october262]

I am recording off of Plex DVR, which then transcodes the video into x265 via ffmpeg. This randomly happens for a few seconds in each episode. At this particular time it is around 10min 30sec mark. Some episodes its pretty constant. Anyone know whats causing it and how to solve it?

Sample here- https://mega.nz/file/e9UiiTaI#9KHalVeb1k948wsZuyq_QDg9aCBXcikDgj-6kdVzOW8

what is your ffmpeg command that you are using ?? try with -c:v libx264 -c:a copy instead of -c copy
https://www.reddit.com/r/ffmpeg/comments/i2k5do/need_help_with_stuttering_issue/

[Chrushev]

I am recording off of Plex DVR, which then transcodes the video into x265 via ffmpeg. This randomly happens for a few seconds in each episode. At this particular time it is around 10min 30sec mark. Some episodes its pretty constant. Anyone know whats causing it and how to solve it?

Sample here- https://mega.nz/file/e9UiiTaI#9KHalVeb1k948wsZuyq_QDg9aCBXcikDgj-6kdVzOW8

what is your ffmpeg command that you are using ?? try with -c:v libx264 -c:a copy instead of -c copy
https://www.reddit.com/r/ffmpeg/comments/i2k5do/need_help_with_stuttering_issue/

ffmpeg -i "$FILENAME" -s hd720 -c:v libx265 -r 24 -preset veryfast -crf 26 -vf yadif -codec:a libfdk_aac -ac 2 -b:a 128k -async 1 "$TEMPFILENAME"

I need to be able to downconvert to stereo as a lot of OTA tv is in 5.1 so I cant just copy the audio.

[ProWo]

Omit - r 24

[Chrushev]

Omit - r 24

But Id like to reduce FPS down from 60 to 30 or less. Is there a way to do this. I suspect this may be the cause, but there is got to be a way to do it without stuttering? As I said before stuttering is not continuous, happens only a few times in a video.

[ProWo]

You have to know rhe source fps first.
If it's 60 fps g.e. then use - r 30 to drop every secon frame.
you cannot go from 60 to 24

[jagabo]

The source of your video was 24p. It was broadcast as 60p by duplicating frames in a 3:2 pattern: 0 0 1 1 1 2 2 3 3 3... You can't convert back to 24p using the -r 24 filter because it uses a simple mathematical decimation that's not content aware. It has to remove 3 of every 5 frames to go from 60p to 24p. Sometimes the decimation will coincide with the duplication pattern:

0 0 1 1 1 2 2 3 3 3  : duplication pattern (original frames duplicated in 2:3 pattern)
+ - + - - + - + - -  : + means keep, - means discard, 3 of every 5 discarded
0   1     2   3      : correct decimation

Sometimes it won't:

0 0 0 1 1 2 2 2 3 3  : duplication pattern (original frames duplicated in 3:2 pattern)
+ - + - - + - + - -  : + means keep, - means discard, 3 of every 5 discarded
0   0     2   2      : incorrect decimation

That is what's happening to your video. The stuttery parts are where the decimation left your video with 2 copies of every other original film frame. Changing the frame rate to 30p won't work either. It will leave you with a duplicate every 4 frames. You need to use a smarter decimation method. One that is content aware so it adapts to changes in the duplication pattern. Unfortunately, ffmpeg's decimate filter doesn't support "M in N" decimation (only "1 in N"). And it's not thread safe so you can't chain three of them together (-vf decimate=5,decimate=4,decimate=3 will eat up all system memory and crash after a while). -vf fps=23.976 might work.

[ProWo]

@Jagabo
Not every video source is 24fps.

[jagabo]

Not every video source is 24fps.

Of course. But the video the OP supplied in his first post was obviously originally 24p.

[richardpl]

Fixed bug with decimate filter in FFmpeg, It was nothing about threading, Now cascading decimate fitlers works as expected. (Note that last few frames from input video are not decimated, i think this is expected behavior)

[Chrushev]

The source of your video was 24p. It was broadcast as 60p by duplicating frames in a 3:2 pattern: 0 0 1 1 1 2 2 3 3 3... You can't convert back to 24p using the -r 24 filter because it uses a simple mathematical decimation that's not content aware. It has to remove 3 of every 5 frames to go from 60p to 24p. Sometimes the decimation will coincide with the duplication pattern:

0 0 1 1 1 2 2 3 3 3  : duplication pattern (original frames duplicated in 2:3 pattern)
+ - + - - + - + - -  : + means keep, - means discard, 3 of every 5 discarded
0   1     2   3      : correct decimation

Sometimes it won't:

0 0 0 1 1 2 2 2 3 3  : duplication pattern (original frames duplicated in 3:2 pattern)
+ - + - - + - + - -  : + means keep, - means discard, 3 of every 5 discarded
0   0     2   2      : incorrect decimation

That is what's happening to your video. The stuttery parts are where the decimation left your video with 2 copies of every other original film frame. Changing the frame rate to 30p won't work either. It will leave you with a duplicate every 4 frames. You need to use a smarter decimation method. One that is content aware so it adapts to changes in the duplication pattern. Unfortunately, ffmpeg's decimate filter doesn't support "M in N" decimation (only "1 in N"). And it's not thread safe so you can't chain three of them together (-vf decimate=5,decimate=4,decimate=3 will eat up all system memory and crash after a while). -vf fps=23.976 might work.

Thanks, should I be using -vf fps=24 instead of -r 24 ? Whats the difference between those?

I have also tried -r 24000/1001 before going to 24, but it had the same issue.

Maybe my reasoning behind going down to 24 fps is silly, please correct me if I am wrong. But these are DVR shows to watch one time by my family, so I want to have them watchable but not take up all of my HDD space. So I have quality set pretty low. It is my understanding that lets say at 1000 kbps video at 60fps will look worse than video at 30fps.

Because each frame will have half the space to fit into. Is this correct? If I am misunderstanding this maybe I can just not force it down to lower framerate. But from what I understand 30fps video at 1000kbps will look better than same video at 60fps 1000kpbs.

Its annoying that over the air is broadcasting stuff that was originally in 24fps at 60fps.

Also, from what you are saying, there isnt some magic number (like multiple of 30, or 2 or 4 or anything like that) that would make things align well so that there isnt stutter. Correct?

[jagabo]

Thanks, should I be using -vf fps=24 instead of -r 24 ? Whats the difference between those?

No, after some testing it turns out that -vf fps=24 suffers from the same problem. See below...

Maybe my reasoning behind going down to 24 fps is silly, please correct me if I am wrong. But these are DVR shows to watch one time by my family, so I want to have them watchable but not take up all of my HDD space. So I have quality set pretty low... It is my understanding that lets say at 1000 kbps video at 60fps will look worse than video at 30fps. Because each frame will have half the space to fit into. Is this correct?

With x264 duplicate frames don't require much bitrate so you usually don't gain much by decimating this type of source.

Also, from what you are saying, there isnt some magic number (like multiple of 30, or 2 or 4 or anything like that) that would make things align well so that there isnt stutter. Correct?

Yes. With a source with duplicates in an inconsistent pattern you need a smart decimation that adapts to pattern changes.

After playing around with several filters I came up with this:

ffmpeg -y -i 24in60.mkv -vf select='not(mod(n\,2))',decimate=5,setpts=N/24/TB -r 24.0 -c:v libx264 -preset slow new24p.mkv

First select is used to remove every other frame, reducing the frame rate to 30p (the result will have one duplicate in every 5 frames). Then decimate is used to reduce the frame rate to 24p, preferentially discarding the duplicate. Finally, setpts is used to generate new time codes for each frame. The -r 24 isn't strictly necessary as far as I can tell. Several players I tried played the video without using it. But VirtualDub had some problem loading the video when it wasn't included. This sequence adapts to changes in the duplicate pattern.

That gave almost the same file size as simply reencoding at 60p with:

ffmpeg -y -i 24in60.mkv -c:v libx264 -preset slow new60p.mkv

[Chrushev]

Thanks, should I be using -vf fps=24 instead of -r 24 ? Whats the difference between those?

No, after some testing it turns out that -vf fps=24 suffers from the same problem. See below...

Maybe my reasoning behind going down to 24 fps is silly, please correct me if I am wrong. But these are DVR shows to watch one time by my family, so I want to have them watchable but not take up all of my HDD space. So I have quality set pretty low... It is my understanding that lets say at 1000 kbps video at 60fps will look worse than video at 30fps. Because each frame will have half the space to fit into. Is this correct?

With x264 duplicate frames don't require much bitrate so you usually don't gain much by decimating this type of source.

Also, from what you are saying, there isnt some magic number (like multiple of 30, or 2 or 4 or anything like that) that would make things align well so that there isnt stutter. Correct?

Yes. With a source with duplicates in an inconsistent pattern you need a smart decimation that adapts to pattern changes.

After playing around with several filters I came up with this:

ffmpeg -y -i 24in60.mkv -vf select='not(mod(n\,2))',decimate=5,setpts=N/24/TB -r 24.0 -c:v libx264 -preset slow new24p.mkv

First select is used to remove every other frame, reducing the frame rate to 30p (the result will have one duplicate in every 5 frames). Then decimate is used to reduce the frame rate to 24p, preferentially discarding the duplicate. Finally, setpts is used to generate new time codes for each frame. The -r 24 isn't strictly necessary as far as I can tell. Several players I tried played the video without using it. But VirtualDub had some problem loading the video when it wasn't included. This sequence adapts to changes in the duplicate pattern.

That gave almost the same file size as simply reencoding at 60p with:

ffmpeg -y -i 24in60.mkv -c:v libx264 -preset slow new60p.mkv

Thanks for the investigative work. So you are saying I should probably try to just leave FPS native and not worry about it as libx265 will take care of those extra frames and quality shouldnt really suffer?

[jagabo]

So you are saying I should probably try to just leave FPS native and not worry about it as libx265 will take care of those extra frames and quality shouldnt really suffer?

Yes. But you should try one or two for yourself and compare.

[Chrushev]

Just an update for anyone curious. yes it seems like libx265 does a good job of neutralizing those duplicate frames. Here is comparison:


Overall bit rate : 538 kb/s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS

VERSUS


Overall bit rate : 518 kb/s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 59.940 (60000/1001) FPS