How to Set Up On-Set Dailies in DaVinci Resolve

The first decision is what the dailies need to prove. On-set dailies usually serve two different jobs at the same time: editorial needs files that cut cleanly and relink later, while production needs files that play anywhere and show the day’s work with the intended look. DaVinci Resolve can do both, but the setup changes depending on whether you're making offline editorial media, lightweight review files, or both from the same camera originals. A good dailies setup in Resolve keeps the camera originals untouched, applies only the agreed on color pipeline, preserves timecode and metadata, and exports files that the receiving team can actually use without a science project.

Start from the delivery requirement

Before importing media, get the editorial spec and the review spec separated, because they may come from the same timeline, but they aren't the same deliverable.

Decision area	Editorial dailies	Production review files
Main job	Cut smoothly and relink to the OCN later	Let stakeholders watch, identify, and comment on shots easily
Typical format	ProRes Proxy, ProRes LT, ProRes 422, DNxHD, or DNxHR	H.264 or H.265 MP4
Render style	Usually individual clips	Individual clips, scene strings, or a daily roll
Timecode and metadata	Preserve source timecode, clip name, reel or roll, scene, and take	Burn in the identifying metadata viewers need for notes
Audio	Synced production audio with the editorial channel order	Stereo mix unless the review spec says otherwise
Burn-ins	Usually clean unless editorial requests them	Usually enabled
Naming	Source filename or an approved conform-safe convention	Human-readable shoot day, scene, take, and camera information

Editorial dailies are usually built for cutting and later conform, so they need stable filenames, timecode, reel or camera roll metadata, synced production audio when available, and a codec the NLE likes. Production review files are built for playback and communication, and they often need burn-ins, a baked LUT, compressed file sizes, and a format that works on laptops, tablets, phones, or a review platform. The common deliverable options are:

ProRes Proxy, ProRes LT, or ProRes 422 in a QuickTime container for Resolve, Premiere Pro, Final Cut Pro, and many general offline workflows
DNxHD or DNxHR for Avid-style editorial workflows, usually with MXF or QuickTime depending on the receiving spec
H.264 or H.265 MP4 for production review, client viewing, and small-file uploads
WAV or embedded audio depending on whether editorial wants synced audio in the picture files or separate production sound delivered alongside

The important thing is to avoid making one file do everything poorly. A burned-in H.264 MP4 is great for a producer watching at breakfast, but it's usually a bad editorial proxy. A clean ProRes Proxy file with proper timecode is great for offline editing, but it may be too large or too plain for quick production review.

Treat editorial proxies and production review files as separate deliverables.

Build the Resolve project around the camera originals

Treat the camera originals as source evidence, not working media. Your team should generate dailies after safely copying and verifying the original camera negative. Don't point Resolve at the camera card and start rendering from there. Work from a verified clone or storage volume that preserves the original camera folder structure. In Resolve, create a dedicated dailies project or a clearly separated dailies area inside the show project. For an on-set or near-set process, a simple structure is usually better than clever organization:

Shoot day
Camera letter
Card or mag number
Reel or roll
Scene or block, if reliable metadata exists
Audio by sound roll or day

Resolve’s Media page is the right place to bring in the camera originals because you can inspect folder structure, clip metadata, duration, frame rate, timecode, audio channel layout, and file naming before anything hits a timeline. Add the media into bins that match the physical or logical structure of the shoot. If the camera team delivered a shot log, bring that information into your naming and metadata decisions early instead of trying to reconstruct it after export. Set the core project settings before building timelines. The big one is timeline frame rate, because Resolve locks important timing behavior once timelines exist. Match the production frame rate unless editorial has explicitly requested something else. If the show shot 23.976, the dailies timeline shouldn't casually become 24.000, because that small difference becomes a very large problem when audio sync, timecode, and conform enter the room. The project settings worth locking down early include:

Timeline frame rate
Timeline resolution and monitoring aspect
Video monitoring format, if using a calibrated display
Audio sample rate, usually 48 kHz for production workflows
Camera RAW decode behavior, if working from RAW formats
Color management mode
Optimized media and proxy media settings, if the Resolve station needs playback help

The goal is consistency, because if every shoot day uses a different project setup, dailies become harder to compare, harder to troubleshoot, and harder for editorial to trust.

Import camera originals without damaging relink paths

When you import camera media, preserve source filenames unless the workflow has a very specific reason not to. Editorial conform depends on being able to trace an offline clip back to the original source. Resolve can carry metadata, but humans still troubleshoot with filenames, roll names, and timecode.

Keep filenames, roll names, timecode, and other metadata attached to the source media.

For RAW and high-resolution camera formats, teams often use Resolve because it can read the originals even when you shouldn't ask the NLE to handle them. That's the point of a dailies pipeline: Resolve reads the large OCN and renders lighter, organized editorial and review media. Pay attention to the metadata fields that help downstream systems reconnect the dots:

