| Start Year | End Year | DB Start | DB End | Video Capture | Editing | Long-form Description |
|---|---|---|---|---|---|---|
| 2012 | 2013 | DB6 | DB7 | None | Twitch highlighting | During the first 2 years of the VST the video editing was done via the Twitch highlight system. Discovered Issues: |- Editing via Twitch highlight was extremely problematic due to the nature of the run (VERY long videos) |- Twitch's highlight system (at the time) was VERY poor at precise seeking and cutting in long videos. |
| 2014 | 2014 | DB8 | DB8 | Wubloader (v1) | YouTube | Video Capture: Due to the overzealous VOD muting that Twitch added on 2014-08-06 dave_random wrote the first wubloader to capture the video live during the event. The first Wubloader used: Livestreamer to capture the stream live to UTC named .mp4 files, FFMPEG to edit the requested videos, ImageMagick for thumbnails, and PHP to run everything, YouTube API to upload videos, and GoogleDocs API to interact with the private VST gDocs sheet (for when to cut and upload a requested video). A video would be trimmed with 2 minutes on either side of the times in the spreadsheet and uploaded as unlisted to YouTube. Video Editing: Once on YouTube, a VST person editing videos would go in to the youtube editor, and then trim down the video to the desired actual clip length. After the video finished processing, the VST person editing the video would then set it to public on both YouTube and the VST private sheet. This would then make the video avaliable on the VST public sheet as well as the YouTube channel. Once again, the VST found the edge case: |- You can not have "too many" (we never figured out the exact number) videos in the "processing edits" state on youtube at once. |-- Once you hit the too many videos "processing edits" you become completely locked out of the YouTube video editor. |-- This lasted an undefined set length of time past when the last video finishes processing. Discovered Issues: |- There was a minor problem with the way the capture worked, that if all the capture nodes missed a stream piece there would be no way to edit it. |-- This was usually circumvented by a couple VST members also doing a local capture for themselves. |
| 2015 | 2018 | DB9 | DB12 | Wubloader (v2) | Thrimbletrimmer (v1-3) | Video Capture: Due to the new home-grown editing componet (to avoid YouTube editing hell) dave_random had to create a new Wubloader. The new Wubloader used: nodejs for tying all the pieces together, Livestreamer to capture the stream live to UTC named .mp4 files, FFMPEG to edit the requested videos, ImageMagick for thumbnails, YouTube API to upload videos, and GoogleDocs API to interact with the private VST gDocs sheet. The Wubloader project was moved to node.js instead of PHP as we now had to also serve a editing front-end that was tied to gDocs auth as well. Also it had to accept input from the new Thrimbletrimmer video editor, so videos could be sent to youtube pre-trimmed. Initial video edits were still done with 2 minutes on either side and down-scaled to 480p, for ease-of editing (as video quality doesn't really matter to editors). Due to livestreamer going unsuported in 2016, for the DB11(2017) and DB12(2018) runs the capture component had to be switched to streamlink Video Editing: Thimbletrimmer (v1-3) was a custom video editing component written and maintained by Master_Gunner. It is a (relatively) simple video editing interface that allowed accurate trimming of the beginning and end of a video clip. The editor also allowed fine tuning via milliseconds so videos could be accurately trimmed to start/end on a good audio spot. Master_Gunner gradually updated the editor over the years to better work with the way the VST edits videos and imporve funcationality. Discovered Issues: |- The minor problems with the way the capture was done remained, but it was a rare occurence that it was a major problem. |-- This is only really an issue with hard stream drops, and the nodes not instantly picking back up when the stream came back. |- The only problem with the way editing was done is not with the editor itself, but with that the actual cutting of the video. |-- Video cutting had to be done on the same node the editing was done on, this was because there was no inter-node communication. |-- This could lead to a node becoming overloaded with edits, and thus having to re-do some edits as that node's editing service had to be restarted. |
| 2019 | 2020 | DB13 | DB14 | Wubloader (v3) | Thrimbletrimmer (v4) | Video Capture: This was created because of a new Twitch "feature" discovered during DB12 (2018-11-10): Where they (Twitch) changed the way authentication worked with their HLS servers to force a 24-hour refresh. This caused ALL of the captures the VST were making to miss a poster moment. After that ekimekim decided to take on the task of making a new Wubloader. The new Wubloader uses: A completely self written (in python 2.x) HLS capture bot by ekimekim and Chrusher, Which uses: gevent for process concurrency on nodes, PostgreSQL for a backend database, Flask for writing the interaction API, nginx for serving HLS segments, stats, and the API, Prometheus for monitoring the servers, Grafana for dashboards, FFMPEG to edit the requested videos, Docker for deployment of nodes, YouTube Video Upload API to upload videos, GoogleDocs API to interact with the private VST gDocs sheet. The new Wubloader is different in that it was designed to be a distributed modular system for capturing the stream from Twitch and editing clips from it. This means that we can have a number of capture nodes that can all get segments from each other in case of stream drops or network problems. With the modular design, editing and cutting videos are now independent processes that can be done by any editing or cutting node, respectively. Lines from the VST private sheet are also stored in a database (with UUID identifiers) so only a single node has to poll the spreadsheet vs all of them. Thrimshim is also an API component written to interact between Thimbletrimmer and the Wubloader. As we are captruing the raw HLS stream segments in multiple resolutions, this means we just re-stream those segments for editing and don't re-encode anything. Best Practices: 1) At least 2 nodes that keep the full capture. 2) The node that runs the database/monitoring/sheet-sync is on good physical hardware and internet. 3) Editing nodes can run on any setup, but cutting nodes should be on physical hardware. 4) Geographically different nodes to minimize possibility for segment loss / ad interruption. DB13 Actual Server Setup: (multiple)Wubloader capture nodes were setup that start constantly polling the stream to ask for new segments. |- These nodes were located in geographicaly distinct locations to correctly avoid ad segments. |- Some nodes were partial capture nodes that only kept limited time window of data and act as backup for other nodes. |-- These were nodes with limited disk space. |-- These nodes were deployed as a "in case all other nodes miss a segment". (On each capture node) a backfiller and restreamer were running to sync missed segments to and from all other nodes. (On the "best" full capture node) The database, sheet-sync, and monitoring components were setup. |- "best" here means: Best physical hardware and internet connection. (On 2 "good" full capture nodes) Thimbletrimmer (video editor), Thrimshim (API), and cutter were setup. |- "good" here means they are on physical hardware (not Virtual Machines). Video Editing: Thimbletrimmer (v4) is a custom video editing component developed by Master_Gunner with some modifications written by ekimekim. Due to moving to storing HLS segments, the video editor had to be re-written, it now uses: Video.js a HTML5 Video Player that can play a HLS playlist, Custom Javascript interaction with Thrimshim (wubloader API) for getting segments and sending information back, and Custom Javascript and HTML to make the player better. It is a (relatively) simple video editing interface that allows accurate trimming of the beginning and end of a video clip. The editor also allows fine tuneing on a .1 second basis so videos could be accurately timmmed to start/end on a good audio spot. Discovered issues: |- During the DB13 run twitch disabled all 3rd party API keys for viewing streams, and we were forced to switch to using Twitch's own API key. |- Very rarely one of the 2-second segments will not have any audio, this has been verified to be a twitch problem. |-- Detection methods for the no-audio segments is being investigated. |- Pre DB14 YouTube removed the auto-add to playlist based on tag feature. |-- This caused ekim to have to write a custom playlist manager component of the wubloader. Further details and the code itself can be found on the Wubloader GitHub page. The current version of the Wubloader was designed by ekimekim and developed by ekimekim, Chrusher and MasterGunner. |
| 2021 | 20?? | DB15 | DB?? | Wubloader (v3.5) | Thrimbletrimmer (v5) | Video Capture: Due to Python 2.x being EOL'd everything needed to be ported to Python 3.x The new Wubloader (v3.5) uses: A completely self written (in python 3.x) HLS capture bot by ekimekim and Chrusher, Which uses: gevent for process concurrency on nodes, PostgreSQL for a backend database, Flask for writing the interaction API, nginx for serving HLS segments, stats, and the API, Prometheus for monitoring the servers, Grafana for dashboards, FFMPEG to edit the requested videos, Docker for deployment of nodes, YouTube Video Upload API to upload videos, YouTube Playlist Management API to manage playlists, GoogleDocs API to interact with the private VST gDocs sheet. The main new feature with the Wubloader 3.5 is the Playlist Manager as YouTube removed the "auto-add to playlist by tag" feature because they hate fun. The Playlist Manager automatically adds videos to playlists based on event category, day, and other tags set by people editng the VST private sheet. There is a new tab in the VST private sheet that lists playlists, their IDs, and which tag to use for them. These IDs and tags are then pulled in when sheetsync looks at the private sheet and added to the Playlist Manager as needed. Best Practices(same as v3) DB15 Actual Server Setup: (multiple [8])Wubloader capture nodes were setup that start constantly polling the stream to ask for new segments. |- These nodes were located in geographicaly distinct locations to correctly avoid ad segments. |- Some nodes were partial capture nodes that only kept limited time window of data and act as backup for other nodes. |-- These were nodes with limited disk space. |-- These nodes were deployed as a "in case all other nodes miss a segment". |-- At least 1 of these nodes was deployed in a country where Amazon can not legally serve ad segments. (On each capture node) a backfiller and restreamer were running to sync missed segments to and from all other nodes. (On the "best" full capture node) The database, sheet-sync, playlist-manager, and monitoring components were setup. |- "best" here means: Best physical hardware and internet connection. (On 2 "good" full capture nodes) Thimbletrimmer (video editor), Thrimshim (API), and cutter were setup. |- "good" here means they are on physical hardware (not Virtual Machines). Video Editing: Thrimbletrimmer (v5) is a custom video editing component developed by ElementalAlchemist. Thrimbletrimmer (v5) uses: Custom code by ElementalAlchemist located here: Thrimbletrimmer Github hls.js used to handle playing HLS video data. Luxon a JavaScript datetime library. For the new update video.js was dropped in favor of hls.js. When doing video playback, the browser's native video player is used, (HLS.js turns the HLS video data into data the browser-native player can handle), Luxon for working with timecodes, Custom Javascript interaction with Thrimshim (wubloader API) for getting segments and sending information back, and Custom Javascript and HTML to make the player better. The new editor is much more advanced it can now do: |- Multi-range editing |-- Allowing editors to cut out the middle or multiple portions of a video |- Frame seeking (instead of seeking by .1 seconds) |- Auto-add of video chapters (added mid-run DB15 by EA) |-- Time-codes are auto-determined, editors still have to enter the chapter text Discovered issues: |- DB15 (post run) it was discovered that "too long" playlists (on the re-streamer) could run the server(s) out of memory. Future Updates: |- allow updating the title/description/(public vs unlisted) of existing videos from the editor (instead of needing someone with youtube login access) |- allow uploading video thumbnails on edit, or setting thumbnail to any chosen frame from the video |-- Using the: YouTube Set Thumbnail API Further details and the code itself can be found on the Wubloader GitHub page. The current version of the Wubloader was designed by: ekimekim and developed by: ekimekim and Chrusher. The current version of the Thrimbletrimmer was designed and developed by: ElementalAlchemist . |