« FCP Users: here’s a better way to use PSD’s! | Main | More Books… »

OnLocation Seminar Follow-up

Recently, I gave an online OnLocation e-seminar to over 200 people. I had a TON of questions at the end, and couldn’t get to all of them in the time provided, so here’s a follow-up to some of the more pertinent questions:

Do the Qt files recorded on the hard drive have the same timecode as the tapes in the camera?
The clips have the same timecode that the camera provides. This is a good reason to continue to use tape in the camera. Remember, OnLocation doesn’t impact the tape mechanism in the camera. It’s there, so feel free to use it! :) If the tape isn’t running, and the T/C generator in the camera isn’t set to Free Run, then the recorded clips will all start with 00:00:00;00 timecode. OnLocation doesn’t generate it’s own timecode.

If you aren’t familiar with Free Run mode, it’s a great way to get unique timecode for each file, and not use tape. Many prosumer cameras like the DVX-100 or HVX200 have a free run timecode generator. you have to get used to the idea that the timecode generator is running whether you’re shooting or not, but it works well with OnLo.

Does it record native DV or a compressed file?
OnLocation records what the camera provides via FireWire, which is a full-quality signal, exactly the same quality as what’s recorded to tape. There’s no loss in quality using OnLocation.

Could you monitor REDRaw(r3d) files using Onlocation?
The RED camera doesn’t currently offer a compressed output via FireWire, which is what OnLocation CS4 requires to see a signal. There’s a lot of great development talks with RED right now, so maybe this will change in a future release.

Can you pull pre-recorded video into shot list? Or does it have to be recorded directly into shot list?
It is possible to pull some clips into OnLocation from other sources for comparison purposes, but not all files will be compatible. Simply drag/drop clips from an open window into the Shot List. OnLocation will tell you if the clip is compatible or not. I’ve found this is most useful when using multiple OnLocation projects, and wanting to combine clips from different projects into one project.

Is the metadata contained in a XML format?
The metadata is imbedded in the QuickTime or AVI file for DV format. For HDV recording, it is stored in a separate XML file.

You said that as you did takes in the “placeholder” screen the take # would change, but in your demo it didn’t change. Why is that?
Good question. Chalk it up to operator error. The shot list has two different modes of recording, which I showed: Shot-Recording Mode, and Take-Recording Mode. Somehow, at the beginning of the demo, I mistakenly selected the wrong mode. To utilize the placeholders, select Take-Recording Mode, as shown here: takemode.png
Later on in the seminar, I caught this mistake, and later clips do show the takes field incrementing, but I didn’t call this out. :p Bad Karl.

Can camera rec button start on location record?
YES! There’s a remote record toggle control at the bottom of the Field Monitor, shown here:
Turn this on, and OnLocation will begin recording at the same time as your camera begins recording.

Will OnLocation work with the HD-SDI IO cards?
Not in the CS4 release. As laptops continue to evolve, we’ll be looking at other signal formats, but for now, OnLocation only records signals transmitted via FireWire.



    I’m interested in using OnLocation to record DVCPROHD from an HVX200, now that I have a laptop that’s got enough oomph to handle the program. What sort of hard drive setup is the minimum–and what is recommended–to be able to comfortably and reliably record DVCPROHD?

    Is USB 2.0 with a 7200RPM drive enough, or should I invest in either an eSATA Expresscard adapter, or the secondary hard drive sled that my laptop allows me to use? I know either of the later would be preferred, but can I get away with USB? Thanks for any input.

    Thanks for the comments. I’ve typically used a FireWire 800 based GRAID Mini to record DVCPROHD on my MacBook Pro. A single 7200 RPM USB drive will work if it’s regularly maintained. In testing, we saw that a heavily fragmented drive started triggering the “drive too slow” error message from OnLocation. Keeping the drive defragmented prevented this problem.

    Let me take a moment to explain what this message means – OnLocation uses a RAM memory buffer to ensure no loss in dropped frames. The incoming video signal is first buffered in the available RAM, and it writes the data to disk after. If something hiccups on the drive for a moment, the RAM buffer fills up, and then when the drive speeds back up, the buffer is written out to disk.
    If the buffer fills up past a comfortable margin (I think it’s around 35%), you’ll see this error message. No frames are lost at this point, but you should consider stopping recording soon. If the buffer continues to fill up, there’s a second-tier error that pops up, alerting you that the buffer is almost full, and you should stop recording.

    As a “worst-case” test, I once tried using a 4200 RPM drive for capture of DVCPROHD footage. OnLocation complained the whole time that the drive was too slow, but as long as I recorded very short clips, the resulting files were fine. I never let the buffer fill up all the way, so eventually (when I stopped recording) the data was written to the drive. I’d never recommend this for real-world production, but understanding how the RAM buffer works helps explain what speed drives are necessary.

Sorry, the comment form is closed at this time.

Copyright © 2014 Adobe Systems Incorporated. All rights reserved.
Terms of Use | Privacy Policy and Cookies (Updated)