Hi guys – I’m testing out the new video engine of Cubase 9.5.10 some more, and I’m having trouble getting Avid DNxHD video files to work. I have already purchased and installed the Video Decoder for Avid DNxHD and I’ve verified that the license is activated on my e-Licensor.
My problem is that Cubase will still not recognize the MXF DNxHD files. These files are exported from Premiere and they work perfectly with Pro Tools.
Any ideas?
So I’ve now submitted a support request to Steinberg. Hoping they eventually get back to me. Anyone have any luck with this?
Hi guys – quick update – I finally heard back from Steinberg and they literally did not know what I was talking about… as if the support person didn’t realize that Steinberg had a product called “Video Decoder for Avid DNxHD.” Needless to say, I was quite surprised, so I have replied and explained more, and provided a link to the actual product page so the support person can check it out: Video Decoder for Avid DNxHD® | Steinberg
So for now, I’m still stuck, and waiting to hear back from my reply. Anyone have any luck with this?
I’m not a video expert, but does cubase support MXF containers? Simply changing the container might help.
Thank you, vinark! This was the clue I needed to solve the problem!
So the solution is to use MOV files as containers for Avid DNxHD files, and NOT to use MXF containers!
And with a quick test, it seems to be working pretty well, although it uses a lot more CPU than I expected, but then again, the new video engine is not very well optimized IMO. So perhaps future updates will reduce CPU usage.
I’m sure DNxHD is nice and all that, but the usual thing is to make a lower resolution proxy for music production, unless you have a monster PC. Most times the finished product comes from the video editing suite - the video used in audio tools is just for reference…
Hi SuperG,
You are correct that most people will never need DNxHD at all. They will be fine with some other codec. However, there are plenty of people who are involved in workflows that involve Prores and DNxHD (two very similar pro codecs). I’m one of those people who prefers one of those codecs (DNxHD in paticular, lately, since it natively exports from Premiere on both platforms), and some of us don’t have a choice to use a pro codec, some require it, or for some, it’s actually a faster workflow, depending on the client or situation.
Also, you may not be aware of this, but DNxHD, for example, has sample-accurate audio streams, which is important to many people. For example, if you regularly use H264 files, Cubase will NOT import the audio accurately, and it in fact has a nasty extra little decoding bug right at the beginning of the file. Go test it out, it’s pretty surprising in Cubase 9.5.1. Hope they change it in the next update. That may not be important to you, personally, but if you rely on that audio for critical reference, then you’ve been using audio that is NOT accurately synced to frame. However, with DNxHD, for example, the reference audio track is frame accurate. So for H264, it would require your workflow to also include a separate uncompressed audio WAV file to retain frame accuracy. So the workflow with DNxHD is actually faster and more convenient, and again, frame accurate.
Lastly, you are incorrect about needing a “monster PC” to run DNxHD. While I mentioned in my post that I was surprised that’s Steinberg’s engine was chewing up more CPU than I expected for DNxHD, what I didn’t mention was that Steinberg’s poorly-optimized video engine chews up even MORE CPU with H264. It’s actually pretty common for H264 in general to chew up more CPU in most engines BTW, since it is a relatively high-CPU codec. A lot of people have no idea about that… but it’s specifically designed to reduce file sizes, at the expense of CPU. DNxHD and Prores are optimized for quality at the expense of file size, and their compression algorithms are actually LESS complex in many ways compared to H264, thus making them easier on a CPU.
So to give you an example, here are some real-world results from my testing on my own system, which just proves the point. This may be helpful to some people in the forum who are interested:
H264 1080p: 12.4% CPU - Note: seeking is laggy
DNxHD 1080p: 10.1% CPU - Note: seeking is NOT laggy
H264 720p: 9.6% CPU - Note: seeking is NOT laggy, also used 1-frame KF
DNxHD 720p: 8.4% CPU - Note: seeking is instant
H264 540p: 8.6% CPU - Note: seeking is instant, also used 1-frame KF
DNxHD 540p: 7.7% CPU - Note: seeking is buttery instant
So as you can see, even for normal users, DNxHD can have some great advantages. 1) it has sample-accurate audio (which is a huge deal if you don’t have separate stems/reference to work with!), 2) It is MORE efficient on the CPU (contrary to some myths floating out there), and 3) it actually behaves better in the Steinberg engine, with faster/smoother seeking. DNxHD 540p, in particular, was buttery smooth. Those are pretty good advantages in my book, and not to mention some workflows or clients or studios simply default to it.
The downside is that DNxHD files take up much more hard drive space. In the example files I used above, however, the space increase was NOT that bad. With SSD and HDD prices so affordable these days, it’s not a big deal in my book. But some people will be very space-limited, so this could be a big disadvantage for them, perhaps on a laptop, or if they have very tight budget constraints. However, I used the lowest-quality compression algorithm (LB, low bandwidth) on my test DNxHD files, and these were approximately 1.5X to 4X the size of my tested H264 files, which is not that bad really, taking into account the advantages you get from DNxHD. There are much, much higher-bandwidth settings for DNxHD of course, and I have also tested those, and they perform similarly, but they of course occupy much more hard drive space.
In any case, I hope this helps someone out there. Prores and DNxHD files are not for everyone, but there are definitely some very good advantages, and only one real disadvantage (file size), plus with Cubase/Nuendo, you also have to pay an additional $30 fee to get DNxHD support. But it works, and it works relatively well, and it’s a real, viable option for people, even for those who wouldn’t normally consider it.
And BTW, all that has nothing to do with the broader issue that Steinberg’s new video engine is still poorly optimized. I’ve mentioned this in other threads. They really need to keep working on it. Other video engines in other DAWs, for example, including Steinberg’s OLD engine, perform much better. And of course, using DNxHD in Pro Tools performs extremely well, as you would expect it to, but it shows that Steinberg’s optimization has a long ways to go.
Thanks for the great write up! Can you specify a difference in cpu usage between new cubase engine and PT?
I did some tests on other codecs and DAWs several weeks/months ago, including on Cubase’s old engine, but I haven’t done a head-to-head on DNxHD between Cubase 9.5.1 and the latest release of Pro Tools (2018.1). I will try to get around to it and post something when I have time. It was only yesterday that I got DNxHD working in Cubase 9.5 at all. However, in general, I have found the Pro Tools video engine to perform very well, and anecdotally, it performs beautifully with DNxHD files of any spec I throw at it, with very smooth performance. But I’d have to go look at CPU specifically on a comparison of the exact same file. In my other tests, in almost EVERY case, the new Cubase video engine performed worse, or sometimes far worse than other DAWs, including the old video engine. Steinberg has some serious optimization to do, but to their credit, the DNxHD feature works pretty well so far, now that I have it working. And thanks, in NO part, to Steinberg itself helping me out.
Good write up, uarte. Yes, DNxHD does have advantages. An I-frame only codec like DNxHD is cpu friendly, mpeg-2 or wavelet codecs are too. (h264 & h265 are not…)
I’m really just pointing out the ‘general’ case where I point out it’s just common sense to use a less CPU-heavy codec and/or resolution.