Input frame rate is not consistent with output frame rate.
e.g. a 25fps video will export as 24.94 fps or 24.96 fps (there is no standard number, it’s totally random every time!).
No interpolation used, just standard Proteus model.
Not having a standard fps output makes the application unusable!
George, can you gives some more details on the codec and container being used for this?
If you can send your logs to the support team for review as well with a link to this forum post. help@topazlabs.com
To gather logs, please select Help > Logging > Get Logs for Support and attach the zip file to your reply.
Here is a video to help with the steps of how to collect the logs.
Info of the file:
Complete name : 1 - Highlights.mov
Format : MPEG-4
Format profile : QuickTime
Codec ID : qt 2005.03 (qt )
File size : 4.09 GiB
Duration : 3 min 16 s
Overall bit rate mode : Variable
Overall bit rate : 178 Mb/s
Frame rate : 25.000 FPS
Writing library : Apple QuickTime
TIM : 00:00:00:00
TSC : 25
TSZ : 1
Video
ID : 1
Format : ProRes
Format version : Version 0
Format profile : 422 HQ
Codec ID : apch
Duration : 3 min 16 s
Bit rate mode : Variable
Bit rate : 177 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:2
Scan type : Progressive
Bits/(Pixel*Frame) : 3.413
Stream size : 4.06 GiB (99%)
Writing library : adb0
Language : English
Encoded date : 2024-11-19 10:20:22 UTC
Tagged date : 2024-11-19 10:20:22 UTC
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Audio
ID : 2
Format : PCM
Format settings : Little / Signed
Codec ID : sowt
Duration : 3 min 16 s
Bit rate mode : Constant
Bit rate : 1 536 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Bit depth : 16 bits
Stream size : 36.1 MiB (1%)
Language : English
Encoded date : 2024-11-19 10:20:22 UTC
Tagged date : 2024-11-19 10:20:22 UTC
Other
ID : 3
Type : Time code
Format : QuickTime TC
Duration : 3 min 16 s
Frame rate : 25.000 FPS
Time code of first frame : 00:00:00:00
Time code of last frame : 00:03:16:23
Time code, stripped : Yes
Language : English
Log:
2024-11-19-12-21-59-Main.zip (95.3 KB)
Thank you. What app are you viewing the file properties in after they are processed?
Running some tests on my end to try and replicate the issue for the team to review.
Media Info, Directory Opus, standard Properties (Windows), Handbrake and Adobe Premere show the same info on the processed files.
I did find something interesting a few minutes ago, this bug appears on Proteus but not on NYX!
NYX exports are fine, all Proteus exports have the wrong fps. On the same source files!
I also experience this problem with al version 5.4.0
This is the input frame rate
This is the output framerate (variable?)
This instead and the output from Topaz Video outdated version [4.2.2] now become a reference for testing
Another observation:
I did a few tests and when exporting to H264 .mp4 file, the bug goes away.
On H264 .mov file the bug is still there.
And - of course - on ProRes exports, which is the main problem since we need the best possible export for further compression.
It appears to be an .mov problem somehow.
EDIT: Nope, worked for the short tests (portion of a file). When exporting the whole thing, it creates wrong fps files even on .mp4 
I seriously cannot believe this issue still happening when I was told months ago they were going to fix it.
1.- EXPORTING IN PRORESS RESULST IN SHORTER CLIPS AND INCORRECT FRAME RATE.
Example, I input a 1080p 59.97 frame rate video. Exporting in prores (any flavor) results in a shorter clips because is encoded at 60.05 frames per second. this issue is been going for months and wasn’t present in previous versions.
logsForSupport.zip (146.9 KB)
merged this over to help consolidate feedback.
I assume the ffmpeg encoder is to be ruled out?
Got the same issue, the output file suddenly has a Variable Framerate and the video stutters. Up to two days ago there was no issue, i reversed back to 5.3.6 and the issue is fixed.
I kindly ask if this problem can be solved.
I send a sample file that when upscaled 4K with Proteus and ProRes 422 HQ codec returns variable frame rate.
Thank you
are we being ignored again in this issue?
I might have found something if it wasn’t already discovered: I think the “recover detail” setting may be bugged.
I was getting juddery VFR outputs on every model that uses that setting, but not on the ones that don’t. So I turned it to zero. Smooth CFR output.
Incidentally, the juddering is also present if you output the frames as images, so I don’t think its an encoder problem but rather what’s being fed to the encoder.
I seriously cannot believe this issue still happening either. All throughout v5.x - v6 the VFR bug exists, and it makes all renders useless.
For me, I was able to get it ‘solved’ by pIcking FFV1 output in a .mov container (even in v6). I didn’t use any frame interpolation models, though.
Currently back at v5.3.6, which works flawlessly. January will be my time to renew. I may cancel my subscription if it isn’t fixed by then. And no, this is not some dumb threat: just me, rationally, trying to assess whether it’s worth renewing when I’m forced to stay stuck on a v5.3 version. At some point it starts making less and less sense. I can always return in a year or so. We’ll see.
I tryed all newer, including betas, VFR exists all above 5.3.6 and makes it broken. I went down to 5.3.6 too …and I stay there until all mayour bugs are fixed!
Sadly, I’ve mentioned this before - commenting on a issue does not equal to committing to its correction of said issue(s).
1 nv clean color corrected PQ_3_prob4.zip (4.2 MB)
What on earth… doesn’t matter if i export prores, h265 … model also doesnt matter… i get either (a) backwards jumps or (b) duplicate frames where there were no duplicates or jumps in the source…
when i export to prores, it becomes variable framerate (source was solid 23.976)
BTW: THANKS for mentioning 536 as saviour, because it actually does work. jeez luise, i was starting to doubt my sanity when i couldn’t produce any straight output anymore.
Its been 4 weeks when this was first reported, and the issue is still not even found let alone fixed? The issue 100% is with the new videoplayer they added because the issue came around when the new videoplayer got added, it’s better to create a videoplayer from scratch than one cooked up by the internet by some people with free time.
About the VFR problem, does it also happen when video contains no audio or when in TVAI audio is set to re-encode? It’s only speculation, but should be checked if not already done; could the audio track leads to frame dropping?!
