Canon 5D Mark III Uncompressed HDMI firmware update April: Texas Media Systems

The problem is that you are hindering Premiere in decoding by using a Quicktime container-based format. When you shoot .MOV (whether to ProRes or DNxHD), Premiere has to go through the Quicktime engine in order to decode, limiting itself to 32-bit operations. When you shoot to the nanoFlash (XDCAM .MXF) Premiere can use its own internal engine to decode your footage with full 64-bit operations.
 
The problem is that you are hindering Premiere in decoding by using a Quicktime container-based format. When you shoot .MOV (whether to ProRes or DNxHD), Premiere has to go through the Quicktime engine in order to decode, limiting itself to 32-bit operations. When you shoot to the nanoFlash (XDCAM .MXF) Premiere can use its own internal engine to decode your footage with full 64-bit operations.

There was a performance issue in CS5.5 for 5D3 MOV clips on Windows and the Adobe recommended solution was to rename the 5D3 MOVs to MPG to get around the issue (invoking a different loader). It worked and it ran much faster. However, with CS6, the 5D3 MOVs play full speed- no slowdown and no need to rename as MPG. It's not clear if they wrote their own MOV container parser etc., however it's very fast- everything runs in real-time. In my day job I work with audio/video codecs writing software. Even if the codec is 32-bit, as long as the 32 => 64 bit IO is designed well (separate process), it will run just about as fast as native 64-bit. Most of the codec operations are 32-bit and don't need to address more than 4GB of memory (address space limit of 32-bit).

On OSX, while Quicktime itself (Quicktime.h) is 32-bit, I believe they rewrote all the low level codec code used QtKit, etc., in 64-bit (MOV loaders, etc.). FCP-X and Motion 5 use this new code. In OSX on my Retina MacBook Pro, I can edit 5D3 MOV clips in PPro CS6 in real-time as well. The MOV container is not complex- I wouldn't be surprised if Adobe wrote their own parser (if not, they've have done a good job optimizing their interaction with the Quicktime libraries). Yeah- Quicktime X is 64-bit: http://en.wikipedia.org/wiki/QuickTime#QuickTime_X_.28QuickTime_Player_v10.x.29 (OSX only)
 
First, QuickTime X is simply a player frontend. It may be 64-bit, but the "behind-the-scenes" aspects of using the QtKit are still 32-bit, even in CS6 (there could be a myriad of reasons why you are having better performance with 5D3 clips now).

AV Foundation is the new API that FCPX uses. Premiere doesn't use it yet, I would presume either Apple locks it off from 3rd party developers or Adobe just didn't the info in time to actually implement it. Premiere CS6, to the best of what I've been able to find out, still uses the 32-bit QtKit processes to decode QuickTime files (there are some complaints on other forums from editors miffed at slow DNxHD .MOV performance).

Even if you currently don't see any slowdown, I'd prefer to use XDCam .MXF for the best option for Premiere editors because you never know when you might have some massive project and discover that you'd much rather be working with something that Premiere handles natively instead of having to continually jump over to an API in order to do a simple decode.

Aside from that, I, personally, would never buy a Pix220...only the 240. The recorders are expensive enough as it is without having to purchase a second one if you ever upgrade to a camera with SDI. One thing the Pix has over the nanoFlash is the SSD recording option, which is ideal.
 
The problem is that you are hindering Premiere in decoding by using a Quicktime container-based format. When you shoot .MOV (whether to ProRes or DNxHD), Premiere has to go through the Quicktime engine in order to decode, limiting itself to 32-bit operations. When you shoot to the nanoFlash (XDCAM .MXF) Premiere can use its own internal engine to decode your footage with full 64-bit operations.

Premiere doesn't use Quicktime, it has it's own process for quicktime files. There was a bug with CS5.5 where Nikon material was actually opened with Quicktime instead of Premieres own which caused a lot of slowdowns. Renaming helped.

I think you are definitely missing some technical info as saying stuff like "decoding with full 64-bit operations" doesn't make much sense. 64-bits will not magically make everything "better and faster". It help memory use but opening quicktime files isn't something that needs to be 64-bits anyway. Atleast the process itself.
 
The Pix 220i & NanoFlash are both lovely devices but isn't the Atomos Ninja 2 a far more affordable option as an HDMI recorder?
 
Premiere doesn't use Quicktime, it has it's own process for quicktime files.

Then why would Adobe make this statement on their forums regarding HDV captured in QuickTime on a Mac?

Why would there be a complaint about the performance in CS6 with QuickTime DNxHD files?

Why am I unable to open any .MOV footage on my Windows 7 box with Premiere CS6.0.3 when I uninstall the QuickTime player?

