VEAI 3.0: Back to the Future

Hi All,
After using VEAI for a few months, going through its code base, the list of issues, the feature requests and many frustrated customers, it has become clear that VEAI has to change significantly to evolve into a product loved by all users, beginners and experts.

All the issues and feature requests can be categorized broadly into 3 types:

  1. Video read or write:
    No support for various output codecs or even codec profiles
    No pass through streams
    Issues handling various color spaces
    Inability to handle variable frame rate
    Meta data and other streams of information are lost
    Audio channels and bit rate changed to low quality
    Frequent crashes on native M1 builds while opening certain mp4 files

  2. Workflow:
    Periodic re-login is required
    Ability to work offline has become hit or miss
    Missing command line support
    Inability to play around with model versions or tweak model parameters in the json files
    No ability to pause or recover after processing for days
    The current workflow of using VEAI is very time intensive with tons of waiting for processing or preview to finish, preview lengths are fixed and huge memory hogs
    The UI needing to process video again and again even though it was processed before
    Need to use external programs to preprocess videos before using VEAI
    No availability of plugins to make VEAI part of a video editing pipeline
    Slow performance or not using all of the GPU resources

  3. Models:
    Artifacts or no significant quality improvements
    Inability to switch between model versions except the ones visible in model manager
    Manually having to fix frames and color after using VEAI
    Request for new models to do solves different problems

Most of the problems in VEAI stem from the fact that it treats video as a series of constant rate images. All the current models run on these assumptions and as a result have issues processing variable frame rate videos, frame repeats, scene changes etc. This also hampers development of future models like stabilization, scene detection etc. that require multiple passes over the video.

To address these concerns and allow seamless additions of new features, we have decided to rewrite VEAI as a new application with a whole different architecture and way of doing things. Starting today and over the next few weeks we will be sharing various alpha and beta releases of VEAI 3.0 in this category.

VEAI will consist of two independent parts: the GUI and the backend FFmpeg filters. The GUI will merely call the FFmpeg backend and spawn separate processes. This will finally allow VEAI to utilize the newer RTX 30 series GPUs to their full extent. Currently users have to use multiple instances of VEAI to optimally use the GPUs.

Video IO
The use of FFmpeg directly will also resolve all of the video read/write issues. These filters will be open source and will allow interested users to use our C API to write plugins, filters etc. for other applications. We would also be adding more plugins/filters for other applications in the future.
Our public FFmpeg repo with filters is hosted here

GUI
Create and store projects, so batches, previews and settings can be retained
Ability to create/modify and share presets
Customize the FFmpeg command being run to allow use of other filters from FFmpeg
Users will now be able to process a video in the background and continue using the app
Complete offline support with an option to download all models (that actually works)
New flow to allow login for machines that are completely offline
User editable model and preset files for easy sharing
Retain previews on disk, eliminating need to process already previewed video
Process video using multiple models at the same time
Generate previews of whatever length you might want
Recover from crashes and continue processing
Ability to pause and continue on another machine
GUI alpha/beta will start next month

Models
VEAI 3.0 will also introduce a stabilization model that will allow users to stabilize their videos and keep the original resolution. The model will not only smooth out the camera motion and reduce/remove camera jitters it will also predict the missing frame data when the correction is applied. Expect the FFmpeg filter for the model in the next couple weeks.
Ideally this approach would allow us to focus on our core expertise to create and improve our models to perform better on all user videos.
Please let me know and start a discussion below if you have any suggestion, concerns, etc. about the current roadmap for VEAI.

Thanks
Suraj

40 Likes

You guys are up to something.

I’m really excited about that.

7 Likes

Exciting news, thank you Suraj!

2 Likes

I’m really looking forward to seeing these changes, particular being able to recover from crashes and sharing models.

Will it be possible to skip upscaling monochromatic / repeated frames to save time and processing power?

Wow ! Thanks Suraj !!! finally going in the right direction ! very excited !! :slight_smile: !

Nice!

Will the photo apps join the architectural changes?

This is a major step forward, Suraj. Great to see, and look forward to some testing in due course.

