Settings Export & Import

Video AI Ideas
1

What

Allow exporting and importing the current settings of all the clips loaded into VAI.

Why?

  • To allow recovery of work when TVAI crashes or bugs out [1].
  • To give the customer control and a choice of when and where (export) processing takes place, such as delayed processing during night, or on a different machine from the one where the GUI was used to decide on each clip’s settings.
  • To be able to integrate TVAI in a pipeline that consists of further post-processing, where TVAI mainly serves as a pane-of-glass monitor used to decide on defect cleanup settings.

Is there a workaround already?

No, not in the tool.

Custom developed UI automation software can extract the information by simulating a user going through the process of: Select first clip, click menus to bring up the FFMPEG command dialog, copy the text, parse it and store as a JSON/YAML object (for instance). Then repeat that process for all clips in the list. Import however is a lot more difficult and practically intractable as it involves a lot of steps; re-adding the clip, finding it in the list, finding the right UI widgets for each extracted hyper-parameter, filling in the corresponding values automatically. Since the TVAI UI keeps changing all the time, this becomes practically impossible to maintain. Additionally, the clips have to be committed to the export queue first before the ffmpeg-UI dialog becomes available, which is another hurdle as the workflow would require the user to export the clips, and quickly stop processing of every single one, just to get hold of some raw data from which configuration settings can be derived.

What would a good format be for import / export?

JSON. It is the lingua franca nowadays for configuration files. But I have no strong preference, as long as it’s machine parsable (yaml/ini/xml …).

[1]: Right now one has to start from scratch and lose many hours of work. I’ve lost countless already when TVAI either outright crashed while I was preparing a batch of ~50 clips, each with tailored configurations being worked on, or when one of the numerous bugs caused the UI to stop functioning, such as no longer updating the app’s internal state when hyper-parameters were adjusted, which could only be resolved by restarting the TVAI program and start from scratch. There will always be bugs, but offering customers a way to minimize time lost via settings export/import would lessen the pain & cost significantly, when those bugs prevent customers from progressing their tasks.

2

Export and import would be useful for duplicating settings on different source files. Not so much for recovery if there’s a crash or unrecoverable error.

Most modern video editing apps use “projects.” A project file stores both the source filenames and all settings, including processing and export, so that all the user needs to do is load the project file to reimport sources and settings. Some apps will autosave projects, periodically preserving WIP, and if the app crashes, upon restart will notify the user that there’s an autosave and ask if it should be restored.

3

That’s a good use case as well.

In fact, I use it for that; partly. Pick one clip representative for a subset of clips. then repeat for another “leader clip” of another set. Once I’m happy, I click export to get access to the “ffmpeg-panels”. Copy-paste the information using UI automation into another program, which then uses the values as templates to be applied across all the different sets of clips. Then create jobs for a custom scheduler that dispatches jobs to whatever free machines I have the TVAI CLI installed on. Heck, even for smaller projects, I always create a job queue file, since my own job-runner is more reliable than the TVAI GUI in terms of monitoring, alerting and restarting (if needed) failed jobs. And editing a simple text file is so much quicker and less error prone than using a GUI.

As for recovery. Well it depends on each individual’s usage pattern I’d say. Whenever I’m on a windows machine, I unconsciously press CTRL+S every 30 seconds since I don’t trust any app on windows to stay up for long. The only exception is Sublime text which has the best built-in tracking of what goes on, and seems invulnerable to any kind of failure mode; Always recovers automatically and perfectly. But that’s one app in a million. Now, creating a good recovery solution is hard. And for media processing quadruply so. As such I deliberately wrote the feature request to have the narrowest scope possible, while still allowing for being used for recovery as well. A simple state dump to a file, and a loading would solve so many issues I have with this program.