FFmpegSource

[hello_hello]

ffms2_r1390 (https://codeberg.org/StvG/ffms2/releases/tag/r1390)

Thanks.

[flossy_cake]

ffms2_r1390 (https://codeberg.org/StvG/ffms2/releases/tag/r1390)

^ this is working for me too, with regards to both audio and prefetch.

In light of this ffms2 is now top tier for me. If it could do multithreaded indexing to speed up the indexing process, that would put it ahead of LWLibav for me personally - would that even be possible in theory or is indexing a strictly linear process?

[rgr]

"int atrack = -2
The audio track to open. atrack=-1 means select the first available track. atrack=-2 (the default) means audio is disabled."

It would be useful to know in the manual that the track numbering starts from 1.

[Myrsloik]

"int atrack = -2
The audio track to open. atrack=-1 means select the first available track. atrack=-2 (the default) means audio is disabled."

It would be useful to know in the manual that the track numbering starts from 1.

It doesn't. All tracks share the same number series. Your file probably has video as track 0.

[rgr]

It doesn't. All tracks share the same number series. Your file probably has video as track 0.

Ok now I understand. The description suggested to me that ffms2 only renumbers audio tracks.

[rgr]

I downloaded a new version (I don't remember what old one I had) and I see some error.
ffms2 creates (at least for some files) the index file from scratch, even though one already exists (and was created by the new version of ffms2).

[rgr]

I downloaded a new version (I don't remember what old one I had) and I see some error.
ffms2 creates (at least for some files) the index file from scratch, even though one already exists (and was created by the new version of ffms2).

I found an error pattern -- for files with national characters in the name, the ffindex file is always created even if it exists.

[StainlessS]

Good post rgr, :goodpost:
helps dev find code location of error.

[StvG]

ffms2_r1391 (https://codeberg.org/StvG/ffms2/releases/tag/r1391)

AviSynth: fixed unnecessary index recreating.

[FranceBB]

Thank you!
Looks like I have something to test on Monday ehehehehehe

[flossy_cake]

ffms2_r1391 (https://codeberg.org/StvG/ffms2/releases/tag/r1391)

AviSynth: fixed unnecessary index recreating.

I was just wondering about FFGetVersion()... this returns 3.1.1.0 with the above build. I want to check it in my script to make sure the user who uses my script (which uses ffms2) is using YOUR fork of ffms2 with the recent rffmode fix... wondering what should I check for in the version number string to make sure of that. i.e what convention for numbering you will use in the future, eg. as long as all 4 digits are > 3 & 1 & 1 & 0 should I be safe to assume it is your r1391 or above?

Thanks

[StvG]

I was just wondering about FFGetVersion()... this returns 3.1.1.0 with the above build. I want to check it in my script to make sure the user who uses my script (which uses ffms2) is using YOUR fork of ffms2 with the recent rffmode fix... wondering what should I check for in the version number string to make sure of that. i.e what convention for numbering you will use in the future, eg. as long as all 4 digits are > 3 & 1 & 1 & 0 should I be safe to assume it is your r1391 or above?

Thanks

If you do right click on the dll file Properties->Details, the version strings are different than the official ffms2. Also the version is 3.1.0.0... instead of 3.1.1.0... I remember that the upstream changed the version from 3.0.1.0 to 3.1.1.0 (https://github.com/FFMS/ffms2/commit/dc5953c05ee5665330dbb63293355cc00e9d4895#diff-6f9d3ed22601609f9f0a456e33d6d633eae61e73b49fe76e6a681cac113f017f) instead 3.0.1.0->3.1.0.0 but obviously I didn't change ffms.h.

As for FFGetVersion() I can add the revision number, so the output will be "3.1.0.0 r1391".

[flossy_cake]

As for FFGetVersion() I can add the revision number, so the output will be "3.1.0.0 r1391".

:thanks:

[flossy_cake]

@StvG

I'm just having some issues with interlaced AVC files - recordings of broadcast TV from Enigma2 PVR (it remuxes them to .ts files on its hard drive)

To even get anything usable (seekable) with FFMpegVideoSource I must first run the .ts files through this ffmpeg pseudo-repair:

"ffmpeg.exe" -i "C:\recording.ts" -c copy "C:\repaired.ts"

I suppose this is not so remarkable if the PVR itself has to cut the stream when it makes the recording, so there is probably going to be some weirdness in the stream anyway.

Test file 1: 576i AVC 25.0fps (https://drive.google.com/file/d/1ZuEXrzeQK4RUx9FpMJmvCGt23fRlDDYA/view?usp=sharing)
Problem: plays at 12.5fps when rffmode=1, plays at 24.973fps when rffmode=0

Test file 2: 1080i AVC 25.0fps (https://drive.google.com/file/d/1Dusyec9ce6OPIRb-p5AhMbzstKEPqv-d/view?usp=sharing)
Problem: "no audio track found" when track=-1. Setting track=1 result in "audio track contains no audio frames"

audio = FFAudioSource(filePath, track=-1)
video = FFVideoSource(filePath, rffmode=1)
AudioDub(video, audio)
SubTitle(string(FrameRate)+"fps", align=5)


LWLibAv plays them without issue
edit: except it needs av_sync=true to match FFAudioSource's adjustdelay=-1

:thanks:

[StvG]

ffms2_r1393 (https://codeberg.org/StvG/ffms2/releases/tag/r1393)
Added revision to the displayed version.
Fixed fps (rffmode > 0) (H264).


Test file 2: 1080i AVC 25.0fps (https://drive.google.com/file/d/1Dusyec9ce6OPIRb-p5AhMbzstKEPqv-d/view?usp=sharing)
Problem: "no audio track found" when track=-1. Setting track=1 result in "audio track contains no audio frames"

audio = FFAudioSource(filePath, track=-1)
video = FFVideoSource(filePath, rffmode=1)
AudioDub(video, audio)
SubTitle(string(FrameRate)+"fps", align=5)


LWLibAv plays them without issue
edit: except it needs av_sync=true to match FFAudioSource's adjustdelay=-1

:thanks:

ffmpeg -i "1080i AVC.ts" -vcodec copy vid.h264 -acodec copy aud.ac3

Muxing vid.h264 and aud.ac3 with mkvtoolnix -> no issues.

[flossy_cake]

ffms2_r1393 (https://codeberg.org/StvG/ffms2/releases/tag/r1393)
Added revision to the displayed version.
Fixed fps (rffmode > 0) (H264).

:thanks:

I did notice the frame rate is still 24.x instead of 25.0 when rffmode=0, but it seems that could be easily workedaround with AssumeFPS(25) or defaulting rffmode to 1.

[flossy_cake]

To even get anything usable (seekable) with FFMpegVideoSource I must first run the .ts files through this ffmpeg pseudo-repair:

"ffmpeg.exe" -i "C:\recording.ts" -c copy "C:\repaired.ts"


I forgot about the seekmodes... seekmode 2 resolved this issue for me, so I don't need to run it through the above repair process.

Without performing the above repair, the fps issue is resolved also.

This leaves the only issue being the audio issue on the 1080i test file. Here (https://drive.google.com/file/d/1AnagYIoIeXZQjhJNtYFKHnblvxSQpq01/view?usp=sharing) is the original unrepaired 1080i .ts file straight from the PVR if it's of any use.

[StvG]

:thanks:

I did notice the frame rate is still 24.x instead of 25.0 when rffmode=0, but it seems that could be easily workedaround with AssumeFPS(25) or defaulting rffmode to 1.

I forgot about the seekmodes... seekmode 2 resolved this issue for me, so I don't need to run it through the above repair process.

Without performing the above repair, the fps issue is resolved also.

This leaves the only issue being the audio issue on the 1080i test file. Here (https://drive.google.com/file/d/1AnagYIoIeXZQjhJNtYFKHnblvxSQpq01/view?usp=sharing) is the original unrepaired 1080i .ts file straight from the PVR if it's of any use.

If you do demuxing and muxing, as I wrote in my previous post, you will see that ffmpeg gives multiply "Application provided invalid, non monotonically increasing dts to muxer in stream 0: x >= x". Also if you do the mentioned demuxing+muxing, the resulted mkv file have 25fps with rffmode=0 too. I wouldn't use other containers than mkv with ffms2 (for anything). If you don't want remuxing ts or other containers to mkv, go with l-smash-works (it's more reliably for the containers other than mkv) or other source filter.

[FranceBB]

Hey Steve, sorry to bother you but one of my colleagues in Germany reported a bug.
The source file (https://onedrive.live.com/?authkey=%21AKTWZPhkRjP%2DoeY&id=B1CCE5E25DD4A220%21499&cid=B1CCE5E25DD4A220) is an XDCAM-50 file, namely an MPEG-2 Open GOP file 4:2:2 25i TFF 8bit BT709 SDR muxed in mxf:

General
Complete name : A:\MEDIA\temp\test01-190224-01source.MXF
Format : MXF
Commercial name : XDCAM HD422
Format version : 1.3
Format profile : OP-1a
Format settings : Closed / Complete
File size : 1.35 GiB
Duration : 3 min 13 s
Overall bit rate : 60.0 Mb/s
Frame rate : 25.000 FPS
Encoded date : 2024-02-19 12:05:39.760
Writing application : Grass Valley K.K. EDIUS 8.5.3.3262

Video
ID : 2
Format : MPEG Video
Commercial name : XDCAM HD422
Format version : Version 2
Format profile : 4:2:2@High
Format settings : CustomMatrix / BVOP
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : M=3, N=12
Format settings, picture structure : Frame
Format settings, wrapping mode : Frame
Codec ID : 0D01030102046001-0401020201040300
Duration : 3 min 13 s
Bit rate mode : Constant
Bit rate : 50.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.965
Time code of first frame : 00:00:00:00
Time code source : Group of pictures header
GOP, Open/Closed : Open
GOP, Open/Closed of first frame : Closed
Stream size : 1.12 GiB (83%)
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Delay_SDTI : 0


When he indexes it with

FFVideoSource("A:\MEDIA\temp\test01-190224-01source.MXF", fpsnum=25 , fpsden=1, seekmode=1)

it shows a repeated (i.e duplicated) frame, namely Frame 401 at 00:00:16:04, however using

LWLibavVideoSource("A:\MEDIA\temp\test01-190224-01source.MXF", fpsnum=25, fpsden=1)

there are no duplicated frames.

This was tested with ffms2 3.1.0.0 1357+36 1c0dcfa (1393) from January 6th, 2024.

In particular, FFInfo() shows

https://i.imgur.com/DM4ov9l.png
https://i.imgur.com/db2yWUs.png


for the two identical frames (401 and 402).
You can see that they're identical 'cause the yellow leaf falling from the tree at the bottom doesn't move and stays still.
These are frame 401 and 402 decoded by LWLibavVideoSource("A:\MEDIA\temp\test01-190224-01source.MXF", fpsnum=25, fpsden=1) with Info():

https://i.imgur.com/MK2fDOJ.png
https://i.imgur.com/yKAm4lM.png


you can see the leaf actually moving as it's on its way to the ground...

Here you can find both the source and the re-encoded output which contains the duplicated frame: Link (https://1drv.ms/f/s!AiCi1F3i5cyxg3Ok1mT4ZEYz_qHm?e=jyDjO1)

The source is called "source" of course.

p.s I assume that StvG stands for "Steve G" but correct me if I'm wrong xD

[Myrsloik]

FFMS2 5.0 RC1 (https://github.com/FFMS/ffms2/releases/tag/5.0-RC1)

Test it. Report your findings. Open proper issues on github.

- 5.0
- Fixed all issues with FFmpeg 6.1 which is now the minimum requirement
- Fixed av1 decoding
- Added HDR10+ and DolbyVision metadata
- Fixed audio decoding that could otherwise get stuck in an infinite loop on certain files
- Fixed framerate in Avisynth when using VFR=>CFR mode
- Dropped VapourSynth API3 support
- Indexer now has a configurable progress update interval
- Alpha planes are now correctly marked as being full range
- The full set of demuxer options can now be passed using the FFMS2 API
- Now sets channel layout in Avisynth+

[StvG]

...FFVideoSource("A:\MEDIA\temp\test01-190224-01source.MXF", fpsnum=25 , fpsden=1, seekmode=1) ...

Hey,

Indeed specifying fpsnum returns wrong frames.

Just FFVideoSource("A:\MEDIA\temp\test01-190224-01source.MXF") is ok. I have to look at this.

[kedautinh12]

Hey,

Indeed specifying fpsnum returns wrong frames.

Just FFVideoSource("A:\MEDIA\temp\test01-190224-01source.MXF") is ok. I have to look at this.

Will you update your ffms2?

[FranceBB]

Hey,

Indeed specifying fpsnum returns wrong frames.

Just FFVideoSource("A:\MEDIA\temp\test01-190224-01source.MXF") is ok. I have to look at this.

Yep, specifying just FFVideoSource() works, but it's indeed weird. Generally having dups when fpsnum and fpsden are specified only happens when the decoder finds some issues with a certain frame. I'm not really sure why it's getting this result instead... :(



FFMS2 5.0 RC1 (https://github.com/FFMS/ffms2/releases/tag/5.0-RC1)

Test it. Report your findings.

Thank you for releasing a new major version and its release candidate.
I noticed that it's 64bit only. Are we gonna get a 32bit version too once the stable version is gonna be out?
The second question is: does it include all the changes StvG made over the last 4 years?
It would actually help to have like one single codebase.
Anyway, this new version is also affected by the bug I reported above but in a slightly different way.
Frame 401 and Frame 402 are the very same frame and they don't match the former frames.
In version 5.0.0.0 RC1 we have the leaf falling (that was supposed to be at frame 401-402) at frame 399-400 (which is wrong 'cause it means that it missed some frames before) and there's movement:

https://i.imgur.com/fOJKu7s.png
https://i.imgur.com/TSzh0pp.png

but as soon as we get to frame 401-402 we get the same frame repeated twice:

https://i.imgur.com/mjFkDfc.png
https://i.imgur.com/i7IaRpZ.png


What's worse is that frame 401-402 (duplicated) of version 5.0.0.0 RC1 should actually be frames 403-404 as correctly reported by LWLibavVideoSource():

https://i.imgur.com/luga1Wa.png
https://i.imgur.com/aNohXw8.png

[Myrsloik]

https://github.com/FFMS/ffms2/releases/tag/5.0-RC2
(5.0-RC2)
Fixes these issues reported by FranceBB:

duplicate/dropped frames in CFR mode with the same framerate as the source (or a multiple)
incorrect seeking in files where the decoder only uses slice threading


I'd really appreciate if someone runs seek tests on this build.

And to answer the rest of FranceBB's questions:

StvG's changes are hacks at best that change and prod until a single file "works". It's useful for end users in the short term but of no use to the project long term. The actual FFMS2 development aims at doing things as correctly as possible and get things fixed upstream when possible.
If there's great demand for a 32 bit version maybe I'll release that but let me remind you that x64 is over 20 years old now and every single x86 CPU worth encoding with has supported it since then more or less. Do you really need a 32 bit build or are you simply chasing the memory of your encoding youth?

[FranceBB]

Thank you for the new build!
I tested it and it indeed fixed the issue. :)
I'm gonna make it go through some regression testing as well on a few known use-cases and I'll let you know, but thank you in advance for this.

About the 32bit version, of course 64bit CPUs and OS have been around for several years, but the problem is that some Avisynth plugins are still 32bit.
Sure, there are workarounds like using MPPipeline etc, but some people prefer to use 32bit Avisynth instead, which is why, in FFAStrans (FFMpeg Avisynth Transcoder) (https://forum.doom9.org/showthread.php?t=176655), the freely available project I constantly and very passionately contribute to, we also offer the option to use 32bit Avisynth with 32bit plugins in the workflows, hence the need of a 32bit indexer. :)

[poisondeathray]

5.0-RC2 is missing PNG support (images, or PNG in MOV)

FPS returned for short video (1 frame) prores in mov is incorrect (should be 24/1 fps , but results in 12288 fps)
https://www.mediafire.com/file/9kghx7frsant1fe/ff_pr4444.mov/file

[ChaosKing]

I'd really appreciate if someone runs seek tests on this build.




More or less the same as before, compare with older builds https://forum.doom9.org/showthread.php?t=176231
https://i.imgur.com/e1SxjXS.png

crowd sample is now ok :D

[Myrsloik]

5.0-RC2 is missing PNG support (images, or PNG in MOV)

FPS returned for short video (1 frame) prores in mov is incorrect (should be 24/1 fps , but results in 12288 fps)
https://www.mediafire.com/file/9kghx7frsant1fe/ff_pr4444.mov/file

Fixed both. Vcpkg stopped compiling ffmpeg with zlib by default.

[hello_hello]

Yep, specifying just FFVideoSource() works, but it's indeed weird. Generally having dups when fpsnum and fpsden are specified only happens when the decoder finds some issues with a certain frame. I'm not really sure why it's getting this result instead... :(

Way back in 2014, I had a clever idea that MeGUI could also encode VFR video correctly if it added fpsnum and fpsden to a script when using FFMS2 as the source filter. Zathor thought it was a good idea too, until eventually we discovered it wasn't. To this day I think MeGUI still adds fpsnum and fpsden to a script for some container formats. I almost feel guilty about it.
Originally the problem seemed limited to AVIs (https://forum.doom9.org/showthread.php?p=1730881#post1730881), but over time I discovered it could happen with any format and even sometimes with VFR video. When it was reported in the FFMS2 thread at the time, the response was underwelming (https://forum.doom9.org/showthread.php?p=1679226#post1679226). Lsmash was, at least at the time, just as likely to suffer from the same problem, dropping frames it shouldn't and duplicating others, but eventually I got used to the idea that if one of them didn't work properly with a particular file the other likely would.

I wonder if it's the same problem finally being fixed, or something new. I enjoyed the trip down memory lane though. :)

[StvG]

... I'd really appreciate if someone runs seek tests on this build...

https://ibb.co/bLzGmXX
https://ibb.co/vZsFK3J

The video files and the previous git version that is tested are from here (https://forum.doom9.org/showthread.php?p=1992736#post1992736).

Also tested @3a5d85c with the rffmode=1 commits - it doesn't fix the issues (related (https://forum.doom9.org/showthread.php?p=1994388#post1994388)). It needs per frame reading of the tff flag. Below is example with the first few hundreds frames marked as tff but after that there are bff:
https://ibb.co/VvNB5W9
https://ibb.co/T8v3Gmf

Edit: also maybe check for the avs+ channel mask should be added to avoid undefined behavior when older avs+ is used (related (https://forum.doom9.org/showthread.php?p=1994891#post1994891)).

[kedautinh12]

I can see from the StvG's test, his ffms still better when can decode Zenit.mkv, ffms2_seeking_issue.mp4, interlaced_h264.mkv, and 3d-parrot.mkv. They still don't add commits from StvG

[Myrsloik]

I have a question about the ffms2_seeking_issue.mp4 sample: Does anyone know exactly how it was generated or where it comes from? Was it remuxed from something else using ffmpeg?

[ChaosKing]

I have a question about the ffms2_seeking_issue.mp4 sample: Does anyone know exactly how it was generated or where it comes from? Was it remuxed from something else using ffmpeg?

I think i remuxed it with ffmpeg from the mkv version.

[Myrsloik]

I think i remuxed it with ffmpeg from the mkv version.

Here's an inconvenient truth for you: FFmpeg is buggy and marks all I-frames as proper seekpoints whe muxing mp4. This means there's an insane number of invalid mp4 files out there with no good workaround (you'd have to parse the whole bitstream or something which is outside the scope of FFMS2). Even FFmpeg itself will seek badly in these files. So if you want a small task try remuxing the mkv=>mp4 files again but this time don't use FFmpeg.

You may be surprised at the outcome.

Meanwhile I'll have a quick peek at interlaced h264 and vc1 do seem to have regressed a bit...

[ChaosKing]

I had a feeling that ffmpeg mp4 was kinda broken. But didn't expect it to be this bad...
What would be a good alternative tool for mp4 files?

[tebasuna51]

I had a feeling that ffmpeg mp4 was kinda broken. But didn't expect it to be this bad...
What would be a good alternative tool for mp4 files?

Answers to this question moved to a new thread MP4 muxers (https://forum.doom9.org/showthread.php?p=1998341#post1998341), because are off topic here.

[StvG]

ffms2 20240306_r1390

ffms2_r2390 (https://codeberg.org/StvG/ffms2/releases/tag/r2390)

Differences compared to 5.0-RC2 (https://github.com/FFMS/ffms2/releases/tag/5.0-RC2):
* In some cases can be seek accurate while `5.0-RC2` is not (for example, https://imgbb.com/bLzGmXX https://imgbb.com/vZsFK3J)
* AviSynth: GetParity and _FieldBased are set per frame
* AviSynth: rffmode=1 that uses every frame tff/bff
* AviSynth: set _EncodedFrameTop and _EncodedFrameBottom (rffmode > 0)
* AviSynth: both ANSI and UTF8 file names are supported
* _ColorRange is set per frame
* Supported older AviSynth+ version that doesn't have audio channel mask property

[kedautinh12]

Nice, thank @StvG

[tebasuna51]

Confused, this new release is r1390, and the previous was r1393

StvG typo, modified to r2390

[Guest]

StvG typo, modified to r2390

Has been rectified (:

Thanks @StvG & @teba

[FranceBB]

Thank you for v5 r2390.
I tested it against the OpenGOP MPEG-2 file and it's working fine now. :)

[Myrsloik]

5.0 RC3 (https://github.com/FFMS/ffms2/releases/tag/5.0-RC3)
Now with FFmpeg that has zlib and some other fun libraries included.

Don't bother reporting any of the listed known issues. They'll probably be resolved before the next release.

[flossy_cake]

ffms2 20240306_r1390

ffms2_r2390 (https://codeberg.org/StvG/ffms2/releases/tag/r2390)

Differences compared to 5.0-RC2 (https://github.com/FFMS/ffms2/releases/tag/5.0-RC2):
* In some cases can be seek accurate while `5.0-RC2` is not (for example, https://imgbb.com/bLzGmXX https://imgbb.com/vZsFK3J)
* AviSynth: GetParity and _FieldBased are set per frame
* AviSynth: rffmode=1 that uses every frame tff/bff
* AviSynth: set _EncodedFrameTop and _EncodedFrameBottom (rffmode > 0)
* AviSynth: both ANSI and UTF8 file names are supported
* _ColorRange is set per frame
* Supported older AviSynth+ version that doesn't have audio channel mask property

:thanks:

(and thanks for remembering to preserve the FFGetVersion() format)

[rgr]

VFR.

I have a question about VFR reading. Will:
ffms2 ("file.mp4")
read *all* frames with the average fps?

I want to make sure I don't have any missed or duplicate ones.

[LigH]

Avisynth supports only one frame rate per clip.

[FranceBB]

Yes and it will output the average FPS, so it will drop scenes with more frames and duplicate scenes with less frames.
Generally what you want to do is specify fpsnum and fpsden and set them to the maximum framerate.
For instance, if file.mp4 was shot on a mobile, has a maximum fps of 60fps (normal motion) and a minimum fps of 10fps (when it was recording static scenes), then:

FFMpegSource2("file.mp4", atrack=-1)

would return a 35fps stream with duplicated frames and dropped frames, which is NOT what you want.
What you want is a 60fps stream so that motion is preserved and whenever frames were lower because there was no motion, they're duplicated, which they would be anyway if you were displaying it on a 60Hz monitor, so:

FFMpegSource2("file.mp4", fpsnum=60000, fpsden=1000, atrack=-1)

[tebasuna51]

FFMpegSource2("file.mp4", attack=-1)
A typo, I suppose, for
FFMpegSource2("file.mp4", atrack=-1)

[rgr]

Yes and it will output the average FPS, so it will drop scenes with more frames and duplicate scenes with less frames.

And that's what I want to avoid. I just want all frames (without duplicating or dropping) like VirtualDub does. So I want to treat VFR as CFR. I'll change the FPS later anyway, and the audio doesn't matter.

[FranceBB]

A typo

yep, fixed. :)

And that's what I want to avoid. I just want all frames (without duplicating or dropping)


You... can't, I'm afraid. You can only output a certain framerate and to obtain that ffms2 will either drop or duplicate.
The best bet is to set fpsnum and fpsden to get the maximum output framerate so that it will never drop frames.
Sure, there will be dups scattered here and there, but that's not a problem.
Why? Simple. It's because it's exactly what you would see if you were to open a VFR video on any other player.
Simply put, if you have a video with VFR that oscillates from 10fps to 60fps as the example I mentioned above and you were to play it on your computer connected to a 60Hz monitor, the player would output 60fps all the time to the monitor (that's excluding FreeSync/GSync monitors which are not that common anyway).


In other words, trust me, just set fpsnum and fpsden to the maximum FPS of the video and you're gonna be fine.
Encoding it as CFR is gonna be fine anyway 'cause x264 is really good at spotting duplicated frames so it will just put a B frame there with a reference to the former frame, thus wasting virtually no bitrate. Besides, if you still wanna re-encode it to VFR instead of CFR post Avisynth, you still can anyway as FFMpeg->libx264 can automatically remove dups and encode it as VFR for you. ;)

[poisondeathray]

If the MP4 is timestamp VFR variety - It does not drop frames if you omit the fpsnum, fpsden options . You only get the encoded frames and average FPS .

If you enter fpsden, fpsnum, it will add duplicates and/or drop frames to achieve the desired CFR