Since ProRes has the ability to scale during playback, I wanted to share some insights on how this works and what pitfalls can arise when it happens. Apple allows ProRes scaling capabilities for one reason; it allows the user realtime playback of more layers of video, filters and effects. FCP sees that it needs additional CPU functionality so it dynamically asks for a scaled version of your original video allowing the processor to use its cycles for processing the filters and effects, rather than decompress the larger (and better quality) video file. Think of it as Dynamic Offline.
That presents a real issue for fans of the RT extreme engine, since FCP is not using all of the data available. Without rendering the sequence, the user is actually sacrificing the quality for playback, not as much an issue for monitoring as it is for those who use the RT engine to bypass the rendering process for output. Within the Kona Control panel whenever the frame buffer indicator changes to red, it is showing that Final Cut Pro is delivering less than a full raster size frame for output to your IoHD or Kona card.
We mention “Bit Depth” here as it refers to the potential accuracy of color reproduction. The number of levels of gray that can be faithfully reproduced determines what we call the default “Bit” or Color depth. 8bit color depth is by far the most common in use today, with cable and satellite transmissions as well as all Mpeg encodings, as are all in-camera videotape formats. However, when not handled correctly, the 256 levels of gray can create problems often appearing as banding or artifacts during playback.
Working within a 10bit space offers users wider latitude when doing effects, color correction or image processing due to the much larger 1024 levels of gray per channel. Having more information allows the image processing to use as much of the available color space as needed when applying color correction, converting or especially when compressing the image back down to 8bits for delivery.
One of the biggest issues in most post facilities is maintaining quality all the way through to delivery whether the content is used over the air or not. The camera native codecs are truly amazing for their ability to capture light as RGB data in a quality form. However, that “native” data was only meant to work within the manufacturers proprietary hardware and custom designed software in specific cameras. That we can edit these files at all is truly amazing. Prior to the firewire revolution the number of people that ever saw a camera’s native compression schema were very, very few.
While an uncompressed workflow’s higher quality and ease-of-use often win the debate for many users, the hardware requirements for a multi-user uncompressed HD environment are financially or technologically prohibitive to the majority of users. Knowledge of fibre connectivity, switching, compression packets, drive throughput, sustained data rates and image compression is now a necessity. Few if any, understand the requirements for sustained storage capable of delivering in excess of 200 MB per-second, per user, to allow them to work efficiently and effectively in uncompressed HD. With that in mind it is easy to see the need for a viable, cost effective solution for working in 10bit HD from Apple is long overdue.
I had resigned myself to using only uncompressed workflows for all HD mastering and relying on DVCProHD as my “offline” format. With the advent of a truly professional intermediate codec like ProRes, in association with tools such as AJA’s IoHD, I have given up my reliance on uncompressed workflows and have begun utilizing only ProRes workflows. It is my belief that ProRes is one of the last pieces of the puzzle allowing Apple to take its place at the head of the line in current and future NLE production tools.
While the HDV format offers Final Cut Pro users cost effective ways to enter the HD editing, the low cost of these tools belay the plethora of issues involved with natively editing HDV content on a Mac. Whether users capture HDV direct into ProRes or work with software converted files, ProRes allows welcome relief from the Long-GOP mpeg editing issue, offering HDV users full I-frame editing, RT extreme acceleration, true 10bit capabilities and a reprieve from the endless rendering needed for playback while still allowing users the use of tools they are accustomed to working with. A HDV to ProRes workflow offers users of these low cost cameras to edit projects with the ease and convenience that they shot them.
While a number of companies claim they have hardware support for capture into the ProRes codec, AJA has exclusivity with the IoHD, designed in cooperation with Apple, just as the original Io product line was, and no other manufacturer can produce ProRes-specific hardware based capture acceleration because of the cooperation that Apple and AJA have together with this product line.
Manufacturers other than AJA claiming ProRes hardware support are only handling that compression via the host computer’s CPU, robbing precious processing cycles to encode in this mathematically intensive task. While the IoHD can handle its HD captures on virtually any MacBook Pro or MacPro running on an Intel processor.
FYI, ProRes is available on Windows, albeit in read only format - so if you capture on Mac, it can be read on Windows, you just can’t write to the ProRes codec/s from Windows. But it does open up some workflows, especially for compositing etc. of backgrounds, reference material, etc.
-mike
PS - AFAIK, ProRes is DCT not wavelet
Posted by Mike Curtis on 03/08 at 07:01 PM
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
