Still the Last Frame Duplicated Problem!

Win Version 10.0.19044.1889, 16GB Ram, 1TB SSD, Ryzen 5 5600 or 5700, Geforce GT1660


This “Last Frame is duplicated” Problem still exists, and i wasted at least 40 Hours before it was clear, that this old Problem (that was even in 2.6.4 in a less worse form)
still exist, and that i wasted 299$ for something that has even more problems as Video AI 2.6.4 !

Source: (Copyrighted, i will not upload it !)
320x240 MPEG1 File, Progressive, 4:2.0, 5832 Frames, 29,97fps

Video AI 5 counts 5832 Frames in the Seek Bar, but shows the
second last Frame as the last Frame, so the last one is missing/dropped.

Ok let’s see what the Output is, without Themis, or any other FPS changes.

Output: ProRes (tried AVI and FFV1 too ! Same Problems !)

5833 Frames ! The Frame before the last one is duplicated, and the last one is complettely gone (which makes sense, when Topaz AI 5 eat the last one, in the first place)

Ok, maybe Topaz has a problem with MPG Files (which would explain, why it jumps around in a range of ~10 fps like crazy, if i hold the -right cursor key-) let’s convert it with VirtualDub2 to HuffYuv, 4:2:0 inside a AVI Container.

So the most basic Container & Lossles Codec out there.

I open it in MPC-HC, VLC, VirtualDub2, anything is Ok . 5832 Frames, no Dupes, no jumping around.

Now i open the Avi File (with the most simple and basic and probably oldest
Lossles Codec out there) in Topaz Video AI 5.

Again the same Problem.

Video AI 5 counts 5832 Frames in the Seek Bar, but shows the
second last Frame as the last Frame, and the real last frame is missing, and on Top of that.

Frame 0 in Topaz is in reality Frame 5.
Frame 1 in Topaz is the same as Frame 0 in Topaz.
Frame 2 is Frame 6 in reality and a dupe of Frame 7 in Topaz.
Frame 3 is Frame 4 in reality
Frame 4 is Frame 5 in reality → So Frame 4 and Frame 0 & 1 in Topaz are dupes.
Frame 5 is Frame 4 in reality → So Frame 5 and Frame 3 in Topaz are dupes.
Frame 6 is Frame 5 in reality → It seems, from this Point on, there is ““only”” 1 Frame Difference.
Frame 7 is Frame 6 in reality
Frame 8 is Frame 7 in reality
Frame 9 is Frame 8 in reality
etc etc

Reality: In Tools & Players that can read (for ages !) the most basic Codec in the most basic Container in the right way.

Ok, let’s try something different.

Duplicate the last Frame (so that the Output has 5833 frames) in the MPG File inside VirtualDub2, save it as 4:2:0 HuffYUV in a Avi Container, and let’s see what Video AI 5 does.

Same behavor from Frame 0 to Frame 7, and the last Frames ?

Now Video AI, doesnt eat/drop the last frame, and doesnt duplicate the second last one.

The Last Frames are like in the Modified Original. (were a duplicate from the last frame was inserted on purpose !)

Is this some kind of bad joke ?

If i duplicate the Last Frame all is ““normal”” (except the first 7 Frames, see above)

If i dont duplicate then, Video AI eat’s the last Frame, and duplicates the second last Frame.

Topaz Video AI 5 is absolute useless if it behaves like this, and does random stuff like that.

I’m so angry ! I can be the nicest person on the planet, but if i work 3 Days in a stinking, dirty, hot, forgery for 300$ and buy something that is at least broken for 2 Years, then i’m getting Mad and got a big reason to lose my politeness !

You let people pay 300$ and can’t fix a problem, that is there since at least 2 years ?

Jesus Christ ! A whole team of coders, people who can write code in ASM, and mess around with AI and then those people cant fix that ?

It must be a bad joke, or on purpuse, so that people update and update and renew (yeah more $) there License for a newer Version, in the hope, that this god d… old Problem will be finaly fixed.

And dont blame FFMpeg for that ! So many Players & Tools use it as ground base, and dont got that problem with AVI and HuffYUV.

I go back to Topaz 2.6.4 !

Because there it was clear for me, how to avoid that problem and it was clear for me how to process the Output. It was not Random behavior like in AI 5 !

Example with Topaz 2.6.4:

Take a File that was not processed before in Topaz 2.6.4, and create a Output File.
Anything Ok ! Input 300 Frames, Output 300 Frames (So the first is 0, and the last is 299)

Take Topaz 2.6.4 Output File as Input File (this is what creates the Problem !)

Then it’s always the same System.

Topaz 2.6.4, will drop the last Frame (299), and the 7th & 8th Frame (293 & 292)
before the last one are always dupes from each other, there are no other Problems than that !

Solution ? AviSynth before Topaz 2.6.4


then use that Source File in Topaz 2.6.4

After Topaz Output, use it as Topaz Input, to make another Output.

Output will be 299 Frames.

Topaz 2.6.4 dropped Frame 300 and the 7th & 8th Frame (293 & 292)
before the last one are always dupes from each other.

So use AviSynth again, but now for the Topaz 2.6.4 Output.

FrameNuum = last.FrameCount
DeleteFrame(FrameNuuuum - 8)

Voila ! Problem solved.

Is the source VFR ?

No, it’s a very old MPEG 1 (so VFR is probably not supported) Clip from 2004, when VFR was extreme rare and only supported from WMV, RMV and the obscure Sorenson Mpeg4 Codec. That’s the only 3 Codecs were i ever saw VFR before the
Smartphone Recording & Youtube era came up.

Here the MPEG 1 File Data:
The MPEG1/2 Plugin count 5833 Frames because the last frame in VirtualDub, is always a fake frame in gray.

Here as AVI with HuffYuv, and simple PCM 44,1 Audio
Here the “Caching Input Driver” (based on FFMpeg) counts 5832 Frames, because
it ignores the last gray frame.

No matter if i open the MPEG 1 File or AVI File, the last Frame in VirtualDub is the
fake frame that is gray, and the Timeline counts 5833 Frames.

Ok it seems this Problem is finaly fixed :slight_smile:
Bravo Topaz Team :slight_smile: