Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Major Sync issues

When I place the epic clip on top of the pix clip they are then sync together using timecode. At present we are getting most slates to sync with each other. However we are getting maybe 2 takes out of 30 that even though the timecodes match the pictures do not. The remedy is to slip the r3d back 1 frame but this is not a viable long term solution.
 
Wow, quite a bit of good information here. It sounds like Simon is on a good track with all your help.

Remember that the PIX Sync and TC generator is essentially an Ambient Lockit built into the PIX.

It looks like Shane's workflow nails the recommended operating procedure, there isn't much else to add there.
 
Simon N said:
When I place the epic clip on top of the pix clip they are then sync together using timecode. At present we are getting most slates to sync with each other. However we are getting maybe 2 takes out of 30 that even though the timecodes match the pictures do not. The remedy is to slip the r3d back 1 frame but this is not a viable long term solution.
Click to expand...

Interesting.

The only other method I can think of to check sync would be to get a smart slate and connect it in reader mode to the TC output of the PIX. Shoot the slate with a fairly high shutter--to get rid of LED smear--and compare TC displayed with file timecode on both devices. That might get you closer to understanding which device is a frame off.

Two notes:

1) If you use a Dencke TS-3, set it for +1 frame mode. Denecke slates don't display a timecode frame until all 80 TC bits have been read--Ambient Slates will display the frame as soon as it reads it in the TC word.
2) You will have to take into account the processing delay of the picture from imager to SDI out. This is the same reason why you have to slip the PIX video two frames relative to the R3D files to begin with.
 
I had to put -3 Frames in the file start TC offset of the Pix to get perfect synch. R3D/PIXfiles.

Now, when I shoot HDRx the Camera looses Synch(RED color) and Gen... Any one experience this issue?
Pat
 
Sounds like the problem is you're comparing the time code in the camera to visual reference on the slate. As far as I know, the slate isn't getting genlock, only time code, right? So the visual time code on the slate may be half a frame off and look one frame off, etc. sounds like a phase issue with the scrolling numbers.

Did you try this with actual sound instead of slates and picture only? Do 30 clips of a load close sound like a clap or slate stick hits, then listen to the sound with picture and see if it works.

As said before, numbers on the slate are to get you in the ballpark, the hit is what really matters. Does it sound correct? If its really a frame out you will probably notice.

Testing with visual time code only is not a real world test, since that's never going un your movie, they always cut that part out. That's why I'm suggesting a real sound test, to see if it works how it has to in the production.

If the epic and pix recordings march, it could be that your user error is in the type of test being performed, that it is not a realistic expectation. Especially if clips go out one frame and then come back in, that doesn't make any sense. Also try over a few hours, 5 minutes is a very short time determining if there is a time ode drift somewhere.

Tim
 
Patrick Tresch said:
I had to put -3 Frames in the file start TC offset of the Pix to get perfect synch. R3D/PIXfiles.

Now, when I shoot HDRx the Camera looses Synch(RED color) and Gen... Any one experience this issue?
Pat
Click to expand...

That make sense as the pix is getting its video signal over sdi which has a delay. I have mine set at -2 frames.
I'll have to test the hdrx issue.
 
The issue is possilbly being caused by the camera not liking a contstant sync into it via lockit boxes. jamming the camera and leaving it to free run has produced realtively stable results not perfect but getting better.
 
Simon, It is actually better to leave the timecode attached as it will prevent any drift due to differences in crystal oscillator performance between the camera and the lockit. Genlock of course must be kept attached.
Can you where you ended up configuration wise and what exactly is "out of sync"
 
Dave Winder said:
Simon, It is actually better to leave the timecode attached as it will prevent any drift due to differences in crystal oscillator performance between the camera and the lockit. Genlock of course must be kept attached.
Can you where you ended up configuration wise and what exactly is "out of sync"
Click to expand...

We have now left timecode attached, however the problem is due to genlock being attached. I am night shooting at the moment, but when I get a complete resolution for the issue, I will post so others do not have to go through the stress I have done recently. In a nutshell, I have been doing everything as I should have done, there is a sync input problem between the lockit and the camera.

Our configuration is now simply lockit box with timecode only into the camera with no "sync in". Timecode down the sdi into the pix.

"Out of sync" as I describe it has turned into many things this week, but primarily the original issue I was trying to resolve was that out of 25 clips recorded onto the pix, when auto synchronised via timecode, i.e. both Pix mov & R3d had the same timecode stamp on them, on average 20 would match picture frame exactly and 5 would have a 1 frame picture difference despite having the same timecode.
 
Simon N said:
We have now left timecode attached, however the problem is due to genlock being attached. I am night shooting at the moment, but when I get a complete resolution for the issue, I will post so others do not have to go through the stress I have done recently. In a nutshell, I have been doing everything as I should have done, there is a sync input problem between the lockit and the camera.

Our configuration is now simply lockit box with timecode only into the camera with no "sync in". Timecode down the sdi into the pix.

"Out of sync" as I describe it has turned into many things this week, but primarily the original issue I was trying to resolve was that out of 25 clips recorded onto the pix, when auto synchronised via timecode, i.e. both Pix mov & R3d had the same timecode stamp on them, on average 20 would match picture frame exactly and 5 would have a 1 frame picture difference despite having the same timecode.
Click to expand...

Simon,

Are you using a separate Lockit box or the one built in to the PIX?
 
We are using a seperately lockit box. Ambient ACL203 Clockit.

Out of 37 clips shot last night 28 we perfectly in sync between r3ds and pix mov pictures. The others were 1 frame adrift.
 
Esmaile Neissi said:
seams add to me !!! i haven't experienced this befor
Click to expand...

That is why it is driving us nuts. Only a few users are experiencing it and we can't figure out why.
 
We are experiencing it with 2 different epic cameras & 2 different pix recorders.
 
If you use TC from an external TC generator you need to Genlock it otherwise you will have a subframe drift. The cam will have to choose with TC it will take in account. On HDCAM cameras and other tape cam it would eventually screw your shoot if TC & Gen weren't used simultaneously.

Today I changed the body and lost synch.... Tomorrow I'll look into it.

Pat

1 day later... we came to conclusion that the TC/Genlock IN of the camera is faulty...
 
We had frame drift when we had the sync attached from the lockit box - when we removed the sync cable and left in timecode the drift issue stopped. The same symptoms on 2 different Epics. This is a different issue though to the one I originally posted about re the PIX. We still are getting only an 80% success rate of having pix & r3d shots match.
 
You must log in or register to reply here.
Back
Top