Timecode slipping from HD-SDI out at DVinfo.net

Chris Braga · March 10th, 2011, 12:33 AM

Hi Guys,

Since you where all champs with helping me with my last issues I beseech your collective help once again.

I need to know if the timecode imbedded in the Nanoflash HD-SDI signal out slips for any of you? The way our post house works is it records the footage onto tape from the Nanoflash HD-SDI signal out, but it is having problems with the timecode slipping more than we already knew of (2 frames). We are using Firmware: 1.6.29 as it is the last update that doesn't have timecode delay issues when playing back.

Now please don't ask why Post don't edit the files from the cards straight onto the AVID, I've explained it in my other post, I just need to see if someone knows how to overcome this issue or if maybe a future update to the firmware will be more reliable with the Timecode syncing issues we are experiencing currently in our show.

Cheers Chris

P.S I'll get back to your replies its just I do all my posts at work during scene block throughs so sometimes I'm a little slow in replying.

Andy Mangrum · March 10th, 2011, 06:05 PM

Hello Chris,

Could we have some more information about your setup, so that we can answer your question better?

What camera are you using? Sony EX3 etc

What Format are you recording? 1080p24

What Bit rate are your using? 100Mb I-Frame

Also I assume that you are using embedded Time Code from your post, also are you using MXF, I would assume so since your post is avid, but it is always good to double check.

As for Time code we should be within 1 Frame more specifically 1/4 of a frame for the record, or are you referring to playback or your files?

Best Regards

Trevor Asquerthian · March 12th, 2011, 05:13 AM

If they are capturing baseband from the Nano (or tape) via HD-SDI this is how I understand Avid works with timecode:

It grabs the TC at the start of digitising and then adds a frame for each frame passed.

So there is plenty of potential for TC errors... as has been experienced by offline/online workflows for years and requires an 'eyematch' check of offline against online.

Don't know if that is what is occurring here, but I wouldn't lay the blame on the Nano straight away.

Trevor

Dave Sperling · March 12th, 2011, 09:58 AM

Chris,

Some additional questions that would be useful to diagnose your problem:

1- How long are your takes?

2- Is the original timecode source generated internally within the camera?

3- Or is this a multi-camera shoot with the timecode generated by a separate time code generator?, or timecode generated by one camera and fed to other cameras?

4 - If a multi-camera shoot, are the cameras gen-locked together?

5 - Exactly what do you mean by 'slipping' and how do you determine it? ie - are several cameras not maintaining exact relative time code? / is the timecode recorded internally in the camera different than the timecode recorded in the NanoFlash? / Is this some sort of timecode 'offset' that remains constant over the length of a take, or does the amount of offset drift over the course of the take?

6 - Have you tried doing a simple timecode record test? -- output the camera 'viewfinder with timecode' to a monitor and record both internally in the camera and externally to a nanoflash simultaneously (Ideally the Nanoflash should be in the shot as well so you can see the screen on the Nano right next to the tc numbers on the monitor.) Then you can compare what has been recorded with what you see on screen. 15 or so minutes should suffice, though make sure that you do a sync slate clap in the beginning, middle (every couple of minutes) and end of the take. Sync up the two recordings on the timeline and let us know about any offsets or drift.

Hopefully there would then be enough info (combined with the requests from Andy) to be able to analyze the problem.

Best,
Dave S

Trevor Asquerthian · March 13th, 2011, 05:17 AM

Offline Timecode Drift | Edit Geek

might also help you diagnose

Dan Keaton · March 13th, 2011, 05:37 AM

Deart Tevor,

Thank you for the link!

Chris Braga · March 13th, 2011, 11:54 PM

Hey guys,

Thanks for all the replies, sorry about the late reply, but its been a busy week at work.

Okay I'll answer all the questions here I go;

Andy:

What camera are you using?: We are using 2 Sony F23's

What Format are you recording? 1080p 24f

What Bit rate are your using? 280M I-Frame

Yes we are using embedded T/C, and we are using MXF files to record to, and yes post is AVID.

And i'm referring to the playback of the system, I've ust asked Bruce (DOP) he told me that post weren't sure if it was their decks or our Nanoflash problem, because when they changed the tape deck, thats when it seems to have timecode issues. But the DP asked me to ask you guys if you knew of any situation were the T/C embedded in the metadata of the clip could slip?

Hi Dave

1- How long are your takes?:
Our takes differ, like as we speak we are shooting a 2:47 scene with 3 chars, and we sometimes shoot .10 sec scenes.

2- Is the original timecode source generated internally within the camera?:
No we use an external Timecode lock it box.

3- Or is this a multi-camera shoot with the timecode generated by a separate time code generator?, or timecode generated by one camera and fed to other cameras?:
This is a two camera drama with timecode generated by a separate timecode jammer.

5 - Exactly what do you mean by 'slipping' and how do you determine it? ie - are several cameras not maintaining exact relative time code? / is the timecode recorded internally in the camera different than the timecode recorded in the NanoFlash? / Is this some sort of timecode 'offset' that remains constant over the length of a take, or does the amount of offset drift over the course of the take?:
Sorry by Slipping I mean that the timecode is not stable and seems to be running out of sync overtime, thus been different from the sound t/c source. I'll have to find out more on this issue, as post are not sure what the exact problem or how the slipping is occurring, but all of our timecode boxes are syncing correctly.

6 - Have you tried doing a simple timecode record test? -- output the camera 'viewfinder with timecode' to a monitor and record both internally in the camera and externally to a nanoflash simultaneously (Ideally the Nanoflash should be in the shot as well so you can see the screen on the Nano right next to the tc numbers on the monitor.) Then you can compare what has been recorded with what you see on screen. 15 or so minutes should suffice, though make sure that you do a sync slate clap in the beginning, middle (every couple of minutes) and end of the take. Sync up the two recordings on the timeline and let us know about any offsets or drift.:
No we haven't done that test, I'll bring it up with my DP and let you know. The problem with recording internally, well to speak the Sony F23's do not have an internal system to record to (they are modelled after the Panasonic Genesis body), and we do not have any of the recording toasters on set with us so this might be hard.

Hope this helps.

Cheers Chris.

Trevor Asquerthian · March 14th, 2011, 02:43 AM

Quote:

Originally Posted by Chris

i'm referring to the playback of the system, I've ust asked Bruce (DOP) he told me that post weren't sure if it was their decks or our Nanoflash problem, because when they changed the tape deck, thats when it seems to have timecode issues.

and

Quote:

Originally Posted by Chris

The problem with recording internally, well to speak the Sony F23's do not have an internal system to record to

So how are they getting the images onto tape? Are you not recording to tape and Nano simultaneously?

Or are they recording to Nano then doing a baseband transfer to tape then ingest to Avid? (which would be a very convoluted workflow, which could very likely result in tc slippage against sep sound).

From your answer it sounds as if they either swapped a tape deck out for playback into avid purposes, or swapped it out for recording purposes - and either way the problem didn't exist before the swap-out. That would lead me to check the settings on the swapped out VTR.

For your verification test could you record to the Nano with the Lok-it TC display and the nano screen with TC arranged in one shot? Then do some stop start recordings and check that all the timecodes (2 in shot and one on file) match at the start and ends. (Or just use a digi-slate)

Wouldn't nail down the sep sound problem but should confirm that recorded video timecode is consistent with Lok-it at the Nano level.

FYI: Avid can 'read audio timecode' so if you can get the timecode as an audio signal onto one of the audio tracks of the nano then you can set that as an aux timecode track in the Avid for comparison with the genuine tc track. This can highlight any tc skipped frames that Avid might have missed.

Hope you get it sorted... do report back.

Dave Sperling · March 14th, 2011, 07:57 AM

Hi Chris,

Hadn't realized until your last post that you were working with F23.
By the way, are you recording simultaneously to HDcamSR decks, or is the NanoFlash being used for the master record?
I don't tend to be on F23 shoots very often, so I'll just throw out a couple of WAGs based on my old 'days in film'.

First, I'm going on the assumption that with an F23 setup you are indeed genlocking the cameras.

As I recall the F23 gives you options to shoot 23.98 or 24. When shooting in 'true 24' you start dealing with a bunch of tech issues that you may not deal with in 23.98, since most video gear is based around using 23.98 as a standard rather than true 24. Even the NanoFlash manual mentions potential problems with NLE support if shooting true 24.

So my best guess is that, since your takes are relatively short, and when the problem occurs its drift seems to increase over time, and a very slight drift would often not be noticed over the course of a short take (so I would term the drift major), i'm guessing that somewhere in the system something is interpreting 24 as 23.98 or vice-versa. If it's a specific deck, It could have to do with the internal settings on that deck. It could also be an NLE problem.

If the above is the case, then when the problem occurs, the drift in numbers should take place at a constant rate. (ie, the drift at 12 minutes into a take would be twice the drift at 6 minutes in.)

