FFMPEG convert 50P to 25P?

[marcorocchini]

Hi but I'm a c**

please I wonder how to convert a 50P source into 25P using ffmpeg (and not using a simple "-vf interlace" filter) possibly without too much quality loss

thanks

[poisondeathray]

Did you mean normal playback, not "slow motion" half speed at 25p ?

This will drop 1 out of every 2 frames and adjust the input framerate by 1/2 accordingly

-vf decimate=cycle=2

"quality loss" depends on what you choose to encode it with

[marcorocchini]

mmm cat

my source is 1920x1080, 422, and 50P

I need to reduce to a mp4 that is 411, 720x576, and 25P

I should use something like:

ffmpeg64bit332.exe -threads 8 -y -i %4 -i %audiosource% -vf decimate=cycle=2,scale=w=720:h=576,scale=interl=1:in_range=tv:out_range=tv,unsharp=luma_msize_x=3:luma_msize_y=3:luma_amount=0.8,colormatrix=bt709:bt601 -sws_flags lanczos+accurate_rnd -pix_fmt yuv420p -c:v libx264 -profile:v main -level:v 4.1 -x264-params me_range=4:subme=4:rc_lookahead=1:ref=3:chroma-me=1:chroma_qp_offset=0:qpmin=0:qpmax=69:sliced_threads=0:b_pyramid=2:b_adapt=1:b_bias=0:8x8dct=1:cabac=1:constrained_intra=0:no-psy=1:scenecut=40:ipratio=1.1 -g 72 -bf 2 -crf 22.8 -an -aspect 16:9 lowResOutput.mp4

is it correct?

OR

more simply I try to use the -r 25 ? like this

ffmpeg64bit332.exe -threads 8 -y -i %4 -i %audiosource% -vf scale=w=720:h=576,scale=interl=1:in_range=tv:out_range=tv,unsharp=luma_msize_x=3:luma_msize_y=3:luma_amount=0.8,colormatrix=bt709:bt601 -sws_flags lanczos+accurate_rnd -r 25 -pix_fmt yuv420p -c:v libx264 -profile:v main -level:v 4.1 -x264-params me_range=4:subme=4:rc_lookahead=1:ref=3:chroma-me=1:chroma_qp_offset=0:qpmin=0:qpmax=69:sliced_threads=0:b_pyramid=2:b_adapt=1:b_bias=0:8x8dct=1:cabac=1:constrained_intra=0:no-psy=1:scenecut=40:ipratio=1.1 -g 72 -bf 2 -crf 22.8 %AudioSettings% -aspect 16:9 lowResOutput.mp4

[poisondeathray]

I need to reduce to a mp4 that is 411, 720x576, and 25P

Probably 4:2:0 ? 4:1:1 is for NTSC DV

scale=interl=1

Is for interlaced scaling. Not appropriate if you're using progressive 50p => 25p


Try it and see which you like better. -r as an output option should work, but I noticed -r gives problems in some cases with timecodes. Actually decimate sometimes doesn't work either. Both can be inconsistent in ffmpeg

[poisondeathray]

Try it and see which you like better. -r as an output option should work, but I noticed -r gives problems in some cases with timecodes. Actually decimate sometimes doesn't work either. Both can be inconsistent in ffmpeg

eg. here is a test file "1.mp4" as the "source". Each frame has a framenumber written on it 0,1,2.... 640x480p50 CFR. 500 frames

ffmpeg -i 1.mp4 -vf decimate=cycle=2 -c:v libx264 -crf 20 -an 1_dec.mp4

ffmpeg -i 1.mp4 -r 25 -c:v libx264 -crf 20 -an 1_r25.mp4

Both have errors.

1_dec selects even numbers, so it should go 0,2,4,6 . But it has 1,2,4,7 at the beginning. Some frames are not selected correctly, so that will lead to less smooth motion eg. 17,27,31,37, many more. But frame count is correct (250) and it should be in sync if it were a real example with audio

1_r25 selects odd numbers , so it should go 1,3,5,7... But it has 0,1,2,3 at the beginning. Framecount is 152 (incorrect) . But there aren't mistakes after the beginning. If you drop frame 0,2 it looks correct (252-2 = 250)

So ffmpeg is semi-reliable for this sort of thing. YMMV. -r looks less bad in this case, after the beginning, but might cause sync issues.

