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 :)

Timecode issue with 3D Epic

David Barlow

David Barlow

Well-known member
Joined
May 2, 2009
Messages
65
Reaction score
0
Points
0
Location
Southampton UK
Has anyone had the following issue and, if so, do you know how to fix it.

I have two Epic cameras filming 3D on a very simple and completely manual rig so the cameras do not talk to the rig or any other external device other than a Denecke SBT sync generator. The cameras are genlocked and the shutters are working in perfect sync. However, the left and right eye timecodes do not match when shooting in varispeed mode. There is almost always an offset between the two cameras. At project speeds (24, 25, 29.97) there is no discrepancy but as the frame rate increases, the discrepancy gets worse . At 240 fps I can get 21 frames offset in the timecode. Apart from the trend to get worse as the speed increases, there is no fixed pattern. The degree of offset will vary from shot to shot. I am using head and tail slates with good old fashioned clapper so it is easy enough to resync the eyes in Redcine-X Pro (brilliant software by the way) but the editors are a bit concerned about keeping track of the left and right eyes once the slates get removed if they cannot rely on the timecode. Fair point.

The Denecke is put through a Kramer PT-102VN DA to split the genlock between the two cameras but the timecode output from the Denecke is split on a tee between the two cameras. I have understood this to be a reasonable way to do things but I am very happy to be corrected.

A final symptom. The monitor image is fine on the 3D monitor when the cameras are not recording. When in record or playback the eyes play out of sync on the monitors. I assume this is because the cameras rely on the timecode to synchronise playback and if it is off set everything goes out of sync. Usually the camera that I use to initiate the record (mostly the left eye) seems to run ahead of the other one but just to confuse matters this is not always the case. It is possible that I push the record on the other camera sometimes because I do put the rig in some fairly awkward positions and this would explain this. I am running v2.0.5 beta on both cameras.

Anyone got any suggestions? They would be most gratefully received.

David
 
I have noticed it depends on the build. What build are you running?

Yesterday in prep with Epic build 2.0.5 and a time-base of 23.98 and the cameras master-slaving with GIG-E cable: we could do 24, 48 and 72 at 4k/5k. We can also do 96 @ 3k, 120@2k and 144@2k. The builds in the last 6 or so months tell you when the speed settings are happy with the "SYNC" indicator going green with good settings. (Ideally with Epic 3d the "TC", "GEN", "SYNC" and "LAN" are all green for good shooting).

I am not sure about the DA on the TC. We and the fellow 3d companies we know just run using a "T" or "Y" out of the SBT. As with most 3d - test it - test it - test it...

Prost,
Rich
 
David Barlow said:
The cameras are genlocked and the shutters are working in perfect sync. However, the left and right eye timecodes do not match when shooting in varispeed mode. There is almost always an offset between the two cameras. At project speeds (24, 25, 29.97) there is no discrepancy but as the frame rate increases, the discrepancy gets worse . At 240 fps I can get 21 frames offset in the timecode. Apart from the trend to get worse as the speed increases, there is no fixed pattern.
Click to expand...
Once you get a long shot manually synced, do they stay in sync, or do they drift?

I would assume that if this is a feature, you're never going to have a slow-mo shot lasting more than :30 seconds (300 seconds of 10X slow-mo). That's not that tough to keep grouped together. I would talk to your stereographer and your post house, do some tests, and make absolutely certain there aren't any frame-rate phase issues. These can be fixed in post, but it's not fast or cheap; I know of a major 3D horror-movie project that had issues like this, but these affected the entire movie, not just the slow-mo; that boiled down to faulty reference, not timecode per se.

You shouldn't lose more than 3dB with a Y-splitter from the timecode output in terms of audio level, and I think this is well within tolerance of what the camera expects to see.
 
Rich, I am running 2.0.5. I have found that I can do any speed that is a multiple of my project speed. However, I have only tested 24 and 25 time bases as these are all I am interested in for this project. I have not noticed a difference between them. The fastest speed I have tested is 240 fps with a project timebase set at 24 or 225 fps at 25. I always use the 2:1 ratio resolutions. Action and shutters synced as well as I can tell. Since this is a European TV production, it has now been decided that everything must be shot with 25 timebase and I can live with that.

