Rarbg — X265 Encoding Settings

RARBG didn't use a strict bitrate target; they used CRF. However, based on release logs, here is the predictable output they achieved:

| Source Resolution | Source Type | CRF Value | Average Bitrate (Typical) | File Size (90-min film) | | :--- | :--- | :--- | :--- | :--- | | 2160p (4K) HDR | Movie | 18 | 8-12 Mbps | 8-12 GB | | 1080p | Movie (Clean) | 19 | 3,500 - 5,000 kbps | 2.5 - 3.5 GB | | 1080p | Movie (Grainy) | 20 | 6,000 - 8,000 kbps | 4 - 6 GB | | 720p | Movie | 21 | 1,500 - 2,500 kbps | 1.2 - 1.8 GB | | 1080p | Anime | 18 | 2,500 - 3,500 kbps | 1.8 - 2.5 GB |

Key insight: Notice that grainy 1080p movies often landed at a higher bitrate than clean 4K streams. RARBG prioritized allocating bits where needed.

This was their killer feature. Even for SDR (Standard Dynamic Range) content, RARBG encoded in 10-bit. Rarbg X265 Encoding Settings

-c:a aac -b:a 384k -ac 6

Or for stereo:

-c:a libopus -b:a 128k -ac 2

RARBG adopted x265 (HEVC) relatively early. While x264 (AVC) was the universal compatibility king, x265 offered roughly 50% better compression. For a site hosting thousands of movies, this meant lower bandwidth costs and happier users with small hard drives.

But x265 is notoriously finicky. Bad settings produce "blocky" shadows or "waxy" skin tones. RARBG didn't have bad settings. RARBG didn't use a strict bitrate target; they used CRF

Anime compresses extremely well, but suffers from banding (gradients in skies/shadows). RARBG added a grainy dither to mask banding.

-c:v libx265 -preset slower -crf 18 \
-x265-params "aq-mode=4:aq-strength=0.8:no-sao=1:deblock=-1,-1:zone=0,0,b=1.2"

Yes. With tools like HandBrake or FFmpeg, you can use these settings right now.

For HandBrake users:

A word of caution: Encoding with these settings is slow. On a standard laptop, expect 8–12 hours for a 2-hour movie. But the result? A 2GB file that looks like a 10GB remux.

The Good:

The Bad: