Topaz Video AI Beta 6.0.3.0.b

Hi everyone,

We’ve built a new beta with a fix for variable framerate exports.

We’re hoping to move quickly and push this to the main channel, so we’d definitely appreciate any quick test of commands that currently generate VFR in the main 6.0.2 release. Please confirm with ffprobe, MediaInfo, AviSynth, or any of your usual tools that the new exports are at a constant framerate and the expected number of frames. Thanks for your patience on this fix!

6.0.3.0.b

6 Likes

Unfortunately, it still doesn’t work for me.

For context, in branch 6.0.2.1.b I wrote:

"For some reason, this isn’t working for me. The model loads, but video processing doesn’t start. The GPU shows high utilization, but in reality, the graphics card isn’t even heating up.

I don’t know what the issue could be. Could it be because my Asus 3080 Ti TUF OC is flashed with a BIOS from another model? It’s the official XOC BIOS from the GALAX RTX 3080 Ti, which removes power limits.
(Board power limit. Target: 1000.0 W Limit: 1000.0 W)

I can assure you that in all other tasks and games, my GPU has been working flawlessly and without overheating for a whole year.
I’m interested in getting the program to work on my system.

I remember that a few years ago, you (Topaz) faced a lack of variety in GPUs for testing your software. Back then, we (users) downloaded several gigabytes of test files prepared by you, ran them on our machines, and then sent you the data.

I’m willing to do the same now if it’s needed to help you debug Topaz Video AI. And I think many others would also be willing to participate."

1 Like

Using the command:

ffmpeg -hide_banner -i video.mov -vf vfrdet -f null -

Can confirm a test file that was saved as vfr pre this beta is now cfr

[Parsed_vfrdet_0 @ 000001204158a180] VFR:0.000000 (0/2786)te=N/A speed=2.93x

1 Like

I did a really short test using the GUI and MediaInfo shows a CFR (test done from 25fps to 60fps). I will test more thoroughly after I finish my queue since I don’t like to pause it.

EDIT: A little bit more extended test (500 frames). Enhanced with Rhea, x264 codec, CFR 5Mb/s → OK. Interpolated same video from 30fps to 60 fps with Chronos, x265 codec (both Main and Main10), CFR 5Mb/s → OK.

This might be the end of this headache.

1 Like

@meimeiriver finally

The issue of variable frame rate also exists in this version. However, during my testing, I came across something strange.

When I edited only a segment of a longer video (720p to 1080p with double enhancement using the Proteus and Iris MQ models, then converted with Chronos fast from 23.974 to 30 FPS and HDR), I ended up with a fixed frame rate.

Using the same settings to process the entire video with identical configurations, however, resulted in a variable frame rate again. Could it be that the issue is not reproducible for you because your test videos are too short?

1 Like

I will try later. I use the double enhancement too in most of the videos that are a decent quality, then in a different pass I do the interpolation to 60fps. However I never used HDR so far. I will try to process a shorter full video only because I don’t want to waste my time.

The one movie I tried came out variable—BUT that’s what the input video was. I noticed a command that says to match the source frame rate mode.

So here are my findings with a full short video of 15min2sec.

  1. Using a double enhancement in GUI v6.0.3 (Iris & Proteus) in the same pass, exported to MP4/H264/Dynamic Bitrate/ Quality level High —> no VFR anymore. Same number of frames exported according to TVAI and MediaInfo.
  2. Interpolating the previous file from 24fps to 60fps using Chronos creates a weird variable output which, by the way, is never “finalized”, it still has the suffix of the temporary file. I tried this interpolation both through CLI and GUI and here is the output.

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4.1@Main
Codec ID : hvc1
Codec ID/Info : High Efficiency Video Coding
Duration : 15 min 2 s
Bit rate : 4 975 kb/s
Width : 1 920 pixels
Height : 1 036 pixels
Display aspect ratio : 1.85:1
Frame rate mode : Variable
Frame rate : 59.940 (59940/1000) FPS
Minimum frame rate : 30.000 FPS
Maximum frame rate : 15 360.000 FPS
Original frame rate : 60.000 FPS

