Dnxhd 444 (10 bits) vs Prores 4444 (12 bits) from Arri Alexa
I will be soon working on a low budget feature film shot on Alexa.
The idea of production is to be able to (pre)edit on the spot and not be burdened with transcoding, so they originally wanted to record in Prores 4444 - plus, ArriRAW is pretty heavy and they don't want to be handling 80TB or something of rushes.
I strongly recommended them Avid as an editing tool (vs Final Cut Pro) and got them quite convinced.
Then, I looked for that the Arri Alexa record specs and I found this: a) 12 bit RGB ProRes 4444; b) 10 bit RGB DNxHD 444
So, DNxHD 444 is "only" 10 bit, whereas Prores 4444 is 12 bit.
Is there a noticeable difference? Because, if we work with Prores 4444, Final Cut Pro would be the logic choice - choice that I'd like to avoid.
I don't know if this makes sense, but all advise would be of great help.
Things to consider:
1. DNxHD is a purchasable option on the Alexa cameras. Check with whomever is supplying the camera whether this is available. If not, it may be added to the rental price compared to ProRes.
2. DNxHD 444 10 bit is 440Mb/s while ProRes 444 12 bit is 330 Mb/s. ProRes will give you 25% more storage per recording device in the field. Or less media to transfer and backup for the same amount of hours.
3. DNxHD is 1920x1080 only. If shooting ProRes with Alexa, you might be considering 2K (if needed).
4. What is your offline/online plan? Are you looking to edit camera originals at original data rate? Log or non log? Are you finishing in Media Composer or elswhere? If you are creating a proxy for editorial, you have a transcode anyway. The real question is how are you finishing? A conform in Resolve or other similar system for color correction?
5. ProRes 444 is a native codec in Media Composer. On OS X you can render to it as well. But all the aforementioned questions apply. What is your offline and online strategy?
Personally I find there is nothing to gain going with DNxHD as a camera acquisition format.
First off, thanks for your remarks, those really help!
Things just got clearer today: there was a meeting and this is what came up.
The workflow would be: record in Prores 4444 Log C; go through DaVinci Resolve to create offlines in DNxHD with a LUT rec709; edit in Avid.
My (bad) idea of recording in DNxHD 444 was to avoid the transcoding step before editing - and edit natively the rushes. But we would lose too much giving up the Prores (12 bits + 2K format) and we would "gain weight" (as you point out 440Mb/s in DNxHD vs 330Mb/s in Prores). Plus, I'm not sure that you can always edit real time in Avid when editing with those big rushes.
Now, I'm still not sure that the director, that might like to see the rushes in Avid after each day of shooting, will like that transcoding phase in DaVinci.
There is the possibility of using an external recorder and, with the Alexa Rec Out, record a proxy in DNxHD 36 with a LUT Rec709.
If we do it, it depends on the budget and the confort of the operator, I guess.
I would really appreciate your advice on this all.
FWIW - transcoding in Resolve is very fast - faster than an import with transcode into MC. Rendering out of Resolve can be in native MXF media, so there's no time lost getting the Resolve media into MC.
Oliver Peters Post Production Services, LLC
As Oliver says, Resolve is very fast, and I have seen dedicated dailies systems that are souped up and designed for dailies throughout transcode ProRes to DNxHD as 3-4x faster than real time. If you're making dailies in a MacBookPro and reading and writing to a USB2 drive, expectations should be much different.
That being said, the word "dailies"can mean a lot of things and usually you get a spec sheet or requirements from editprial as well as what is expected by producers/director. It can be any or all of (and not a complete list):
-Burn-in or not
-burn-in on first "x" seconds of clip
-which burn-in fields
-Size and position of burn-ins
-If 2K, letterboxed?
-Sync in dailies or Sync in MC?
-Sync mix and ISO, or just Mix?
-LUT with ASC CDL or not ASC CDL?
-Is it really LUT only or do they want additonal color balancing and correction to match shots as needed?
-Additional logging in dailies such as scene, take, description,
-Reports on each dailies delivery with issues, focus, or other problems that either Producer, DP, editor or post super should be aware of
-In addition to editorial dailies, are you making "viewing dailies"? These are typically H.264 for director and DP to have for their needs
-If so, what burn'ins and watermarking needed (property of...)?
-One single drop off and end of day, or is there a hand off at lunch to get started on morning's shoot?
-If you are, how many copies?
-If you, who manages cards/drives from set?
As far as capturing in an external device, make sure it carries the same file name and any timecode offsets have been eliminated. These recorders tend to record QT wrapped DNxHD, so that will need to be AMA Linked and consolidated into an MC project. Is other metadata expected to be logged? Is audio sending a mix to camera that in turn gets recorded here? If so, how does audio metadata get tracks if conform to the BWF ISO tracks are needed?
Or is this a run and gun low budget production? If so, some of this may be needed, some may not. But make sure it is written down and agreed upon for whatever price it is being done for. Too many times one thing is agreed upon, then they ask for more once production has started.
I forgot to add that when editing from recorded proxies off of camera, it does not eliminate the need to QC all the camera originals as there could be an issue there that does not manifest itself with the proxy, such as a bad write, file corruption, etc. That is why making dailies from the camera originals is a good idea, as you can verify file issues as part of the dailies process before sending back SxS cards or whatever is being used to record camera originals back to set.
Also, as a dailies provider, I never clear the cards/disks and let the camera crew deal with that process. You do need clear and precise communication methods as to when a card can be cleared, which is after you've archived and successfully QC'd the material. Hopefully the camera package includes enough cards to provide for that scenario. If you're making one copy only because of fast turnaround needs, then make sure you do a sumcheck, and open each file and at least scrub through from beginning to end before giving the "all clear".
Wow, thanks so much for these awesome advices.
I'm starting to think that we will give up the option of using an external recorder. The director wants to see the rushes with a rough edit: that would put us one day behind no matter what.
What you say about the QT container that most of the recorders use to wrap DNxHD is very useful information, nevertheless, I better keep that in mind for the future.
I guess the sync will be done in MC (Mix only). It should not be too much of a hassle creating offlines of all the shots. The LUT will be general - maybe something more sophisticated than a Rec709 LUT.
About the sound, I don't have a precise idea yet, I still have to talk with the sound people.
This is an independent film, there is some money (not run and gun style), but it's not Hollywood, so I consider with attention the most expensive options.
I'm used to S3D production, with huge amount of datas and any kind of sync issues to solve ahead. I am trying to get rid of some the reflexes I acquired - like those related to the huge time that data transfer + transcoding take.
Resolve transcode, after what you told me, seems a pretty good option.