Apple’s ProRes codec finally allows Final Cut Pro to be the useful and viable alternative to what was a painfully laborious process of editing uncompressed HD on a Mac. Whether your content is captured live from camera, mastered from existing tape or converted in software from any of the existing media formats, ProRes is something you should seriously look at. This is especially true for anyone looking to create and maintain the highest quality imagery throughout the production process. ProRes was not intended to replace the camera native codecs we use daily but to extend the post process into the future. With ProRes’s relatively low bandwidth requirements for playback, modest needs for file storage and extensive capabilities within the RT Extreme architecture for both quality, performance and incredibly high quality playback. Apple has finally shown the postproduction world there is more within Pro Apps than just hype. Final Cut Pro Users will understand that uncompressed HD quality has arrived in a compressed space with the release of ProRes and that leaves the once vaunted DVCProHD workflow for Final Cut Pro floundering in an 8bit quandary of banded skies and broken graphic dreams.
The original files for this test were assembled from camera original materials in an Adobe After Effects project and delivered as video, additional text and gradients elements within the AE project were all processed for testing as 10bit uncompressed 4:2:2 1920 x 1080 23.98 Psf output via an AJA Kona 3 card (driver v5.2). This master uncompressed 10bit 4:2:2 YUV file was first laid off to HDCamSR tape, then the output was captured via a single link HDSDI to an AJA IoHD and Kona Desktop setups for testing.
The camera comparison was captured with the laptop IoHD configuration, simultaneously recording to P2 and via baseband component out using a Panasonic HVX 200 and simultaneously recording to SxS cards and baseband via the HDSDI out of the Sony EX1 Live capture was done direct into both the 720 and 1080 formats, due to the nature of the recording characteristics of both cameras the duplicate frame extraction for the live files were done in post to achieve to progressive frames from the interlaced output.
All Trademarks, service mark and registered copyrights included or mentioned in this article are used regard and within the rights of the individually registered owners. Use here does not constitute an endorsement for products or services.
To Leader Instruments and Tektronix USA for the waveform and vector scopes, AJA Video Systems and Fletcher Camera Chicago for hardware and technical support, Sonnet Technologies and Dulce Systems for storage, and most of all to John Ladle at HDSales for keeping my nose to the grindstone.
Phenomenal overview.
I suspected something was up with (HQ) when my MacBook seemed to work harder with the “less compressed” footage than with ProRes. Thanks for uncovering and confirming this effect.
Your testing of concatenation errors also gives me more confidence in using ProRes for our PBS series.
Posted by IEBA on 03/10 at 08:08 AM
Now if you could _write_ ProRes on a PC (like in Premiere) then there’d be a whole lot more use!
Posted by IEBA on 03/10 at 08:50 AM
Mr Smith
Sorry for the delay in my reply.
While I was in LA for HDExpo, I met with David Taylor, head of Cineform and working towards testing all of the 10bit compressed codecs after NAB, I am planning on taking a look at Sheer, AVC-I and Cineform as part of this test.
I am also hoping that a couple of the things coming at NAB will also be available cross platform as requested.
IEBA- thank you, very kind words indeed.
gary
Posted by .(JavaScript must be enabled to view this email address) on 03/16 at 10:08 AM
Great article Gary.
The issue you raised (below) about standard vs. HQ ProRes 422 is interesting. The standard seemed better after conversion, but what about after being manipulated in Color?
Once it is manipulated in 10 bit color space wouldn’t that change everything based on your theory that it’s left in 8-bit space after conversion? That is to say, once you make one adjustment in 10-bit space aren’t you now dealing with a 10-bit image and if so, how do the two versions of the codec compare after that?
from the article:
My testing found that when the camera native codecs (DVCPROHD, HDV or SxS) were converted to ProRes in software they universally ran better when using the Standard version of ProRes rather than choosing the HQ version.
Posted by .(JavaScript must be enabled to view this email address) on 10/08 at 12:13 PM
What a great article.
Answered almost every question I’ve had about ProRes. Just one requested clarification. When mentioning software conversion options (with caveats), did you mean for example, HDV material captured to disc via the QT HDV codec that is then transcoded (exported) to non HQ ProRes422? Would that be an reasonable compromise alternative to a direct hardware-based capture/conversion?
The reason I ask is that I currently lack the budget for a hardware capture/conversion solution so it would be great to use the old-fashioned HDV capture approach for the time being.
Thanks
Posted by .(JavaScript must be enabled to view this email address) on 10/30 at 05:14 PM
Sorry people- I have been working on the Update for this article and not had a chance to responds
Kaaf2009 goes first.
The standard seemed better after conversion, but what about after being manipulated in Color?
Once it is manipulated in 10 bit color space wouldn’t that change everything based on your theory that it’s left in 8-bit space after conversion?
Once the conversion happens the file is now 10 bit, so the pass thru Color does not change anything, other than to completely render out the file with all 1024 levels.
The entire point of rendering to ProRes standard was reduce the strain on your CPU when handling the file during Output. Once the files have been re-rendered by Color- the file will actually playback even smoother since your computer will no longer be compensating for the 8bit file in a 10bit container, but be a full 10bit via the render in Color- easing the load on the CPU even more.
Make sense?
Posted by .(JavaScript must be enabled to view this email address) on 11/02 at 08:21 AM
Dan.
I am try to wrap my head around your statement
When mentioning software conversion options (with caveats), did you mean for example, HDV material captured to disc via the QT HDV codec that is then transcoded (exported) to non HQ ProRes422?
Software conversion is just that, any conversion done from any native camera codec ( HDV, AVC, EX AVCHD or DVCProHD) where the camera generated as a file format on a card or transferred via FW or USB and then is converted to ProRes using any software application( FCP, Compressor, QT player)
I do not recommend conversion to another Apple codec prior to the conversion to ProRes.
does this answer the question?
Posted by .(JavaScript must be enabled to view this email address) on 11/02 at 08:29 AM
I think I do understand now. When you said “ran better” below, you’re not referring to the image quality. You just mean it was less taxing on the CPU to playback right?
I’ve run across some articles which gave the impression that ProRes 145 actually produces better image quality (coming from HDV) than the HQ version. Maybe they were all just referring to performance and not image quality.
When mixing formats one obviously wants to choose
the best codec they can handle (presumably HQ), but these reports of HQ having trouble with HDV
gave me pause.
from the article:
My testing found that when the camera native codecs (DVCPROHD, HDV or SxS) were converted to ProRes in software they universally ran better when using the Standard version of ProRes rather than choosing the HQ version.
Posted by .(JavaScript must be enabled to view this email address) on 11/02 at 11:23 AM
When you said “ran better” below, you’re not referring to the image quality. You just mean it was less taxing on the CPU to playback right?
Yes, “run” would indicate something regarding performance, not the image “look” or “quality”.
I’ve run across some articles which gave the impression that ProRes 145 actually produces better image quality (coming from HDV) than the HQ version. Maybe they were all just referring to performance and not image quality.
No codec will make your content look better, in the case of HDV if you are talking about converting content AFTER it was captured, the original file is 8 bit with a 4:2:0 color space. Working in ProRes will allow any thing done in post to maintain quality without additional loss of color or detail.
Working in ProRes will allow you to work faster in Final Cut, at higher quality, with little or no additional lost of detail or color.
Users IMHO have nothing to gain from a software conversion from a highly compressed compressed camera codec to ProRes HQ, especially when the Standard version works just as well with that type of file as the HQ version does without the need for ±50% more CPU power to handle the same file.
The issue has to do with how much processing is done. ProRes has to be compressed then decompressed for playback. It is that CPU heavy processing required during decompression of the HQ format from files that originated as 8bit being processed during playback that people are referring to.
Posted by .(JavaScript must be enabled to view this email address) on 11/04 at 08:21 AM
Mr. Adcock,
Your latest post on this subject does not make any sense to me and seems to contradict the thrust of your article.
There certainly is a big benefit in transcoding to ProRes or - more so - from AVCHD to ProRes, because of AVCHD’s comparatively heavier compression.
ProRes completely transcodes a long-GOP source, taxing on all but the fastest systems due to costant de-compression/re-compression, to a CODEC that is far easier to edit on a given system.
Transcoding also converts an 8 bit source to 10 bit, conferring a big advantages in post by expanding the color space. We are referring to “I/O precision” and a 10bit file can be withstand more compression and decompression without degrading as much, especially when compositing graphics, for example.
It’s been quite a while since I read your article but I believe that you made an effective case for ProRes but perhaps not explicitely expounding on those specific points.
Your last sentence in your latest response:
“It is that CPU heavy processing required during decompression of the HQ format from files that originated as 8bit being processed during playback that people are referring to.”
This is not correct. A prime purpose of transcoding a file to ProRes is to make it easier to edit. Once transcoded it is easier to playback (and edit) and is, in fact a completely separate file and doesn’t care if the original file has been dumped into the void. After post you can then take the ProRes file and transcode to some other file for delivery, including back to HDV or AVCHD, with no discernable quality hit.
Personally, I don’t use ProRes but I do use use Cineform and I understand fully how it and why it works and I know that ProRes works on the same underlying principles.
Posted by wsmith on 11/04 at 09:57 AM