Source timecode
Clip name
Reel name, tape name, or camera roll
Camera ID
Sound roll
Scene and take
Shoot date
FPS
Resolution
Audio channel configuration

If a clip shows the wrong frame rate, missing timecode, or unexpected audio channels in the Media page, solve that before rendering, because once you export hundreds of clips with bad assumptions, every correction turns into a re-render.

Apply the on-set LUT without over-grading the dailies

Dailies should show the intended viewing transform and basic creative intent, not become a hidden final grade. ARRI’s dailies guidance describes Resolve as a fast option for delogged or color-corrected dailies from ARRIRAW or Apple ProRes camera originals, including workflows using 3D LUTs, per-shot LUTs, primary grading, and CDL export. That range is useful, but it also creates a trap: Resolve can do a full DI-style grade, so people start doing one. For most on-set dailies, keep the look reproducible:

Use the show LUT or camera LUT agreed in the workflow memo
Apply CDLs if the color pipeline calls for them
Use primary corrections for exposure and balance when needed
Avoid secondary windows, tracking, keys, and heavy look work unless the finishing pipeline has a defined way to carry or recreate it
Keep SDR and HDR dailies separate if the production has both deliverables

Where you apply the LUT depends on the workflow. A timeline-level LUT is fast, but it assumes every clip shares the same source color space and transform requirement. Clip-level LUTs are safer when multiple cameras, LUTs, or exposure-index decisions are involved. Node-based color on the Color page gives you clearer control and makes it easier to separate normalization, show LUT, and small balancing corrections.

Separate normalization, balancing, LUT, and output trim into clear color stages.

For example, a simple node structure might be:

Camera color space normalization or RAW decode adjustment
CDL or primary balance
Show LUT
Legalization or output trim if required for the viewing format

Do a quick comparison against the on-set reference if you have one. If the DIT, DP, or camera team supplied stills, CDL values, or LUT names, the dailies should visibly match that intent. If they don't, don't “fix” the whole day creatively without asking. Dailies are a communication tool, and surprise color decisions create confusion fast.

Sync audio and keep channel mapping boring

If production sound is separate, sync before creating editorial dailies. Resolve can sync by timecode when the camera and audio recorder share jammed timecode, and it can also use waveform sync in some cases, but timecode remains the cleaner professional path when available. After syncing, inspect the audio channel mapping. Editorial may want a mix track on channel 1 and isolated mics on later channels, or they may have a specific channel order from the sound department. The dailies team shouldn't randomly collapse multichannel production audio into a stereo pair unless the spec says so. Confirm these audio details inside Resolve:

Embedded camera scratch audio is present where expected
Production WAVs match the shoot day and sound roll
Synced clips maintain source timecode
Channel count and order match editorial expectations
Sample rate is 48 kHz unless the show has a different standard
Dual-system audio remains traceable to the original sound files

For production review MP4s, a simple stereo mix may be enough, while for editorial files, preserve what the assistant editor needs. Those are different outputs, and Resolve can render them separately.

Add burn-ins that solve review problems

Burn-ins aren't decoration, because they're there so someone watching a file can identify exactly what they're seeing and report a useful note. Resolve’s Data Burn-In controls let you overlay clip and project metadata onto the image. For dailies, your team usually applies burn-ins to review files and sometimes to editorial viewing copies, but not to clean editorial proxies unless editorial requests them. Common dailies burn-in fields include:

Source clip name
Source timecode
Record timecode, if relevant
Scene and take
Camera roll or reel
Camera ID
Shoot date
Resolution or frame rate
LUT or color pipeline identifier
Audio roll or sync status

Keep the burn-in readable but out of the way. If the show is framed for 2.39 inside a 16:9 file, place burn-ins in the letterbox area when possible. If there's no letterbox, use safe margins and avoid covering faces, slate information, or action. Reviewers need the metadata, but they also need to see the shot.

Place review burn-ins in unused letterbox space when the active picture allows it.

Burn-ins should also match the file’s purpose. A director reviewing selects may need scene, take, and source timecode. A VFX supervisor may care more about clip name, frame count, and camera metadata. A post supervisor may want roll, date, and LUT ID. If you put everything on screen, nobody can read it.

Choose transcode settings by recipient

Resolve gives you several ways to create lower-bandwidth media: proxy generation, optimized media, Media Management transcodes, and Deliver page renders. For on-set dailies, the Deliver page is usually the most controlled option because it lets you combine sync, color, burn-in, naming, audio, and codec choices into repeatable presets. Blackmagic’s Proxy Generator is useful when the goal is automatic proxy creation from watch folders, especially for Resolve-native workflows, and it can generate formats such as H.264, H.265, or ProRes proxies and link them back to originals. But if your dailies need a show LUT, data burn-in, synced production sound, CDL handling, or strict editorial naming, a managed Resolve render is usually a better fit. For editorial proxies, prioritize relinkability and edit performance:

