Transcoding

The situation with transcoding (either exporting standalone movies in a variety of formats, or generating .mov or .mp4 proxies) is very similar.

Originally, the only transcoding support was that provided by QuickTime for Java. The original Export As Movie settings dialog was based around the capabilities offered by QuickTime, including creating flattened or reference movies, exporting a QT movie using a variety of video and audio codecs, using other exporters like AVI or image sequence, adding burnt in text or timecode, and setting QuickTime metadata (such as title and copyright).

When the Media Framework abstraction layer was introduced the QuickTime for Java exporter was moved to use that interface, and additional exporters using Xuggle and DSJ were implemented as well.

With the introduction of the native helper in CatDV 11 and imminent removal of QuickTime of Java, two new exporters were implemented:

Native QuickTime exporter

To support those situations where QuickTime is needed to transcode a file (either when using a specific codec such as from Calibrated fro Avid, or to render out sequences) the ability to transcode using QuickTime was added to the native helper. The logic was based on the old QTJava exporter but completely re-implemented in C++ rather than Java.

FFmpeg exporter

FFmpeg is a widely used open source media decoding and encoding tool.

As well as exporting to a lot of obscure formats that nobody uses, FFmpeg can transcode any supported media file (any file that it can play) to QuickTime MOV and

H.264 MPEG-4 files. It can also export to MXF, though it won’t necessarily produce files that are 100% compatible with a target camera format or NLE like XDCAM HD 422 or Avid DNxHD without a lot of tuning of very advanced parameters.

Unlike the FFmpeg player inside the native helper, where we directly link to the FFmpeg libraries, for transcoding we invoke FFmpeg via the command line. This

gives us access to the x264 encoder, a very fast open source H.264 encoder but which is under a GPL license and requires you to release the source code of anything that links to it.

Intermediate transcoding

The FFmpeg exporter can’t read files that require QuickTime and Calibrated, and the QuickTime exporter can’t read files such as AVCHD transport streams, and neither exporter can read RED movies, so to support such transcode paths we allow transcoding via an intermediate image sequence.

Each native helper player can dump the frames from a file to a sequence of JPEG images, together with WAV files for each audio channel, and each exporter can take one of those image sequences as it’s input.

That way we can automatically transcode a sequence consisting of an AVCHD file and a RED file to a QuickTime movie, say, by decoding the frames using the FFmpeg and RED players and then passing the resulting image to the QuickTime exporter.

With default settings (the FFMpeg Exporter “Intermediate Decode” setting left at “Automatic (only if required)”, and the Advanced Media Handling “Transcoding media” preferences option left at “Automatic (use intermediate images if required)”) the FFmpeg and Native QT exporters will attempt a normal transcode first and then try decoding via an image sequence instead.

Hardware acceleration

In 12.1 we compiled up the ffmpeg.exe command line tool to support hardware accelerated transcodes using NVENC encoder options and CUVID decoder options if an NVIDIA graphics card is installed. These are available by selecting the h264_nvenc and hevc_nvenc video codecs in the FFmpeg exporter settings dialog.

Only recent NVIDIA cards support this, and only on Windows and Linux. The main benefit is on the encoding side where it can improve h264 exports by a factor 5x or more and h265 exports by 10x or more.

Outside of FFmpeg, we utilise CUDA on Windows and Linux when available, specifically for RED decode and ARRI decode giving a substantial increase in the time taken to process the frames.

For macOS, outside of FFmpeg, we utilise Metal where we can. We currently take advantage of Metal for RED decode and once we upgrade to the latest ARRI SDK, we'll be able to leverage Metal for ARRI decode too.

Please be aware that RED decode will not use GPU decode by default and it's quite a difference in how it works compared to the CPU decode version.