All the green sync lights are always green when I shoot. However, I have found it is possible to shoot with all the lights green (TC, GEN, SYNC and LAN) and yet still have the shutters out of phase. So I do check carefully. That is why I use old fashioned clapper board slates head and tail.

Marc, there is a fixed offset in timecode. The shutters are in phase and line up perfectly in REDCINE-X PRO using the difference map on the clapper boards if I shift the eyes into line. I have not noticed any gradual drifts of sync within the shot or drifting in and out of sync. As you say the edited shots will not be particularly long; however, we are shooting very uncontrollable subjects at high speed so shot lengths can be up to 15,000 frames or ten minutes on playback. However, head and tail clappers still line up to the frame if I remove the offset.

Sorry to show ignorance but could I just check what you mean by "frame-rate phase issues". Do you mean that the shutter scans are running in sync or do you mean drifting of the synchronisation of the action between the left an right eyes? Also when you say "faulty reference" are you referring to the sync generator. (Denecke SBT).

Thanks guys for responding. RED are looking at my log files, so maybe they will come up with an answer, but I am sure any suggestions are helpful.

David
 
The stock SB-T is not expected to properly genlock RED EPIC, not sure about timecode. We have recently been working closely with Charlie Parra at Denecke. Charlie has created a new version of the SB-T which we have been testing with great success. The new version eliminates the need for a genlock DA, and when used with a 75 ohm BNC T, provides rock solid genlock and timecode to the EPIC. While I have not yet tested frame rates other than 23.976, the performance of this new generation SB-T unit has been excellent. As far as I know, RED currently does not expect EPIC to be able to sync for 3D applications at frame rates above 120, but this would be better addressed by Deanan. My only suggestions would be to contact Denecke and request that they upgrade your SB-T and make sure you are using 75 ohm BNC T connectors.
 
Yes, I have heard about the new Denecke. Found it impossible to get one here in the UK so had to settle for the SB-T. Does that mean that it is now available in the UK? Jason, I am interested to hear you say that the SB-T is not expected to genlock the Epics when so many people recommend them and I see them used on many shoots using Epics. Combine that with with Marc's statement about about "faulty reference". Scary. I have heard of issues with drifting sync in 3D with RED cameras.

In my situation, it may not be official from RED, but the fact remains that my cameras appear to sync perfectly at ALL multiples of 24/25 timebase up to and including 300fps in 3D. This is one reason why I dare not mess with the cameras firmware in case I lose this. My ONLY problem is the offset in timecode between left and right eyes. Shot a 60,000 frame take at 225fps yesterday and everything was fine except the 6 frame timecode offset. I appreciate that this is easily sorted in REDCINE-X PRO, but my footage will not be under my control for post so there is plenty of opportunity for a ****up if the left and right timecodes do not match. I am using the standard RED cables to carry the genlock and timecode to the Epics. I do need the high speed. If no one can suggest why the timecode is off set then we will have to keep careful logs and work around it. It is just rather puzzling. To be clear at frame rates of 24 and 25 fps there is no offset.

David
 
According to RED and Charlie Parra at Denecke, the regular old SB-T is not the right tool for genlocking EPICs. You can definitely get the new SB-T from Denecke and I'm sure they'd ship to the UK. If it ain't broke, don't fix it, but talk to Charlie. I can't see how genlock would affect timecode, but who knows, its voodoo sometimes. I think the timecode issue is more or a RED question. Sorry I don't have better answers.
 
Thank you Jason. That is very interesting to know. I will try to see again if the newer SB-T is available here. This will be of wider interest.
 
David Barlow said:
Thank you Jason. That is very interesting to know. I will try to see again if the newer SB-T is available here. This will be of wider interest.
Click to expand...
Hi David,

The SB-T is designed to drive a single 75 Ohm load. If you are running a 3D rid, then you can modify your current SB-T to drive two cameras. Contact our UK dealer as I am sure that they can modify it for you.