Another thing worth to mention and pretty important in my opinion is the fact that the processing speed in v6.0.3 is 50% slower (7.5fps) compared to the one from v5.3.6 (15fps). Same settings were used for both tests on the same video.

3 Likes

The question, of course, is: how did they achieve this? They actually found the cause? (I heard no such statement from them), or did they just build in the command to force CFR from before? I remain highly skeptical. A frame-by-frame analysis/comparison will be required: just counting output frames does not suffice.

on macOS:

  1. Command-W used to work to close a project, lost shortcut (sure I can tweak Preferences to assign it, but why?)
  2. How about a visual near the export queue to indicate processing time left? Now I have to click on Export Queue to see something… and BTW that Export View pane is ugly, lots of space for little information and I have to click on the X to close it, would like to click on the main window to close it.

I would very much like to see new models and be able to use them in Topaz v3. Sorry, but v4, v5, v6 have not improved things for my workflow and I am still waiting for live preview during export… My 2 cents after 2 years of using Video AI :slight_smile:

2 Likes

I’ve enhanced a 720p@30fps ~30min clip with the following workflow: Iris upscale x2 → ffmpeg scale_npp back to 720p → prot upscale x2 → ffmpeg scale_npp to 1080p → chronos fast to 60fps

The downscaling with ffmpeg inbetween specified no -fps_mode which defaults to passthrough, so frames were equal after downscaling, and so fast the amount of frames.

I also changed container between mp4 and mkv after each run of TVAi and ran the command below on both containers:

ffmpeg -i input.extension -vf mpdecimate -loglevel debug -f null -

This resulted in 14 duplicates on every output file. Which is margin of error with default mpdecimate parameters. So all good so far.

Source:
FFmpeg mpdecimate docs

On the final clip (which i also cut down to 12min) i ran:

ffmpeg -loglevel verbose -hwaccel cuda -i input60fps.mkv -vf mpdecimate -fps_mode cfr -c:v hevc_nvenc output.mp4

Which reported 2000 duplicates out of ~42000 frames.

I then tried to set stricter boundaries for duplicates running :

mpdecimate=hi=1:lo=1:frac=1:max=0

Which basically requires frame-to-frame to be identical down to the pixel.

That resulted in 310 duplicate frames - however, 268 of them are within the first 9 seconds of the video which has something to do with the movflags used as the video is showing a still frame for the first 8-9 seconds.

I tried loosening the parameters for mpdecimate to hi=100:lo=100:frac=1:max=0 whic also ended up with duplicate frames (total of 824, ~550 when removing the first 8-9sec of still frame). Some parts had several duplicates, but for the most part it seemed to follow a pattern of 1 duplicate every 3 seconds.

Make of it what you want. Those are my findings so far.

Daniel, did you use a 24 fps source, or a 24000/1001 (23.976) source?
The reason I ask is that this distinction has been critical in the past when I faced similar issues.

The interpolation to 60 fps from a FILM source isn’t possible without some judder. But interpolating to 60000/1001 works as it’s just a 3-each-2 insertion ratio (dream up 3 frames for every 2 source frames).

Finally, what was the container format for your source clip and output clip respectively?

mp4 → mkv/ts conversation for NTSC/FILM will result in ffmpeg thinking the output is VFR as it’s rather “stupid” in its detection and narrow in its definition.

Likewise going the other way around where the source creator might have forced a CFR flag in the mkv container, even when the pts times themselves vary within the clip, might not carry over to mp4, which would mean the player would see the clip for what it actually is; a series of pts-timestamps that differ +1 one, but form a pattern (a cycle).

The input was a “full” 24fps in an .mp4 container and the same .mp4 as output. If you want, I can provide the YouTube link for verification and testing purposes, it’s a public video.

