PicaJet

Reference Glossary

Transcoding

Converting a video or audio file from one codec, container, resolution, or bitrate to another by decoding the source and re-encoding it into the target format.

Why it matters in a DAM

DAM video libraries ingest camera-native masters in codecs like ProRes or camera-specific formats that browsers and mobile devices can't play natively, so transcoding automatically produces web-deliverable derivatives — typically H.264/MP4 or an adaptive bitrate ladder — at ingest so users can preview and share without opening a video editor. It's also how DAM systems generate lighter-weight, lower-bitrate proxies so editors can work smoothly over a slow VPN connection to a shared library.

A worked example

Camera master ProRes 422, 4K → transcoded to H.264 MP4, 1080p for web preview
Archive master Uncompressed WAV → transcoded to AAC for mobile streaming preview
Editorial proxy 4K master → low-bitrate proxy for offline editing over VPN

Common mistake

A DAM ingest pipeline transcodes from an already-compressed derivative (a previously exported H.264 file) instead of the true lossless or high-bitrate master, compounding generation loss — recompression artifacts stack with each re-encode, so every downstream derivative should be generated from the highest-quality master on file, never from another lossy derivative.

Transcoding takes a media file’s full content, decodes it back to raw audio or video data, and re-encodes it using a different codec, container format, resolution, or bitrate. It differs from a simple file conversion in that it involves a real re-encode pass, not just repackaging — which means transcoding a lossy format always introduces at least some additional generation loss, since decoding and re-encoding compressed video is rarely perfectly reversible.

In a DAM, transcoding runs largely invisibly, triggered automatically on ingest: a camera-native or professionally mastered file arrives in a codec that isn’t practical for browser playback, and the system generates one or more web-friendly derivatives — often an adaptive bitrate set so playback quality adjusts to the viewer’s connection speed. Editorial teams also depend on transcoding to produce lightweight proxies, letting an editor scrub and cut video responsively even when the true master sits on distant, slow-to-access storage.

Because every transcode pass from a lossy source adds compounding artifacts, the ingest master matters more than any individual derivative — a DAM’s transcoding pipeline should always read from the highest-quality file on record, and that master should be preserved untouched rather than overwritten by a compressed working copy.

Frequently asked

What is transcoding?

Transcoding converts a video or audio file from one codec, container, resolution, or bitrate to another by fully decoding the source into raw frames or samples, then re-encoding them into the target format. This is different from transmuxing (rewrapping), which repackages compressed data into a new container without decoding it. In a DAM pipeline, transcoding typically turns a camera-native master, such as ProRes, into a lighter delivery format like H.264/MP4.

Why do DAM video libraries need transcoding at ingest?

Camera-native masters arrive in professional codecs like ProRes, which browsers and mobile devices cannot decode or play natively. So a DAM's ingest pipeline automatically transcodes each upload into web-deliverable derivatives — typically H.264/MP4 or a full adaptive bitrate ladder — the moment the file lands. That lets any team member preview, scrub, and share the asset instantly, without installing editing software or waiting to download the full-resolution master.

How does transcoding support offline video editing?

Transcoding generates lightweight, low-bitrate proxy files that stand in for the full-resolution master during editing. Editors can scrub and cut responsively over slow VPN connections to a shared library instead of streaming or downloading heavy 4K originals. Once the edit is locked, the editing software relinks the timeline to the original master for final export, so the proxies used mid-edit don't limit the finished output's quality.

Does transcoding always preserve quality?

No. Transcoding a lossy format always risks introducing additional generation loss, because decoding and re-encoding compressed video is rarely perfectly reversible — some data is discarded at each pass. Even transcoding into a format with matching or higher nominal settings can still soften detail or add compression artifacts, since the encoder re-allocates bitrate differently than the original pass did. This is why DAM pipelines should transcode from a master, not a derivative.

What's the mistake of transcoding from an already-compressed derivative?

Transcoding from a previously exported H.264 (or other compressed) derivative, instead of a true lossless or high-bitrate master, compounds generation loss: recompression artifacts from the earlier encode stack with the artifacts introduced by the new pass. Each additional decode-and-re-encode cycle degrades the image further, even if nobody changes a single setting. Over repeated re-transcodes for new formats or renditions, this accumulation can become visibly noticeable.

What should a DAM's transcoding pipeline always read from?

A DAM's transcoding pipeline should always read from the highest-quality master file, preserved untouched rather than overwritten by compressed working copies or proxies. Every transcode pass from a lossy source adds compounding artifacts, so the master should be locked as a protected, read-only reference that every derivative — web preview, editing proxy, adaptive rendition — is generated from independently, rather than chained off a prior derivative.

Sources

  • Video transcoding converts a file from one codec or format to another, typically by decoding the source and re-encoding it while adjusting resolution, bitrate, or codec for compatibility across devices and platforms. checked 2026-08-07Adobe — What is video transcoding and how to use it