VidFUCK

From YSTV Documentation Wiki

VidFUCK (short for Video Frame UnfuCK) was a process designed to fix frame duplication in early recordings of YSTV's live HD programmes. It is named after the much more sensible VidFIRE process, as used by the BBC in program restoration.

Background

After the HD upgrade in 2013, YSTV needed a way to record their studio shows at the 1080i50 resolution they were now being produced in. Vidsrv had been fitted with a Blackmagic Decklink Duo, with the intended purpose of allowing studio output to be passed through the server as part of the Tarantula playout system. Since the studio passthrough feature of Tarantula was not being utilised at the time (nor would it ever be, due to a lack of development), it was decided to use the SDI input as a means to record live studio shows.

Media Express was used for this, producing (fairly large) uncompressed AVI files that were impractical to work with. To get them into a more manageable form for both the limited storage space on both Fsrv and the edit PCs, they were ran through Handbrake to create much smaller H264 encodes.

Unfortunately, Vidsrv was not quite powerful enough to encode the 1080i50 source in realtime. As a result, recordings had frequent frame duplication. Programs affected by this included:

Live on the Lawn 2014 was also recorded using Vidsrv. However due to a chronic shortage of HD cameras at the time, the program was produced in SD PAL, which the server had no troubles recording in realtime.

In May 2014, YSTV invested in a Hauppauge PVR Rocket - a cheapish HDMI recorder, which was able to do realtime H264 hardware encoding of HD content.

The Problem

For NaSTA 2015, ERN 2014 was chosen to be submitted as YSTV's Best Live entry. Given that it was an ambitious show, with both a program being produced in the G/046 studio and a separate OB covering the results (something which hadn't been done since 2008 - and hasn't been done since!), it was thought that it would be a prime candidate for an award win. However, after reviewing the recording, there were concerns that the jitteryness of the video would result in it being marked down by the judges.

It seemed that Vidsrv had suffered more than usual given the length of the show and heat being generated by people and servers alike in the control room; resulting in not only in frequent frame duplication, but sometimes triplication!

Hence, it was decided to try a way to 'fix' the recording by removing the duplicate frames, and then using interpolation to recreate the missing ones. Sam Nicholson took on this ambitious task, with the help of whoever was in the control room at the time. At some point the process was dubbed 'VidFUCK', so-named after the restoration technique VidFIRE.

VidFUCK Process

  • The first step was to break the original recording into a PNG image sequence. A simple ffmpeg command to do this was run on Encodesrv.
  • Once the PNG sequence had been generated, the duplicate frames needed to be found and removed. The best tools that could be found to do this were Windows-based, so the PNG sequence was copied over to an Edit PC. After a few trial runs to get the settings correct (ensuring that only true duplicates were matched), the application was left to chew through the entire sequence.
  • With the duplicates removed, the sequence needed to be recompiled, and the missing frames regenerated. Fortunately, when importing an image sequence into After Effects, it uses the image filenames to determine what order frames should appear in the sequence; leaving appropriate gaps where frames were missing. A free plugin pt_FrameRestorer was then used to generate the missing frames through interpolation.
  • Audio from the original recording was readded to the sequence, which was then exported to a single video file ready for editing.

Issues

  • While the final VidFUCKed video was a huge improvement over the original recording, there were still problems where frames had been duplicated at the same time as a cut. The resulting video had noticeable morphs where After Effects had attempted to interpolate between two completely different frames. This was worked around manually in the NaSTA edit by cutting out the affected frame(s).
  • The process takes a long time, and tied up an Edit PC for multiple days. Doing this in the run up to NaSTA submissions was in hindsight ill-advised.

Legacy

Despite the success of the technique, it was never used again. With current programs no longer having the same recording issues, and most of the affected recordings having been lost in Easter 2014 as part of Drive Crash 2, the process was quickly forgotten about... until this page was created three years later.