Heads up, this is going to be a big post. The most important thing to know is that the program is unfinished in it's current state.
As many of you may know, I've recently been working on making a GUI for all the TASVideos publication tasks. It's come a long way from my first intention of it being an alternative to the batch approach; I got to explore a lot of ideas and dream up a lot of interesting features, but at the same time I worked hard, overstepped my particular skill level, and burnt myself out pretty quickly.
You can grab the source here. Here's an outline of the project and it's feature set, use, bugs and unfinished tasks:
The point of the GUI was to make an encoder and publisher's life easier. For this to work, the simplest and most common encodes should be able to be done using the program with just a few clicks and no configuration. Similarly, more advanced tasks (that are still somewhat common) should have the necessary options to be able to achieve the required goal in as simple a way as possible. Finally, for the outliers, the tasks which are once-off situations which require extreme customization, or the people who simply prefer scripting; the program should allow custom input so as not to get in the way of their progress.
When you open the program for the first time, you're greeted with the settings window. This can be triggered again by going into edit > preferences and is saved into a plain text ini file in the "programs" subdirectory of the encoding package. All of the options here are to help make the use of the program more friendly for each particular user.
After the settings window has been dealt with, you're greeted with a menu bar and a collection of tabs. This is the program itself. Typically, the tabs should be tackled in order. The "Pre-Load" tab pre-configures the rest of the program appropriately for then run you're encoding. If you paste the submission URL and hit "Fetch Game Details", the game's information will be downloaded from the server. It does not allow you to fetch the same link twice to prevent abuse. Emulators with known setting tweaks are listed in the Emulator drop down box. If the emulator you require is there, select it (and in Dolphin or Bizhawk's case, select the other appropriate options). After that is done, hit "set emulator options". This configures all of the appropriate emulator-specific tweaks throughout the program. The checkbox "Apply settings to new sources as they're added" is for emulators like Dolphin (specifically more recent versions) that require a particular source filter. Having this applied ensures the source is set appropriately when it's added. If per-chance you forget this and want to apply the settings to your sources later, the "apply to sources" button does that.
The next tab is the "Video & Timecodes" tab. In most typical cases, you will just have to click "add file" and add your sources - the rest of this form will handle itself. In other scenarios, you can select one, multiple or all of the loaded inputs and hit edit (there's also a right click menu for convenience). When you do so, you're greeted with a whole host of per-source video options that can either be applied to the selected video or all videos. If a particular option is not ticked, it will not be changed - for instance, if you select two sources with one of them being resampled and do not check the "resample" checkbox, they will remain with their separate options, despite the fact you can change other options. This makes batch processing much easier. Below the video source table are "Multiple Resolutions" and "Multiple FPS". These functions detect if the input video files vary in the indicated field and if so, allow you to control the handling of it. This is done by selecting a particular reference video from the list to match. The reason behind choosing another video and not a target rate or resolution is based on how the files were intended to be handled. If your target resolution is small than one of the videos then that video will be losing data when it's shrunk down - but if you're outputting for Youtube, the video would be resized up and whilst the pixels would be uneven - no data would be completely left out. This method would allow better handling and direct resizing to the output resolution of the
target video, giving the best option in any scenario. Additionally, any edits made to a video in the edit dialog are reflected in the video table (so if all the videos are the same resolution and you crop a video, multiple resolutions will be activated). This is useful for handling scenarios such as the old gens videos and a similar principle applies to trim and JPC-RR. Alternatively, there's an option for an input script, which isn't a script to be encoded but rather is a script that loads the sources. This can be followed by trims, edits, crops, resizes - it's all at the user's discretion and would be placed into the final script in lieu of the loading of sources.
Timecodes are set automatically if you've selected your emulator previously. This includes the enabling or disabling and the automatic rate setting. You can force enable/disable or change the rate if necessary. The audio and logo tab's audio table is identical to the video one, although with less options. It's worth noting that if you selected Dolphin as an emulator and dspdump1.wav was detected, it will automatically be resampled to the appropriate rate. The logo settings are as they're described.
The details and options tab configures the script for you. A lot of the run details are fetched via the fetch function, but here you can edit them as you will. All information should be double checked by the publisher or encoder. If your dump is of a 3D game, you can set the native resolution for the script to resize it down to. If you're using a dual-screen emulator, you can define the screen's positioning in the video (although emulator settings can do this automatically). The x264 compatibility pass option introduces a third pass into the encoding procedure, specifically for dealing with Bizhawk N64. The timecodes generated during the first pass are rejected by the encoder and so this does a second first pass, only after adjusting the frame rate to 60000/1001 and to an alternate timecodes file. This alternate file is used by x264 during the encoding process, but the original timecodes file is still used for muxing, to retain the correct timings. "Prestretch subtitles for aspect-corrected encodes" renders the subtitles differently for the MKV encodes (where AR flags are used). In the case of ng_bighalo, it uses different spacing and sizing methods to predict the output aspect ratio and compensate for this. In the case of freesub, it renders the subtitles on a transparent video clip at the size the AR correction would amount to and then resizes that clip and overlays it on top of the video. In both cases, the output video's subtitles no longer look like they're stretched or compressed.
The encode tab is the last tab I was working on when I stopped, so some of it is unfinished. The idea behind this was that scripts or data from the program could be loaded into the queue and encoded. A max number of running jobs could be specified, as well as an "upload when done" option and so encodes for various games could be encoded all at once in a unified queue. This would save a lot of time. The Encode Type combo box has a few options. Publication MKV, Publication MP4 and Youtube Stream all set the defaults for each of those current encode types (including x264 settings down the bottom). CRF is left adjustable if need be, although 20 is chosen in most cases (16 is chosen for N64, and 18 is chosen for Dolphin as they are the most appropriate). QP is used for Youtube. If either of the Extra HQ options is selected, native resolution factor becomes selectable. For 2D games, this is a point resize to n times the initial resolution before anything is applied. For 3D games, this is a downscale to n times whatever was specified as the native resolution in the previous tab. The suffixes are generated automatically. Custom encode enables all of the settings and leaves them as they currently are - so if you select Publication MP4 and then Custom, you can customize that encode. There's an unimplemented Save / Load feature here that was intended on letting encodes make their own presets. Other notable settings include the ability to (for Virtual Boy) mux the two screens as two video tracks on non-standard encodes and the ability to toggle subtitles on and off if need be.
The last tab, Youtube, was part of the original (much more basic GUI I made). It reads the database generated by TVC man and allows the copying of checksums to the clipboard. Otherwise it's unfinished. The menu bar is also mostly unfinished. It was my intention to be able to save all of the settings as a project and load so you could easily see what you did for an encode or make a new one based on those settings. I also intended on making an "about" screen, with information about all the contributers. Instead, I'll list them here: A lot of the ideas and logic in the script was either by or inspired by both feos and Aktan. Almost all of the Virtual Boy stuff (including the multiple screens idea) came from Spikestuff. The previously mentioned people, along with fsvgm777, Fog and Dacicus all provided feedback, insight and support during the making of this. Nach provided the JSON information. Adelikat helped with the JSON fetching code and both supported and motivated the expansion to the much more grand design we have here.
Anyway, that's the program and it's general use. Unfortunately coding is not my specialty and the source is a mess (it's absolutely atrocious, ALL controls should not be updated when one changes, c'mon). I'm out of practice and I didn't plan very well, but for the most part it works. For anyone interested, my todo list stands as follows:
- Add method to export script
- Clean up code, port to C# (probably do one while doing the other)
- Comment code while doing this so others can read it better
- Add max simultaneous encodes to settings window
- Warn when over 30 AVI files are loaded in the source window, or figure out a way to import 50+ AVI files without AVISynth error.
- Add a live preview for subtitle placement and timing (and potentially source editing)
- Better NDS screen handling. Implement NDS screen stacker > input script. NDS stacker should have ranges and stacking type settings.
- Add tooltips so long, terrible explanations aren't needed
- Fix the tab order, fix shortcut keys, etc.
- Find a way to monitor running processes to enforce the encode limit
- Find a way to automatically create torrents
- Investigate nanoglyth's archive uploading experiments as auto-uploading there should be possible
- Allow additional files to be muxed in (eg .srt subtitles)
- Add adjust volume to either sources or overall. Values should probably be 0% to 200% using Amplify(0.00) to Amplify(2.00)
- Add a screenshot picker tool that automatically uses optipng and pngout (and if file size is > 45kb warns and potentially auto saves a jpg with correct settings)
- Include appropriate plugins and programs (such as anaglyph.dll)
- Implement queue. Queue folder with 00001.avs and 00001.ini (avs being script and ini being settings for easy reload).
- Use base file name for temp files to ensure no clashes. This includes timecodes.
- Write script. Modification will be needed to include the functions currently not included.
And here's a copy-paste of my definitions for the encode queue columns:
ID = incrementing integer
File = base file name
Destination = Output folder
Type = Encode Type (eg publication mkv)
Description = User provided description
Format = MKV, MP4
Quality = CRF20, QP5, etc (include method and number)
Resolution = 640x480
AR = AR mode, 4:3 Hard Resize, 4:3 AR Flags, etc.
Upload = Enabled, In Progress, Done, Disabled
Source = Script (if so, path) or simply "Program"
Status = Enabled, Disabled, In Progress, Aborted, etc
And that's that. As I stated before, I burned myself out pretty hard with all of this. I haven't coded anything for
years and this was a pretty ambitious project to undertake. I'm leaving it here in case either myself (or perhaps someone more skilled) wants to resume work on it at any point. I'm more than happy to answer any questions, discuss any of the features I was yet to implement (as in most cases I had a rough idea of what I was going to do and how I was going to do it), help decipher the code, hell, anything really. I do really want to see this finished at some point but I've just sunk all of the time I've had in the past couple of weeks into this and need a break for a while.