(My film reference refers to the fact that when we first converted our Aaton cameras to shoot 30fps for direct transfer to video, we were always scratching our heads in terms of the reference rate for the DAT audio to keep it in sync, and the post house had to be on the same page as the sound recordist or everything would drift.

Best of luck with it. I know these gremlins can be hard to track down!

March 10th, 2011, 12:33 AM	#1
Chris Braga New Boot Join Date: Nov 2010 Location: Sydney, Australia Posts: 6	Timecode slipping from HD-SDI out Hi Guys, Since you where all champs with helping me with my last issues I beseech your collective help once again. I need to know if the timecode imbedded in the Nanoflash HD-SDI signal out slips for any of you? The way our post house works is it records the footage onto tape from the Nanoflash HD-SDI signal out, but it is having problems with the timecode slipping more than we already knew of (2 frames). We are using Firmware: 1.6.29 as it is the last update that doesn't have timecode delay issues when playing back. Now please don't ask why Post don't edit the files from the cards straight onto the AVID, I've explained it in my other post, I just need to see if someone knows how to overcome this issue or if maybe a future update to the firmware will be more reliable with the Timecode syncing issues we are experiencing currently in our show. Cheers Chris P.S I'll get back to your replies its just I do all my posts at work during scene block throughs so sometimes I'm a little slow in replying.

March 10th, 2011, 06:05 PM	#2
Andy Mangrum Sponsor: Convergent Design Join Date: Jul 2010 Location: Colorado Springs Colorado Posts: 166	Re: Timecode slipping from HD-SDI out Hello Chris, Could we have some more information about your setup, so that we can answer your question better? What camera are you using? Sony EX3 etc What Format are you recording? 1080p24 What Bit rate are your using? 100Mb I-Frame Also I assume that you are using embedded Time Code from your post, also are you using MXF, I would assume so since your post is avid, but it is always good to double check. As for Time code we should be within 1 Frame more specifically 1/4 of a frame for the record, or are you referring to playback or your files? Best Regards __________________ Andy Mangrum, Tech Support Convergent Design, Inc

March 12th, 2011, 05:13 AM	#3
Trevor Asquerthian New Boot Join Date: Feb 2010 Location: London, UK Posts: 5	Re: Timecode slipping from HD-SDI out If they are capturing baseband from the Nano (or tape) via HD-SDI this is how I understand Avid works with timecode: It grabs the TC at the start of digitising and then adds a frame for each frame passed. So there is plenty of potential for TC errors... as has been experienced by offline/online workflows for years and requires an 'eyematch' check of offline against online. Don't know if that is what is occurring here, but I wouldn't lay the blame on the Nano straight away. Trevor

March 12th, 2011, 09:58 AM	#4
Dave Sperling Major Player Join Date: Jan 2010 Location: Tinton Falls, NJ Posts: 780	Re: Timecode slipping from HD-SDI out Chris, Some additional questions that would be useful to diagnose your problem: 1- How long are your takes? 2- Is the original timecode source generated internally within the camera? 3- Or is this a multi-camera shoot with the timecode generated by a separate time code generator?, or timecode generated by one camera and fed to other cameras? 4 - If a multi-camera shoot, are the cameras gen-locked together? 5 - Exactly what do you mean by 'slipping' and how do you determine it? ie - are several cameras not maintaining exact relative time code? / is the timecode recorded internally in the camera different than the timecode recorded in the NanoFlash? / Is this some sort of timecode 'offset' that remains constant over the length of a take, or does the amount of offset drift over the course of the take? 6 - Have you tried doing a simple timecode record test? -- output the camera 'viewfinder with timecode' to a monitor and record both internally in the camera and externally to a nanoflash simultaneously (Ideally the Nanoflash should be in the shot as well so you can see the screen on the Nano right next to the tc numbers on the monitor.) Then you can compare what has been recorded with what you see on screen. 15 or so minutes should suffice, though make sure that you do a sync slate clap in the beginning, middle (every couple of minutes) and end of the take. Sync up the two recordings on the timeline and let us know about any offsets or drift. Hopefully there would then be enough info (combined with the requests from Andy) to be able to analyze the problem. Best, Dave S

March 13th, 2011, 05:17 AM	#5
Trevor Asquerthian New Boot Join Date: Feb 2010 Location: London, UK Posts: 5	Re: Timecode slipping from HD-SDI out Offline Timecode Drift \| Edit Geek might also help you diagnose

March 13th, 2011, 05:37 AM	#6
Dan Keaton Inner Circle Join Date: Dec 2002 Location: Augusta Georgia Posts: 5,421	Re: Timecode slipping from HD-SDI out Deart Tevor, Thank you for the link! __________________ Dan Keaton Augusta Georgia

March 13th, 2011, 11:54 PM	#7
Chris Braga New Boot Join Date: Nov 2010 Location: Sydney, Australia Posts: 6	Re: Timecode slipping from HD-SDI out Hey guys, Thanks for all the replies, sorry about the late reply, but its been a busy week at work. Okay I'll answer all the questions here I go; Andy: What camera are you using?: We are using 2 Sony F23's What Format are you recording? 1080p 24f What Bit rate are your using? 280M I-Frame Yes we are using embedded T/C, and we are using MXF files to record to, and yes post is AVID. And i'm referring to the playback of the system, I've ust asked Bruce (DOP) he told me that post weren't sure if it was their decks or our Nanoflash problem, because when they changed the tape deck, thats when it seems to have timecode issues. But the DP asked me to ask you guys if you knew of any situation were the T/C embedded in the metadata of the clip could slip? Hi Dave 1- How long are your takes?: Our takes differ, like as we speak we are shooting a 2:47 scene with 3 chars, and we sometimes shoot .10 sec scenes. 2- Is the original timecode source generated internally within the camera?: No we use an external Timecode lock it box. 3- Or is this a multi-camera shoot with the timecode generated by a separate time code generator?, or timecode generated by one camera and fed to other cameras?: This is a two camera drama with timecode generated by a separate timecode jammer. 5 - Exactly what do you mean by 'slipping' and how do you determine it? ie - are several cameras not maintaining exact relative time code? / is the timecode recorded internally in the camera different than the timecode recorded in the NanoFlash? / Is this some sort of timecode 'offset' that remains constant over the length of a take, or does the amount of offset drift over the course of the take?: Sorry by Slipping I mean that the timecode is not stable and seems to be running out of sync overtime, thus been different from the sound t/c source. I'll have to find out more on this issue, as post are not sure what the exact problem or how the slipping is occurring, but all of our timecode boxes are syncing correctly. 6 - Have you tried doing a simple timecode record test? -- output the camera 'viewfinder with timecode' to a monitor and record both internally in the camera and externally to a nanoflash simultaneously (Ideally the Nanoflash should be in the shot as well so you can see the screen on the Nano right next to the tc numbers on the monitor.) Then you can compare what has been recorded with what you see on screen. 15 or so minutes should suffice, though make sure that you do a sync slate clap in the beginning, middle (every couple of minutes) and end of the take. Sync up the two recordings on the timeline and let us know about any offsets or drift.: No we haven't done that test, I'll bring it up with my DP and let you know. The problem with recording internally, well to speak the Sony F23's do not have an internal system to record to (they are modelled after the Panasonic Genesis body), and we do not have any of the recording toasters on set with us so this might be hard. Hope this helps. Cheers Chris.

March 14th, 2011, 07:57 AM	#9
Dave Sperling Major Player Join Date: Jan 2010 Location: Tinton Falls, NJ Posts: 780	Re: Timecode slipping from HD-SDI out Hi Chris, Hadn't realized until your last post that you were working with F23. By the way, are you recording simultaneously to HDcamSR decks, or is the NanoFlash being used for the master record? I don't tend to be on F23 shoots very often, so I'll just throw out a couple of WAGs based on my old 'days in film'. First, I'm going on the assumption that with an F23 setup you are indeed genlocking the cameras. As I recall the F23 gives you options to shoot 23.98 or 24. When shooting in 'true 24' you start dealing with a bunch of tech issues that you may not deal with in 23.98, since most video gear is based around using 23.98 as a standard rather than true 24. Even the NanoFlash manual mentions potential problems with NLE support if shooting true 24. So my best guess is that, since your takes are relatively short, and when the problem occurs its drift seems to increase over time, and a very slight drift would often not be noticed over the course of a short take (so I would term the drift major), i'm guessing that somewhere in the system something is interpreting 24 as 23.98 or vice-versa. If it's a specific deck, It could have to do with the internal settings on that deck. It could also be an NLE problem. If the above is the case, then when the problem occurs, the drift in numbers should take place at a constant rate. (ie, the drift at 12 minutes into a take would be twice the drift at 6 minutes in.) (My film reference refers to the fact that when we first converted our Aaton cameras to shoot 30fps for direct transfer to video, we were always scratching our heads in terms of the reference rate for the DAT audio to keep it in sync, and the post house had to be on the same page as the sound recordist or everything would drift. Best of luck with it. I know these gremlins can be hard to track down!