To be able to work with the 32-bit QuickTime architecture, Premiere Pro (which is 64-bit) needs as separate (headless) 32-bit application that cand talk directly to QuickTime. This separate application (called QTServer32) then talks to Premiere via a network socket that is confined to just your computer. I mention that because if it is hanging on loading the ExporterQuickTimeHost plug-in (which is what does the talking via network to QTServer32), then there might be an issue with a firewall or something that is preventing it from doing what it needs to do.

If you don't ever need to export files via QuickTime APIs, then you could just remove the ExporterQuickTimeHost.prm plug-in, but that's just a workaround and may not actually solve your original issue. To be able to solve that, one would need more information about your system and some log files.

Source

I think you are definitely missing some technical info as saying stuff like "decoding with full 64-bit operations" doesn't make much sense.

Clumsily worded, I will admit.

64-bits will not magically make everything "better and faster". It help memory use but opening quicktime files isn't something that needs to be 64-bits anyway.

Do you know what happens when you open a video? Its data gets written to memory. Not only does 64-bit open up more memory space to use, but it also allows the memory to be written to faster because it doubles what can be written in one cycle over 32-bit. This may not seem like much in just a single operation, but opening lots of video files (i.e. within a project environment that contains a good number of clips), it all adds up.

UPDATE: Flash of insight just hit me. You're half right. Premiere can handle 5D3 footage easily because it has native H.264 decoding. DLSRs just use H.264 in a QuickTime container is all, so Premiere could decode it before CS6 with the extension trick (.MOV to .MPG) and then in CS6 I would assume they changed it to where the program could identify those files and not default to using QuickTime to decode H.264, which would speed things up significantly. However, we're not talking about recording DSLR footage natively, we're talking about external recorders, most of which record to ProRes/DNxHD. Premiere has no native decoding of those formats because they are propriatery formats. All decoding of that video must take place through the QuickTime interface, which is 32-bit and carries the overhead of other software needed to make it happen. If Apple ever open sourced ProRes, I would hope Adobe would immediately add native decoding of that format into Premiere as well, which would be terrific.
 
Last edited:
The Pix 220i & NanoFlash are both lovely devices but isn't the Atomos Ninja 2 a far more affordable option as an HDMI recorder?
Yes, I heard Atomos team worked very closely with Canon to make sure C100 works flawlessly with Ninja 2. It's not too crazy to think they would do the same for 5D MK III and Ninja 2.

I also speculate, now this may sound crazy, that the reason 5D MK III has pillar boxes around HDMI output is because that is what the sensor actually resolves. We all guessed 1080 mode resolves around 800 lines and of course, Canon will never admit to this. Maybe, just MAYBE, this clean HDMI firmware HAS TO include the sensor resolving more lines in order to output 1080 image.
 
Last edited:
Well duh. What do you think? Ever used HDMI before?

Wow, there you go again being rude while also being technically off base. There is no indication that the HDMI will output the actual framerate & resolution your are shooting in. As Gary stated it may only be one variety for all shooting modes. Canon does not have my trust since this feature was obviously held in their pocket at release and might not be the exact implementation that would make us happy.
 
Wow, there you go again being rude while also being technically off base. There is no indication that the HDMI will output the actual framerate & resolution your are shooting in. As Gary stated it may only be one variety for all shooting modes. Canon does not have my trust since this feature was obviously held in their pocket at release and might not be the exact implementation that would make us happy.

I'm not ALWAYS rude. But that question is not a very good one especially as no one can even test it out yet.

HDMI will offcourse output the actual framerate & resolution you are shooting in. If it doesn't then it's not the update Canon specifically has talked abuot.
 
I've never used an external recorder before, and have two dumb questions for anyone who could help.

1. Will an external recorder allow you to bypass the 30 min recording time? (Or does the camera have to be recording for the external recorder to be recording?)

2. Will MKIII + external recorder be able to meet specs for BBC broadcast? Will the external recorder likely get you around BBC bitrate requirements?
 
1. Will an external recorder allow you to bypass the 30 min recording time? (Or does the camera have to be recording for the external recorder to be recording?)

Yes, an external recorder will allow you to record for as long as your media allows. Some even have dual media slots, meaning you can keep swapping until the end of time (or the power goes out, whichever comes first.)

2. Will MKIII + external recorder be able to meet specs for BBC broadcast? Will the external recorder likely get you around BBC bitrate requirements?

Absolutely. Pretty much all external recorders great exceed the BBC broadcast required specifications.
 
Another variable is if the LCD on the camera goes blank when the HDMI port is used. Right now, if you plug a monitor in the LCD goes blank. A canon phone rep told me expected the LCD to stay active when using an external recorder with the firmware upgrade but could not say for sure. There are a few big "ifs" right now. One would hope logic will prevail but waiting and seeing are probably the best approach.
 
Back
Top