Frame offset, RANDOMLY, when outputing via edit to tape.
by tobias kihlgren
on
Sep 4, 2008 at 1:48:36 pm
So.... my problem is simply that the video I am outputing via edit to tape is diffing one frame in maybe 50% of the times, note that it happens RANDOMLY. This makes my job a little more stressful in deadline situations.
This is my specs:
codec: AJA VUY
tape: digibeta
capture card: aja cona LH
FCP: 6.0.4
Protocol: Sony RS-422
QT: 7.5
I have tried changing the playback offset in the Device control Preset, back and forward, without any result. Can I somehow change the offset by 0.5 frames somewere or is there any else adjustments somewere?
Re: Frame offset, RANDOMLY, when outputing via edit to tape. by Michael Gossen on Sep 4, 2008 at 7:05:40 pm
Frustrating. What I always do is try to simplify. Revert back to an 'Easy Setup' before you output. Reinstall Kona Drivers. They just came out with version 6 like last week. That will help revert any little settings you might have changed over the course of trying to fix this. The bottom line is Kona works, FCP works, most of these things have been tested over and over. Try some defaults. It is really rare when things happen with true randomness. Maybe it just isn't an easy pattern to spot. Stick with it. I think you can only adjust your capture offset by .5 frames in the device control... Good luck.
Re: Frame offset, RANDOMLY, when outputing via edit to tape. by Michael Gissing on Sep 5, 2008 at 8:46:47 am
Do you have reference video feeding both the Digi and the Kona?
I have only once had issues with FCP and RS422 control of a digi beta deck and that was a Decklink driver and an update was required. I haven't heard of people having that same issue with Kona but non referenced RS422 control can cause random frame errors during lockup.
Video machines are designed to report their status at the beginning of the second field of a video frame. FCP as the controller is meant to ask for status at the same time. If the request and transmit of status is out of sync becasue there isn't a reference signal to lock both together then frame errors can occur.
