Discofork
Repository brief

FFmpeg/FFmpeg

Read the upstream summary on the left, browse the cached forks below it, and load each fork comparison into the right-hand panel.

Cached analysis
cached 2026-03-30T11:54:31.732Z
3mo ago

FFmpeg/FFmpeg

FFmpeg/FFmpeg is the upstream mirror of FFmpeg, a large multimedia processing codebase for audio, video, subtitles, metadata, and streaming. It is very active, widely forked, and heavily starred, with recent commits showing ongoing low-level codec, filter, swscale, x86/aarch64, and test work.

GitHub
Loading tags...
Stars58,435
Forks13,641
Default branchmaster
Last pushed2026-03-30T11:38:49Z
Recommended shortcuts

Jump straight into Discofork's strongest cached fork picks, or open a compare view in one click.

Forks

Choose a fork to inspect

10 of 10 fork briefs
Selected

Choose this fork if your priority is native Visual Studio/WinRT integration and you are willing to accept upstream lag and feature loss. If you need the broadest FFmpeg feature set or closest upstream parity, upstream is the safer base.

Prefer this fork only if you specifically need its downstream codec/platform changes. If you want current FFmpeg behavior, upstream is the better default because this fork is highly diverged and stale.

Choose this fork if your goal is FFglitch-style scripted or live glitching workflows. Avoid it if you need close upstream FFmpeg compatibility, frequent upstream updates, or a conservative maintenance burden.

Choose this fork only if KSYUN RTMP H.265/HEVC support is a hard requirement. For general FFmpeg use, upstream is the better default because this fork is stale and materially diverged.

Choose this fork if your workload runs on Rockchip hardware and you value integrated hardware decode/encode plus scaling over upstream freshness. Avoid it if you need broad platform portability, current FFmpeg master parity, or minimal maintenance burden.

Prefer this fork only if you already depend on FFmbc-specific broadcast behavior or need a stable legacy branch. For new projects or general multimedia work, upstream FFmpeg is the better default because it is far more current and actively maintained.

Choose this fork only if you specifically need Vitamio-era Android playback behavior or its bundled mobile-specific fixes. If you want current FFmpeg capabilities, active maintenance, or broad platform support, upstream is the better default.

Choose this fork if your priority is WebRTC integration plus stronger CI/rebase automation. Choose upstream if you mainly need the latest general FFmpeg media features and do not need the fork’s WebRTC-focused workflow layer.

Prefer this fork only if SIXEL-centric terminal workflows or its custom patches are the goal; for general FFmpeg use, upstream is the safer and more current baseline.

Choose this fork only if you specifically need the VR unwarp/distortion-correction filter and its calibration options. For general multimedia work, upstream FFmpeg is the better default because this fork is old, highly diverged, and likely missing many later fixes and capabilities.