-
Insufficient Disk Space
I’m having a problem with Final Cut Pro incorrectly calculating the available free AV time. Here’s what I’m trying to do…
MacPro Dual Quad-Core
Final Cut Pro 6
Aja Kona 3
Scratch Disk: Internal 300GB (non-raid)I’m trying to capture video at 1080p and 2 channels of audio. Ultimately, the captured Quicktime files will be used at our facility as video files with audio guide tracks in ProTools for our audio mixers. The source tapes are either DBC, D5, or HDCAM-SR. We want to ingest all sources at 1080p so that the aspect ratios are consistent with all files and will conform to our 16×9 plasma displays. The Kona card is performing the up-conversion of the SD sources correctly. So that isn’t a problem.
Truth be told, capturing into FCP might be overkill, because we’re not actually doing any editorial of the picture. But when I try capturing using Kona’s VTR Xchange application, I get dropped frames with 1080PsF source material. So that’s another problem that might require more hardware, which isn’t going to happen at the moment.
Anyway, the current functioning setup involves capturing into FCP using one of the Kona Easy Setups with Apple ProRes 422. Then, the files are dropped into Compressor and transcoded to the PhotoJPEG codec in order to get manageable file sizes with acceptable quality.
Currently, this process works fine, but management has requested that we try to avoid the two-step process if possible and initially capture the video at the PhotoJPEG codec. I’ve been successful thus far with creating new Easy Setups that have a customized Sequence Preset and Capture Preset. These indicate PhotoJPEG codec at 50% quality. The Kona Digitizer is set to 8bit, because I was getting dropped frames with 10bit. Anyway, my testing works perfectly with short one minute clips. But when trying to batch capture a feature length film with defined in and out points, the capture fails immediately, and I get an error message stating that there is “Insufficient Disk Space”. If I crash record by hitting the ‘NOW’ button in the ‘Log and Capture’ window, it’ll allow me to capture the entire feature without any problems.
So…that’s my situation. The ‘Log and Capture’ window is correctly indicating 89GB of free space but calculates that as only 11.8 minutes of available free AV time. (This isn’t the case when capturing at Apple ProRes 422; FCP calculates over 156 minutes of available free time.) Additionally, when crash recording as indicated above, the final file size is roughly 27GB. So this is well under the amount of available disk space and indicates to me that FCP is incorrectly calculating the available free AV time.
I’ve attempted to capture in this manner with other codecs, such as Motion JPEG A or Motion JPEG B, but there still appears to be an incorrect calculation of available time.
Does anybody have any suggestions? Does the process I’m attempting make sense or is there a better way to go about it? Are we forced to stay with the two-step process which is currently working?
If you made it this far and feel like responding, thank you. 🙂
-
2 Replies
-
JPEG is a variable rate codec…. so much that FCP doesn’t really know how much space will be used per minute of footage and gives you a poor calculation.
as I recall this has been an issue with PhotoJPEG for years…
-
Aaron,
Thanks for the response. I didn’t know that PhotoJPEG was a VBR codec, but I figured it had something to do with my problem based on what I’ve been reading. So that kinda makes sense. It would be nice if there was a check-box or something to disable the Available Free Time calculation and limitation.
Do you have any suggestions as to how we can go about this procedure? We’re trying to eliminate the secondary step of going into Compressor to accommodate our schedule. In the two-step process, it takes an additional 1.5 hours at the end of the last video capture to allow for compression and import into ProTools. Captures earlier in the shift can be compressed in the background while the next picture is being captured, but the last capture of the shift still requires the scheduled time.
If we cannot figure out a solution, then we’ll probably move forward with a simple crash record.
Thanks again for you assistance.
Reply to this Discussion! Login or Sign Up