I don’t use .mkv for exports, that is my final container after I finish all the enhancements and add some attachments to the file with the settings used in TVAI (1 screenshot as .png and 1 .txt file). I use this method as a “record” in case I want to try the enhancements again at a later time with different settings or models.

I did a couple more tests with a some videos off YouTube with different framerates, one is 23.976 FPS, the other is 25 FPS. Input container .MP4 to output container .MP4. All done through CLI.

  1. The output after 2 enhancements in a single pass (Iris & Proteus) had a CFR with the same frame count. Comparing/syncing the videos in GridPlayer I didn’t see anything off in real-time while playing. Obviously this player doesn’t allow comparison frame-by-frame since it is based on VLC. So everything checked on MediaInfo.

  2. The second pass (interpolation to 60 FPS), showed the same “weird” VFR but DIFFERENT from one to another. See below and notice the difference in “Maximum frame rate”.

Frame rate mode : Variable
Frame rate : 60.000 FPS
Minimum frame rate : 30.000 FPS
Maximum frame rate : 15 360.000 FPS

Frame rate mode : Variable
Frame rate : 60.000 FPS
Minimum frame rate : 30.000 FPS
Maximum frame rate : 60.000 FPS

Just on a hunch or lucky dumb idea I decided to repack the files in a .MKV container. Surprisingly now both files show CFR.

Frame rate mode : Constant
Frame rate : 60.000 FPS

So I assume TVAI writes something in the header of the file during/after interpolation that is confusing MediaInfo. I am not familiar with other tools like ffprobe, so I will leave that test to others. Still that doesn’t explain why for the previous test mentioned above this trick didn’t work. :thinking: Especially since the same file processed in v5.3.6 had a CFR of EXACTLY 60FPS after interpolation, not 59.940 (59940/1000) FPS.

You can look at this post I made in another thread for the two ffprobe commands, showing how to check what differ between those two clips.
If the pts pattern is different and the time bases and / or the reported frame rates differ, that would explain the different interpretations of cfr vs vfr. It they are the same however, it would point towards some tagging.
But afaik, mp4 doesn’t have a tag for asserting cfr vs vfr (haven’t paid for the standard doc so can’t verify this assumption), which would mean the difference for two mp4 for files in this regard ought to be explained by the frame rate and time base.

Topaz is apparently prioritizing nailing this issue, but needs help from customers to track down the root cause through (useful) user provided “failure cases”, so you checking yours might expedite a proper fix.

I don’t know why, but Topaz Video AI makes the image worse where it shouldn’t.
I used the Chronos model to increase the FPS and chose the FFV1 codec (lossless compression). You can see the result in the image.
Just to clarify, this is not an interpolated frame; even the original frames (which should, in theory, stay the same) get corrupted.
snapshot_00.34.482

It is clear that the text has become “squared”

1 Like

Did use the beta and using the resolve plugin does make resolve crash.


ot but nice made. :smiley:

1 Like

The best Video I have seen in decades love it !!!

2 Likes

Well, TVAI definitely writes something in the file to make MediaInfo think that is VFR, I tested it on multiple files. We know that it does because it adds something to the files that records the settings used to process the file.

videoai : Enhanced using iris-3; mode: manual; revert compression at 50; recover details at 25; sharpen at 50; reduce noise at 10; dehalo at 25; anti-alias/deblur at -25; focus fix Off; and recover original detail at 20. Enhanced using prob-4; mode: manual; revert compression at 50; recover details at 25; sharpen at 50; reduce noise at 10; dehalo at 25; anti-alias/deblur at -25; focus fix Off; and recover original detail at 20. Changed resolution to 1920x1080

videoai : Framerate changed to 60 using chr-2

The weird part is that “part” disappears after the video is repacked in .mkv and the frame rate is reported differently.

I have some other comments/findings/opinions about this v6.x.x but I will post those in the main thread of the release.