avisynth or vapoursynth are more accurate and reliable for those types of operations such as decimation, field matching . You see these types of errors when IVTCing (e.g. DVD's) as well with ffmpeg, where the wrong frame is dropped or wrong frame duplicated

[Sharc]

Try this. It seems to work here, keeping the even frames correctly from the beginning:
ffmpeg -i 1.mp4 -c:v libx264 -crf 20 -filter:v "fps=25.0" -an 1_fps25.mp4

[poisondeathray]

Try this. It seems to work here, keeping the even frames correctly from the beginning:
ffmpeg -i 1.mp4 -c:v libx264 -crf 20 -filter:v "fps=25.0" -an 1_fps25.mp4

Nice

-vf decimate might work if the settings and thresholds were adjusted. It's more like adaptive decimation with detection so it might choose the wrong one. So in hindsight that's the wrong one to choose for this situation

-r should have worked on this synthetic example, because timestamps were perfect

[Sharc]

-r should have worked on this synthetic example, because timestamps were perfect

Yes, -r as an output option should do the same as -vf fps= as I understand, equivalent to changefps() in avisynth. Seems to be a bug in ffmpeg

Added:
Interestingly the frame sequence is different for an .mkv container: 0,1,2,4,6,8, ………….

[poisondeathray]

Added:
Interestingly the frame sequence is different for an .mkv container: 0,1,2,4,6,8, ………….

Did you mean as an output container ? mkv seems to work ok with -vf fps

[Sharc]

Added:
Interestingly the frame sequence is different for an .mkv container: 0,1,2,4,6,8, ………….

Did you mean as an output container ? mkv seems to work ok with -vf fps

Yes, I meant mkv as an output container using -r as output option.
With -vf fps both containers are ok.

[richardpl]

Try it and see which you like better. -r as an output option should work, but I noticed -r gives problems in some cases with timecodes. Actually decimate sometimes doesn't work either. Both can be inconsistent in ffmpeg

eg. here is a test file "1.mp4" as the "source". Each frame has a framenumber written on it 0,1,2.... 640x480p50 CFR. 500 frames

ffmpeg -i 1.mp4 -vf decimate=cycle=2 -c:v libx264 -crf 20 -an 1_dec.mp4

ffmpeg -i 1.mp4 -r 25 -c:v libx264 -crf 20 -an 1_r25.mp4

Both have errors.

1_dec selects even numbers, so it should go 0,2,4,6 . But it has 1,2,4,7 at the beginning. Some frames are not selected correctly, so that will lead to less smooth motion eg. 17,27,31,37, many more. But frame count is correct (250) and it should be in sync if it were a real example with audio

1_r25 selects odd numbers , so it should go 1,3,5,7... But it has 0,1,2,3 at the beginning. Framecount is 152 (incorrect) . But there aren't mistakes after the beginning. If you drop frame 0,2 it looks correct (252-2 = 250)

So ffmpeg is semi-reliable for this sort of thing. YMMV. -r looks less bad in this case, after the beginning, but might cause sync issues.

avisynth or vapoursynth are more accurate and reliable for those types of operations such as decimation, field matching . You see these types of errors when IVTCing (e.g. DVD's) as well with ffmpeg, where the wrong frame is dropped or wrong frame duplicated

Again pointless and incorrect propaganda about avisynth and vapoursynth by you. Why you use -r as input parameter? There are better filters for dropping every 2nd frame, like select filter.

[marcorocchini]

in my case:

this is my source (codec=Grass Valley Lossless; YUV422;1920x1080@50P)

https://www.dropbox.com/s/d07a3zb7eb8at4a/example.avi?dl=0

my target, this time, is a simple preview over phones so very low quality because I only need to scale the source from high qualityHD 422 -->to SD 420

Priority is for speed encoding

if I use:

ffmpeg64bit2019.exe -threads 8 -y -i %4 -i %audiosource% -vf scale=w=720:h=576:in_range=tv:out_range=tv,unsharp=luma_msize_x=3:luma_msize_y=3:luma_amount=0.8,colormatrix=bt709:bt601 -sws_flags lanczos+accurate_rnd -r 25 -pix_fmt yuv420p -c:v libx264 -profile:v main -level:v 4.1 -x264-params me_range=4:subme=4:rc_lookahead=1:ref=3:chroma-me=1:chroma_qp_offset=0:qpmin=0:qpmax=69:sliced_threads=0:b_pyramid=2:b_adapt=1:b_bias=0:8x8dct=1:cabac=1:constrained_intra=0:no-psy=1:scenecut=40:ipratio=1.1 -g 72 -bf 2 -crf 22.8 -an -aspect 16:9 R25.MP4

where ffmpeg is this https://www.dropbox.com/s/45rjyw3adz05p0j/ffmpeg64bit2019.exe?dl=0

I get this result:

https://www.dropbox.com/s/lf1i4ri9zb0jnzh/R25.mp4?dl=0

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

now I try without the -25 but using the

ffmpeg64bit2019.exe -threads 8 -y -i %4 -i %audiosource% -vf decimate=cycle=2,scale=w=720:h=576:in_range=tv:out_range=tv,unsharp=luma_msize_x=3:luma_msize_y=3:luma_amount=0.8,colormatrix=bt709:bt601 -sws_flags lanczos+accurate_rnd -pix_fmt yuv420p -c:v libx264 -profile:v main -level:v 4.1 -x264-params me_range=4:subme=4:rc_lookahead=1:ref=3:chroma-me=1:chroma_qp_offset=0:qpmin=0:qpmax=69:sliced_threads=0:b_pyramid=2:b_adapt=1:b_bias=0:8x8dct=1:cabac=1:constrained_intra=0:no-psy=1:scenecut=40:ipratio=1.1 -g 72 -bf 2 -crf 22.8 -an -aspect 16:9 decimateCycle2.mp4

getting this:

https://www.dropbox.com/s/x6mgk4mqc746bsd/decimateCycle2.mp4?dl=0

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

now I try without the -25 and without decimate=cycle=2 but using -filter:v "fps=25.0"

ffmpeg64bit2019.exe -threads 8 -y -i %4 -i %audiosource% -filter:v "fps=25.0" -vf scale=w=720:h=576:in_range=tv:out_range=tv,unsharp=luma_msize_x=3:luma_msize_y=3:luma_amount=0.8,colormatrix=bt709:bt601 -sws_flags lanczos+accurate_rnd -pix_fmt yuv420p -c:v libx264 -profile:v main -level:v 4.1 -x264-params me_range=4:subme=4:rc_lookahead=1:ref=3:chroma-me=1:chroma_qp_offset=0:qpmin=0:qpmax=69:sliced_threads=0:b_pyramid=2:b_adapt=1:b_bias=0:8x8dct=1:cabac=1:constrained_intra=0:no-psy=1:scenecut=40:ipratio=1.1 -g 72 -bf 2 -crf 22.8 -an -aspect 16:9 filterV25.mp4

note that -filter:v "fps=25.0" have to be before -vf scale=w=720:h=576 eccc otherwise the output is dont 720x576

getting:

https://www.dropbox.com/s/shjl4ps166hw2up/filterV25.mp4?dl=0

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

try to confront quality and "smoothness" in edius


[Attachment 51224 - Click to enlarge]

and SEEMS that

R25.mp4 is the "best" but is not in sync frame by frame (seems shifted of 1 frame backwards) but also maybe oversharp if compared with the original clip
Decimate

decimateCycle2.mp4 is "good" but seems a little jerky during playback (and not oversharp), but in sync frame by frame with the original clip

filterV25.mp4 is very smooth playback and is in sync frame by frame with the original clip but seems to have details slightly "corrupted", detail seems not smooth

[poisondeathray]

Why you use -r as input parameter?

-r after the -i is an output option, is it not?

-r before the -i is an input option, or at least it used to be. Did something change ?


Why does it not work properly here ?

There are better filters for dropping every 2nd frame, like select filter.

-vf select by itself does not seem to drop frames, or maybe I'm not using it correctly (e.g. you can select, say odd frames, but they are duplicated, and it's still 50fps with dupes)

How would you use it in this scenario, or what is the syntax. It seems like you have to combine it with some filter or method of dropping frames



But -vf fps seems to work ok as expected

[poisondeathray]

filterV25.mp4 is very smooth playback and is in sync frame by frame with the original clip but seems to have details slightly "corrupted", detail seems not smooth

This is 50p . The fps didn't work. I think it has to be in the same filter graph as the other filters

(That would explain the "very smooth" playback and detail problems - crf encoding will raise quantizer based on framerate)

R25.mp4 is the "best" but is not in sync frame by frame (seems shifted of 1 frame backwards) but also maybe oversharp if compared with the original clip
Decimate

Its the same issue as in the demo above - 2 extra frames, and wrong selection at the beginning

-r should "just work" in theory. But 2 samples, 2 buggy results so far....


I think you are oversharpening it with your "unsharp" filter on all of them . Very bad on dress pattern - aliasing

[Sharc]

filterV25.mp4 is very smooth playback and is in sync frame by frame with the original clip but seems to have details slightly "corrupted", detail seems not smooth

Your filterV25.mp4 is still 50fps. You can't simply daisy-chain the two filters.

This (simplified) should work:
ffmpeg.exe -i "%~1" -filter:v "scale=w=720:h=576, fps=25.0" -c:v libx264 -crf 22.8 -an -aspect 16:9 filt_new25.mp4

You may also want to read this:
https://trac.ffmpeg.org/wiki/ChangingFrameRate

[marcorocchini]

filterV25.mp4 is very smooth playback and is in sync frame by frame with the original clip but seems to have details slightly "corrupted", detail seems not smooth

Your filterV25.mp4 is still 50fps. You can't simply daisy-chain the two filters.

This (simplified) should work:
ffmpeg.exe -i "%~1" -filter:v "scale=w=720:h=576, fps=25.0" -c:v libx264 -crf 22.8 -an -aspect 16:9 filt_new25.mp4

You may also want to read this:
https://trac.ffmpeg.org/wiki/ChangingFrameRate

oh my *** it's true filterV25.mp4 is a 50P

so this is the new commanline:

ffmpeg64bit2019.exe -threads 8 -y -i v:\example.avi -filter:v "fps=25.0,scale=w=720:h=576:in_range=tv:out_range=tv,unsharp=luma_msize_x=3:luma_msize_y=3:luma_amount=0.3,colormatrix=bt709:bt601" -sws_flags lanczos+accurate_rnd -pix_fmt yuv420p -c:v libx264 -profile:v main -level:v 3.1 -x264-params me_range=4:subme=4:rc_lookahead=1:ref=3:chroma-me=1:chroma_qp_offset=0:qpmin=0:qpmax=69:sliced_threads=0:b_pyramid=2:b_adapt=1:b_bias=0:8x8dct=1:cabac=1:constrained_intra=0:no-psy=1:scenecut=40:ipratio=1.1 -g 72 -bf 2 -crf 22.8 -an -aspect 16:9 out.mp4

considering also the poison advice about unsharp (i have reduce luma_amount to 0.3)

so I get this:

https://www.dropbox.com/s/876lxbv2209nomr/out.mp4?dl=0

and this seems "good" but the comparison frame to frame compared to the original example.avi (using the first frame) show that out.mp4 is not exactly in sync. As poison said there is a wrong selection at the beginning.

Is there a way to solve this problem?

and can I to incorporate the "-sws_flags lanczos+accurate_rnd" into the

-filter:v "fps=25.0,scale=w=720:h=576:in_range=tv:out_range=tv,unsharp=luma_msize_x=3:luma_msize_y=3:luma_amount=0.3,colormatrix=bt709:bt601"

block?

[poisondeathray]

https://www.dropbox.com/s/876lxbv2209nomr/out.mp4?dl=0

and this seems "good" but the comparison frame to frame compared to the original example.avi (using the first frame) show that out.mp4 is not exactly in sync. As poison said there is a wrong selection at the beginning.

Is there a way to solve this problem?

It looks ok in terms of frame selection.

example.avi was 50p. out.mp4 is 25p. But correct "even" frames are selected. 0,2,4,6....

and can I to incorporate the "-sws_flags lanczos+accurate_rnd" into the

-filter:v "fps=25.0,scale=w=720:h=576:in_range=tv:out_range=tv,unsharp=luma_msize_x=3:luma_msize_y=3:luma_amount=0.3,colormatrix=bt709:bt601"

block?

Add it onto the scale portion of the filter chain as flags=lanczos+accurate_rnd

because those flags are part of the scale filter

"fps=25.0,scale=w=720:h=576:in_range=tv:out_range=tv:flags=lanczos+accurate_rnd,unsharp=luma_msize_x=3:luma_msize_y=3:luma_amount=0.3,colormatrix=bt709:bt601"

[marcorocchini]

[Attachment 51252 - Click to enlarge]

this is perfect