How can I best change from VFR to CFR and save to Lagarith

[Tom4]

I understand the large file made by Lagarith and always use it!

Have a few VFR mp4 files that display around 9fps in properties.
Plan to check with mediainfo for the max framerate.
Then choose a slightly higher framerate for CFR.

As I understand it just saving to AVI will force CFR output.
If I set the new CFR framerate higher then original VFR max, it might prevent any frame loss.
This will also allow me to save the clips to the same uniform framerate.
I am not worried about more duplicate frames!

Just wondering if there was a preferred method to maximize quality?
I have Adobe Premier and virtual dub.

What software or method will give a quality conversion with Lagarith save.

[Sharc]

Below ffmpeg commandline will reencode the clip to the new constant framerate and keep video and audio in sync. You can set the new framerate with fps=xx.

ffmpeg -i "%~1" -c:a copy -c:v libx264 -crf 20 -vf "fps=30.0, format=yuv420p" "%~1_newFPS.mp4"

I don't know whether ffmpeg supports lagarith as output, but if you need just a lossless output you could use ffv1:

ffmpeg -i "%~1" -c:a copy -c:v ffv1 -vf "fps=30.0" "%~1_newFPS.avi"

Edit:
It seems ffmpeg reads lagarith files but has no codec option for outputting to lagarith. It supports many other lossless codecs like huffyuv, UTVideo .... and ffv1 (my preference). Why stick to lagarith?

[Tom4]

I have also used ffmpeg in the past to just convert to avi which forces cfr.

ffmpeg -r 30000.0/1001.0 -i VFR.MP4 -c:v copy -an CFR.avi

Trying to find a way to use Premiere or Virtualdub which have Lagarith.
As you say, ffmpeg might be an option.

When searching with Google I find site saying Premiere and Virtualdub can screw-up with VFR conversion.
My guess was people trying to push their alternative product, so thought I would post a question here.

[Swedaniel]

Trying to find a way to use Premiere or Virtualdub which have Lagarith.
As you say, ffmpeg might be an option.

When searching with Google I find site saying Premiere and Virtualdub can screw-up with VFR conversion.
My guess was people trying to push their alternative product, so thought I would post a question here.

I dont know how to get Lagarith going by using FFMpeg, but if Lagarith is an codec, you could download the codec separately and use an video converter that can function together with installed codecs, there are several completely free to use video converters capable of doing that!

Edit: Especially if your an fan of lagarith, should defenitely download the codec, can use many free programs to get the best out of the codec for all scenarios with different input videos, formats and codecs! Funnily, once you get going there is allso the option to download other codecs that will function with such an converter aswell, even better is that the best codecs is free to use, most codecs allso will offer an separate settings application that can be launched from within the converter even tough the interface come along with the codec, possibly from here you can find many settings for quality, vfr/cbr, compression ratio, pixel output and so on, not all codecs offer such things tough and each codec offer different features within the settings!

[Alwyn]

I'd just open it in VDub (I'd be using VDub2 64bit) and save it as a LAGS and see what happens. You'll be able to see the base frame rate under Video>Frame Rate.

Be ready though for a huge AVI file. I just did a 60sec UHD VFR MP4 and it came out at 8.8GB! Constant FR at 30fps though. Nice.

If it's HD or bigger, I'd be converting to CFR H264 to keep the file size manageable.

Trying to find a way to use Premiere or Virtualdub which have Lagarith.

They don't "have" LAGS, per se, LAGS is available to them because it was installed at some point beforehand.

[Tom4]

Yes, that's the plan short of any other advice.
Mediainfo gives you the maximum frame rate.
Just going to set a new f/s a little higher.
EG: If the max is 9 f/s, set to 10.
I think it should work ok.

[Alwyn]

I'd set the Mediainfo "real" frame rate. This, from a phone:

Frame rate mode : Variable
Frame rate : 30.000 FPS
Minimum frame rate : 18.424 FPS
Maximum frame rate : 30.928 FPS
Real frame rate : 30.000 FPS

[Sharc]

