Movies and web formats

Oink reads and writes movies with the same Read and Write nodes as image sequences, and the same knobs as Nuke's mov64 reader and writer. Reading and the picture side of writing run inside the app's engine, using FFmpeg libraries that the installer downloads (python3 install.py; an LGPL build). An ffmpeg program is still used for the encoders and a few special cases (below); it must be installed or pointed to with the OPENCOMP_FFMPEG environment variable.

Read a movieCopy Anchor Link

Point a Read at a .mov, .mp4, .m4v, .mxf, .mkv, .webm, .avi, .gif, or an animated .webp / .avif. The frame range becomes 1 to the number of frames in the movie. The frame range, before / after, frame mode and offset knobs work as for sequences.

• Any frame can be asked for in any order: the Read lands on exactly that frame, even in long-GOP H.264 with B-frames. This is tested against ffmpeg decoding the file from the start.
• While a movie plays, the frames after the current one are decoded ahead on background threads, and the colour conversion runs on the GPU. UHD ProRes and H.264 play at about 25 fps with no dropped frames, and scrubbing a long-GOP movie takes tens of milliseconds a frame. Pixels are identical to the older ffmpeg-program path.
• The ffmpeg program is used instead for rotated phone movies, VP9 with alpha, NVDEC decoding, GIF and variable-frame-rate files, and for any file the libraries cannot open. Set OPENCOMP_MOVIE_LIBAV=0 to force it everywhere.
• Each frame's metadata has the movie's timecode for that frame (input/timecode), frame rate, codec, bit depth, colour tags and audio. A Write downstream uses the timecode as its start timecode.
• 10- and 12-bit movies are read at 16 bits a channel. Alpha is read from ProRes 4444, PNG, Animation, VP9 WebM, GIF and animated WebP.

Write a movieCopy Anchor Link

Set the Write's file type to mov (with mov / mp4 / mkv as the format), mxf, webm, gif, webp (animated) or avif (animated). A render streams its frames into one file while it renders: no temporary images.

• quality (Low / Medium / High / Best), or limit bitrate with a bitrate; gop size and b frames for H.264, HEVC, AV1 and VP9.
• encoder: software (x264, x265, SVT-AV1) or NVENC, the NVIDIA GPU encoder, several times faster. If NVENC can't start, the software encoder is used and the Write says so.
• ycbcr matrix and data range as in Nuke; the file is tagged with them and with the output transform's primaries and transfer, so players and the Read decode the same colours.
• The default output transform is Rec.1886 (Nuke's Gamma 2.4 / Rec.709) for mov, mp4, mkv and mxf, and sRGB for webm, gif, webp and avif, which browsers show correctly.
• Movies are one file, so a frame is not renamed into place. Image-sequence frames are different: each is written to a hidden temp file and renamed when complete, so a half-written frame is never seen, and the render reports NaN, infinite or all-black frames.
• write timecode, start timecode (else the input's timecode), audio file, fast start, fps work as in Nuke. The knobs round-trip through .nk files.

PresetsCopy Anchor Link

The Render dialog has a Preset menu that sets the Write's knobs before rendering:

Colour checksCopy Anchor Link

These are measured by tests/test_movie_io.py, on NJR footage and a generated colour chart.

Round trip of the NJR plate (1920x1080, random frames, display-referred PSNR):

SpeedCopy Anchor Link

Measured 2026-09-29 on the NJR "people" plate (001_017) encoded to each codec, and the NJR edit movie. Machine: 64-thread CPU, RTX 4090 (driver 580), ffmpeg 7.1 (flatpak) / 5.1 (host), a shared machine with other jobs running (load 10-14), so treat these as lower bounds. Measured with tools/bench/movie_io_bench.py.

Decode, through the Read's movie path (sequential frames, float RGBA out):

• A random frame (a new decoder seeking): 220 ms at 1080 H.264, 555 ms UHD H.264, 680 ms UHD ProRes.
• NVDEC is no faster here: the CPU decoders keep up, and the frame still comes back to the CPU for the conversion. At UHD the limit is the pipe (16-bit frames, ~1.3 GB/s) and swscale.
• In the app (E2E, 1080p H.264 with B-frames): the first pass plays at 15-23 fps on the loaded machine (about 80 ms a frame from request to screen); cached frames play at 24 fps.

Encode, 24 real frames streamed from the Write (movie_writer):

The encoders alone (host ffmpeg, raw UHD YUV in, 210 frames): H.264 NVENC 58 fps, HEVC NVENC 63 fps, x264 medium 27 fps, x264 veryfast 48 fps, x265 medium 7.6 fps, SVT-AV1 preset 8 4.2 fps. Through the Write, the limit is the RGB -> YCbCr conversion and the 16-bit pipe, not the encoder: NVENC's gain only shows once that is moved to the GPU. AV1 NVENC was not available (host ffmpeg 5.1 has no av1_nvenc; the flatpak's 7.1 needs a newer driver): the Write fell back to SVT-AV1.

LicencesCopy Anchor Link

Reading uses FFmpeg libraries that are loaded only when they are an LGPL build (built without the GPL option and without x264 / x265); a GPL build is refused and the ffmpeg program is used instead. The encoders in the ffmpeg program you point to carry their own licences: the one found on most Linux systems is a GPL build. Apple ProRes and Avid DNx encoding, and software H.264 / HEVC encoding, carry patent or trademark terms that are reviewed before a release. See Licences and source offer.