Timecode mismatch when using pre-record buffer
 

Be aware that if you use the pre-record buffer with the SDI stream the nanoflash inserts the timecode at the moment when you push record at the start of the file. Depending on how long your buffer is your timecode will mismatch from the actual timecode in the SDI stream. This is not documented, unfortunately, in the manual.

The manual states "Embedded – timecode is extracted from HD/SD-SDI stream from the source". Taking this as gospel I assumed that the firmware back timed the timecode at the start of the file by the length of the buffer. That it does not do this is somewhat comprehensible given the indefinite length of the buffer and the consequent difficulty of calculating while simultaneously recording. However it's not comprehensible that this is undocumented. It's cost me time to figure out. And will cost me more time with my transcriptions.

Better would be a user selectable pre-record buffer of definite length and the timecode properly back timed. Better would also be more accurate documentation.

This problem was identified by Alistair Chapman way back in September:

http://www.dvinfo.net/forum/converge...-mismatch.html

It should have made the documentation by now.


David

Hi David,
Sincerely I think we start to ask too much to the NANO.
The buffer recording is something (some times) very convenient, but is just an extra.
The NANO works in this case as expected.
To do what you want, the NANO must calculate back the TC according with the buffered picture.
Probably can be done, but personally I think we are complicating the Firmware with functions that are completely secondary.
rafael

Dear David,

Thank you for your suggestion. We will discuss this in the manual.

When Pre-Record Buffer is enabled and the camera is not providing timecode, we get video, but no timecode.

I will check with our engineers as to how we handle this. Making up the missing timecode is rather easy in some situations and very difficult in others.

Hi Rafael,

I don't believe that the "nano works as expected" if the documentation states that it gets its timecode from the SDI stream. My complaint is not how the nano works, it's the absence of correct documentation about it. My suggestion of a user selectable buffer of determinate length is too allow it to properly back time the timecode. That may or may not be difficult to implement but certainly it's possible to document how it presently works in the manual. That would have saved me a lot of grief.

David

Hi,

Let us run some more tests w/ timecode and pre-buffer.

Tommy Schell

How does the FireStore do this?
 

I know that my old FireStore had a buffer record feature, but I never used it. It might be wise to see how they deal with timecode in this situation.

Anyone have a FireStore to play with?

Jeff

I think what Rafael is saying is your camera is not outputting timecode into the SDI stream when the prebuffer is recording therefore the Nano has nowhere to take a TC reference from therefore must generate it internally.

The fact that the SDI output of cameras only embeds timecode when the camera is recording is a feature that the Nano actually uses to automatically roll when you press the cam rec button.

John, it's clear the Nano can't be taking timecode from the SDI stream when the camera is not recording. That's not the issue. The nano takes the timecode from the SDI stream the moment you press record, but then inserts it as the timecode for the first frame of the buffer....so you have a timecode mismatch that's the length of the buffer. Right now that buffer length is determined by the recording format and the available memory of the buffer. If the nano had user selectable buffer lengths the Nano could backtime the initial time code pretty easily and the timecode would match what's on the camera recording device....not a bad idea, either for safety's sake or for doing what I find myself doing on this documentary, using the material from the EX camera as a proxy editing format because my NLE (Adobe CS5) handles EX material brilliantly but won't be usable with C-D footage until an update. I plan on replacing the EX material, shot by shot, at the end of the edit (lots of fun without a timecode match...however Plural Eyes for Pr CS5 may well help.

Best,
David

Got you David. It is clear to me from your description that the Nano could possibly overcome the problem but the math would have to be written into the firmware - perhaps a timecode offset feature would be handy?