We found another huge quicktime bug in AFX CS5 the other day ... A large prores 444 hq quicktime file that we were splitting (12100 x 1920) opened and rendered out completely wrong (some bizarre internal re-tiling of the image) on 60% of our machines (mac pros / 10.6.4 / 16 gb ram / etc). And unfortunately this happened first on the machines we were using to produce the deliverables. Total nightmare. I'll post this elsewhere under its own heading after doing a bit more testing, but the first thing I tried was using AFX CS3. Worked perfectly. CS5 is not a reliable production tool when used with quicktime, full stop.
Yeah - there are certain bugs taht are annoying and there are others that completely disrupt workflow. Unfortunately this is the worse of the two. Troubleshooting a flub like this in the 11th hour of our projects is a major bummer, to say the least.. Something which we expect to avoid when we pay large sums of money for adobe software.
If you have the ability to connect to a network Server over NFS you will not have this issue. I have had this problem for a long time with both Shake and Nuke. Not sure what is different about NFS but there is no limitation on file size. I just tested CS 5 and Nuke and both fail when connecting to our server over SMB, but when connecting over NFS everything works fine.
Shame on Apple and Quicktime. Quicktime is my worst nightmare in our environment and trying to manage all of it's flaws in a professional environment is such a waste of time
Did this get fixed in 5.5? Please say yes! This is driving me crazy.
And yes, Adobe isn't alone in this, I've been complaining about this buggy QuickTime API from Apple over a year now. REDCine-X has the same limitation/bug for the same reason:
Wow ... double fail. Unbelievable.
Thanks PK for notifying us of those results. We weren't planning on stampeding to the 5.5 upgrade anyway (imho, having to pay for a dot upgrade is a bit of a kick in the teeth when the initial offering is still so buggy) ... but I was really hoping OSX10.7 + CS5.5 would have solved this. Maybe final release of 10.7 will be different? One can only hope the feuding giants eventually get over their civil war and back to their job of making our lives easier ...
> One can only hope the feuding giants eventually get over their civil war and back to their job of making our lives easier ...
We're not feuding. We're working together on this. I can't share the details of our communication, but the communication is there, and it's not a feud.
Regarding this being supposedly easy to fix becuase it worked before:
After Effects CS4 used an old QuickTime API. After Effects CS5 can't use the old API because it doesn't work with 64-bit values and doesn't provide some crucial features. Apple told us to use a new API, so we did. It has a bug. Apple has acknowledged that bug. They are working on a fix. We hope that it comes soon. If you do, too, then ask Apple to hurry. We certainly are.
Not to start anything but I was at NAB and had a few goals in mind.
One was to talk to someone from Adobe about this.
Well after a few demo jockeys (actually not even just the ones working on the perimieter), none of them have heard of this problem.
Funny there must have been an invsible force-field of something cause all surrounding vendors around the Adobe booth seems to know about the ugly thruth.
I for one am skipping our enterprise upgrade to 5.5.
Thanks for the response. I hope you can understand why there would be such incredulous frustration at the amount of time it's taking to fix an essential pipeline aspect of this software. I posted something on an Apple QT thread ages ago and never heard anything back at all, so its good to at least get an update.
> I was at NAB and had a few goals in mind.
One was to talk to someone from Adobe about this.
Next time, ask for me by name. I was there every afternoon waiting to answer just such questions. In fact, one other person did ask about it then.
Todd, you at least have to undestand where we're all coming from here. It's obvious this is an Apple QT API issue. No-one is debating you on that. It's also obvious, though, that Adobe used this brand new API without enough testing and charged people a **** load of money for the software that had a glaring workflow bug.
What really peeves me is that the thread was first responded to with a "submit a feature request" and that's just pure lazy - and downright insulting. After the initial responses here from Adobe it's difficult to have patience in this situation.
I would personally be embarrassed to sell a professional grade software suite without testing something as common as this. I hope it get's fixed "soon" as I (and assume many many others) have had to modify our workflows / buy extra gear to work around this "feature" or lack there-of.
>>> I was at NAB and had a few goals in mind.
>> One was to talk to someone from Adobe about this.
Next time, ask for me by name. I was there every afternoon waiting to answer
just such questions. In fact, one other person did ask about it then.
That person would be me. Here is some advice. Apple's ability (or inability)
to prioritize is very broken. In my 26 years of experience dealing with
Apple, especially during the Steve Jobs years, the best way to get a bug
fixed is by public embarrassment. Once Apple is embarrassed, then and only
then will a lingering issue get put to the top of the pile.
Thus, my specific suggestion would include having everyone here do all of
post this issue on Apple's discussion board under the QuickTime section.
Everyone should post to the same issue to make it get traction.
submit this issue to macfixit.com
submit this issue to macintouch.com
pick a writer at cnet, let's say
In your submissions, make it clear that this is a QuickTime bug and Apple
has known about it since at least September 2009 and is not running to fix
it. Apparently, they are too busy answering government privacy inquiries.
And look how quick that got fixed.
Todd, on your end, you still have dirt on your hands. Here is what Adobe can
and should do...
Where is the darn tech note so that other people don't have to chase their
tail or waste time combing through the forums?
Why isn't this issue listed in the release notes or in this document?
Let's assume Apple is not going to fix this since QuickTime is essentially
deprecated. In Lion, is there a new API under AV Foundation that fills the
void? If not, the AE team might want to create a way to buffer the file to a
local drive and then copy it to the network path. Relying on Apple to fix
this bug in a timely manner isn't working out.
+9000 points to Digital Desktop for extremely logical points. Specially the public tech note by adobe so more people aren't pulling thier hair out wondering why thier files are corrupt every time the render says "complete"
Good points, Digital Desktop (Jeff?).
I'll get such a document created. You're right that that would make it easier for people to find the information. I'll confess that my thought has been along the lines of "Oh, this is going to be fixed really soon, so it's not a high-priority tech note", and clearly I've been wrong about that.
It's a busy day today, so I'll get something up by EOD Monday. Deal?
Well I'm one of those people who's been pulling my hair out and I JUST found this thread. I'm happy to have found the cause but CANNOT believe that this bug has existed for over half a year with no end in sight. How could this not have been seen in Beta testing? Creating quicktimes over 2.15 GB's that get saved to an OS X network drive must happen thousands of times a day with all the companies out there using After FX in a OS X collaborative environment. At least there's a work-around but man... what a disappointment.
I've pretty much had it with Apple too... serious WTF with them. Second biggest company in the world and their Pro users are treated like crap. Sure cancel the Xserve.. then make the ones we still have useless with your stupid Quicktime bugs... why not just be honest with us and drop your Pro machines, software and support completely so we can all just move on. This half-assed effort on their part sucks. My next machine will be a PC (with a graphics card that isn't 3 years old!)
I feel really sorry for you, Greg. I was in your exact same postion a few months ago on a HUGE deadline for Levi's and I worried myself sick all night trying to figure out why I couldn't render a lossless file
Thanks for recognizing this as worthy of a technote (or "feature request" or "hey this thing doesnt work right" or whatever). In my opinion, taking the high-road on these things from the beginning will help reduce the angry mob that tends to build when situations like this aren't taken very seriously during initial discovery.
I saddens me that there are people out there, like Greg, who are likley on deadlines wondering why they can't deliver. There are probably thousands of these people out there - and liekly have no idea that there is a real problem here.
I'll pour one out to all those who have yet to find this thread...
And when you do find it - just...go render your project to local disk. Todd has heard enough complaining here.
> In my opinion, taking the high-road on these things from the beginning
will help reduce the angry mob that tends to build when situations like
this aren't taken very seriously during initial discovery.
Sorry if it wasn't clear from the beginning that we were taking this seriously. When I ask people to submit a feature request or a bug report, it isn't a brush-off. That's actually the best way to officially register your wishes and feedback. That's the point of this post.
The feature requests all get read by the guy across the hall from me, and I am the one who reads all of the bug reports. When we get one of these, it's very common for us to walk next door (to the engineering manger's office) and make sure that he understands how many of a certain report we're seeing.
In this specific case, the bug reports and feature requests that we got around this issue are what we were able to use in our conversation with Apple to show how large a problem this bug is. They don't want to know about how many forum posts we're seeing; they want to know how many bug reports we're getting.
Sorry for the rambling answer, but I just wanted to give some idea that we take bug reports and feature requests very seriously, and a response on this forum pointing you toward submitting these is in fact a sign that we care---not the opposite.
Haha Im not sure if Adobe actually takes down my crash reports
During the CS4 debacle (early days), I had an average of 20 crashes per day.
Each crash was met with the "report to Adobe" window.
I put email in there and sent out each time.
After a few months of this, I started sending nasty emails to see if I would at least get a message from Adobe whether its legal or not
Nope no one got back to me.
Eventually CS4 got better and things were fine again.
But that took almost a year
Now with CS5 a whole new crop of messes to deal with.
Anyhoo the only fix I see is converting is to not use Apples AFP file system.
Im good here since most of my files are rendered straight to MainConcepts MPEG Encoder.
For Uncompressed, render to frames then use CS4 to convert to big QT files.
I cant imagine the folks that have to render to large formats
Thanks for the transparency you have been able to communicate about this issue to date.
You wrote that Adobe can't go back and use the older API because it will not work in 64-bit and also doesn't provide some crutial features. Would it be possible to run with a patch that allows users to boot up in 32-bit mode and work with out a few features to circumvent this bug? What features specifically use the newer QT API?
Also, I think the only question the end users haven't seen a direct answer to on this forum is at what point did Adobe and Apple realize this API had a big workflow bug in it; was this discovered pre-release of CS5 or after?
Hi Todd - I've read the entire thread and I think you've done a good job communicating here (and keeping it professional). I beta test myself and know it's a grind. I think posting a notice about the bug publicaly is a good idea (perhaps in a readme faq or something as well when you install). Feel free to thrust blame on Apple - maybe that will shame them into action. It's a pretty big deal though - my editors have been asking me what the deal is...that movies weren't saving correctly. People have wasted a lot of time (when I posted last night it was 2:00 in the morning because I had just babysat a giant render only to see that it wrote out a file ending in 2.15 GB to my Xserve project server). I just finally noticed last night that they all stopped at 2.15 GB and of course figured 'oh great - now I have to delve into Snow Leopard server to figure out what's wrong here'... it never would have occured to me it was a QT bug.
Thanks for clearign things up, Todd.
I don't doubt that you take your job very seriously - and your transparency is valuable. I realise you care.
I think I worded my response to you poorly. When I say take the high-road in this situation, what I mean is that even if the bug is thought to be fixed within weeks of CS5's launch, and Adobe is aware of such flaw, it should immediately be made public knowledge. If even to save a handful of users extreme frustration (more than a handful in this case). My biggest problem here is that Adobe was aware of this far before I was dealing with the issue and yet it was still very difficult for me (and others spoken here) to find this specific thread on the forums.
Not to mention that since this bug is seeming to be entirely out of Adobe's control (apples API) - that you would specially want to make a big fuss about it in a tech doc or otherwise - so the mob knows we have to wait on a third party for a fix.
Perhaps a rapidly updating (like, real time) known issues system that users can easily discover when they are having problems could be extremely helpful for everyone (even you and the guy across the hall from you). (edit: maybe something like this exists and I just can't find it?)
In any right, I appreciate your responses and transparency.
It's extra sad that Adobe is already touting, and selling mind you, a new release (.5) before getting this bug fixed.
And as far as I can tell - this flaw is not listed in the release notes for the .5 update either. Shame, shame...
I've created a new discussion in Apple's Support Forums about this issue. Any existing discussions I found were archived, hence the new one.
I strongly suggest you post your own thoughts to the thread if you wish to get Apple to address the issue.
> It's a busy day today, so I'll get something up by EOD Monday.
Let me revise that to "I'll have something written by EOD Monday, but I need to wait until Tuesday for the relevant engineer to double-check for accuracy."
Here's a public and easy-to-find statement of the issue:
> Your post says that SMB works. Can you confirm this? I have found that both SMB and AFP Experience this issue.
According to the engineering manager, SMB is the workaround that Apple recommended. But, if it's not working for you, we need to know that. Can you try again and confirm?
I'll get someone to look at this post and confirm from our side that SMB works.
I have done a whole lot of testing on this issue. I have this problem
across both Shake and Nuke in our facility. Both AFP and SMB have
this problem. Did you test SMB and confirm that it works? The only
protocol that works for me is NFS. I have tried this both on our
XServe Server and Isilon Cluster. Mounting either Server over SMB I
can not render a quicktime over the 2.15GB Limit with either After
Effects CS5, Shake, or Nuke.
Here's a public and easy-to-find statement of the issue:
Thanks, Todd, for listening to user feedback and acting quickly to get the info out.
And since your post - I can already feel the anit-adobe-ism withering away.
Digital Desktop wrote:
Apparently, Apple has a real good handle on this and they are running as
fast as they can to fix this... NOT!
This is all still quite an abomination for Apple. I can hardly imagine the issues they'll have when they release FCPX with this new api and people wont be able to render movies with it...oh dear.
EDIT: Oh, but when it affects thier own product I imagine they might move "a little" faster to fix it.
Suppose we can look forward to a fix shortly after FCP X is released.