Forum Replies Created

Page 31 of 106
  • Alan Okey

    March 7, 2011 at 8:56 pm in reply to: Work flow and Final Cut spec requirements

    [Garrick Simpson] “I’m editing a short film that was shot on 1080i HD.”

    That doesn’t give us much to work with. Was it shot on HDV? AVCHD? Some other format?

    MPEG Streamclip won’t be of much use to you unless you need to transcode a bunch of footage to ProRes prior to editing. While editing ProRes footage can provide a much smoother experience in FCP than natively editing highly compressed long-GOP formats, it does require more drive space to work with.

    Your storage situation is definitely a problem. Editing with footage stored on your system drive is highly discouraged, and editing off of shared storage (simple file sharing) will definitely be a bottleneck. For the best editing performance, you should try to obtain a dedicated external Firewire 800 drive (preferably a RAID) for storing your video footage. On the iMac, you’re limited to FW800 speeds. OWC can mod 2010 iMacs to add an eSATA port, but it will void your warranty.

    https://eshop.macsales.com/shop/turnkey/iMac_2010_27

  • [John Street] “do you know if ProRes422 is restricted to certain file dimensions?”

    I recall seeing other posts indicating that ProRes will function erratically when not used at standard video production resolutions, so I think your hunch is correct. Use of the ProRes codec should be restricted to standard production resolutions for best results.

  • Unfortunately Compressor won’t allow me to lower the bit rate below 10 Mbps, and the client is asking for 3-5 Mbps.

    Regarding the requested oddball 704×480 resolution: In such cases, should the output simply be scaled to these dimensions, or should it be cropped?

    I appreciate the assistance.

  • Alan Okey

    February 26, 2011 at 8:38 pm in reply to: I did not know that! Send to compressor info

    An important caveat worth mentioning is that the “send to Compressor” option does not support virtual clusters. Hence, if your computer is configured as a virtual cluster in order to let Compressor take full advantage of multiple processor cores, “send to Compressor” can’t be used.

    https://support.apple.com/kb/TS1099

  • Alan Okey

    February 24, 2011 at 6:25 pm in reply to: Audio sync issue in Final Cut for music video

    Make sure that the audio file you’re bringing into your FInal Cut Pro project is a 48kHz 16-bit .aiff file. If it’s not, you can use Compressor to convert it.

    When shooting music videos, its always a good idea to feed the the playback audio into at least one of the audio channels on the camera for reference. For example, if you were playing back the audio on a boom box or a PA system, you could take a line out from the boom box or music player and feed it to one of the camera’s audio inputs. If your camera has XLR audio inputs, you’ll need a converter box to do this, such as:

    https://whirlwindusa.com/catalog/black-boxes-effects-and-dis/direct-boxes/pcdi

    make sure you select line level on the camera’s audio input.

    You won’t use this recorded audio as the final audio track in your project, but it helps to have a direct line feed to the camera so that you end up with a good clear reference track to match back to during editing.

  • Alan Okey

    February 23, 2011 at 12:50 am in reply to: H.264 footage

    Dennis,

    Thank you for your thorough and well-reasoned response. It’s all too easy to become stuck in a rut if one’s assumptions are not periodically challenged.

    To be fair, I don’t think that anyone has argued that h.264 is an ideal finishing codec. I can certainly see the value in the ability to edit a codec in its native format (within the context of a better quality finishing codec) if it can be done smoothly and reliably.

  • Alan Okey

    February 22, 2011 at 10:23 pm in reply to: H.264 footage

    Additional reasons:

    – h.264 is a lossy codec that doesn’t hold up well over successive generations of decompression/recompression

    – the high CPU overhead required for decoding/encoding makes h.264 a poor performer for multi-stream (multicam) editing. A codec that requires less CPU overhead will allow for a greater number of simultaneous streams of editing when disk bandwidth is not a bottleneck. That’s why Uncompressed formats aren’t CPU hogs – there’s little CPU overhead involved.

    When Apple engineered ProRes, they could have built upon long-GOP h.264 had they thought it to be a good foundation for a production codec. They didn’t, despite the fact that they were wholeheartedly behind h.264 as a delivery codec. Even Avid veterans recommend transcoding to DnxHD instead of using AMA. I trust that both companies had good reasons to develop their production codecs as they ultimately did.

    h.264 excels at what it was designed to be – an efficient codec for delivery, achieving excellent image quality at low data rates. It was never designed to be a production codec, as its high overhead makes it much more difficult to work with. There’s a reason that Premiere needs a beefy GPU to edit h.264 smoothly.

    I’m not convinced that simply throwing more horsepower at a problem is the most efficient solution. Perhaps a smarter use of GPU power would be to use it to accelerate the transcoding of h.264 into production quality codecs like ProRes. I’d love to see Apple leverage GPU power in this way. A Log and Transfer on steroids would be a great addition to FCP’s workflow.

    If my understanding of h.264 is erroneous, please correct me.

  • Alan Okey

    February 22, 2011 at 5:34 pm in reply to: Data Rates for Streaming

    I’d recommend that you post your question in the Cow’s SAN forum as well.

  • Alan Okey

    February 22, 2011 at 5:08 pm in reply to: H.264 footage

    [Shane Ross] “BUZZ!!! Wrong answer. No no no no no no no no no no no no no… Never do this. This has GOT to be painted in BIG BRIGHT RED letters on the top of every forum out there:

    H.264 IS NOT AN EDITING CODEC.

    It is a shooting and delivery codec, but it should NOT be used for editing. It is highly compressed thus taxing on computer processors.”

    As much as I am in total agreement with you on this, I fear that it’s a losing battle. I’m actually surprised that there haven’t been more snarky “but Premiere Pro can do it” comments about this.

    My fear is that a large number of people (especially those shooting on DSLRs) see this as an example of FCP being old and not in sync with the times rather than understanding or agreeing with the fundamental reasons why h.264 isn’t an ideal codec for editing. My gut feeling is that sooner or later all NLEs will adapt to deal with h.264 footage natively (despite its shortcomings) due to overwhelming consumer demand. It doesn’t mean that we have to be happy about it or that it’s the most elegant technical solution, but I fear that’s the way things are headed.

    Dealing with this issue feels like trying to bail out a sinking boat with a teacup as giant waves pour in over the sides.

  • Alan Okey

    February 20, 2011 at 1:35 am in reply to: Shotgun Mic

    The Sennheiser ME66 and ME67 shotgun mics are quite popular.

Page 31 of 106

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy