Forum Replies Created
-
Matt Lyon
March 4, 2012 at 4:23 am in reply to: Workflow and playback for Uncompressed 10-bit is choppy on my Mac Pro.[David Roth Weiss] “BTW, all the great stuff you discovered about FCP time-stamping audio files makes you a techno force to be reckoned with, so I certainly don’t doubt your technical chops one bit. I just think you might be assuming that ProRes is less friendly than it really is.”
Thanks David. Don’t worry, I have a thick skin and am always happy to learn something new 🙂
I realized I was quoting my info based on Apple’s system requirements page for ProRes. But that was for HD playback, so yeah, SD ProRes on non Intel hardware is a different can of worms.
But that being said, this post by Gary Adcock seems to suggest that there are quality losses when playing ProRes on non Intel hardware:
https://forums.creativecow.net/thread/8/1024925
Whereas, I’m pretty sure that isn’t the case with uncompressed 10 bit material.
Matt Lyon
Editor
Toronto -
Matt Lyon
March 3, 2012 at 6:16 pm in reply to: Workflow and playback for Uncompressed 10-bit is choppy on my Mac Pro.yes, but with fast enough hard drives, it was possible to edit 10 bit Uncompressed on a powermac G4.
ProRes need a top of the line G5 or intel mac, minimum. To me that implies that ProRes is MORE processor intensive. That’s not the same as saying that ProRes’ data i/o requirements are lower.
Matt Lyon
Editor
Toronto -
Matt Lyon
March 3, 2012 at 5:02 pm in reply to: Workflow and playback for Uncompressed 10-bit is choppy on my Mac Pro.[Daniel Sametz] “Go then with Prores HQ. It’s good for keying and composing and less processor intensive than 10 bit uncompressed. But if you must use the codec then the more the internal HDD the better. :)”
Wouldn’t ProRes actually be MORE processor intensive, due to its more sophisticated decoding requirements during playback? 10 bit uncompressed has more hardcore data throughput requirements, but I would think it would actually be LESS processor intensive. Unless I’m remembering wrong, 10 bit uncompressed is supported on much older hardware then ProRes is.
Matt Lyon
Editor
Toronto -
Interesting discussion!
I’ve never honestly even thought this might be an issue. Nor has anyone ever told me this could be an issue. I’ve always just edited at 23.976, exported w/ 3:2 and been done.
[Doug Beal] “If you do not fix frames that have interfield motion (the results of 23.98 edit landing on field2 of a 29.97 conversion it will get kicked back by some companies BitMax for one.”
Is this a matter of their QC machines being overly conservative? Have you ever had an actual broadcaster reject a master because of an edit landing on a split field? Not saying it doesn’t happen, I’ve just never seen this on a QC report. But I’m not an online guy, so I don’t see that many QC reports 🙂
Matt Lyon
Editor
Toronto -
Hi Derek, I’ve noticed this too and have found two workarounds:
when you export check the “recompress all frames” option
or
instead of using a freeze frame, razor blade the very last frame and copy-paste it as many times as you need. Then use a slug on the track above, with a fade up, to accomplish the dissolve.
hth,
Matt Lyon
Editor
Toronto -
I agree with Dave, you can do this all in Compressor (the crop, scale and frame rate changes). Use “nearest frame” for the motion rendering setting, since 12 divides into 60 evenly; you don’t need to do any fancy interpolating. But 64 kbps is a VERY low data rate, so you’ll need to shrink your export dimensions until an acceptable quality level is reached. Use two pass encoding to get the best possible quality, and play with the keyframe settings (although I usually get the best results with “auto keyframes.”
I recommend setting an “in and out” in the preview window, and running some tests on a short section of your video until you are happy with the settings. Then remove the in and out markers and export the whole thing.
hth,
Matt Lyon
Editor
Toronto -
This may not help, but I got this tip from Walter Biscardi:
Turn off the “remove duplicate frames and advanced pulldown” option in the L&T preferences. Since I did this, my EOS plugin transfers are much more reliable.
Might also try stripping away all the audio tracks to make a “video only” sequence before you recapture. I’ve found this has made the process smoother for me in the past. Might not cure the crashing though…
hth,
Matt Lyon
Editor
Toronto -
Matt Lyon
February 16, 2012 at 3:44 am in reply to: Exporting ProRes422 HQ – do I recompress all frames?[Rafael Amador] “No if your sequence is not fully rendered. The reference movie needs the render files too.”
Rafael, in my experience, if you export a reference file without rendering the sequence first, then the unrendered sections will be computed on the fly, during export and embedded into the reference movie. So you’ll end up with a bigger reference file, but it will work.
I’ve had issues in the past where I would get color pops upon export between a video clip, and a freeze frame of the last frame of the clip. Turning on the “recompress all frames” was one way (of several) to solve this. But that doesn’t sound like this situation.
Could it be a function of the “conform aperture” setting in quicktime player? Kind of a wild guess … but since FCP does ignore the “production aperture” info in a quicktime movie, it would be consistent with the behaviour you are seeing.
Try opening the movie in QTPlayer 7 and playing with the different “conform aperture” settings in the “presentation” tab of the movie properties.
hth,
Matt Lyon
Editor
Toronto -
Matt Lyon
February 9, 2012 at 2:41 am in reply to: ProRes 422 Color/Gamma Shift on Export – Same as SourceNp Dustin. I just remembered when I had to use the “recompress all frames” options: it was when I had used a freeze frame in a pro res timeline. There was a shift from the original clip to the freeze frame when I exported a self contained movie. This was in fcp 6, so I’m not sure it still applies.
Matt Lyon
Editor
Toronto -
Matt Lyon
February 9, 2012 at 1:48 am in reply to: ProRes 422 Color/Gamma Shift on Export – Same as Source[Dustin Parsons] “So the problem is definitely with QuickTime because it’s appearing correct everywhere else.”
The evidence is pretty damning, Dustin! I think your findings are pretty consistent with common complaints about the quicktime player that are routinely posted to this site.
At least you know that FCP isn’t modifying the colors, and it’s just a QT Player display thing. I have read other posts about changing the “visual settings” in the video track options in the movie properties window in quicktime player 7. I haven’t played with it much myself, but you can search the forum and find more info.
Can you ask your clients to view the clip in VLC? Maybe send a link to the installer download to make it easier for them? Or upload a file to Vimeo or YouTube for them to review? Honestly though, there are so many other display variables that might be happening on their machines that I don’t know how much it’s worth killing yourself over.
Matt Lyon
Editor
Toronto