I am greatly surprised by Adobe for this misleading hype.
Many people are fully aware that uncompressed can be played and scrubbed “like butter”. There is nothing for the CPU or GPU to un-compress before displaying. One can edit uncompressed on a slow, older machine - if that video can be sent from storage to display fast enough.
Thunderbolt is indeed a breakthrough in that regard. Adobe is trying to say that this is all made possible by Thunderbolt and that is highly misleading.
Yes, Thunderbolt is responsible for pumping so much data to the processor but it’s uncompressed! Try it with highly compressed long GOP MPEG video and one will quickly see that - unless the machine is superfast and has GPU acceleration of Mercury, etc. etc. things won’t be so fast.
Maybe this Adobe guy isn’t aware of this fact. In that case I’d hope that the people responsible for presenting such info here on this site would understand that and mitigate against fostering such misbegotten notions.
Now, having pointed all of this out, I have a question for people here: Does the Mercury Playback engine (which is a new processing pipeline) even need to touch the video if it’s uncompressed? If the video doesn’t need to processed before playback, then Mercury doesn’t need to process it - except for effects and transitions.
Indeed the video here shows some effect being thrown on and it’s done blazingly fast. But was that Thunderbolt? NO, because Thunderbolt is strictly an I/O technology, not a processing technology. Is the demonstrator trying to say Thunderbolt sped up the processing of the effect?
Let’s get real.
Posted by wsmith on 04/18 at 12:23 PM
The main point of the demo is to show the 64 Mercury playback (CPU mode, not GPU/Cuda mode). Without a clean 64 bit playback engine (we use Grand Central Dispatch on OSX) , you can’t get this type of performance.
Remember that Mercury Playback has 2 modes: Software CPU (what you see in the demo - the red line means CPU processing) and Hardware GPU/Cuda mode (yellow line) .
GPU/CUDA only kicks in if you have effects that use it, like scale, motion, position, color correction and many more. The heavy lifting that is being done in this demo is handled by the 64 bit Mercury software (CPU) engine and Thunderbolt I/O.
BTW - 4K DPX playback in Full quality is no easy task.
I should also mention here, that in our labs we have several larger raids with 8, 10, and 12 drive systems that do not perform this well. Thunderbolt opens a whole new workflow.
It’s the 2 years of hard work between Adobe and Intel that made this possible . Not just Adobe…
DKH
Posted by dhelmly aka DavTechTable on 04/18 at 01:37 PM
I think what probably isn’t clear enough in this video is that Thunderbolt makes doing what you are seeing there possible on a laptop.
The reality is, the speeds you can get with thunderbolt enabled drives were only really possible with e-sata in the past (and it was cumbersome).
Being able to seamlessly playback and edit uncompressed footage in the field is a real game changer for folks like me. We shoot tons of greenscreen and fx plates… where compressed footage just won’t do. The holy grail for us has been the dream of doing this on set… this is the first time it’s been really practical.
Also, I may be mistaken but… the Mercury Engine does more than just the effects. It hands scaling and printing to screen… which, in realtime, is not trivial. You only “not touching” the pixels when you are looking at the video 1 to 1 with nothing over top.
We put an all-stop on buying CPUs until we see Thunderbolt installed on them… it’s that important to our pipeline. It’s probably the most exciting hardware added to the Mac, for me, since… the mouse.
You may think this is hyperbole but remember… you are looking at uncompressed footage being captured and stored in the same chain. That’s a lot of data. Folks like me have been wrestling with 150MB/sec footage for 5 years on tiny pipes. This really changes everything.
a
Posted by Alex Lindsay on 04/18 at 01:40 PM
I see; thanks for your insights. I’ll try to respond to both Mssrs. Helmly and Lindsay in my rejoinder.
I’d very much like to see this all done again with H.264 video. I firmly believe that the results would be different even with Thunderbolt. Inasmuch as uncompressed workflows are still relatively quite rare (as far as I know) testing with H.264 would be a far more credible and useful test.
BMD has been touting uncompressed workflows for quite a while now, going back to 32bit Win XP and CS3 and eSATA-connected RAID 0 arrays. Apparently 64bit was never required for that.
I’m puzzled about the DPX portion of the demo in that the BMD device - which looks like a pre-release prototype of the UltraStudio 3D - doesn’t support 4K. I assume that if the DPX in the Promise RAID box is indeed 4K, it is being scaled down to 2K, in realtime, by the BMD box and not Mercury.
Isn’t any scaling that one might require handled by BMD devices by internal BMD hardware?
I have real doubts re the statement: “The heavy lifting that is being done in this demo is handled by the 64 bit Mercury software (CPU) engine and Thunderbolt I/O.”
From what I gather, other than little bit of effects used on the demo timeline, Mercury really didn’t have to be involved at all and wasn’t.
Thunderbolt is definitely welcome but other I/O technologies could have managed the same required sustained throughput.
Let’s see another test with the same hardware setup, file parameters, and H.264 video, please.
Thanks
Posted by wsmith on 04/19 at 03:58 PM
I guess I would say… from a professional production perspective, H.264 is a delivery mechanism, not part of the editing workflow. This may not handle the needs of the Prosumer… but NAB is, for the most part, a pro show. If we spent much time talking about h.264 editing workflows, the pro’s would have same reaction you are having to uncompressed. We might get someone at PVC to do an H264 workflow… I know, personally, I don’t touch it before export to the web. If I get it on ingest, I just upgrade it to real working format.
And… with Thunderbolt, there is less and less reason for highly compressed workflows. Sure, there are other technologies that achieve large bandwidth throughput… but USB3 saturates at half the Thunderbolt bandwidth and USB is more processor intensive. ExpressCards only look like a good idea when you don’t use them often. eSata is cumbersome and, on the Mac, not really supported.
With eSata RAID 0’s we were pretty excited about 300 MB/sec. I was looking arrays that allowed for twice that speed with redundancy (0+1) AND camera input… to a laptop. You can’t really do that with the other options.
Devices can only handle the scaling if they are in the pipeline. The Mercury engine works independently of this.
a
Posted by Alex Lindsay on 04/19 at 04:14 PM
wsmith,
Sorry for the confusion, - The 64bit Mercury Software Engine is used for 100% of the playback, H264, RED, and all other codecs when using Premiere Pro CS5 & 5.5.
If you go back to Premiere CS4 (32bit) , yes you could playback a few layers of uncompressed video with a 8-12 drive raid array that heated up your editing bay, required driver updates, and made so much noise you could hardly hear yourself think, but it never ran as smooth as this Thunderbolt Raid unit does. The difference is very noticeable. We have several large Raid Arrays here in our test labs and use them everyday and can’t wait to replace them with Thunderbolt units.
We had a ton of people using large drive arrays commenting on the same thing, heat , noise, over all speed, simplicity and cost. For the entire show the Promise Raid never got hot. It ran all day every day from 9am to 6pm without fail.
You are correct that Thunderbolt is completely I/O. We never claimed it accelerated anything but delivering frames to Premiere and AfterEffects. The demo shows that both of these 64 bit apps can handle these frames as fast as the drive can shell it out (800-900 MB/s). The 32 bit app with it’s limitation of 2GB of ram would start to get “sticky” after you scrub back and forth several times. That’s the demo….
The 4K DPX files we added to the NAB demo after we had countless people asking to see 4K playback so we exported a RED file as DPX and re-imported and created a quick timeline. It was pretty impressive.The whole purpose of this demo pod at NAB was to give customers a chance to “test drive” Thunderbolt in anyway they wanted. We had the only booth that allowed you to experience it. People left that demo pod looking for a place to order one.
Sorry you feel it’s hype - We had a lot of great responses from people who kept bringing friends and co-workers back to see it. People who do this for a living totally got it - no hype here…
H264 is a great format for quick DSLR (Canon 5D) Native edits and as many people have come to know, Premiere Pro CS5 is quite good at editing it. The issue with DSLR is more CPU related for decoding. The more CPU power (not GPU) you have the better H264 editing experience you’ll get - plain and simple.
H264 runs about 4.8MB/s vs the Uncompressed 158MB/s we were showing in the demo. Thunderbolt would act no different on 5600RPM slow drive when running h264 - again, it’s only 4.8 MB/s , not much data throughput needed- Now backing up large H264 projects would be a different story. Thunderbolt changes everything in the way we handle our projects.
The demo was never meant to say that Thunderbolt helps decode H264 or any other codec - it just gets us the best IO performance for least amount of money.
I hope this helps position it a bit better.
Posted by dhelmly aka DavTechTable on 04/19 at 04:45 PM
Mssrs. Helmley and Lyndsay,
Thanks for both of you for taking the time to discuss this with me. I agree Thunderbolt is a great thing and I welcome it as a superior I/O technology. I just felt/fee that the demo was perhaps conflating its performances gains with the processing of the video.
I understand the difference between pro and prosumer editing CODECS. Personally, I’ve had great success working with I-Frame and also Cineform (my favorite).
I’m currently at a crossroads. Do I build a new liquid-cooled Wintel box to house my uprgade to CS5 or do I finally decide to Buy a Mac and adopt the new FCP? (supposing it’s any good, comparatively).
But before I can make that decision, I’m most keenly interested in seeing a demo of how good this new Mercury Engine really is. By that I mean at utilizing Premiere’s multi-cam editing function. I’ve heard about how well Mercury handles that - even, if these tales are to be believed - with 4 simultaneous 4K RED streams! (for that I’m sure Thunderbolt will come in quite handy.
What I’d really like to see with my own eyes is 4 simultaneous 4K streams in multi-cam mode. I know that since I’m on Windows, those streams would have to be uncompressed. That’s because I know that Adobe refused to open, for whatever reason, that portion of its API and SDK to Cineform so they could make it happen. I got that directly from David Taylor at Cineform.
So, Mr Helmly, please show us this demo with 4, 4K RED streams. And I’d really rather not see the demo in uncompressed. I mean how many people have that kind of redundant storage??? Let’s see the demo in some pro editing CODEC and under Windows. I suspect that the Grand Central Station code optimizing is a factor on the Mac demo we saw.
I have spoken to Adobe re multi-cam on 4,4K streams and the people there in the “labs” were rather tight-lipped and said I’d just have to stay tuned for NAB. That was last year. This year we see your demo, after which I felt a mix of ho-hum: it’s uncompressed, and feeling that Thunderbolt was being over-hyped as being partly responsible.
Is there one video demo anywhere on the web that does show me that?
And back to Cineform for a minute: Obviously we Wintel users need an answer to ProRes. We need everything it offers like cutting thru massive files like butter, easy editing RAW with metadata, etc., etc. and that Premiere or After Effects doesn’t offer.
Thanks and sorry to be such a tough customer.
Posted by wsmith on 04/19 at 07:29 PM
wsmith,
Some answers to questions:
I also work with Cineform quite a bit and know the CEO & company quite well as we are in regular communication- Sometimes weekly.
4K native RED files are much easier to use in Multicam than 4 1920x1080 H264 files. The key to 4K RED is setting your Program monitor to Playback Resolution that your system can handle. Anyone needing 4K at Full res has the option of using multiple RED Rockets. Our Multicam does it’s best to scale down to resolution that will keep things playing in RT. We have a ton of suggestions on ways to improve our current Multicam setup. Stay tuned..
I’ve got several videos already in the queue for AdobeTV but will add your request to the list or assign someone from my team to do it. First, I’d suggest asking people on the RED forum about 4K multicam to get info first hand from real RED users. Look Obin Olsen as he knows the RED Adobe workflow inside out.
We did team up with RED and do additional work on RED playback in 5.5 - As I mentioned before, Premiere Pro 5.5 is now free for 30 days with codecs active for the trial period (starting May 3rd 2011) No risk, just try it yourself…
Hardware:
I have a few liquid cooled machines here and see no real benefit to the extra cost. You want a system that keeps not only the processors cool, but the inside of the unit cool as well. GPU and Rocket cards get pretty hot. On Win7 64, the HP Z800 is what we use as our high-end Win7 machine. It’s rock solid and a well designed machine and easy to configure. For mac people, it’s the closest thing to a MacPro if you need a Windows machine. HP did a great design job on the Z800.
We also use a ton of macs here as well. Our cross platform goal is to make the mac products as equal as Win 7 64 possible. Win 7 64 has a slight speed advantage as NVIDIA controls the updates of their video driver whereas Apple controls the OSX video driver which is just a subset of the NVIDIA & ATI driver (a unified driver). Grand Central Dispatch is in full use on the Mac and we have equivalent multi core/threading on Win 7 64. Anyone using Premiere or AE can see that we hit all threads and cores when needed.
If you are good at building your own “White box” then just use any dual Quadcore or Six Core processor (go for more cores over processor speed/Ghz) , 12 or 24 GB RAM for video suite workflow, NVIDIA 4000, 5000, or 6000 card. For most people, the 4000 card or even a Geforce 580 card will work fine. The higher-end cards will be faster for more creative workflow (layering) and offer AfterEffects more video RAM for preview. Yes, we will use all threads on the CPU and GPU.
Look here for more info: http://tv.adobe.com/show/davtechtable/
DI Codecs:
Yes, we all need an answer to Apple ProRes and the logical one would be for Apple to just release their encoder for Windows and help set a new standard. It’s already earned a great reputation. Its clear Apple has no interest in cross platform encoding which shortsighted for an industry that relies on much of the 3D rendered output and other workflows on Windows or Linux- At least we can read the files on Win 7. The current state of Quicktime on mac or Win is whole other typic for another forum…....
We have been reviewing a number of codecs for several cycles in our labs. The main reason we have not pushed one out there yet is the constant changes in codecs and delivery methods. We have held several focus groups on this topic, including our own Cinema DNG standard - it’s a very hot topic and one we can’t rush into. H264 appears to be a clear winner for delivery. We are still hard at work reviewing DI’s and fully understand that we need one sooner rather than later. We are talking to some of the best people in the industry and taking their input on what’s needed.
Your comments about Adobe doesn’t offer RAW with meta has me puzzled. All of our native files support metadata from the file and camera hardware. We continue to enhance P2 & XDCAM metadata as well. There are some fields that don’t yet come accross. You can also add any metadata you want to any Native file. You can even setup and export a Schema to share with other users. In CS5.5 we also fully support RED RMD (RED Metadata). Cineform uses an active metadata scheme which uses an external database file which has it’s pro and cons. We prefer to embed the metadata file into the video clip so it travels with the clip. Some codecs like MPEG2 require a sidecard file which we also create. I think you need to take a closer look at what we actually do when it comes to metadata.
For the record, we have always respected the Cineform codec which why we have worked so close with them giving them support they need to make their products integrate tightly with our products. Remember that the Cineform Codec is 30 MBs which will fill up a raid in no time flat - new users need to understand that. Drive space and conversation time is a huge consideration when picking a finishing codec - it’s also why Cineform holds up in the workflow.
I’m totally confused on the 4K API “Adobe refused to support ” statement in your post and will call DT @ Cineform today to get a better understanding what he meant. I also just called the head of Premiere Pro engineering (yes, our teams talk regularly) and he’s completely unaware of any reason why a partner would think we would block 4K in anyway. CS5 was the first time we offered 4K so it may be older info with CS4 or CS3.The main issue for those versions was addressable RAM in bigger than 4GB chunks in 32 bit which is needed for a real 4K workflow.
We do have several partners offering 4K workflows. We also made a number a number of changes in 5.5 to enhance 4K editing.
For the record, Premiere Pro CS5.5 can handle 10K x 8K (10240x8192).
Remember that 4K workflow is fairly new and we see a lot of people getting excited about editing 4K that have no real idea of the workflow involved. 99% of the output is either 2K or 1080 and you really need to ask yourself, do I need 4K
There some people that will tell you that editing in 4K and scaling down to 2K or 1080 is a great workflow. But there are just as many that will tell you that it’s a waste of time and stick with 2K. Our goal is to support whatever workflow the user base wants. We run a lot of tests on export taking 4K & 2K down to all of the various outputs to insure high quality. BTW - we just added support 5K for the RED Epic at NAB.
There are also very few 4K viewing options and they are currently really expensive. We do see a lot people wanting to use 4K for creative work (pan & scan & zoom).
In the film world, 4K is gaining popularity but they also have dedicated workflow specialist that understand the 4K pipeline. We are working with a number of them already and they have helped shape much of the Premiere Pro 4K framework in 5.5. It seems both sides are learning the 4K workflow at the same time.
We don’t refuse anything that gets in the way of progress in making PremierePro and rest of the suite the “workhorse of the industry. Our hard work on Premiere Pro over the past 5 years should stand for itself. It has come a long way in my 15+ years here at Adobe.
Yes, we have more work to do and to us that’s exciting and keeps us going everyday. We’ve got a lot more planned. We are addressing more of the professional workflow issues as well as the small things that drive us all nuts.
At Adobe, we call them JDI’s “Just Do it” which means, just fix those small things that constantly get in the way of a good experience and take away from story telling. We addressed a ton of them in 5.5 and will continue to chip away at them in future versions. Keyboarding was a big one in 5.5 - completely revamped in 5.5.
I’ve also been a Premiere user for over 20 years and know every version inside out and I can tell you first hand - there is not better group of Video Engineers, Product Managers, Field teams, Software Testers, or Sr Management at Adobe or in the NLE industry. We continue to hire some of the best people in the industry, which is why many video editors & video creatives are currently looking at, adding, or switching to Adobe.
In many cases FCP & Avid users are just adding Premiere Pro to their workflow – which why we continue to support and improve our FCP & Avid workflows - “The Right Tool for the Right Job “is what we believe and in some cases it may not be Premiere Pro and we’re Ok with that. We will just work harder to improve (if possible) whatever the issue may be.
Just ask any Adobe partner and they’ll all tell you the same thing. The video group at Adobe “just gets it”.
BTW - I don’t check this forum everyday. Feel free to hit any of the the blogsite for direct questions.
DKH
North American Technical Field Manager ProVideo/Audio
http://blogs.adobe.com/davtechtable
Posted by dhelmly aka DavTechTable on 04/26 at 09:28 AM
This was an excellent discussion for many of us in the midst of grappling with the decision that the FCPX VegasSuperMeet “sneak peak” has left us with.
While the original topic was Thunderbolt I/O, it’s led into the WHOLE subject of where we currently are and are going in a few months.
From my perspective (and we are/were a FCP Studio 2 user):
1. Adobe is now far ahead with a COMPLETE stable of working 64 bit NLE, Compositing, Titling, Audio, Optical Disc, Media Encoder, Photo manipulation solutions. And they also make use of a specialized graphics card acceleration solution. Unfortunately, for whatever the reasons, Apple let their wonderful apps just languish for so long. How far along Apple is with a full working 64 bit Studio of apps is anyone’s guess - they did not see fit to release this info as of yet. I think from what Apple little info released, they are a long way from a full stable working 64bit suite - if they really are going there. We decided we’re done waiting and upgraded from our old CS3 to CS5.5.
2. Adobe is cross platform; FCP Studio is not. We are sticking with the Mac hardware and OS because it just seems more stable always - and we can cross over occasionally to Windows thru BootCamp.
3. Saw Dave’s Thunderbolt demo on a MacPro laptop and the Thunderbolt mini-raid attached. It is a great I/O advancement. Some of the above discussion seemed to be confused as to the value of what Thunderbolt will provide - it is for moving LARGE and/or MULTIPLE LARGE files from the storage drives to feed the CPU’s; think high bit rate uncompressed files layered on the timeline/comp. Thunderbolt has little to do with improvement in dealing with highly compressed files like h.264. BUT - Thunderbolt is not on the MacPro towers yet - and as usual, Apple won’t provide any timeline for doing so. So like one poster above, we’re taking one tower and experimenting with our changeover to CS5.5 and adding 10.6 (for 64 bit), 24GB ram, nVidia Quadro 4000 for the Mac, and re-install of all. We have a ProDQ 8Tb Raid which gives us pretty good large uncompressed throughput. But when Thunderbold comes to the MacTowers will look at this again.
Great discussion folks - was a big help to me at this fork in the road.
PS - Looks like Thunderbolt will help with the rat’s nest of cabling as well.
Posted by lightprismtv on 04/28 at 05:10 AM
oh - two flies in the ointment in our plans of switching back to the Adobe suite are:
1. the rumors of Microsoft purchasing Adobe and dropping cross platform support
2. the reason we original switched from Adobe to FCP ... market share - when we were collaborating on a couple of indie shorts, they were all using FCP. That is still there - market share and the number of folks still FCP’ing. So I will keep my hand in FCP for that reason. But most projects we originate will go with the Adobe suite.
Posted by lightprismtv on 04/28 at 05:20 AM
lightprismtv,
re your reservations to Premiere Pro:
1. I think Microsoft buying Adobe is highly unlikely. I have no inside info, but given Adobe’s success overall, not just in this market, I think I wouldn’t make that a hurdle to adoption.
2. What I like about Premiere is that it plays nice with any format, and input, as well as FCP and others.
Personally, I buy more for what I can get done today, less concerned about tomorrow only because every software updates regularly (except FCP it seems). I am anxious to get my hands on FCP to test it. For the videos I shot at NAB, I used Premiere.
Disclaimer, I didn’t have to pay for it as Publisher of PVC, but I already have FCP installed as well and I did pay for that. I didn’t use Premiere because they gave it to me, I used it because I wanted to.
Posted by .(JavaScript must be enabled to view this email address) on 04/28 at 05:47 PM
