# DaVinci Resolve Bit Rate vs Bit Depth Explained

> **Quick answer:** Bit rate (Mbps) measures how much data your DaVinci Resolve export moves per second, controlling file size and compression artifacts. Bit depth (8-bit, 10-bit, 12-bit) measures how many shades of color each pixel can hold, controlling gradient smoothness and banding. They're independent settings, and raising one never fixes a problem caused by the other.

*Published by [TryUncle](https://tryuncle.com) — the on-screen assistant that teaches DaVinci Resolve on your own screen.*
*Updated 2026-08-02 · DaVinci Resolve 21.0.3 (July 2026) · Canonical: https://tryuncle.com/learn/davinci-resolve/davinci-resolve-bit-rate-vs-bit-depth-explained*

Someone tells you your export "needs a higher bit rate" to fix the banding in your sunset shot, and you believe them, because both words have "bit" in them and both live on the same Deliver page. As of August 2026, running DaVinci Resolve 21.0.3, that mix-up is still one of the most common small misunderstandings in the app, and it's a forgivable one. The two settings sit two clicks apart. They do not do the same job.

Here's the short version. Bit rate is a speed. Bit depth is a scale. Get them backward and you'll spend an afternoon raising a number that was never going to fix the problem you're looking at. It's a close cousin of another pair of settings beginners mix up constantly, the one we untangle in our breakdown of [DaVinci Resolve's 23.976 vs 24 vs 25 fps](https://tryuncle.com/learn/davinci-resolve/davinci-resolve-frame-rate-23-976-vs-24-vs-25-explained), where the confusion is which number to type in, not what the number measures.

## What's the actual difference between bit rate and bit depth in DaVinci Resolve?

Bit rate measures how much data your file moves every second. Bit depth measures how many shades of color each pixel is allowed to hold. They're unrelated numbers that happen to share a word.

Andy Shipsides, writing for AbelCine, put the distinction as plainly as it gets: bit rate, "sometimes also referred to as Data Rate, is a term used to describe the amount of digital information (bits) that is conveyed or recorded per unit of time," while "Bit Depth, aka Color Depth, describes the amount of information stored in each pixel of data. As you increase bit depth, you also increase the number of colors that can be represented" ([AbelCine](https://www.abelcine.com/articles/blog-and-knowledge/tutorials-and-guides/hd-formats-bit-rate-vs-bit-depth)).

**Bit rate measures how much data your file uses every second. Bit depth measures how many shades of color each pixel can hold.** One is expressed in megabits per second, Mbps. The other is expressed in bits per channel, like 8-bit or 10-bit. Nothing about raising one changes the other, because they're not measuring the same axis of the picture at all.

| | Bit rate | Bit depth |
| --- | --- | --- |
| What it measures | Data throughput over time | Color precision per pixel |
| Unit | Mbps (megabits per second) | Bits per channel (8-bit, 10-bit, 12-bit) |
| What it controls | File size, compression artifacts, blockiness | Gradient smoothness, banding, grading headroom |
| Where you set it, Deliver page | Restrict to field, under Quality | Codec choice (H.264 vs ProRes vs DNxHR, and which variant) |
| What breaks if it's too low | Blocky, mushy detail in motion | Visible stepping in skies, skin, shadows |

## What is bit depth in DaVinci Resolve, exactly?

Bit depth is the number of distinct values each color channel in a pixel can hold, and it's measured in bits, not megabits.

An 8-bit file gives every red, green, and blue channel 2^8, or 256, possible values, according to [Wikipedia's entry on color depth](https://en.wikipedia.org/wiki/Color_depth). A 10-bit file gives each channel 2^10, or 1,024, possible values, four times the precision. A 12-bit file gives each channel 4,096 values. Combine all three channels and 8-bit tops out around 16.7 million total colors, while 10-bit reaches over a billion.

Those extra steps matter most exactly where you'd expect: smooth, slow gradients. A clear sky, a shallow-depth-of-field background, an evenly lit face. With only 256 steps to divide a gradient across, an 8-bit file can run out of intermediate values and jump straight from one shade to the next, visible as banding, a stair-step pattern instead of a smooth blend. A 10-bit file has four times as many steps to divide that same gradient across, so the transition looks continuous instead of stepped.

DaVinci Resolve's own manual draws a hard line around where 8-bit sources actually cause trouble: "8-bit images come from older or consumer-grade video equipment like mobile phones and camcorders," and pushing significant color correction on that footage is exactly what produces visible banding, since there isn't enough underlying precision to redistribute smoothly once you start pulling levels around ([DaVinci Resolve Manual](https://www.steakunderwater.com/VFXPedia/__man/Resolve18-6/DaVinciResolve18_Manual_files/part1903.htm)). The same manual page notes that Resolve's Fusion page always processes at 32-bit float, far beyond anything a delivery codec uses, specifically so internal effects and compositing work doesn't add its own rounding errors on top of whatever precision your source footage started with. That 32-bit float distinction is worth sitting with for a second: it's not a "bit depth" in the same sense as your delivery codec's 8, 10, or 12-bit, it's floating-point headroom for the math itself, so a node stack of six or seven operations doesn't quietly compound rounding error the way repeated integer math would. Your export still comes out at whatever bit depth you chose on the Deliver page. The float precision just means the calculations that got you there were more accurate along the way. RAW footage adds a related wrinkle before bit depth even enters the picture, covered in full in our guide to [what debayering means in DaVinci Resolve](https://tryuncle.com/learn/davinci-resolve/what-is-debayering-in-davinci-resolve), since a RAW file's sensor mosaic has to be reconstructed into a real image before any bit depth number applies to it at all.

**Bit depth decides how many rungs are on the ladder between pure black and pure white in every color channel.** Fewer rungs, further apart, and a smooth gradient starts to look like a staircase the moment you grade it hard enough to expose the gaps.

## Does a higher bit depth camera setting guarantee 10-bit all the way to your export?

No, and this is where a lot of confusion about banding actually starts, well before anyone touches the Deliver page. Bit depth is a chain, not a single setting, and the weakest link decides what actually reaches your finished file.

Start with what the camera records. Flip a camera's picture profile to a log gamma curve like S-Log3 or C-Log3, and you're choosing a shape for the tonal curve, not a bit depth. Those are two separate decisions that happen to live on the same menu screen. On modern cinema cameras, a log profile is typically paired with 10-bit 4:2:2 internal recording, which is exactly the pairing a flat, low-contrast curve needs to survive a hard grade without banding. But "typically" is doing real work in that sentence, because not every camera with a log profile records it at 10-bit. Canon's own Cinema EOS line makes the point directly: the EOS C300 Mark II's spec sheet lists "10-bit Canon Log 2 Gamma available," per its Wikipedia entry, meaning that specific camera genuinely pairs its log curve with 10-bit recording ([Wikipedia](https://en.wikipedia.org/wiki/Canon_EOS_C300_Mark_II)). Older bodies, budget cameras, and plenty of consumer devices with a "cinematic" or "flat" picture profile borrowed from a log curve don't make that same promise. Check your specific camera's internal recording spec sheet before you assume flat footage means 10-bit footage.

Then there's everything that happens after the camera. DaVinci Resolve's own Project Settings carry a color science bit depth, separate from your timeline's working codec, separate again from whatever you eventually pick on the Deliver page. Import genuinely 10-bit source material into an 8-bit project, and you throw away the extra tonal steps before you ever touch a color wheel, with no warning dialog telling you it happened. The free version of Resolve caps that project-level bit depth at 8-bit no matter what your source footage holds, which we cover in full below.

**A single 10-bit camera setting doesn't make a 10-bit finished file.** Every link in the chain, camera recording, project color science, timeline, and export codec, has to hold that bit depth, or the file downstream inherits whichever link was weakest. That's also why a title card, graphic, or screenshot dropped onto an otherwise 10-bit timeline can quietly reintroduce banding on its own: if that one clip was exported from another app as an 8-bit PNG, it carries only 256 steps per channel regardless of what the rest of your timeline is doing.

## What is bit rate in DaVinci Resolve, exactly?

Bit rate is how many bits of data your file processes every second, and it has nothing to do with color precision at all.

Per [Wikipedia's entry on bit rate](https://en.wikipedia.org/wiki/Bit_rate), "bit rate is the number of bits that are conveyed or processed per unit of time," commonly abbreviated bps, with 1 Mbps equal to one million bits per second. Shipsides gives a concrete, real-world example of what that number actually buys you: "the XDCAM EX format in its highest quality mode has a data rate of 35 Mbit/s (35 Million bits per second), which translates to about 50 minutes of footage per 16 GB SxS card" ([AbelCine](https://www.abelcine.com/articles/blog-and-knowledge/tutorials-and-guides/hd-formats-bit-rate-vs-bit-depth)).

A higher bit rate generally means more data survives per frame, which usually means less compression damage, less blockiness in fast motion, and cleaner detail in complex textures like foliage or crowd scenes. But Shipsides is careful to flag that bit rate alone doesn't decide final quality either: how efficient the specific compression algorithm is matters just as much as the raw number, since "many cameras achieve excellent results at much lower data rates" than you'd assume from the number alone, purely because the encoder behind that number is doing smarter work per bit.

**A bit rate number tells you how much data moves per second. It tells you nothing about how many shades of color are inside that data.** A blocky, low bit rate 10-bit file and a smooth, high bit rate 8-bit file are both completely plausible exports, and neither one is a contradiction. They're two independent settings doing two independent jobs.

## How do you calculate the file size a given bit rate actually produces?

Bit rate translates directly into file size once you know the runtime, and running the math yourself takes the mystery out of why one export lands at 400 MB and another lands at 4 GB for the exact same runtime.

The formula is simple: bit rate in Mbps, multiplied by duration in seconds, divided by 8, gives you file size in megabytes. You divide by 8 because a byte is 8 bits, and file sizes are conventionally measured in bytes while bit rate is measured in bits.

Take a 10-minute, or 600-second, 1080p export at YouTube's recommended 8 Mbps for standard frame rate SDR. That's 8 times 600, divided by 8, which is 600 MB, plus a small amount for the audio track running alongside it. Push the same 10 minutes to 4K at 40 Mbps, and you get 40 times 600 divided by 8, which is 3,000 MB, right at 3 GB, for footage that YouTube itself is going to re-compress anyway once it lands on their servers.

| Scenario | Bit rate | Duration | Approx. file size (video only) |
| --- | --- | --- | --- |
| 1080p, YouTube SDR, standard fps | 8 Mbps | 10 min | ~600 MB |
| 1080p, YouTube SDR, high fps | 12 Mbps | 10 min | ~900 MB |
| 4K, YouTube SDR, standard fps | 40 Mbps | 10 min | ~3,000 MB (3 GB) |
| 1080p, ProRes 422 HQ | ~220 Mbps | 10 min | ~16,500 MB (16.5 GB) |
| 1080p, DNxHR SQ | ~110 Mbps | 10 min | ~8,250 MB (8.25 GB) |

Look at the gap between the H.264 rows and the intra-frame codec rows. That gap is the entire reason mezzanine and archival formats exist as their own category, separate from delivery formats. ProRes and DNxHR spend enormous amounts of bit rate specifically so every frame decodes independently, which is what makes them fast to scrub and re-grade later, at the cost of a file 20 to 30 times larger than an H.264 upload at the same runtime.

**Bit rate times duration, divided by eight, is the entire file size formula, and bit depth never enters that equation at all.** A 10-bit ProRes file and an otherwise-identical 8-bit encode at the same quality tier land within a few percent of the same size, because chroma sampling and compression aggressiveness, not the extra color steps, are what actually move the needle on file size. If you're staring at a export that's twice the size you expected, the answer is almost always your bit rate setting or your codec's compression tier, never how many shades of color it's carrying.

## Why do editors mix up bit rate and bit depth in the first place?

Because both terms use the same word, "bit," to describe two completely different measurements, and DaVinci Resolve's own interface doesn't always separate them as clearly as it could.

On the Deliver page, bit rate lives under Quality, in the Restrict to field, a number you type directly. Bit depth isn't a labeled field at all in most export presets. It's implied by which codec and which variant of that codec you pick from the dropdown above it, H.264 versus ProRes 422 HQ versus ProRes 4444, each one silently carrying its own fixed or selectable bit depth. One setting is explicit and numeric. The other is buried inside a codec name you have to already know how to read.

That asymmetry is exactly why "just raise the bit rate" becomes the default troubleshooting move when banding shows up. It's the field you can actually see and type a bigger number into. Fixing bit depth means changing your codec choice entirely, sometimes rethinking your whole shoot, which is a much less satisfying answer at 11pm before a client deadline.

**The word "bit" shows up in both terms, but that's the only thing they share.** One counts how fast data moves. The other counts how many shades of color exist to move in the first place.

## Does a higher bit rate fix color banding in DaVinci Resolve?

No. A higher bit rate makes a file's existing color information survive compression more cleanly, but it can't add color information that was never captured.

Banding is a bit depth problem, not a compression problem. If your source footage was recorded, or your project is exporting, at 8-bit, you have exactly 256 possible values per color channel to work with, per [Wikipedia's entry on color depth](https://en.wikipedia.org/wiki/Color_depth), and no amount of extra Mbps changes that ceiling. Raise the bit rate on an 8-bit export with visible banding, and what you get is a cleaner, crisper version of the same 256-step staircase. The compression noise that was smudging the edges of each band disappears. The bands themselves do not.

This is the single most common version of the bit rate versus bit depth confusion, and it's worth a concrete example. Say you grade a sunset shot on an 8-bit timeline, push a strong contrast curve through the sky, and see visible stepping across the gradient. Doubling your export's Restrict to bitrate from 20 Mbps to 40 Mbps genuinely improves the shot, since the file now holds more data per frame and compresses less aggressively overall. But zoom into that specific sky gradient and the bands are still there, just rendered a little more crisply. The only fixes that actually touch banding are switching to a genuinely 10-bit source and timeline before you grade, or applying dithering as a deliberate mitigation, which scatters fine noise across the gradient to visually break up the stepping rather than adding real color information back in, a technique we cover in full further down this page.

**Raising bit rate never fixes banding that bit depth already baked in.** If your sky, your skin tones, or your shadow gradients are stepping visibly, check what bit depth you actually shot and graded in before you touch the Restrict to field at all.

## Do 10-bit codecs always need a higher bit rate than 8-bit ones?

Not necessarily, and one codec family proves it cleanly: bit depth and bit rate can move completely independently once real-world compression enters the picture.

Apple's ProRes 422 family is the clearest example available. Per [Wikipedia's entry on Apple ProRes](https://en.wikipedia.org/wiki/Apple_ProRes), ProRes 422 Proxy, ProRes 422 LT, ProRes 422, and ProRes 422 HQ are all 10-bit at 4:2:2 chroma sampling, exactly the same color precision across every tier. What separates them is bit rate alone, and the spread is enormous.

| ProRes 422 variant | Bit depth | Chroma | Data rate at 1080p, 29.97fps |
| --- | --- | --- | --- |
| ProRes 422 Proxy | 10-bit | 4:2:2 | ~45 Mbps |
| ProRes 422 LT | 10-bit | 4:2:2 | ~100 Mbps |
| ProRes 422 | 10-bit | 4:2:2 | ~147 Mbps |
| ProRes 422 HQ | 10-bit | 4:2:2 | ~220 Mbps |
| ProRes 4444 | 10 or 12-bit | 4:4:4 | ~330 Mbps |

Four codecs, identical bit depth across the 422 family, nearly a fivefold spread in bit rate between the cheapest and the most demanding. The extra Mbps in ProRes 422 HQ isn't buying more color precision over plain ProRes 422. It's buying less aggressive compression per frame, which shows up as cleaner detail in complex textures and fewer compression artifacts under heavy grading, not more colors per channel.

The reverse mismatch is just as real. Compare codec families instead of tiers within one family, and the pattern flips. Avid's own bandwidth specifications put DNxHR LB at roughly 34 Mbps and DNxHR 444 at roughly 333 Mbps at 1080p 23.976fps, according to the [Avid Knowledge Base](https://kb.avid.com/pkb/articles/en_US/Knowledge/DNxHR-Codec-Bandwidth-Specifications), a spread built around both compression aggressiveness and, at the top end, genuine 4:4:4 color precision. And most consumer delivery still runs through H.264, whose original 2003 standard was, per [Wikipedia's entry on H.264](https://en.wikipedia.org/wiki/H.264), "primarily focused on 'entertainment-quality' video, based on 8-bits/sample, and 4:2:0 chroma sampling," with higher bit depths only available through later profile extensions most consumer cameras and platforms never actually use. HEVC, H.264's successor, does better out of the box: per [Wikipedia's entry on HEVC](https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding), it "can deal with 4:2:0 color format with 8 and 10 bits per color sample" in its core profiles, which is exactly why HEVC, not H.264, is the practical path to a genuinely 10-bit delivery file at a consumer-friendly bit rate.

**A file can carry a huge bit rate and still be 8-bit, and a file can carry a modest bit rate and still be 10-bit.** The codec and its specific variant decide bit depth. The Restrict to number decides bit rate. They're two separate dials on the same export, and reading one tells you nothing about where the other is set.

## What bit depth does DNxHR support across its five tiers?

ProRes isn't the only intra-frame family that keeps bit depth steady while bit rate swings wildly between tiers. DNxHR, Avid's answer to ProRes and a codec DaVinci Resolve exports natively, does the same thing, with a real bit depth jump built into its top two tiers instead of ProRes's more gradual climb.

Per MASV's breakdown of the format, DNxHR's five quality tiers split cleanly by bit depth and chroma: "DNxHR LB – Low Bandwidth (8-bit 4:2:2)," "DNxHR SQ – Standard Quality (8-bit 4:2:2)," "DNxHR HQ – High Quality (8-bit 4:2:2)," "DNxHR HQX – High Quality (12-bit 4:2:2)," and "DNxHR 444 – Finishing Quality (12-bit 4:4:4)" ([MASV](https://masv.io/blog/dnxhd-files)).

| DNxHR tier | Bit depth | Chroma | Typical use |
| --- | --- | --- | --- |
| LB | 8-bit | 4:2:2 | Offline editing, proxies |
| SQ | 8-bit | 4:2:2 | Broadcast delivery |
| HQ | 8-bit | 4:2:2 | Broadcast delivery, higher quality |
| HQX | 12-bit | 4:2:2 | UHD/4K broadcast mastering |
| 444 | 12-bit | 4:4:4 | Finishing, VFX, cinema delivery |

The jump from HQ to HQX isn't a bit rate bump on the same 8-bit picture, the way ProRes 422 stepping up to ProRes 422 HQ is. It's a genuine bit depth jump, from 256 steps per channel to 4,096. If you're mastering a 4K broadcast delivery in DNxHR and picking between HQ and HQX purely because "HQX just means a bigger, safer file," that's the same bit rate and bit depth mix-up this whole page is about, just wearing a different codec's name tag. HQX costs more space because it's carrying more color information, not because someone turned a quality slider up a few notches for no reason.

## Does AV1 or HEVC get you higher bit depth at a lower bit rate than H.264?

Sometimes, yes. AV1 and HEVC are both newer than H.264, and both were designed from the start to compress harder for the same visual quality, which is exactly why they can deliver more bit depth inside a bit rate budget H.264 can't touch.

AV1's own specification splits capability by profile. Per Wikipedia's entry on AV1, "the Main profile allows for a bit depth of 8 or 10 bits per sample," the High profile adds 4:4:4 chroma at that same range, and "the Professional profile extends capabilities to full support for 4:0:0, 4:2:0, 4:2:2 (half) and 4:4:4 chroma sub-sampling with 8, 10 and 12 bit color depths" ([Wikipedia](https://en.wikipedia.org/wiki/AV1)). That's a meaningfully wider bit depth ceiling than H.264's consumer-grade 8-bit baseline, at bit rates AV1's more efficient compression keeps lower than H.264 needs for comparable quality.

Whether any of that matters to you depends entirely on what you're exporting from DaVinci Resolve, though. Our full breakdown of [whether DaVinci Resolve supports AV1 export](https://tryuncle.com/learn/davinci-resolve/does-davinci-resolve-support-av1-export) covers the catch: Resolve only exports AV1 on Windows and Linux, and only with a GPU that has a hardware AV1 encoder, Nvidia RTX 40-series or newer, AMD RX 7000-series or newer, or Intel Arc. Mac users are locked out of AV1 export entirely, since no Apple chip has an AV1 encoder, which makes HEVC the more realistic 10-bit-at-a-reasonable-bit-rate option for most Resolve editors on macOS.

HEVC gets there more simply, since it doesn't need a specific GPU generation the way hardware AV1 encoding does. A Main 10 HEVC export gets you genuine 10-bit precision on any platform Resolve runs on, using the same core profile support quoted in the section above.

**If your delivery target accepts HEVC or AV1 instead of requiring H.264, you can often get 10-bit precision at a bit rate that would have only bought you 8-bit under H.264's older, less efficient compression.** That's not a bit depth trick, it's a codec efficiency difference, but it's the practical reason "switch codecs" sometimes fixes a banding problem that "raise the bit rate" never could.

## How does chroma subsampling fit into the bit rate vs bit depth question?

There's a third number hiding in every codec name in this guide, and it's neither bit rate nor bit depth. Chroma subsampling, the 4:2:2 or 4:4:4 attached to ProRes and DNxHR variants throughout this page, measures something different again: how much color detail survives compared to brightness detail, independent of how many shades each surviving pixel can hold.

Digital video splits every pixel into a luma channel, brightness, and two chroma channels, color. Human vision is far more sensitive to changes in brightness than in color, so most codecs throw away some chroma resolution to save space without a visible quality loss. 4:4:4 keeps full chroma resolution, one color sample per luma sample. 4:2:2 keeps half the horizontal chroma resolution. 4:2:0, what most consumer H.264 and HEVC delivery uses, keeps a quarter. None of that has anything to do with how many shades of color each surviving sample can represent, which is bit depth's job, or how much data moves per second, which is bit rate's job. A file can be 8-bit 4:4:4, 10-bit 4:2:0, or any other combination its codec supports.

Where chroma subsampling actually shows up in day-to-day editing is at hard color edges, not smooth gradients. A green screen key, a graphic with sharp color transitions, or fine text over a colored background will show chroma edge softness or fringing in 4:2:0 or 4:2:2 that 4:4:4 avoids, because those formats are throwing away color resolution at exactly the pixel boundaries where a key or a hard edge needs it most. Bit depth banding, by contrast, shows up in smooth gradients where there's no hard edge at all, just a slow transition that runs out of steps.

| Property | What it measures | Where problems show up | Set by |
| --- | --- | --- | --- |
| Bit rate | Data throughput per second | Compression blockiness, motion artifacts | Restrict to field (H.264/HEVC) or codec choice (ProRes/DNxHR) |
| Bit depth | Color steps per channel | Banding in smooth gradients | Codec and variant choice |
| Chroma subsampling | Color resolution vs. brightness resolution | Edge softness, keying quality, fine color detail | Codec and variant choice |

This is also why the FAQ comparison between 10-bit 4:2:2 and 8-bit 4:4:4 further down this page isn't a trick question. They each solve a different problem: one protects gradients, the other protects edges, and a production that genuinely needs both, a high-end commercial with heavy keying and heavy grading, typically ends up on something like ProRes 4444 or DNxHR 444, which is 10 or 12-bit and 4:4:4 at the same time, at the cost of the largest file sizes covered anywhere on this page.

**Bit rate, bit depth, and chroma subsampling are three separate numbers that happen to travel together inside a single codec name.** Reading "ProRes 422 HQ" correctly means recognizing that "422" is chroma subsampling and "HQ" is a bit rate tier, while the bit depth, 10-bit, isn't even written in the name at all. You have to already know it.

## Does DaVinci Resolve's free version limit bit depth, bit rate, or both?

It limits bit depth specifically, not bit rate directly, and the free-versus-Studio line sits exactly where color precision, not data throughput, matters most.

Per [Blackmagic Design's own comparison page](https://www.blackmagicdesign.com/products/davinciresolve/compare), the free version "works with virtually all 8-bit video formats at up to 60fps in resolutions as high as Ultra HD 3840 x 2160," while DaVinci Resolve Studio "supports 10-bit video up to 120 frames per second and resolutions beyond 4K." That's a hard ceiling on color precision, not on export data rate. You can still type any bit rate you want into the Restrict to field on the free version. What you can't do is carry genuine 10-bit precision all the way through grading and out to a final export.

That distinction matters for a specific, common scenario: shooting log footage on a camera capable of internal 10-bit recording, then editing and grading in DaVinci Resolve's free version. The footage itself may well be 10-bit. The version of Resolve doing the grading, though, is working in 8-bit, which reintroduces exactly the banding risk this page already covered, especially on a log profile pushed through a heavy contrast curve. Upgrading to Studio doesn't change a single bit rate number. It changes the color precision ceiling the whole grading pipeline runs at, a decision our dedicated guide on [DaVinci Resolve Free vs Studio for YouTube automation channels](https://tryuncle.com/learn/davinci-resolve/davinci-resolve-free-vs-studio-for-youtube-automation-channels) walks through in more detail for creators trying to decide if the upgrade is worth it.

**DaVinci Resolve's free version renders in 8-bit. Only Studio unlocks the 10-bit engine that keeps gradients smooth under a heavy grade.** If you're seeing banding specifically after grading log or HDR footage in the free version, check which version you're running before you touch a single bit rate field.

## What bit depth do HDR10, HLG, and Dolby Vision actually require?

HDR isn't optional about bit depth the way SDR delivery is. Every major HDR format sets a bit depth floor, because the entire point of HDR is a wider brightness and color range, and an 8-bit signal doesn't have enough steps to spread that wider range across without banding turning into the dominant visual artifact on screen.

HDR10 is the strictest about it. Per the UHD Alliance, HDR10 carries "a bit depth capability of 10-bits, offering a greater range of colors than those found in traditional HD sources," and both the Blu-ray Disc Association and the UHD Alliance's own Ultra HD Premium certification require that 10-bit floor for any 4K HDR delivery to qualify ([UHD Alliance](https://alliance.experienceuhd.com/news/what-hdr10/)). There's no 8-bit HDR10 option. The format's name effectively encodes the requirement.

Dolby Vision goes further still, supporting up to 12-bit color depth against HDR10's 10-bit ceiling, though most consumer Dolby Vision delivery still ships at 10-bit in practice. Our dedicated guide on [whether DaVinci Resolve supports Dolby Vision](https://tryuncle.com/learn/davinci-resolve/does-davinci-resolve-support-dolby-vision) covers how that actually works inside Resolve: Studio has graded and rendered Dolby Vision natively since version 15 in 2018, using a built-in software CMU with no Dolby hardware required, while the free edition has none of that tooling at all. A consumer-facing Dolby Vision file typically exports as H.265 Main10, the same 10-bit HEVC profile covered above, with Dolby metadata layered on top; a full broadcast or streaming master goes out as a Dolby Vision IMF using Kakadu JPEG 2000 instead.

HLG, Hybrid Log-Gamma, the royalty-free HDR format broadcasters favor because it's backward-compatible with SDR displays, is commonly delivered at 10-bit as well, for the same reason: an HDR tone curve without the extra tonal steps to back it up just moves the banding problem from a normal gradient into a much wider dynamic range, where it's even easier to spot.

| HDR format | Minimum bit depth | Notes |
| --- | --- | --- |
| HDR10 | 10-bit | Required by Blu-ray Disc Association and UHD Alliance for 4K HDR certification |
| HLG | 10-bit (typical) | Backward-compatible with SDR displays; broadcast-favored |
| Dolby Vision | 10-bit (12-bit supported) | Studio-only in Resolve; H.265 Main10 for consumer delivery, IMF for mastering |

**Grading and delivering any HDR format on an 8-bit timeline isn't a stylistic choice, it's a spec violation that will fail certification and show visible banding in exactly the wide, smooth gradients HDR is supposed to make look better than SDR.** If a client is asking for HDR delivery, confirm your project's color science bit depth before you confirm anything about bit rate.

## Can dithering or Resolve's Deband tool fix banding without touching bit depth?

Partly, and it's worth understanding why "partly" is the honest answer instead of a clean yes or no.

Dithering doesn't add real color information. It can't, since the file's bit depth is still whatever it was. What it does instead is exploit how human vision actually works. Per Wikipedia's entry on dither, "in a dithered image, colors that are not available in the palette are approximated by a diffusion of colored pixels from within the available palette," and "the human eye perceives the diffusion as a mixture of the colors within it" ([Wikipedia](https://en.wikipedia.org/wiki/Dither)). Without it, reducing color depth "will result in flat areas (contours)... shaded or gradient areas may produce color banding, which may be distracting," but scattering the available colors in a fine pattern instead of a hard step tricks the eye into perceiving a smoother gradient than the file actually contains.

DaVinci Resolve doesn't apply dithering automatically on export. What it has instead is a purpose-built OpenFX tool called Deband, and per PremiumBeat's breakdown of the tool, it works by isolating the edges where banding is visible and using them to "minimize them by dithering pixels from either side of the banding," essentially doing by hand what dithering does automatically in a codec's own encoder ([PremiumBeat](https://www.premiumbeat.com/blog/debanding-footage-davinci-resolve/)). Deband ships with adjustable Edge Threshold, Radius, Post-Refine, and Display Edge controls, and it's a Studio-only tool, so free-version editors fighting banding don't have it available at all, another item on the growing list of things that trace back to which version of Resolve you're running rather than a bit rate field.

The simpler, older workaround does a cruder version of the same job: add a subtle film grain or noise node above the banded area, on the Color page, through the OpenFX library. The scattered noise breaks up the hard edge of each visible band the same way dithering does, and it has the side benefit of surviving online compression better, since a platform's own re-encode tends to soften and blend grain in a way that further disguises the transition.

**Dithering and Deband genuinely reduce the visibility of banding that a higher bit rate never touches, but they're a disguise, not a cure.** The underlying file still only has as many real color steps as its bit depth allows. If you have the option to reshoot, re-grade from a higher bit depth source, or simply grade less aggressively on an 8-bit timeline, that beats dithering every time. Dithering is what you reach for when the footage is what it is and the deadline is tonight.

## Where do you actually set bit rate and bit depth in DaVinci Resolve's Deliver page?

Bit rate is a direct field. Bit depth is a consequence of which codec you pick above it, and the two live in different parts of the same panel.

On the Deliver page, under the Video section's Quality settings, the Restrict to option is where you type a target Mbps number directly, a manual override on the bitrate DaVinci Resolve otherwise calculates automatically based on codec and quality preset. That's the field covered in more depth in our companion guide on [DaVinci Resolve export file size too large](https://tryuncle.com/learn/davinci-resolve/davinci-resolve-export-file-size-too-large), and it's purely a bit rate control. It never changes how many bits per pixel your export can hold.

Bit depth sits one level up, in the Format and Codec dropdowns above Quality. Choosing H.264 caps you at 8-bit on almost every consumer delivery target, per the H.264 baseline standard already covered above. Choosing H.265/HEVC opens a Main 10 profile option that carries genuine 10-bit precision at a still-reasonable bit rate. Choosing ProRes or DNxHR opens a family of variants where bit depth and chroma sampling are fixed per variant, exactly the way the ProRes and DNxHR tables above lay out, and bit rate follows from which specific variant you pick, not from a field you type into directly.

There's a third setting worth knowing before you export anything graded on a 10-bit or higher timeline: Data Levels and the encoder's rate control mode, whether it's set to constant or variable bitrate, both live in the same Advanced render settings panel documented in [Blackmagic's own manual](https://www.steakunderwater.com/VFXPedia/__man/Resolve18-6/DaVinciResolve18_Manual_files/part3948.htm). Neither one touches bit depth, but both change how faithfully your export's actual bit rate matches the number you typed into Restrict to, which matters if you're hitting a hard platform ceiling like YouTube's recommended maximums.

**One panel, two unrelated decisions.** Pick your codec and variant first, since that decision locks your bit depth ceiling for the whole export. Then dial in bit rate second, inside whatever ceiling that codec choice already set.

## Does DaVinci Resolve's optimized media or render cache use a different bit depth than your timeline?

It can, and this is one of the quieter places the bit rate versus bit depth confusion sneaks back in, because Optimized Media and Render Cache aren't your delivery export at all. They're working files Resolve generates purely to make playback and scrubbing smoother while you edit.

Per Blackmagic's own manual, Resolve's proxy media settings let you pick the format those working files are written in: "You can choose from among a variety of Uncompressed, ProRes, and DNxHD formats, depending on your requirements" ([DaVinci Resolve Manual](https://www.steakunderwater.com/VFXPedia/__man/Resolve18-6/DaVinciResolve18_Manual_files/part162.htm)). That choice carries a bit depth the same way any codec choice does elsewhere in this guide, an uncompressed 8-bit option for maximum playback speed on modest hardware, a ProRes proxy option at 10-bit, and so on.

The reason this matters: those working files exist purely for your editing session, and Resolve switches back to the original source media, at its own bit depth, the moment you hit render on the Deliver page. An 8-bit proxy doesn't cap your final export at 8-bit. But it's a common source of a specific, confusing symptom: banding that appears while scrubbing the timeline during editing, then disappears in the final render, because you were watching a lower-bit-depth proxy the whole time rather than the actual color-managed source. If you see banding while editing that vanishes on export, check whether Optimized Media or Render Cache was active before you conclude anything about your actual delivery pipeline.

**Optimized Media and Render Cache are playback conveniences with their own codec and bit depth, entirely separate from the bit depth your final Deliver page export actually uses.** Treat banding you see during scrubbing and banding you see in an exported file as two different diagnostic questions, because they very often have two different answers.

## What bit rate should you actually set for delivery?

Match your bit rate to your actual delivery platform and frame rate, not a single number you copy onto every export regardless of destination.

YouTube publishes exact recommended upload bitrates, and they scale steeply with both resolution and frame rate. Per [YouTube's own recommended upload encoding settings](https://support.google.com/youtube/answer/1722171), SDR uploads should target roughly these numbers:

| Resolution | Standard frame rate (24-30fps) | High frame rate (48-60fps) |
| --- | --- | --- |
| 2160p (4K) | 35-45 Mbps | 53-68 Mbps |
| 1440p | 16 Mbps | 24 Mbps |
| 1080p | 8 Mbps | 12 Mbps |
| 720p | 5 Mbps | 7.5 Mbps |
| 480p | 2.5 Mbps | 4 Mbps |

Notice what this table doesn't mention anywhere: bit depth. YouTube's recommended bitrates apply the same way whether your source is 8-bit or 10-bit, because bit rate governs how much motion and detail survive compression at your chosen resolution and frame rate, a completely separate question from how many shades of color each pixel holds. If you're delivering HDR specifically, YouTube's own guidance bumps every one of those numbers up noticeably to account for the wider tonal range HDR carries, which is one of the rare places bit depth and bit rate genuinely interact: a wider color and brightness range needs more bits per second to encode cleanly, even though the two numbers are still measuring different things.

For a project you're archiving or handing off for further color work rather than delivering to a platform, ignore bitrate tables entirely and reach for an intra-frame codec instead. That's the ProRes and DNxHR territory the tables earlier on this page already cover, where bit rate exists to preserve editing flexibility and grading headroom, not to fit a platform's upload cap. Our full glossary of terms like these, alongside dozens of others editors run into daily, lives in our [DaVinci Resolve glossary of common video editing terms](https://tryuncle.com/learn/davinci-resolve/davinci-resolve-glossary-of-common-video-editing-terms).

## What about Vimeo, LinkedIn, and Twitter/X instead of YouTube?

YouTube isn't the only platform with published bitrate guidance, and the differences between platforms are worth knowing before you build five separate custom export presets from scratch.

Vimeo publishes its own numbers, and unlike YouTube, it explicitly ties bit rate guidance to bit depth. Per Vimeo's own compression guidelines, the platform recommends 10 to 20 Mbps for 1080p and 30 to 60 Mbps for 4K, and separately states "we recommend a bit depth of 10 or greater for the highest quality results," adding that "for high dynamic range (HDR) and Dolby Vision videos, your file needs to have a bit depth of 10 or greater" for Vimeo to even recognize the upload as HDR ([Vimeo Help Center](https://help.vimeo.com/hc/en-us/articles/12426043233169-Video-and-audio-compression-guidelines)). That's the platform's own documentation drawing the exact line this whole page has been drawing: bit rate handles data throughput, bit depth handles color capability, and Vimeo needs both numbers right, not just one.

LinkedIn and Twitter/X are less explicit about bit depth in their own published specs, but both are H.264 platforms in practice, which caps you at 8-bit before bit depth even becomes a live question, the same way it does for YouTube's standard SDR path. Our dedicated guides cover the rest of what actually matters for each: [DaVinci Resolve export settings for LinkedIn video](https://tryuncle.com/learn/davinci-resolve/davinci-resolve-export-settings-for-linkedin-video) recommends 5-10 Mbps for a 1080p LinkedIn upload, since LinkedIn re-encodes everything on its end regardless of what you send it, and [DaVinci Resolve export settings for Twitter (X)](https://tryuncle.com/learn/davinci-resolve/davinci-resolve-export-settings-for-twitter-x) walks through X's file size and runtime caps, which matter more on that platform than chasing one specific bitrate number.

| Platform | 1080p bit rate | 4K bit rate | Bit depth |
| --- | --- | --- | --- |
| YouTube (SDR, standard fps) | 8 Mbps | 35-45 Mbps | 8-bit (10-bit for HDR uploads) |
| Vimeo | 10-20 Mbps | 30-60 Mbps | 10-bit or greater recommended |
| LinkedIn | 5-10 Mbps | Not officially specified | 8-bit (H.264) |
| Twitter/X | Matches X's H.264 preset | 4K, Premium-only | 8-bit (H.264) |

**Every platform's published bitrate table answers the bit rate question. Almost none of them answer the bit depth question directly, except Vimeo, which is exactly why it's worth reading a platform's actual compression guidelines instead of assuming YouTube's numbers apply everywhere.** Build one custom preset per platform in Resolve's Deliver page rather than reusing a single "web export" preset for all four.

## Your export is still banding after raising the bit rate. What do you check next?

If you've already ruled out bit rate and the banding hasn't budged, work through this list in order. Each step rules out a specific, common cause before you reach for a bigger fix.

1. **Check your project's color science bit depth first, not your export codec.** Open Project Settings and confirm what bit depth Resolve is actually processing at internally. An 8-bit project setting overrides whatever your source footage or export codec can theoretically hold, since the grading math itself only has 256 steps per channel to work with regardless of what you render out to.

2. **Confirm the banding is real, not a viewer artifact.** Resolve's own UI preview can show banding that a fully rendered file doesn't have, especially over a non-color-managed connection or a laptop's built-in display doing its own dithering on the way to the panel. Export a short test clip of just the banded section and inspect the actual file in a separate player before chasing a problem that might only exist in the viewer.

3. **Check the specific clip, not just the timeline.** A still image, title card, chart, or screen recording dropped into an otherwise 10-bit timeline is very often an 8-bit PNG or JPEG under the hood. Right-click the clip on the Media page and check its format. One 8-bit asset under a heavy gradient can band even inside a project that's 10-bit everywhere else.

4. **Check your camera's actual internal recording bit depth for that specific clip**, using the method covered earlier in this guide. Log footage that turned out to be recorded at 8-bit instead of 10-bit behaves exactly like any other 8-bit source once it's inside Resolve, regardless of how flat and gradeable it looked in-camera.

5. **Check whether you're running Resolve's free version.** If you are, and the source is genuinely 10-bit or higher, the free version's 8-bit processing ceiling is very likely your actual bottleneck, and no Deliver page setting changes that.

6. **Reduce the aggressiveness of the grade itself before reaching for a technical fix.** Banding gets more visible the harder you push a contrast curve or saturation boost through a smooth gradient. A slightly less dramatic grade on the same 8-bit source sometimes eliminates visible banding entirely, with zero export setting changes.

7. **Apply Deband or a grain node as a last resort**, covered above, if none of the previous steps are available to you, whether that's a client deadline tonight or source footage you genuinely can't reshoot. If you're mid-export and unsure which of these seven is actually your problem, that's exactly the kind of on-screen, in-the-moment question TryUncle's Uncle can help narrow down, since it can look at your actual Deliver page and Project Settings rather than a general checklist.

**Banding survives a bit rate increase almost every time, because bit rate was never the layer where the problem lived.** Work down this list from the top, since the earlier steps catch the most common causes, and you'll usually find the actual source before you reach step seven.

## Quick reference: what bit rate and bit depth should you use, by delivery scenario?

If you just want the answer for your specific delivery target without reading the reasoning behind it, use this table as a starting point and adjust from there.

| Delivery scenario | Recommended codec | Bit depth | Bit rate range |
| --- | --- | --- | --- |
| YouTube/social, SDR, 1080p | H.264 or H.265 | 8-bit | 8-12 Mbps |
| YouTube/social, SDR, 4K | H.265 (HEVC) | 8-bit | 35-68 Mbps |
| HDR delivery (HDR10, Dolby Vision) | H.265 Main10 | 10-bit minimum | Match YouTube's HDR-bumped rates or Vimeo's 10-bit guidance |
| Editorial/offline proxies | ProRes 422 Proxy or DNxHR LB | 8 or 10-bit | ~45 Mbps (1080p) |
| Broadcast delivery, general | ProRes 422 HQ or DNxHR HQ | 8 or 10-bit | ~220 Mbps (1080p) |
| UHD/4K broadcast mastering | DNxHR HQX | 12-bit | Follows codec, not a manual field |
| VFX, greenscreen, motion graphics | ProRes 4444 or DNxHR 444 | 10 or 12-bit, 4:4:4 | Follows codec, not a manual field |
| Archival/mezzanine master | ProRes 422 HQ or higher | 10-bit minimum | As high as storage allows |

Two columns in that table are worth a second look. The bit rate column is effectively fixed for every intra-frame codec row, because those formats don't take a manual "Restrict to" number the way H.264 and H.265 do on Resolve's Deliver page. Choosing the codec variant chooses the bit rate at the same time it chooses the bit depth. Only the top three rows, consumer and HDR delivery, are ones where you're actually typing a bit rate number into a field yourself.

**This table is a starting point, not a substitute for checking your specific platform's current published specs, since streaming platforms update their recommended bitrates more often than codec specifications change.** When the two disagree, trust the platform's own current help page over any table, including this one.

## Is there an app that can tell you which setting to change while you're actually exporting?

Reading a definition explains the concept. It doesn't tell you, staring at your own Deliver page, whether the banding you're looking at right now is a bit depth problem or a bit rate problem.

TryUncle is the on-screen assistant for DaVinci Resolve on macOS. Ask in plain words and Uncle points at the exact control on your screen, whether that's the Restrict to bitrate field under Quality or the Codec dropdown that's quietly setting your export's bit depth ceiling. In our own 100,000+ member professional video-editing community, "why is my export still banding after I raised the bitrate" is a recurring stuck point, and it traces back to exactly the mix-up this page covers more often than to a genuinely broken export. After 7+ years of professional, commercial editing work delivering everything from 8-bit web exports to 10-bit broadcast masters, that specific confusion is one we've walked people through more times than almost any other Deliver page question.

This sits in a different category from most tools people mean when they ask about an AI tool to learn DaVinci Resolve. Sottocut and [CutAgent](https://www.cutagent.ai/) automate editing tasks directly on your timeline, cutting or reformatting footage, rather than helping you diagnose a Deliver page setting mismatch. [Eddie AI](https://www.heyeddie.ai/workflows/davinci-resolve) and general chat assistants can explain the difference between bit rate and bit depth in the abstract, roughly the way this page does, but they have no view of your actual project and can't confirm which codec your current export preset is actually using. [PremiereCopilot](https://www.premierecopilot.com/pricing) targets a different NLE's workflow entirely. Uncle watches your DaVinci Resolve screen while you work and can point at the specific field you're staring at, which is what makes it useful the moment a definition needs to become an action inside your own export.

**Guided practice inside Resolve beats watching courses about Resolve when the question is this specific.** Knowing that bit depth controls gradient smoothness and bit rate controls file size is trivia. Knowing which one is set wrong on your own current export, before you render it and find out the hard way, is the decision that actually saves your afternoon. If your export is banding right now and you're not sure whether it's a bit depth problem or a bit rate problem, that's exactly the kind of on-screen question Uncle can answer while you're still looking at the Deliver page.

TryUncle is a paid subscription, currently $29.99 a month under founder pricing for the first 100 seats, cancel anytime, per [TryUncle](https://tryuncle.com/?utm_source=learn&utm_medium=blog&utm_campaign=davinci-resolve-bit-rate-vs-bit-depth-explained). It's macOS only, and it needs an internet connection to work. Pricing moves as founder seats fill, so check TryUncle directly for the current rate rather than treating this number as fixed.

## The short version

Bit rate and bit depth share a word and nothing else. Bit rate is how much data your export moves every second, measured in Mbps, and it's the field you type a number into under Quality on the Deliver page. Bit depth is how many shades of color each pixel can hold, measured in bits per channel, and it's set implicitly by whichever codec and variant you choose above that field, not by a number you type in directly.

Raising bit rate cleans up compression artifacts and blockiness. It does not, and cannot, add color steps that a lower bit depth never captured. If you're chasing banding, check your codec, your camera's actual internal recording bit depth, your DaVinci Resolve version, free caps you at 8-bit, Studio unlocks 10-bit, and your project's color science setting before you touch a single Mbps field. If you're chasing file size or platform compliance, match your Restrict to number to your actual resolution, frame rate, and platform, using the tables in this guide or your platform's own published specs, and leave bit depth entirely out of that conversation. Two dials, a third one for chroma sampling that neither of them touches, and the fastest way to waste an afternoon is turning the wrong one.

## FAQ

### What's the difference between bit rate and bit depth in DaVinci Resolve?

Bit rate is how much data your file moves every second, measured in megabits per second (Mbps), and it mostly controls file size and compression artifacts like blockiness. Bit depth is how many distinct shades of color each pixel can store, measured in bits per channel (8-bit, 10-bit, 12-bit), and it controls how smooth a gradient looks and how much room you have to grade before banding appears. One is a data-flow number. The other is a color-precision number. Changing one setting in DaVinci Resolve's Deliver page never changes the other.

### Does raising the bit rate on my DaVinci Resolve export fix color banding?

No. Banding happens when a file doesn't have enough bit depth to store a smooth gradient, so it snaps to visible steps instead. An 8-bit file only holds 256 shades per color channel, according to Wikipedia's entry on color depth, versus 1,024 for 10-bit. Raising the bit rate on that same 8-bit export gives you a cleaner, less compressed version of those same 256 steps. The bands are still there, just rendered with less compression noise around them. Only a higher bit depth actually adds more steps to the gradient.

### What bit depth does DaVinci Resolve Free support versus Studio?

Per Blackmagic Design's own comparison page, the free version 'works with virtually all 8-bit video formats at up to 60fps in resolutions as high as Ultra HD 3840 x 2160,' while DaVinci Resolve Studio 'supports 10-bit video up to 120 frames per second and resolutions beyond 4K.' If you're grading 10-bit or higher footage and trying to preserve that precision through to your final export, that ceiling is Studio-only, not a bit rate setting you can raise your way around.

### What bit rate should I set when exporting from DaVinci Resolve for YouTube?

YouTube's own recommended upload encoding settings put 1080p SDR at 24 to 30fps at roughly 8 Mbps, and 1080p at 48 to 60fps at roughly 12 Mbps. For 4K SDR, YouTube recommends 35 to 45 Mbps at standard frame rates and 53 to 68 Mbps at high frame rates. Set these in DaVinci Resolve's Deliver page under the Restrict to bitrate field, matched to your actual resolution and frame rate, not a single number you reuse for every export.

### Is 10-bit 4:2:2 better than 8-bit 4:4:4 in DaVinci Resolve?

It depends what you're protecting. 10-bit 4:2:2 gives you four times the tonal steps per channel of 8-bit, which is what actually prevents banding in skies, skin, and shadows. 4:4:4 chroma sampling protects fine color detail at hard edges, like text or graphics, rather than smooth gradients. For most narrative and documentary footage, the extra bit depth in 10-bit 4:2:2 matters more day to day than full 4:4:4 chroma. For motion graphics, screen recordings, or green screen keying, 4:4:4 earns its keep.

### Does 10-bit footage need a higher bit rate to store the same picture as 8-bit?

At the same codec and compression level, yes, because there's genuinely more data per pixel to carry. But bit rate and bit depth still move independently once compression enters the picture. Apple's ProRes 422 family proves it: ProRes 422 Proxy, LT, 422, and 422 HQ are all 10-bit 4:2:2, per Wikipedia's entry on Apple ProRes, yet their data rates at 1080p run from roughly 45 Mbps up to roughly 220 Mbps. Same bit depth, nearly five times the bit rate, because compression aggressiveness, not color precision, is what's actually changing between those four codecs.

### What bit depth do you need for HDR10 or Dolby Vision delivery from DaVinci Resolve?

10-bit minimum for both. HDR10 requires it for Blu-ray Disc Association and UHD Alliance certification, and Dolby Vision supports up to 12-bit, though most consumer Dolby Vision still ships at 10-bit. DaVinci Resolve Studio has graded and rendered Dolby Vision natively since version 15 in 2018; the free edition has no Dolby Vision tools at all, so an 8-bit free-version project can't produce a spec-compliant HDR master regardless of what bit rate you export at.

### Is there an app that can tell me which bit rate or bit depth setting to use while I'm exporting in DaVinci Resolve?

Yes. TryUncle is a macOS assistant that watches your DaVinci Resolve screen and points at the exact control you're asking about, whether that's the Restrict to bitrate field on the Deliver page or the codec dropdown that quietly decides your export's bit depth. It's a paid subscription, currently $29.99 a month under founder pricing, and it doesn't render anything or touch your project on its own.

## Sources

- [Wikipedia: Color depth](https://en.wikipedia.org/wiki/Color_depth)
- [Wikipedia: Bit rate](https://en.wikipedia.org/wiki/Bit_rate)
- [AbelCine: HD Formats - Bit Rate vs Bit Depth (Andy Shipsides)](https://www.abelcine.com/articles/blog-and-knowledge/tutorials-and-guides/hd-formats-bit-rate-vs-bit-depth)
- [Wikipedia: Apple ProRes](https://en.wikipedia.org/wiki/Apple_ProRes)
- [Wikipedia: Advanced Video Coding (H.264)](https://en.wikipedia.org/wiki/H.264)
- [Wikipedia: High Efficiency Video Coding (HEVC)](https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding)
- [Wikipedia: AV1](https://en.wikipedia.org/wiki/AV1)
- [Wikipedia: Dither](https://en.wikipedia.org/wiki/Dither)
- [Wikipedia: Canon EOS C300 Mark II](https://en.wikipedia.org/wiki/Canon_EOS_C300_Mark_II)
- [YouTube Help: Recommended upload encoding settings](https://support.google.com/youtube/answer/1722171)
- [Vimeo Help Center: Video and audio compression guidelines](https://help.vimeo.com/hc/en-us/articles/12426043233169-Video-and-audio-compression-guidelines)
- [Blackmagic Design: DaVinci Resolve compare page (free vs Studio)](https://www.blackmagicdesign.com/products/davinciresolve/compare)
- [DaVinci Resolve Manual: Color Bit Depths (Blackmagic Design, mirrored)](https://www.steakunderwater.com/VFXPedia/__man/Resolve18-6/DaVinciResolve18_Manual_files/part1903.htm)
- [DaVinci Resolve Manual: All Other Render Settings for Output (Blackmagic Design, mirrored)](https://www.steakunderwater.com/VFXPedia/__man/Resolve18-6/DaVinciResolve18_Manual_files/part3948.htm)
- [DaVinci Resolve Manual: Optimized Media and Render Cache (Blackmagic Design, mirrored)](https://www.steakunderwater.com/VFXPedia/__man/Resolve18-6/DaVinciResolve18_Manual_files/part162.htm)
- [Blackmagic Design: DaVinci Resolve Color page](https://www.blackmagicdesign.com/products/davinciresolve/color)
- [CineD: DaVinci Resolve 21.0.3 Released (Nino Leitner)](https://www.cined.com/davinci-resolve-21-0-3-released-keyframe-ease-actions-interlaced-fixes-and-sony-burano-x-ocn-decode-fix/)
- [Avid Knowledge Base: DNxHR Codec Bandwidth Specifications](https://kb.avid.com/pkb/articles/en_US/Knowledge/DNxHR-Codec-Bandwidth-Specifications)
- [MASV: Everything You Need to Know About DNxHD Files](https://masv.io/blog/dnxhd-files)
- [UHD Alliance: What is HDR10+?](https://alliance.experienceuhd.com/news/what-hdr10/)
- [PremiumBeat: Methods for Debanding Your Footage in DaVinci Resolve](https://www.premiumbeat.com/blog/debanding-footage-davinci-resolve/)
- [CutAgent (product site)](https://www.cutagent.ai/)
- [Sottocut (product site)](https://sottocut.com)
- [PremiereCopilot pricing](https://www.premierecopilot.com/pricing)
- [Eddie AI for DaVinci Resolve (native integration workflow page)](https://www.heyeddie.ai/workflows/davinci-resolve)