Oh good to know that changing it to 60FPS when doing FHD and it won’t stutter.
Update: I did roll back to version 5.3.6 and no issues with drop frames when upscaling with Proteus or Iris models.
To the Topaz Dev Team:
I had a very similar problem with SVP (Smooth Video Project) software, and it turned out to be related to NVIDIA “Optical Flow.” Turning off optical flow fixed the VFR and stuttering problems.
It may be worth looking at that if the Proteus model is using the optical flow feature.
Thank you.
For some weird reason a simple upscale is dropping frames and returning a variable frame rate file. I am using a constant 30 FPS x264 source but keep getting back a 28.621 VFR with missing frames. Now there is a force CFR option. To check the source and result are what they should be, you should run the following test on both files.
ffmpeg.exe -i filename -vf mpdecimate -fps_mode cfr -f null -
Compare the duplicate and dropped frames from both files. If they are not similar then we still have a problem.
I used the CFR option and the video result is completely broken. The frames are out of order. It seems to be inserting random frames into the places it was previously dropping frames. I am going to have to revert to an older version, not sure which is best.
I hope this is at the top of their list and they don’t think everything is solved with the CFR flag, no it’s not, this thing kills TVAI! At the moment I am helping myself with 5.3.6 and have also installed V6, which I only rarely use for RheaXL
2 Likes
I agree that this kills current versions of TVAI. Considering that the issue has been known for over a month, I’m surprised that Topaz hasn’t released a PSA advising against use of the current versions and blocked updates above v.5.3.6. Instead, silence, and some of us have wasted countless hours trying to troubleshoot the frame issues in rendered video, only to visit the forum and find that it’s a known yet unresolved issue.
1 Like
The problem is that some users (we don’t know the percentage) are experiencing this bug, and Topaz were having trouble reproducing it (we don’t know if that is still the case).
I’ve never experienced the VFR bug (I’ve tried reproducing it and can’t), so why should the updates be blocked? I’m using the latest version without issue so far. This is on PC.
I’ve always found Topaz to be iffy when it comes to frame specifics. Back in the days of V3, it used to drop the first frame of the input video. They “fixed” it with an update, but then it was dropping the first frame of the output video. I returned during V5 and it seemed to work okay at first, until I noticed that it dropped the last second worth of frames at the end of every video (as in the video length is correct and the sound still plays but the video freezes and ffmpeg shows that those last frames are not present).
Because Topaz has never gotten frames right over years, I’ve therefore resorted to a rather extreme strategy… I no longer use it to encode video at all. I output each frame as a PNG image and then ffmpeg them myself into video, so that I have full control over what frames, at what rate, etc. Need enormous amounts of disk space though.
Topaz, I think you’ve done good work with the DNNs themselves, but the surrounding software is not as good.
2 Likes
We get VFR all the time, I didn’t happen on MAC. Rhea model ist not affected, but Proteus+Iris+Artemis under Windows. Many users postet the problem, so if Topaz mean “we can’t reproduce it”, it is ridiculous.
1 Like
I can’t even comment about Mac, as I’m only a PC user.
I use Proteus and Iris the most, and have never had the VFR bug with any export. So until Topaz work out the trigger for the bug, affected users are kind of stuck (unless Topaz actually know, but can’t fix it).
I don’t know why some people it doens’t happen, I think it’s pending on source. I had this several times, it really pissed me off in projects that the result was unusable. Many other users reported this, below is one thread, but there are others. Topaz released a “force CFR” flag in case of this problem…but this does sometimes bad things and an can insert/swap frames, not a solution we can live with. VFR bug
I’m trying to render a clip and can’t quite get it right.
Source: H.264
23.976p
1920w
1080h
~3 minutes from an 83-minute file
Output: ProRes
Settings were 23.976, VLC says 23.981, Premiere says 24.000.
4736w
2664h
In VLC, if I take it frame-by-frame, it’s good, good, good, then plays backwards two frames, then resumes.
In Premiere, it skips frames, holding multiple times per second of playback.
My system:
Windows 11
Premiere Pro
i7-13700k
RTX 3070
48 GB DDR4 RAM
Writing to and from an M.2 SSD
Ran a couple more tests on a smaller clip.
In H.264 I can do it at 4096w. That one seems fine (albeit smaller than I’d like)
In ProRes, with the same exact settings, it’s 24.027 FPS according to VLC. Looks fine in Premiere.
Is there a resolution issue? Should I be hitting a more standard multiple of 1080p? Go for 200% or 250% instead of 248%?
I can attach log files if necessary.
I isolated the incident and took a screen capture. It’s an issue with the Proteus model. I ran the same settings with Theia and it was fine. Furthermore, the reverse-frame issue was appearing in preview, not just the final render.
This is an issue with the app producing a VFR export that our team has been working on a resolution to.
In video ai V6.0.1 they added an option to force CFR for the export and this has worked for some users. They are still working on a full resolution though.
Thank you Kyle! I tried “Force CFR” a couple times last night and it did not produce a fix.
I mentioned this in the main version thread. Turning on “Recover Detail” messed up the frame order. I only output to tiff, yet that made it so that motion would regress every few frames.
Anyway, it might not be the same issue, but it could be connected.
I had the same experience. It actually made the render worse.
