I've been having some weird issues outputting prores from After Effect recently. My typical offline workflow was to output Prores422HQ or Prores4444 for offline and it has been a rock steady method for years. Recently all Prores renders from After Effects have extra garbage frames and longer duration than the source:
An example 720 frame animation with DPX source, rendered to Prores4444 will end up 724 frames when played back on the desktop or ingested into Avid/Final Cut. When this render is re-imported into AE, it is seen as having only 720 frames and fits perfectly in the original 720 frame timeline, but outside of AE it is seen as having 724 frames (QT7, Avid, Final Cut, etc).
Anyone seen this issue before??? I've started using Avid codecs instead -- which works fine -- but this issue worries me since most deliverables are Prores these days... and AE has been the best way to maintain 16-bit color in these ouputs.
*This issue started around a month ago and is on all GFX boxes in the office*
It might be helpful to mention what version of AE you're using. (11.0.3? 12.1.0? 9.0.3?)
Also, has anything (Quicktime, AE, your OS) been updated recently?
Speaking of, I'm assuming you're using a Mac, but which OS are you using?
Thank you for any help on this.
Computer: Mac Pro's 2010-2012
OS: OSX 10.9
The only thing that has really been updated in the last few months would be OS and Creative Cloud (which is up to date). I heard that the Media Encoder has a development path to suppliment reliance on the QT engine with the Mercury Engine, so I don't know if that is related/relevant or just rumors.
As I understand it, Apple changed a lot of stuff related to Quicktime in the new OS. I would look at that as the first culprit. There have been several quicktime-related threads recently, but none of the ones I've seen are similar to your issues. Hopefully someone else can pipe up with some good suggestions besides rolling back to the older OS.
It wasn't until you mentioned it, did I even start to think about the OS upgrade as the issue. Thanks for pointing me in that direction. There are some 10.8 boxes here, so I will see if I can replicate the issue, but I have a feeling that you are right about this one -- some sort of weirdness between AE and QT in 10.9.
I will post more if I find out anything new.
Thanks for checking in. This output error actually happens in a variety of cases: animations with source materials (QT or image sequence) and just pure animation -- sans source footage. That example that I gave was just to help explain the error. We first started noticing it during offline when we started getting frame inaccuracies between AE and the outputted renders we imported into Avid.
I have more testing to do, but I'm leaning towards a it being Mavericks(QT engine) vs AE problem. I have yet to test Squeeze/Compressor to see if I can replicate in other software.
Ok.... I ran more tests.
This extra frame thing doesn't happen when I render out (a pre rendered sequence - QT uncompressed) from Squeeze, QT Pro or Media Encoder. I get a perfect 720 frames on that test sequence.
Here's the funny part:
When I render out the actual AE timeline from Media Encoder ( Composition > Add to Media Encoder Queue ) it renders out a perfect 720 frames as well. Only when I render directly in After Effects (Add to Render Queue ) do I get the 724 frame outputs.
All these tests were outputting to Prores 422hq 1920x1080 @ 23.976.
Can anyone out there duplicate this issue?
Todd and Tim,
Thanks for checking in.
I upgraded to 12.2 but still have the same issues with Prores renders being a few frames too long -- when output from AE. Any other suggestions on troubleshooting this?
Let me restate some of the details here that make this more of a render/Prores issue rather than a project/media timecode issue:
- When exporting Prores directly from AE's render queue on any of our GfX Mac pros, our renders are a few frames too long when viewed in QT7 player or imported into Avid. Although, when those renders are brought back into After Effects, they are seen as the exact correct duration inside AE.
- No other codec tested displays this same behavior for us. We have started using Avid Codecs for offline while we trouble shoot this Prores weirdness.
- When rendered through the Media Encoder Queue, this error doesn't occur either. We are only able to replicate this by submitting to AE's native Render Queue.
Any other thoughts?
- What frame rate is your comp, and what frame rate are you rendering to?
- Are you rendering with audio? If so, what audio rate?
- Does the problem go away if you disable audio in the render?
cbialk, I've spent some more time diagnosing this problem, and I think I'm able to reproduce what you're experiencing. It appears to be a bug, but only happens for certain codecs and only when audio is enabled.
My test is a simple 5 second, 29.97fps comp with a solid and the Timecode and (audio) Tone effects applied. When I render that to QuickTime using any of the ProRes codec flavors, or the DVCPRO HD codec flavors, I get the following results:
- In QuickTime 7 Player, the last frame is repeated once
- In After Effects, the last frame is NOT repeated.
- If I inspect the QT file metadata (open the file in TextEdit), the XMP duration value is incorrect. For a 5s 29.97 comp it should be 150150, but I'm getting 154151.
So, in short, you have found a bug. Sorry about that. It's been filed. To work around the problem, you can:
- Disable audio in the render.
- Render to a different codec.
- Render with audio to ProRes using AME.
Thanks for getting in there and testing this. I've been a little busy today, so I have not yet had a chance to run these tests. With that said, it sounds like this is exactly the issue that I have been running into.
I was hoping it wasn't a bug, but at least I know that I was on the right track with this. For now Avid Codecs and AME for Prores outputs is a doable workaround. I'm just glad there is a workaround for those Prores deliverables.
I will see if I can duplicate your results later tonight or tomorrow, but I think you nailed it.
Just to reiterate: the bug I'm seeing doesn't occur when audio is disabled for the render.
So if you don't need synced audio, or can survive by exporting separate audio and video clips, then you can work around it by disabling audio.
If you need synced audio, use AME. Which isn't a bad way to go regardless.
Thank you cbialk and Tim for adressing this problem.
And giving us the workaround through AME.
I just encountered the problem myself while rendering out as Uncompressed YUV 8 bit 4:2:2. The file was 20.16 secounds long, rather than the 20 seconds it was meant to be.
So are there any news on the bug Tim? Have you found out about the problem?
I'd like to give a little under-the-hood peek at why this bug occurs, as it highlights a notable change in how After Effects, Premiere Pro, and Adobe Media Encoder write QuickTime files.
For writing most QuickTime files, After Effects sends the frames to the Adobe QT32 Server process to be encoded. This is because because After Effects is a 64-bit application, but the QuickTime API is only a 32-bit process. As of After Effects CC (12.1), certain codecs are written directly by After Effects, and the QT32 Server process is not used. These codecs are the ones being affected by this bug: ProRes, DVCPRO HD, and Uncompressed YUV. The same applies to Premiere Pro and Adobe Media Encoder. This behavior, in and of itself, does not cause the bug.
This bug occurs only in After Effects because it does something that Premiere Pro and Adobe Media Encoder do not: it renders a few extra frames ahead of what is currently being encoded. It does this so that if the render is stopped by the user or by an application or system failure, there are enough completed frames so that the partially-completed file can be closed and used. It renders these extra frames even past the end of the composition, but when the frames are encoded the extra bits are trimmed off. It does this for audio as well as the video frames.
OK, so now glue these two things together and we get the specific bug conditions: when After Effects was writing frames to those specific codecs (without using QT32 Server), it was not trimming off the extra audio. This results in a file with an audio track that was a few frames too long. The video frames are written to the correct length, which is why this problem did not affect renders from After Effects that have no audio track.
As Todd mentioned, we have a fix in progress (I have successfully tested the fix), and we are aiming to release it next week. Until then, please use the workarounds mentioned earlier in this thread.
I wanted to point out the specifics of this bug for two reasons:
1. After Effects tries make the encoded file usable even when you cancel a partially-completed render.
2. We have made significant progress in moving away from the QuickTime API's, and towards either writing the files natively or with the assistance of the AV Foundation API. Apple is deprecating QuickTime, integrating the important functions of that platform into Mac OS via AV Foundation. After Effects has a lot of code that relies on QuickTime API's, and it is important that we proceed carefully in following Apple's API changes, as moving the code between API's is a complex task.
FYI: We found a problem with the bug-fix update, so we needed to build a new patch and redo some testing. We're still working on this and hope to have a bug-fix update out within a week or two.
In the meantime, here's a post about some known issues and their workarounds:
This is a very serious bug, that shouldn't be so hard to solve, since CS6 doesn't seem to suffer from it.
Adobe should get it's priorities right, we have been waiting far too long for a solution!
After Effects CS6 doesn't experience this bug because we changed how frames are written with certain QuickTime codecs in After Effects CC (12.1). See my last post in this thread for more detail.
We are progressing with the problem that has been preventing us from releasing the bug-fix update. We hope to release it soon, this week if all goes as expected.
Honnestly, this bug drove me crazy today I thought it appeared only in cc 12,2 so I downgraded to 12,1 and it came back (I should have read you better).
And because of it I had to redeliver 20 commercials today, because this bug is really weird when i import the prores I just made into Ae they last the good length so I said to myself ok this was a one time bug I don't know how but i solved it but once reading it in qt 7 it was 4 frame longer....??????
How do you explain that AE sees a clip shorter than it really is in quicktime???
It's a super frustrating thing for sure. I've pretty much adjusted my workflow to render with AME for anything important like deliverables now -- just to be safe. I've pretty much stopped using prores as an offline codec as well. (Not a big deal -- I work with Avid editors anyways and the 175 codec is super nice) The weirdest thing though is how under the radar this is. I would have expected more noise about this -- especially by now.
Sorry to hear you had to reship. I'd reccomend just using AME and skipping the whole aerender thing completely -- unless you are kicking out image sequences. In the last month, I've only rendered DNX, Tiff, and DPX with aerender. Everything else goes through AME.
I can't deliver through AME my client need prores with a special aspect ratio and AME is unable to deliver it correctly so I now do the delivery in cs6 while doing everything else in cc and it's the same for my whole office where everybody is complaining about this bug and the 8 khz one among others all day long for 2months now!! ...
jo pi wrote:
How do you explain that AE sees a clip shorter than it really is in quicktime???
After Effects determines the duration of a QuickTime file by reading the number of video frames. This bug only affects the length of the audio track, so After Effects shows an affected file at the duration you expected to get. QuickTime Player is using a different method to determine the length of the file that includes the extra length generated by the extra audio frames.
Total suck. Just so I don't run into this problem with AME, are you not able to adjust aspect using the "custom" parameter like in this linked screen grab?
Is it a specfic problem with prores? The reason I ask is because that seems to be the flavor of choice for many billboards ala Time Square etc... I just want to be ready for this one too.
I can't really answer that question because I didn't investigate enough, all i can say is that we have to deliver in SD in PAL with an old aspect pixel ratio that use to be in AE back in maybe CS4 and which allowed you to fit a 1024 pixels wide film into a 720 pixels wide for an height of 576 pixels which seems pretty prehistorical but still is the standard for delivering commercials to the french tv network, by the way sorry I didn't mention earlyer that I am french.
Sorry to not be helpful
This problem is addressed by the After Effects CC (12.2.1) bug-fix update, which is now available:
Note the part at the end of that page about a crucial update for the Creative Cloud desktop application, which addresses some severe problems with AME, Premiere Pro, and After Effects.