... and check whether video and audio (if there is audio at all) will stay adequately synchronized. Usually mobile clips are short though, so a minor deviation may not even be noticed.
(but btw. why stick to lagarith?)

Added:
FWIW here another MediaInfo report of a mp4 clip. I don't know on what video (meta) data the report is based upon

Frame rate mode : Variable
Frame rate : 59.671 FPS
Minimum frame rate : 39.805 FPS
Maximum frame rate : 120.160 FPS

[Tom4]

I use lagarith because it is perfect every time without problems once you get the first RGB copy.
Reprocessed the same clips over 10+ times and it retains all information.
Most people ask why I use Lagarith to argue for their own choice.

No idea why it bothers them. LOL

Added: You see what I mean about using the max frame rate, so no frames are lost,
the corrections can be made once I have a CFR version.
If the maximum VFR for 9f/s video is above 30 I will settle for 30f/s.

[Swedaniel]

I use lagarith because it is perfect every time without problems once you get the first RGB copy.
Reprocessed the same clips over 10+ times and it retains all information.
Most people ask why I use Lagarith to argue for their own choice.

No idea why it bothers them. LOL

It seem pretty nice, i had been using Cinepak by Radius codec with the RGB24, which is pretty cool, now i see lagarith have that allso, plus ive got an hold of an YUV Viewer for YUV2 and YV12 but havent had much material to try it out, look like the Lagarith codec have some stuff to solve that problem allso!

Edit: Well now ive tested the codec, it is working pretty good, colors looked a lil bit funny from over here with RGB, it worked better with RGBA, from within the codec settings there was options to enable multi threading, switch between RGB/RGBA/YUV2 and YV12, cant find any RGB24 tough! There was allso some other settings (Enable Null Frames, Prevent Upsampling When Decoding).

Time to ship the material into some MP4, WebM, DivX, XviD, H.264, VP8 using various video converters to see how it goes, probably will test the Lagarith encoded material with WinRar and PeaZip to see how the compressions goes, since the videos take quite a bit of space!

Edit2: Look like it was YUY2 and not YUV2! Plus the funny looking colors with the RGB was with VLC Media Player, when using NVIDIA 3D Vision Video Player + LAV Filters it is looking real good with the RGB videos allso!

[Tom4]

Neil from Adobe Community wrote on Nov 29, 2023 -

Handbrake has a little 'radio' button you need to click called 'CFR' ... AND ... you also need to set a specific number framerate in the framerate option. Then it converts.



ShutterEncoder can also convert, but for some reason they've moved the convert to CFR option from the general settings to the Preferences for the app. So you need to find those, there's an icon sort of thingie upper left of the UI that is their Prefs. Then find the option to convert to CFR, which takes some scrollling.

[lollo]

Most people ask why I use Lagarith to argue for their own choice.

That's not Sharc, for sure

[Tom4]

I found Sometimes the MetaData screws up the Video/Properties/Detail information through windows or software.

Stripped MetaData and MediaInfo changed from "Fixed f/s" to "Variable f/s showing Minimum and Max f/s"

ffmpeg -i VID-IN.mp4 -map_metadata -1 -c:v copy -c:a copy VID-OUT.mp4 

After stripping the Metadata, I had a "Maximum f/s" or "Original f/s" for the script below.
Script below seems to work as intended, despite the -vf is repeated warning. I'm not good with this code!


Remove Duplicate Frames - VFR 2 CFR - save as FFV1 RGB 16bit AVI

ffmpeg -i VID-IN.mp4 -vf mpdecimate -fps_mode vfr -vf scale=in_range=limited:out_range=full 
-color_range 2 -c:a copy -c:v ffv1 -pix_fmt gbrp16le -vf "fps=29.970" VID-OUT.avi 

Anybody know the RGB type pixel/bit formats that are compatible with above code.
I tried a dozen and only got "gbrp16le 16 bit" and "bgr0 8 bit" to work?

There are also yuv type, if anyone can build on this.

[Selur]

Anybody know the RGB type pixel/bit formats that are compatible with above code.
I tried a dozen and only got "gbrp16le 16 bit" and "bgr0 8 bit" to work?

