I wanted to explain why we pulled out the 2 codecs [ProRes and Avid DNXHD] from the latest build of Draft.
When selling a commercial product, different licensing agreements come into play. Early on, we evaluated and licensed H264 because the rate is quite reasonable for large quantities of Draft licenses, but the licensing fee for other codecs is an order of magnitude more [or in some cases, even higher]
The decision was made to keep Draft free, but pull out the specific codecs that are unclear and release them in a separate ‘Pro Codec pack’ which would be a floating per use license to read and write those specific codecs. The advantage of this to us, is that we are not cutting 1000’s of Draft licenses and ending up with massive licensing fees - the advantage to you is that Draft remains free with support subscription. If you require the use of DNXHD, the licensing fee is TBD but will be below $99 per seat and likely much less than that. I presume that even larger facilities who generate many quicktimes won’t need more than a few floating licenses in use at any one time while generating or reading that specific codec.
We feel this is a better approach than to not provide access to these codecs.
Any feedback on our decision, questions or concerns, please feel free to respond here or email me directly.
I have to be totally honest, this is a major disappointment for us. I can of course totally understand the need to remove a codec like DNxHD due to licensing concerns, but how can it be that ProRes is available to FFMPEG users (which is opensource after all) but not to users of draft?
We are putting finishing touches to our automated dailies/editorial delivery pipeline (which relies on both, DNxHD and ProRes) and not being able to update to the latest beta because of this hits us hard.
Having the option to output MXF directly is of course nice (but paying an extra fee for that of course not so much).
When will you know how much the ProCodecPack will be?
We are currently discussing with Apple the details regarding licensing ProRes for our product. We don’t yet know the details and it may be allowed to be included, or the fee may be negligible. in terms of pricng, we are targeting $49 for the pro-codec pack, but are waiting to hear confirmation from Apple regarding Prores before we finalize pricing. I believe they suggested they would get back to us post-siggraph.
I apologise for any issues, but i’m sure you understand the difficult [and suprising] position we are suddenly put in. it was our understanding that there was no fee for these until very recently - and working with these large companies is not fast, with requests going unanswered for large periods of time.
The positive note that i can give you us that we intend to continue to support, improve and develop DRAFT beyond it’s current capabilities and have dedicated developers associated with this product. With our floating licensing and limit groups inside Deadline - i don’t believe the pro-codec pack will be an expensive barrier to entry for facilties such as yours as it will likely require only a few seats to allow concurrent dnxhd creation.
Do you agree? or do you have the need to do hundreds of concurrent dnxhd’s? I’m very seriously asking this question! i’ve been surprised before!
cb
this sounds very reasonable, we only need max 2 nodes capable of transcoding to ProRes/DNxHD for now, so $49 is no issue.
As you pointed out it seems Draft has a lot of potential, having the option to batch process Alexa.mov´s to DNxHD MFXs with a LUT burn in alone is worth a lot, and for this of course, it would be handy to be able to utilize all the machines on the farm (but i don´t want to to appear ungrateful, having Draft for free at all is amazing!).
If we are to invest a couple of hundet bucks to get a full blow encoding farm which is as versatile as draft is going to be…no problem. We are slowly starting to realize in how many areas Draft can be used, not only in VFX but also in post-production that I am sure we will be able to raise a bit of money to make Draft what i´s supposed to be: one of the best tools in our arsenal…
1. performance improvements
2. more colour support [custom LUTS, 1D and 3D - colour tools]
Custom LUTs would definately be handy and makes Draft future proof, but as you have Alexa and Cineon in there now, it´s more than 90% of what we usually need…
3. a full UI to build scripts [likely we would charge for a full UI, however]
-> this would be sweet! if people who are less into scripting could create draft scripts I would be stoked! (yes, we would pay for that editor!)
4. expanding support [RED, Canon, Nikon and other RAW support or formats to read and other esoteric formats to write]
very interesting and handy for sure. also if you could make Draft talk to the shotgun deamon by default, i think you could offer an amazing automated transcoding pipeline (we are starting to work on this but maybe you guys want to do this even better then we could?) I am talking thumbnails, auto proxy creation, sent to editorial als MXF, re-render EXR in scanline, etc…
5. filters eg our ‘awake’ plug-in set containing fft blurs, etc maybe some optical flow and advanced compositing filters.
-> interesting for undistort and denoise automation most definately, but i think this is handled by nuke/fusion in most facilities so i wouldn´t invest too much time in this if i where you.
I would love to have support for custom LUTS (both 1D and 3D)!
I understand the codec licensing thing… but it raises a question. Currently Draft’s ProRes support is limited due to the libraries it uses. Draft doesn’t create “proper” ProRes QTs (I think it has something to do with the ATOM). The QTs appear fine on the Windows platform but Final Cut doesn’t recognize them properly and thus needs to re-render. So the question: if we now have to pay for the codec support, are we going to get true codec support to create 100% valid ProRes files?
I noticed DRAFT rarely (never?) uses more than one core, which of course, is a bummer…(see attached screenshot)
I created a second slave instance on the dedicated draft machines, but it´s only a workaround and does not help when rendering a single big file.
I have not tested if it is different when rendering to a picture sequence, but MOV is sloooow.
I would also of course love if we could use a H264 accelleration card like the matrox compressHD, but that would mean we have to specify the matroxMAX h264 codec which is not possible i think…?
