Video Formats and Transcoding

Video formats affect image detail, timing, storage, playback, and the reproducibility of an analysis. A conversion that looks acceptable during ordinary playback may soften a landmark, alter frame timing, remove metadata, or create a gap between segmented files. Establish and test the file workflow before processing a full dataset.

This page addresses file handling after recording. See Camera settings for choices made in the camera and Managing video clips in VidSync for importing, organizing, and synchronizing the resulting clips.

Containers, codecs, and bitrates

A video filename does not completely describe its contents. Several distinct properties are involved:

  • Container: the file structure, commonly identified by an extension such as .mov or .mp4. A container can hold video, audio, subtitles, timing information, and metadata.
  • Video codec: the method used to encode and decode the images, such as H.264, HEVC (H.265), or Apple ProRes. Files with the same extension may contain different codecs.
  • Bitrate: the amount of encoded data used per unit time. A higher bitrate often preserves more detail within the same codec and recording conditions, while producing larger files.
  • Resolution and frame rate: the dimensions and timing of the recorded frames. These can be changed during conversion, intentionally or accidentally.
  • Additional streams and metadata: audio, timecode, orientation, color information, creation time, camera data, and other information that may be needed later.

Compatibility therefore cannot be inferred from an extension alone. Test a representative file in VidSync on the Mac that will be used for analysis. Confirm ordinary playback, frame stepping, duration, synchronization, and simultaneous playback of the expected number of camera views.

Preserve the camera originals

Copy the original recordings to protected project storage before conversion. Retain the camera’s original directory structure when it contains sidecar files or metadata. Create a second copy on separate storage before erasing or reusing recording media.

Converted files should be written to a separate directory with filenames that preserve their relationship to the originals. Avoid workflows that overwrite, rename, or delete the only copy of a recording. The originals permit a later conversion with different settings and provide a reference when a timing, quality, or metadata problem is discovered.

Keep a record of the source filename, output filename, conversion date, software and version, complete command or preset, and any warnings. A text log or table stored with the project is sufficient. File checksums can provide an additional way to confirm that archived originals have not changed.

When transcoding is useful

Transcoding decodes a recording and writes it in another encoded form. It may be useful when the original codec or container does not play reliably in VidSync, when several high-data-rate views cannot play smoothly together, when interlaced footage must be deinterlaced, or when a variable-frame-rate recording requires a carefully verified constant-frame-rate version.

Conversion may also reduce very large files to a manageable size or place files from several camera types into a consistent workflow. Every lossy conversion can discard information, and timing operations can duplicate, omit, or interpolate frames. If the originals already play correctly and storage and performance are adequate, conversion may add little value.

Changing the container without re-encoding the video is sometimes possible. This is often called remuxing. It is faster and preserves the encoded image data, but it does not correct problems within the video stream itself. An inspection of the source file should determine whether remuxing, transcoding, deinterlacing, frame-rate conversion, or no conversion is appropriate.

Choose an output deliberately

Preserve the source resolution and frame rate unless the workflow has a documented reason to change them. Scaling cannot create missing detail, and reducing resolution may remove small features. Increasing or decreasing frame rate can duplicate, discard, or interpolate frames. Deinterlacing should be applied only to interlaced material and should be checked on representative motion.

H.264 is widely used and often provides a practical balance of quality, file size, and decoding performance. HEVC can often retain similar visual quality at a lower bitrate, but it requires more decoding work and its playback behavior should be tested on the intended Mac. Less compressed formats can preserve detail and support editing, while producing much larger files.

Bitrate requirements depend on resolution, frame rate, codec, encoder, camera noise, motion, and scene complexity. Water, foliage, surface shimmer, suspended particles, and other detailed moving backgrounds are difficult to compress. A bitrate that works for a clean laboratory background may obscure features in field footage.

Storage estimates

Bitrates may be reported in megabytes per second (MB/s) or megabits per second (Mb/s). One byte contains eight bits, so 4 MB/s equals 32 Mb/s. Approximate decimal storage can be calculated as:

gigabytes = megabytes per second × seconds ÷ 1,000

At 4 MB/s, two hours of video occupy approximately 28.8 GB, commonly rounded to 30 GB. At 2.5 MB/s (20 Mb/s), two hours occupy approximately 18 GB. For comparable 1080p footage, 2.5 MB/s HEVC is a reasonable starting point when seeking quality similar to the 4 MB/s H.264 example developed for our historical footage. It is not a universal setting.

Multiply the per-camera estimate by the number of cameras, recording hours, repeated deployments, test footage, and backup copies. Include space for the preserved originals as well as the files used for analysis.

Test representative clips

Test clips should contain the material most likely to expose conversion problems:

  • the smallest landmarks or markings required for analysis;
  • the fastest subject motion and the longest expected recording;
  • low-contrast subjects, shadows, noise, and difficult backgrounds;
  • surface shimmer, water, foliage, particles, or other detailed motion;
  • synchronization cues near the beginning and end of recordings;
  • file boundaries created by cameras that split long recordings; and
  • reference objects, calibration targets, and any text or identifiers recorded in the scene.

Compare original and converted clips frame by frame at the magnification used during analysis. Check duration, apparent frame sequence, orientation, color, audio if used, and the first and last frames. Load the expected number of views together in VidSync and confirm that synchronization cues retain the same relationships.

Variable frame rate, interlacing, and segmented files

Variable-frame-rate recordings do not use the same interval between every pair of frames. A conversion to constant frame rate may duplicate or discard frames to fit a regular sequence. Verify visible timing cues before and after conversion, including cues near the end of long clips. Preserve the variable-frame-rate originals and document the conversion method.

Interlaced video records alternating rows at different times. Deinterlacing methods reconstruct progressive frames in different ways, and moving subjects reveal the differences most clearly. Inspect edges and timing during rapid motion and retain the untreated originals.

Some cameras divide long recordings into sequential files. Joining those files requires confirmation that the boundary contains neither a gap nor a duplicated frame. Check the camera’s own segmentation behavior before designing a batch workflow, and test at least one real boundary from every recording mode used.

Agentic AI and FFmpeg workflows

For many projects, the open-source command-line tools FFmpeg and FFprobe provide a simpler and more reproducible approach than learning a production video-editing application solely to convert files. FFprobe can inspect the source streams and metadata. FFmpeg can remux or transcode files, apply specified processing, and repeat the same operation across a directory.

Agentic AI coding tools such as Claude Code and Codex can inspect representative file information, construct an FFmpeg command or batch script, explain each option, and revise the workflow after test results. They are particularly useful for processing many files consistently, handling filenames and directory structures, generating an input-to-output manifest, and recording the final command with the project methods.

A request to an agentic tool should specify:

  • the operating system and installed FFmpeg version;
  • representative FFprobe output or access to representative files;
  • the input directory and a separate output directory;
  • the required codec, container, bitrate or quality target, resolution, and treatment of frame rate;
  • whether audio, subtitles, timecode, orientation, and other metadata must be preserved;
  • the filename convention and desired conversion log;
  • the requirement to preserve all originals and avoid overwriting files; and
  • the tests that converted files must pass before batch processing begins.

Ask the tool to explain the consequences of every FFmpeg option and show the planned input-to-output mapping. Review generated commands before execution. Pay particular attention to paths, wildcard expansion, overwrite flags, deletion or cleanup steps, frame-rate conversion, timestamp handling, rotation metadata, audio mapping, and commands that concatenate files.

Run the workflow first on copies of several short clips in a temporary output directory. Inspect the results in VidSync and compare them with the originals. A successful test should be followed by a small batch that includes long recordings and file boundaries. Process the complete dataset only after those checks pass.

A reproducible batch procedure

  1. Inventory the originals. Record filenames, sizes, durations, codecs, frame rates, and relevant metadata.
  2. Define the desired output. State which properties must be preserved and which conversion is necessary.
  3. Create a separate test directory. Copy representative files and include difficult footage and at least one segmented-file boundary.
  4. Generate and review the command or script. Confirm paths, filenames, overwrite behavior, codec settings, timing operations, and logging.
  5. Convert and compare. Inspect frames, timing cues, duration, metadata, and VidSync playback against the originals.
  6. Process a small batch. Verify that naming, errors, file boundaries, and logs behave correctly across several files.
  7. Run the complete batch. Write only to the designated output directory and retain the originals unchanged.
  8. Validate and archive the method. Store the final script, command, software versions, log, and input-to-output mapping with the project.

Historical transcoding example

The following workflow dates to approximately 2010 and illustrates the decisions involved. The named cameras, software, and intermediate formats are historical rather than current recommendations.

Our Sony HDR-SR12 cameras recorded 1080i video on internal hard drives in AVCHD format. We used the “Log and Transfer” function of Apple Final Cut Pro 6 to import videos as QuickTime .mov files encoded with Apple Intermediate Codec. This low-compression material occupied about 120 GB per camera for two hours. Because the recordings were interlaced and too large for convenient analysis, we used Apple Compressor 3 to create deinterlaced H.264 QuickTime files.

Trial-and-error testing showed that H.264 at 4 MB/s (32 Mb/s) was the lowest bitrate that preserved the fine detail required for our analysis. At that rate, two hours occupied approximately 30 GB per camera. We preserved the original AVCHD data as disk images of the camera hard drives so the footage could later be converted again with a different codec, bitrate, deinterlacing method, or other setting.

The same decisions can now be recorded in a short FFmpeg command or script, making it easier to apply one verified conversion consistently to an entire dataset.

Final verification

  • The original recordings are preserved in at least two locations.
  • The container, codec, bitrate, resolution, frame rate, scan mode, and metadata treatment are documented.
  • Representative original and converted clips have been compared frame by frame.
  • Timing cues, duration, segmented-file boundaries, and simultaneous playback have been checked.
  • The final command or script, software versions, conversion log, and filename mapping are stored with the project.
  • The files used for analysis open, synchronize, step, and play as expected in VidSync.
Scroll to Top