This all sounds awesome but please keep in mind VR video , both 3D vr180 and 2D and 3D 360.
I’ve been using VEAI for a while now on my VR videos and it does a wonderful job. The idea of adding stabilization is fantastic but VR video is certainly a horse of a different color. That and the increasing use of prores raw are two features that are of great interest to me.

1 Like

This is an amazing level of customer respect shown to us, that makes this program more than worth its weight in gold!

Thanks, everyone at Topaz Labs, for your hard work with making this the best program of its kind that has hit the market, I, for one, am so glad that I bought these programs from Topaz Labs!

EDIT: You have fast become my main method of choice for creating better videos and with the inclusion of the AI- stabilization model, I just may have to cross two of my favorite programs out of my pipeline; Virtualdub2, and Avidemux!

3 Likes

Really excited to see what you have cooking! It’s incredibly impressive how far VEAI has come in such a short time, and I’m glad you seem hungry to do even more!

Here is my Dropbox link for my test files.
Here

fixing the deinterlace videos needs total rework. i have a series from WB from early 2000’s that no model can truly remove the interlace and in the best case scenario doubles the FPS and generates stutter images since some damaged frames by heavy interlace are dropped. that is priority number 1 to fix since that could be an amazing marketing tool: remove all interlace from old records/tv shows recordings etc.

2 Likes

You’ve probably got “baked” interlacing. That simply can’t be removed.

Wow FANTASTIC news ! Huge congrats on the bold decision !
Modularization is the right call and I’m incredibly excited about the possibilities ahead (and the developer time you’ll be freeing up by not fixing things like audio issues :grinning_face_with_smiling_eyes:)

Being able to run VEAI as an ffmpeg filter sounds like a dream come true to me.
Well, it will be once I can actually build it on Mac (my M1 Max can’t wait to get video frames thrown at it)

A few questions :

  • What components exactly are you open sourcing ? I assume the GUI and models will remain proprietary, but is the whole backend implemented in the ffmpeg filter, or will it call out to another closed source process ? For example, how are you going to make sure that only customers can download the models (if that matters) ?
  • Could I build this on a Mac today if I massaged the build scripts enough (I’m a DevOps engineer) or does the filter have non portable code at the moment ?
  • I can see you’ve forked off ffmpeg 4.4 : any plans to rebase to 5.0 at some point (and then keep in sync with upstream as much as possible) ? Pretty sure it has some big performance improvements for M1 Macs. Here’s a great build script : GitHub - Vargol/ffmpeg-apple-arm64-build: Build script for ffmpeg targeting the latest open source video codecs running on macOS using Apple's M1 processor.
  • Again, I want to stress how important I think it is to stay close to the mainline ffmpeg, so that we users don’t have to choose between VEAI and the latest ffmpeg performance-oriented improvements like ARM Neon patches, or hardware accelerated ProRes encoding on the M1 Pro/Max chips.

Thanks again for the update, I can’t wait to run a test build on my Macs !

4 Likes

If everything works fine for you now, then it should continue to be fine. You should be able to use ProRes raw as long as it is supported by FFmpeg.
Stabilization of VR videos should be interesting, especially for 360 videos. As long as SAR/DAR is set correctly, in theory it should work well. Hopefully, you can test it when it is out in a few weeks.

1 Like

For now the filter code is open sourced, all the proprietary execution and model code will be hidden away inside dylibs.
Currently the filter is using the AIEngine to run the models, the AIEngine requires authentication and can download models from our server.
We already have a build script for mac, I personally use a M1 max machine to code. The issue with mac is the distribution of command line tools due to gatekeeper issues. We should be posting one in the next couple of days.
We still have to figure out a way to post the AIEngine dylibs required for the build, once we standardize this part you should be able to build for mac. This would be especially useful if you want to use GPL codecs or filters with FFmpeg along with VEAI.

The topaz branch is almost current with the master branch. Changes from the master branch of FFmpeg are pulled in every week. So the current build is based on FFmpeg 5 and not 4.

2 Likes

Thanks a lot for the clarification Suraj ! Apologies for what I got wrong about your ffmpeg branch :slight_smile: Looking forward to the 1st Mac build …

Don’t forget to bring back support for tensor cores :slight_smile:

1 Like