I hope this helps!

Best Regards,

Charlie
 
Hi Charlie,

Thanks for joining in. I will contact UK dealer. Does this modification affect both the genlock and timecode outputs or just genlock? Would it do away with any need for a DA?

David
 
Hi David,

The modification only affects the genlock output. You will not need a DA with a modified SB-T. You can simply use a "T" for each output (TC & Genlock). Richmond Film Services is not aware of the mod yet, but they can contact me (unless I contact them first) and I'll fill them in on the details.

Best Regards,

Charlie
 
TC will never match in Varispeed

TC will never match in Varispeed

Because the trigger of record will always have a slight delay between the two cameras, TC will never match between eyes when shooting high speed. This is a result of the camera generating new TC in varispeed mode, and the beginning offset being multiplied by the factor over 24fps that you are shooting. We always slate with a Deneke with rolling TC even when shooting MOS for this very reason - as you need to sync the eyes in RCX by hand - its an unavoidable workflow until the cameras can trigger record at the exact same instant. From what I've heard, that is a ways off.


We've used the SB-T's with perfect results and several 3D features, at rates up to 288FPS with the epic - and tested using a high speed strobe to confirm the accuracy of the shutter lock. At 288 fps with a 180 shutter, we've seen only a 3 scan line offset in the timing of the strobe - quite an amazing degree of shutter lock in my opinion.

Having a new unit that eliminates the need for a DA sounds great, but there seems to be alot of myth in this thread. Also, we've had DA's fail on us, and we simply use a "T" connector to split the sync and this has worked fine as well, even if its not recommended.
 
I thought that this might end up being the case. It was worth asking but we will have to work around the offset timecode. Thank you Greg for your input.

Regards,

David
 
Did they give a real technical reason?

Did they give a real technical reason?

Wasn't trying to be snarky - just know alot of what I was reading to be incorrect. We've been using SB-T's with Epics both in 3D and 2D configs since we got our M's in July with no issues. Its baffling why someone would claim they aren't 'epic' compatible - they worked fine with the R1's and the main difference with Epic sync is needing to set the SB-T to 2398P.

What was the reason stated for why an SB-T wouldn't provide proper sync to an Epic? Does this mean in all circumstances, or was this in reference to the fact that there is only one BNC out for sync? Still doesn't make sense as using a proper DA is true and tested way to distribute that sync signal to both cameras. If there is some other issue, I would really like to know.

Thanks

g
 
Greg Strause said:
Still doesn't make sense as using a proper DA is true and tested way to distribute that sync signal to both cameras. If there is some other issue, I would really like to know.
Click to expand...
If Charlie from Denecke says it works, I trust him enough to know. He's the man when it comes to this stuff. You can always contact them at (661) 607-0206 to verify correct operation or get a modification done.
 
I was told by RED that the EPIC is more sensitive when it come to genlock than the RED ONE. Charlie also felt the mod was important to supply the proper signal. As far as I understand it had something to do with the impedance. It may work in your current configuration, but the updated model is recommended by both RED and Denecke. That's all I know.
 
The issue with genlock signal is that a 'T' essentially doubly terminates the signal, cutting the level in half. This leaves it very close to the lower threshold required by the circuitry in the camera. Depending on the genlock source this may or not work. Therefore, RED does not recommend using a T.
An Ambient Lockit for example becomes marginal. But, Ambient does have a mod available that provides two genlock output connectors. A Lockit with a T often works 'OK' going straight into the 3BNC-lemo cables. But its not guaranteed.

As for timecode alignment, the cameras are not guaranteed to start record on exactly the same frame. Using the GP Input as a trigger with a single button T ing to both cameras will get you the closest you can, and it is very close, as in a couple of frames. RCX will then usually line them up automatically by timecode. Framerates off the project rate will have more variation. Using a slate is recommended. Using the GigE cable to control record on both cameras will have more variation in the start of the record since there is delay to relay the commands to the slave camera.

High framerate synched recording is supported. Its not a fluke.
 
You must log in or register to reply here.
Back
Top