Motion 5 seems to have trouble reading the MOV files that SA outputs under the default Animation codec saying it is not supported. I also notice that playback is a little bumpy in Quicktime X (no problems w/ Quicktime 7 playback). When I changed the codec setting from Animation to H.264 29.97fps 30 frame keyframe SA froze saying the compress call failed.
Rather than further trial and error I figured I would go to the group and see if anyone has a best practices suggestion for outputting video on a Mac.
Running studio Artist 4.04 on
iMac, 3.1 GHz Intel Core i5
For working with Final Cut Pro X and Motion, using the Apple ProRes codecs is probably the best way to go. Here's a tip on this topic.
Regarding H262 output in Studio Artist 4, Apple introduced a bug in their 32 bit quicktime api that causes the problem you experienced. It's fascinating, because Studio Artist 3.5 was compiled with an earlier version of the Quicktime SDK and H264 output works perfectly fine running with the same internal code for writing out the frames to a quicktime movie file. Since Apple appears to have essentially abandoned development of Quicktime at this point, i don't expect a fix for the H264 api bug and associated H264 output problem that we see in version 4. Upcoming 4.05 tells you to choose a different codec if you try to select H264, so we're more proactive about preventing people from running into the problem.
An easy fix to go from animation to H264 after the fact is to use Qucktime Player 7 Pro (not the evil Quicktime X player). You can easily use Quicktime Player 7 Pro to convert between different codecs. I often render with a lossless codec like animation to get the highest image quality for archiving a processed movie file. I then convert it to H264 for upload to vimeo or somewhere else on the web. You can also use this to convert your animation codec renders to ProRes codec for Final Cut Pro.
I did not know that about H.264, bummer.
I had been doing a convert from Animation to H.264 in Quicktime 7 Pro, but was hoping to avoid that step. Though it appears to be best practice for archive and lightweight playback.
The problem with using a lossy compressed format for archiving is that if you want to source it to multiple output formats, or do touch up or additional processing, you lose information with each lossy compression pass. So that's the reason to use a lossless compression format for your original output. Assuming you have the disc space, since they are memory pigs as far as movie formats go. ProRes is lossy, but much higher quality than a distribution codec like H264, and was designed for use in post production to trade off better quality while still getting reasonable bandwidth for speed of playback.
The people here that are into Final Cut Pro X love ProRes, so they tend to use it for all of their Studio Artist rendering output at this point.
Final Cut Pro X (and hence Motion 5) are based on AV Foundation (as opposed to old style Quicktime). The range of codecs AV Foundation currently supports is relatively limited (hence the issue with gold animation codec).
Now that we're past the codec issue, I'm still finding playback a bit choppy.
All I'm doing is a simple 2 step PASeq, "Erase to white" then "Autopaint". I want to export the actual painting as part of a larger projection sequence and have a wall automagically get "painted". Flag is set to "Enable Always Autowrite" then I run the PASeq. The first few seconds of the painting look right but then it seems to freeze frame for several seconds and then jump to the finished state. This seems to occur when I output to either Movie OR Image Sequence. Could this be a Keyframing issue in the video encoding? I assume I just have something set wrong.
I'm going to back up a second, and ask you why you are using autowrite in a movie stream vs using Action : Process with Paint Action Sequence : Source to Movie menu style processing.
Is your goal to process each frame of the source image with the PASeq? If so, then either using that action menu batch process, or using the 'enable write on paseq cycle' write flag if you really want to use a movie stream would be the way to go.
Seems I was unclear earlier. Or I do not understand "Action : Process with Paint Action Sequence : Source to Movie" properly.
The project that has me tripped up is not an animation in the sense of multiple frames painted completely and then compiled into a moving image. I want to capture the actual paint process and use the stroke by stroke change over time as an animation. A video watching a painting happen. But the final result is only a still image.
Ok, if you want to watch the process of painting happening (like in real time) in the movie, then autowrite into a movie stream is the correct approach.
Gated Autowrite is probably a better choice than autowrite. Autowrite just starts outputting frames the moment you turn it on with an active movie or image stream, so if you sit and do nothing for 5 minutes in the program while it's turned on then frames of nothing happening will still be streaming out.
Gated Autowrite is only supposed to auto dump frames when something is actually happening. like you are manually painting, or auto-painting is happening, etc. So maybe the freeze frame was related to using autowrite vs gated autowrite? Or a hardisk starting up inhibiting the frame writing?
the actual playback rate of a movie stream generated via autowrite into an open movie stream is a function of both the autowrite rate (as specified in the movie preferences dialog), interacting with the FPS playback rate specified in the File : Movie Codec Settings dialog. the first specifies how often frames are output, the second specifies the rate those frames are actually played back at.
A screen capture program like snapz pro is the other option to using autowrite with a movie stream for capturing a movie of 'real time' painting.
Regarding flicker in paint animations, you can build a PAseq that accents flicker, or one that reduces it's perception. It has to do with the notion of whether you introduce temporal continuity in the progression of processed frames, or not. More temporal continuity leads to reduced perception of flicker.
Here's a link to a tutorial post on designing paint animation strategies. It includes links to a large number of different online tutorials and movie processing examples. if you read through the posts there, you will see some links to material that discusses the concept of temporal continuity. And there are many posts that describe different approaches to reducing flicker in paint animation effects by properly designing a PASeq for movie processing.
That's a great resource. The animation is definitely one of the most appealing aspects of SA to me, so I am excited to dive in further.
Some information about compression codecs and working with movie layers in Studio Artist.
Studio Artist has the ability to load a quicktime movie file into a layer, and then work frame by frame, painting on individual frames, adding new ones, etc. So people who love the zen of building up traditional hand painted animation frame by frame manually can use that feature to do so. Or people who might want to touch up a movie file, or add some detail to an auto-rotoscoped movie file, on a frame by frame basis, also have a way to do that kind of touch up work.
As an example, Nina Paley made a great Studio Artist animation where she did the main animation using auto-rotoscoping with a Paint Action Sequence. She then loaded that automatically processed animated movie file into a movie layer, and hand painted in the cat eyes in each frame, to add personalized detail to the final finished paint animation.
Now the thing about doing a lot of single frame edits to a movie file is that working with a compression codec that compresses information over time is a very bad idea. That kind of codec is much more efficient for reducing the size of a movie than one that only compresses information within a single frame. So for playing a movie fast with low bandwidth, or putting a movie on the web, that time based compression makes a lot of sense. But if you want to do single frame edits, then you really don't want time based compression. You just want each frame compressed without requiring information from neighboring frames. So this is why a codec like animation codec, or photo jpeg, is much better to use if you want to load a movie file into a movie layer for working with hand painting on individual frames.
Again, after you are finished with all of that hand touch up work, you can flatten the edited movie layer, and then convert that to some other time based codec if you wish.