Individual clips, not one long timeline movie
Same frame rate as source or agreed project rate
Source timecode preserved
Source filename or approved naming convention
Reel or roll metadata preserved where possible
Constant, edit-friendly codec
Audio channel layout matching the editorial spec

These settings keep the files useful as offline media instead of turning them into simple viewing copies. For production review, prioritize playback and clarity:

H.264 MP4 for maximum compatibility
1080p is often enough, unless framing or focus review requires higher resolution
Burn-in enabled
Stereo audio mix unless otherwise requested
File names that include shoot day, scene, take, or camera information

The most common mistake is exporting review files and calling them editorial proxies. If the file has burn-ins baked into the image, heavily compressed long-GOP encoding, renamed clips with no source relationship, or missing timecode, editorial may be able to watch it, but they shouldn't have to cut with it.

Render from the Deliver page with relink in mind

On the Deliver page, use a render preset for each deliverable type. Don't manually rebuild settings every night when people are tired, because a dailies preset should define the format, codec, resolution, audio behavior, naming pattern, burn-in state, and whether Resolve renders individual source clips or a single timeline file. For editorial dailies, individual clips are usually the safer choice, because that keeps each rendered file aligned with a source clip and makes relinking, replacing, or reconforming easier. For production review, you may render individual clips, scene strings, or a single daily roll depending on how the team watches material. Naming matters, so if editorial wants source filenames, use them. If production wants human-readable review files, make a separate review export with a readable convention. Don't satisfy production by renaming editorial files in a way that breaks conform. Good render behavior is boring:

One output folder per shoot day and deliverable type
No accidental frame-rate conversion
No surprise resizing or cropping
Burn-ins only on the outputs that require them
Your team checks audio after render instead of assuming it's correct

After the first few clips render, open the actual exported files outside Resolve. Check them in the kind of player or NLE the recipient will use, because this catches issues Resolve’s viewer won't reveal, such as MP4 playback problems, missing audio channels, unexpected gamma shifts, or filenames that sort badly.

Watch for the failure modes that cost nights

Most dailies problems come from small setup choices your team makes too early and discovers too late. The failures that cause the most pain are:

Project frame rate doesn't match the shoot or editorial spec
The assistant editor imported camera originals from an incomplete or unverified copy
The colorist applied the LUT twice, once through color management and once as a node or output LUT
The assistant editor rendered synced audio as stereo when editorial expected isolated tracks
The assistant editor changed source filenames without preserving reel or timecode metadata

Build a tiny test round into the first day. Render one or two clips for each output type, send them to editorial and production, and get confirmation before you run the whole card, because that ten-minute test is cheaper than redoing the night.

Make the handoff boring too

The dailies package should tell the next person what they have, not force them to reverse-engineer your Resolve project. Alongside the rendered media, include whatever the production has agreed to exchange: ALE, CDL, sound reports, camera reports, LUT names, Resolve project exports, or simple notes about known issues. A clean package might include:

Editorial proxy folder
Production review folder
Audio folder, if separate
LUT or CDL folder, if part of the handoff
Camera and sound reports
A short render note with codec, resolution, frame rate, color pipeline, and any exceptions

Dailies have to support both set review and downstream post. If editorial can cut immediately, production can review confidently, and finishing can trace every offline clip back to the OCN, the Resolve dailies setup is doing its job.

FAQ

No. Render dailies from a verified copy or clone of the camera originals, not directly from the camera card. Preserve the original folder structure so metadata, filenames, timecode, and relink paths remain intact for editorial and finishing.

Editorial proxies are made for cutting and later conform. They need source timecode, stable filenames, reel or camera roll metadata, correct audio channels, and an edit-friendly codec such as ProRes Proxy, ProRes LT, DNxHD, or DNxHR. Production review files are made for easy playback and communication. They often use H.264 or H.265 MP4, include burn-ins, have a baked-in LUT, and use smaller file sizes.

The LUT can be applied at the clip level, timeline level, through color management, or in a node on the Color page, but the safest choice depends on the workflow. Clip-level or node-based application is usually better when multiple cameras, LUTs, or source color spaces are involved. A timeline-level LUT is faster but assumes every shot needs the same transform.

Usually no, unless editorial specifically requests them. Burn-ins are most useful for production review, where viewers need to identify clip name, scene, take, source timecode, camera roll, shoot date, or LUT information. Clean editorial proxies should normally remain free of baked-in text so they can be used for offline editing without image distractions.

Yes. Resolve can sync production audio to camera clips using matching timecode when the camera and sound recorder were jammed correctly. It can also use waveform sync in some situations, but timecode sync is generally more reliable for professional dailies workflows. After syncing, audio channel order and track layout should be checked against the editorial spec.

You still need editorial proxies that match the conform and audio spec, but lightweight review copies may not always need a separate manual export. Aspect automatically creates generated proxies and previews, while Resolve renders remain useful when the review file needs a specific LUT, burn-in, naming convention, or audio mix.