Hello Everyone!
We have another beta for y’all. Please let us know if processing gets stuck and send us the logs.
Download:
Changelog:
Thanks for testing
Please upload problem videos and logs here: Submit files
- Added Slider to GUI for changing sensitivity for duplicate detection
Yes! I’m glad to see a slider for this!
Goodbye flowframes! 
I noticed that the stalls are coming from the disk operations, especially in previews, where huge TIFF files are being recompressed into a video later, and 15s of preview can easily take 10GB of space with 1080p/60 imagery, which makes normal modern hard drive choking a bit. I redirected the TEMP folder to my HDD, so poor SSD wouldn’t get shredded with writes.
I also noticed, that in highly irregular frametime video (like jumping from 8 to 13-23fps, the frame algorithms in current beta, even with duplicate frames removal, tend to keep this stuttering (maybe for the sake of audio sync?), whereas, while using StaxRip with those two plugins…
…I was able to get a fluid 60fps (the script was set to this amount), but at the cost of audio sync.
The same was with that Lalafell Reaper “square” video, which seems 60fps, but has “stutters” going down to 23-34, which makes it an ideal experimenting field (developers already have it uploaded, so they can go wild!).
Hence, I was hoping VEAI might be best of two worlds in the future!
It’s not only about duplicates in these kind of videos but dropped frames between non duplicates frames. So even with removing the dup frames it will still be a jerky playback because the new frames are not always being interpolated where they should be.
Well, I have some really choppy vids that I’m currently testing, and the results so far are phenomenal, even with the default settings!
It’s not jerky at all, it’s buttery smooth actually! To be fair, I only used 2 vids from the same source, I’ll try others!
EDIT: I’m currently testing a very choppy 15 fps video resampled to 30 frames, let’s see how they hold up!
EDIT2: It did not go very well, as there are limits to the model, as I tried the setting at the default 10%, and it worked well, except the connecting frames were nothing but a blur, and at 5%/20% it was a slide show!
EDIT3: I tried another one at 15 frames, no resampling, yet it is indeed as you said choppy, oh well, I suppose I had to see it for myself.
I know a duplicate replacement has already been here, but I’m still wondering how this affects the synchronization of the audio stream.
Maybe if you actually bought the software they’d care about what you have to say.
@gregory.maddra For my part there is really no new thing about these new beta. You do not even take into account your January roadmap, while we are in February now. In your January roadmap you specify to put a model manager with old models, where is this manager that he should have already released in January? Where is he? Nowhere, just because you don’t even respect your roadmap. We software customers are waiting for a famous model manager. We all look forward to. thank
I like where things are going with the VEAI, and the dedication devs are having towards tackling this variable-frame-rate and frametimes-stuttering problem, which is a TOUGH one.
I’ll be patient and I have faith in the team, because training models and testing them internally takes a LOT of time and effort even with current crazy hardware available. If such effort weren’t there, with the old rule “garbage in - garbage out” (with model training) still intact, we would have underwhelming quality.
You’re right, for ExactDeDup AVISynth plugin to do its job, it first scans the whole video and “registers” the frametimes, and writes them into txt file, to use it later for final file’s MKV container.
All the improvements that are being made are very good, but the fundamental basis of all this are the models. That is why it would be good if they informed us periodically how the option of implementing the previous models is going. It would also be good if they informed us if the old models are being retrained with this new Topaz Video AI v3 or if they are also being trained from scratch or they are not going to be trained anymore.
Mac version - I’ve been busy on other things a while, so have rarely been able touch VEAI in some months. Playing with this beta - and the first thing that strikes me is that the previews still don’t play well - the original and preview frames don’t always sync, and playback of the original in any of the preview mode is extremely stuttery - seems to keep jumping back a frame or two.
It makes comparisons very tricky to do. I remember this being an issue in the early VEAI 3 betas - so I’m a little surprised to find it’s still a problem.
Agreed - preview is still not great on Windows version also, but I think it is on their roadmap to improve it.
I quite really don’t understand the behavior of “Replace Duplicate Frames”. Why it is adding duplicate frames that don’t exist in the original video the more the threshold is higher ??
I am testing now a video I created with an avisynth script with real bit for bit duplicates and TVAI still misses some of them with the default threshold.
Exact duplicates should be found no matter the threshold.
When exporting TIFF Lossless 8 Bit from AVI-file input, the TIFF sequence always starts with filename 000001.tiff as the first frame.
Every professional software expects TIFF sequences to start with filename 000000.tiff for the first frame, so there needs to be an option to configure this for all input formats.
Keep getting unable to parse option value frame 0 errors with imported mp4, and Huffy AVI the media info’s/GUI info included with my logs.
I turned all models on, as a stress test, to see if the program encodes without incident, and it looks like I cannot process anything with the stabiliser model, no matter the setting, at least not with the donor vids I used.
Including the media info/logs now.
EDIT: It’s definitely the input videos, I’ll upload the video info after my tests, I tried encoding to huffy/lagarith/264 AVI, still the same results…
EDIT 2: no amount of re-encoding will fix the donor files, I even went with MKV, still the same.
‘replace dupllicates’ doesn’t really work well with Apollo. Maybe that’s because by default I think Apollo is still interpolating 8 frames ?
So let’s says we have this video with frame 4 frames ABBC (B being a duplicate frame)
Normally the 4th interpolated frame between B and C should be picked as replacement to have a normal flow continuous motion. It seems it’s not the case and an earlier (random ?) interpolated frame is being picked.
In some tests I made it seems there is still a gap in motion and a jittery effect with the new replaced duplicate frame with Apollo compared with Chronos where here the motion really seem being continious and no jittery effect.
But hard to do tests with Chronos since the process is being frozen at 99% and I have to manually stop it but the end video is then incomplete and even corrupted sometimes.
You are correct about the issue with Apollo, it can generate a maximum of 8 frames, more than 8 would lead to repeated frames in the output. Use the chronos or other Apollo models for situations requiring more than 8 frames. Generation above 16 frames could be artifact prone or blurry.
There should be a timeout of 100 seconds if the processing is stuck at the end, we are looking into the issue. Can you please share the last portion of the video you are having issues with?
Can you upload the logs, if you already haven’t. Unless you have a 24GB or larger GPU running all models may not be possible unless you are using a low res video or have memory setting set to lowest setting.
For the stabilization issue, I sent you a message.
