Transcode legacy codecs

View Markdown

Old archives are full of formats that modern browsers and players cannot handle. MPEG-2 transport streams, WMV files from Windows Media Encoder, FLV from the Flash era — they all need to be converted before they can be served on the web or in apps.

“Rewind” (a media archive like the Internet Archive) is digitizing decades of broadcast footage and making it available online.

API

ittybit video \
  -i https://rewind-app.com/archive/broadcast-2004.mpg \
  --codec h264 \
  --format mp4 \
  --quality high

const task = {
  input: 'https://rewind-app.com/archive/broadcast-2004.mpg',
  kind: 'video',
  options: {
    codec: 'h264',
    format: 'mp4',
    quality: 'high',
  },
};

const res = await fetch('https://api.ittybit.com/jobs', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.ITTYBIT_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify(task),
});
const data = await res.json();

import requests

task = {
    "input": "https://rewind-app.com/archive/broadcast-2004.mpg",
    "kind": "video",
    "options": {
        "codec": "h264",
        "format": "mp4",
        "quality": "high",
    },
}

res = requests.post(
    "https://api.ittybit.com/jobs",
    headers={"Authorization": f"Bearer {api_key}"},
    json=task,
)
data = res.json()

TASK='{
  "input": "https://rewind-app.com/archive/broadcast-2004.mpg",
  "kind": "video",
  "options": {
    "codec": "h264",
    "format": "mp4",
    "quality": "high"
  }
}'

curl -X POST https://api.ittybit.com/jobs \
  -H "Authorization: Bearer $ITTYBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d "$TASK"

CLI

ittybit video \
  -i broadcast-2004.mpg \
  -o broadcast-2004.mp4 \
  --codec h264 \
  --quality high

Legacy format reference

Source format	Extension(s)	Era	Recommended target	Notes
MPEG-2	`.mpg`, `.mpeg`, `.ts`, `.vob`	DVD / broadcast	h264 mp4	Most common archive format
WMV / VC-1	`.wmv`, `.asf`	Windows Media	h264 mp4	Often interlaced; deinterlace on transcode
FLV / VP6	`.flv`	Flash era	h264 mp4	Low resolution source; upscaling not recommended
RealMedia	`.rm`, `.rmvb`	RealPlayer	h264 mp4	Variable bitrate, often low quality
DivX / Xvid	`.avi`, `.divx`	Early 2000s P2P	h264 mp4	MPEG-4 Part 2; container is usually AVI
3GP	`.3gp`, `.3g2`	Early mobile	h264 mp4	Very low resolution (176x144 to 352x288)
Theora	`.ogv`, `.ogg`	Early web video	h264 mp4 or vp9 webm	Firefox-era open format

Choose your target codec

Goal	Target codec	Why
Maximum compatibility	h264	Plays everywhere, fast to encode
Minimum file size	AV1	Best compression for archival re-encode
Open format	VP9	Royalty-free, good browser support

For most migration projects, h264 in MP4 is the right default. It is the fastest to encode and plays on every device.

Transcode to AV1 for long-term storage

If you are re-encoding once for permanent archival, AV1 saves storage:

ittybit video \
  -i broadcast-2004.mpg \
  -o broadcast-2004-av1.mp4 \
  --codec av1 \
  --quality high

Batch migration

Transcode an entire directory of legacy files:

for file in /archive/*.mpg; do
  ittybit video \
    -i "$file" \
    -o "${file%.mpg}.mp4" \
    --codec h264 \
    --quality high
done

For cloud processing at scale, post one task per file to the API. Use webhooks to track completion.

Quality considerations

Do not upscale. Legacy files are typically 480p or lower. Encoding at the source resolution preserves quality without inflating file size.
Use high quality. Re-encoding always loses some quality. Start from the highest quality setting to minimize generational loss.
Keep the originals. Store the source files separately. You can always re-transcode later as codecs improve.