Rendering & Delivery
Video Editing Fundamentals
Chapter 8 · Rendering & Delivery
Chapter 2 named Deliver as the final of Resolve's own seven pages, and Chapter 3 promised proxies never affect final quality without explaining the actual mechanism. This chapter is both — the real export step, and where that proxy promise is actually kept.
The Deliver Page
The Deliver page is where a finished timeline actually becomes a real, deliverable video file — render settings, output location, and format/codec selection all live here.
Render Settings vs. Project Settings
A genuinely common point of confusion: project settings control the resolution and framerate the timeline itself uses while editing, while render settings on the Deliver page control what actually gets exported — which can differ from the project's own settings if needed, for instance rendering at a lower resolution than the edited timeline. Understanding these as two separate, independently configurable things avoids confusion when an export doesn't match expectations.
Codecs & Containers
Another genuinely common point of confusion: a container (like MP4 or MOV) is the file format wrapping the data; a codec (like H.264 or H.265/HEVC) is how the actual video data inside is compressed. The same container can hold different codecs, and vice versa. H.264 remains the most broadly compatible codec across platforms and devices; H.265/HEVC offers better compression at the same quality, but with less universal playback support.
Matching Delivery Settings to YouTube's Own Requirements
Cross-referencing Creating YouTube Content's own Editing Workflow chapter directly: YouTube publishes recommended upload specifications for resolution, bitrate, and codec. Resolve's own built-in YouTube export preset simplifies this by pre-configuring settings already matched to those recommendations, rather than needing to look them up and configure everything manually each time.
Where Proxies Get Swapped Back
Revisiting Chapter 3's own promise concretely: during the actual render process here on the Deliver page, Resolve automatically uses the original full-resolution footage rather than whatever proxy was used for smooth editing. This is the actual mechanism behind Chapter 3's own claim that proxies never affect final quality — it happens right here, at render time.
| Concept | Controls |
|---|---|
| Project settings | Resolution/framerate the timeline uses while editing |
| Render settings | What actually gets exported — can differ from project settings |
| Container (MP4/MOV) | The file format wrapping the data |
| Codec (H.264/H.265) | How the video data inside is compressed |
Hands-On Exercises
A project was edited at 4K resolution, but the final export needs to be delivered at 1080p for a client's specific requirement. Explain, using this chapter's own material, why this is possible without re-editing the timeline itself.
📄 View solutionAn editor exports a project, uploads it to YouTube, and immediately considers the job finished without ever opening the rendered file. Using this chapter's own warning box, explain the risk in skipping this step.
📄 View solutionA project was edited using proxies for smoother playback on a lower-power laptop. Explain what actually happens to those proxies during the final render, using this chapter's own material.
📄 View solutionChapter 8 Quick Reference
- Project settings (editing timeline) and render settings (Deliver page) are two separate, independently configurable things
- Container (MP4/MOV) wraps the data; codec (H.264/H.265) compresses it — not the same concept
- Resolve's own YouTube export preset pre-configures settings matched to that platform's own recommendations
- Proxies get swapped back for full-resolution footage right here, at render time — the actual mechanism behind Chapter 3's own promise
- Always review the actual rendered file — a correct editing-time preview doesn't guarantee a correct final render