call:

ffmpeg -h encoder=ffv1

to get something like:

ffmpeg version N-113317-g02fb3a775e-gbfa1b7577d+2 Copyright (c) 2000-2024 the FFmpeg developers
  built with gcc 13.2.0 (Rev3, Built by MSYS2 project)
  configuration:  --pkg-config=pkgconf --cc='ccache gcc' --cxx='ccache g++' --ld='ccache g++' --extra-cxxflags=-fpermissive --extra-cflags=-Wno-int-conversion --disable-autodetect --enable-amf --enable-bzlib --enable-cuda --enable-cuvid --enable-d3d11va --enable-dxva2 --enable-iconv --enable-lzma --enable-nvenc --enable-zlib --enable-sdl2 --enable-ffnvcodec --enable-nvdec --enable-cuda-llvm --disable-doc --enable-gmp --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libdav1d --enable-libaom --disable-debug --enable-fontconfig --enable-libass --enable-libbluray --enable-libfreetype --enable-libmfx --enable-libmysofa --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libwebp --enable-libxml2 --enable-libzimg --enable-libshine --enable-gpl --enable-avisynth --enable-libxvid --enable-libopenmpt --enable-version3 --enable-librav1e --enable-libsrt --enable-libgsm --enable-libvmaf --enable-libsvtav1 --enable-gnutls --extra-cflags=-DLIBTWOLAME_STATIC --extra-libs=-lstdc++ --extra-cflags=-DLIBXML_STATIC --extra-libs=-liconv --disable-w32threads
  libavutil      58. 36.101 / 58. 36.101
  libavcodec     60. 37.100 / 60. 37.100
  libavformat    60. 20.100 / 60. 20.100
  libavdevice    60.  4.100 / 60.  4.100
  libavfilter     9. 17.100 /  9. 17.100
  libswscale      7.  6.100 /  7.  6.100
  libswresample   4. 13.100 /  4. 13.100
  libpostproc    57.  4.100 / 57.  4.100
Encoder ffv1 [FFmpeg video codec #1]:
    General capabilities: dr1 delay threads
    Threading capabilities: slice
    Supported pixel formats: yuv420p yuva420p yuva422p yuv444p yuva444p yuv440p yuv422p yuv411p yuv410p bgr0 bgra yuv420p16le yuv422p16le yuv444p16le yuv444p9le yuv422p9le yuv420p9le yuv420p10le yuv422p10le yuv444p10le yuv420p12le yuv422p12le yuv444p12le yuva444p16le yuva422p16le yuva420p16le yuva444p12le yuva422p12le yuva444p10le yuva422p10le yuva420p10le yuva444p9le yuva422p9le yuva420p9le gray16le gray gbrp9le gbrp10le gbrp12le gbrp14le gbrap14le gbrap10le gbrap12le ya8 gray10le gray12le gray14le gbrp16le rgb48le gbrap16le rgba64le gray9le yuv420p14le yuv422p14le yuv444p14le yuv440p10le yuv440p12le
ffv1 encoder AVOptions:
  -slicecrc          <boolean>    E..V....... Protect slices with CRCs (default auto)
  -coder             <int>        E..V....... Coder type (from -2 to 2) (default rice)
     rice            0            E..V....... Golomb rice
     range_def       -2           E..V....... Range with default table
     range_tab       2            E..V....... Range with custom table
     ac              1            E..V....... Range with custom table (the ac option exists for compatibility and is deprecated)
  -context           <int>        E..V....... Context model (from 0 to 1) (default 0)

and you see the 'Supported pixel formats'

Script bellow seems to work as intended, despite the -vf is repeated warning. I'm not good with this code!

Are you sure the first two vf sections get processed and do not just get ignored?
(You could check with '-loglevel debug' to see what's happening,..)
Better combing:

-vf mpdecimate
-vf scale=in_range=limited:out_range=full 
-vf "fps=29.970"

to

-vf "mpdecimate,scale=in_range=limited:out_range=full,fps=29.97"

Cu Selur

[Tom4]

That would make sense, that the code was being ignored.
So I need to fix it up and try again.

Thanks for the help.

I see the bundling, combing? of code using brackets but could not get it to work.

I note there is no gaps with comma, have not got access to the PC to try this.
So can I keep combing/adding commands in a string?
Guess I will work it out.

-vf "mpdecimate,scale=in_range=limited:out_range=full,fps=29.97"
-fps_mode vfr -color_range 2 -c:a copy -c:v ffv1 -pix_fmt gbrp16le 

[Tom4]

Supported pixel formats: yuv420p yuva420p yuva422p yuv444p yuva444p yuv440p yuv422p yuv411p yuv410p bgr0 bgra yuv420p16le yuv422p16le yuv444p16le yuv444p9le yuv422p9le yuv420p9le yuv420p10le yuv422p10le yuv444p10le yuv420p12le yuv422p12le yuv444p12le yuva444p16le yuva422p16le yuva420p16le yuva444p12le yuva422p12le yuva444p10le yuva422p10le yuva420p10le yuva444p9le yuva422p9le yuva420p9le gray16le gray gbrp9le gbrp10le gbrp12le gbrp14le gbrap14le gbrap10le gbrap12le ya8 gray10le gray12le gray14le gbrp16le rgb48le gbrap16le rgba64le gray9le yuv420p14le yuv422p14le yuv444p14le yuv440p10le yuv440p12le

Cu Selur

I was trying these,
Available pixel formats are:

monob, rgb555be, rgb555le, rgb565be, rgb565le, rgb24, bgr24, 0rgb, 
bgr0, 0bgr, rgb0, bgr48be, uyvy422, yuva444p, yuva444p16le, yuv444p, 
yuv422p16, yuv422p10, yuv444p10, yuv420p, nv12, yuyv422, gray 

Found that,
bgr48be Auto selected to gbrp16le
rgb24 Auto selected to bgr0
bgr24 Auto selected to bgr0
bgr16, rgb10 and rgb16 where unknown, along with a long list of others.

There must be other factors at play for compatibility.
Perhaps try:

gbrp9le gbrp10le gbrp12le gbrp14le gbrp16le 

[Selur]

Yes, something like:

ffmpeg -i "test.avi" -vf "mpdecimate,scale=in_range=limited:out_range=full,fps=29.97" -fps_mode vfr -color_range 2 -c:a copy -c:v ffv1 -pix_fmt gbrp16le "test.mkv"

works fine here.

Regarding the pixel formats: seems like the ffmpeg authors might want to update their documentation.
I normally use yuv color spaces:

-pix_fmt yuv420p
-pix_fmt yuv420p10le
-pix_fmt yuv420p16le

-pix_fmt yuv422p
-pix_fmt yuv422p10le
-pix_fmt yuv422p16le

-pix_fmt yuv444p
-pix_fmt yuv444p10le
-pix_fmt yuv444p16le

since my sources usually are yuv and adding additional color conversions doesn't seem necessary.

Cu Selur

[Tom4]

Yes, something like:

ffmpeg -i "test.avi" -vf "mpdecimate,scale=in_range=limited:out_range=full,fps=29.97" -fps_mode vfr -color_range 2 -c:a copy -c:v ffv1 -pix_fmt gbrp16le "test.mkv"

works fine here.

Cu Selur

Thank you very much for that, the video info was reading correct after process but I was concerned about cmd warning.

Strip Metadata:

ffmpeg -i VID-IN.mp4 -map_metadata -1 -c:v copy -c:a copy VID-OUT.mp4 

For others trying this, its for "Variable Frame Rate MP4", removing repeated frames and saved to "Fixed Frame Rate Lossless AVI".

ffmpeg -i "test.mp4" -vf "mpdecimate,scale=in_range=limited:out_range=full,fps=29.97" 
-fps_mode vfr -color_range 2 -c:a copy -c:v ffv1 -pix_fmt gbrp16le "test.avi" 

The idea was to create a clean CFR slate for processing.
Saving to "Variable Frame Rate MP4" can sometimes have advantage of reducing process requirements.

[Selur]

Note that: This isn't a prefect approach:

mpdecimate,scale=in_range=limited:out_range=full,fps=29.97

• mpdecimate (https://ffmpeg.org/ffmpeg-all.html#mpdecimate) will remove all duplicates
• fps=29.97 (https://ffmpeg.org/ffmpeg-all.html#fps-1) will add back duplicates to archive 29.97 fps, so if after removing duplicates you get less frames (hopefully only in some sections) than are needed for 29.97 fps duplicates will be added back.

Cu Selur

[Tom4]

Note that: This isn't a prefect approach:

mpdecimate,scale=in_range=limited:out_range=full,fps=29.97

• mpdecimate (https://ffmpeg.org/ffmpeg-all.html#mpdecimate) will remove all duplicates
• fps=29.97 (https://ffmpeg.org/ffmpeg-all.html#fps-1) will add back duplicates to archive 29.97 fps, so if after removing duplicates you get less frames (hopefully only in some sections) than are needed for 29.97 fps duplicates will be added back.

Cu Selur

I copied the sections to pad for reading.
I think that mpdecimate removing all duplicates might be ok, provided they were close duplicates, because they will be replaced.
If I can dig into the fps thing, are you saying the choice of 29.97 will add frames compared to 30? Thanks
I used 29.97 because it was the original fps of a clip I was editing, will check this!

So
"fps=ntsc", "fps=30" or "fps=30000/1001" are the same and valid? Got it

Reading the mpdecimate page again
hi
lo
frac

I will trying understanding this later.
Thanks.

[Selur]

Whether fps=XY adds or removes frames depend on how many frames you end up after the decimation.
'fps' will add and remove frames to archive the given frame rate.

"fps=ntsc", "fps=30" or fps=30000/1001 are the same and valid?

'30000/1001' and 'ntsc' are the same.
30 and 30000/1001(~29.97) are not the same
see: https://www.ffmpeg.org/ffmpeg-all.html#fps-1

Cu Selur

[Tom4]

Note that: This isn't a prefect approach:

mpdecimate,scale=in_range=limited:out_range=full,fps=29.97

[list][*]mpdecimate (https://ffmpeg.org/ffmpeg-all.html#mpdecimate) will remove all duplicates
Cu Selur

I read the stuff on "hi", "lo", "frac" functions.
Crunched some numbers and ran tests.
Seems to be in the right ball park, let me know!
Higher resolutions might need the higher numbers.

4744 Frames in Source Video (960x544).

VFR to VFR mpdecimate test:
4356 Frames "mpdecimate=hi=64*0.1:lo=64*0.1:frac=0.1:max=0" 8.17% of frames removed.
4356 Frames "mpdecimate=hi=64*0.1:lo=64*0.04:frac=0.1:max=0" 8.17% of frames removed.
4355 Frames "mpdecimate=hi=64*0.2:lo=64*0.08:frac=0.1:max=0"
4354 Frames "mpdecimate=hi=64*0.4:lo=64*0.16:frac=0.1:max=0"
4352 Frames "mpdecimate=hi=64*0.6:lo=64*0.24:frac=0.1:max=0"
4351 Frames "mpdecimate=hi=64*0.8:lo=64*0.32:frac=0.1:max=0" 8.28% of frames removed.
4338 Frames "mpdecimate=hi=64*0.9:lo=64*0.375:frac=0.1:max=0" 8.56% of frames removed.
4312 Frames "mpdecimate=hi=64*1.0:lo=64*0.416:frac=0.1:max=0" 9.1% of frames removed.

3830 Frames "mpdecimate=hi=64*12:lo=64*5.0:frac=0.33:max=0" 20% of frames removed. (Using mpdecimate Defaults).

ffmpeg -i VID-IN.mp4 -vf 
"mpdecimate=hi=64*0.1:lo=64*0.1:frac=0.1:max=0" -fps_mode vfr VID-OUT.mp4 

By setting "hi", "lo" and "frac" all to "0.1", it appears adjustment can be isolated to "hi" setting "0.1 to 1.0".
If you have experience with mpdecimate settings, please contribute.