Critical tracking data recordi | Forum

Critical tracking data recording issue

Hi,

We have a weird issue with recording tracking data. It took some time to narrow this down, but it seems that whenever we record in our camera (Ursa 12K) internally, any tracking data that is being simultaneously recorded in Aximmetry will be ruined.
The scary part is that during shooting when recording is on, the playback and everything is perfectly smooth so there is nothing indicating that the recording will be trash!

The issue with the tracking data looks like a frame rate mismatch. Playing back the recorded tracking with UE scene straight in Aximmetry and also any offline renders using the ruined tracking data will have unusably choppy playback which behaves exactly like if the frame rate was wrong.

This only happens when we record tracking data with Aximmetry while simultaneously having REC on our Ursa. If we just record the sdi out of the camera, there will be no issues.

We´ve done countless tests and if we do two identical recordings back to back,
first record "Tracking only" with Aximmetry+camera sdi out feed using a BM Hyperdeck Studio 4K pro, the tracking data is always fine.

Then we do the exact same take but also press record on Ursa, the real time playback during recording will continue to be perfect but the recorded tracking data will be unusable.

-We have tried different mediums with Ursa, SSD´s, SD cards etc. Always the same result.
-We´re sending the timecode from Ursa, it has a continuously running timecode.
-This is the case with all tried Aximmetry versions, today we realized the newest one didn´t change it either
-We have matching frame rate on camera, genlock generator (AJA Gen10) and Aximmetry project.
-Tracking data is from RedSpy

Now, we just realized a possible clue of some sort.

When opening the recorded files (tracking data+camera recording/placeholder) in the playback module, Aximmetry shows correct frame rate for all recorded low res place holder files. 30P in this case.
But now I realized when I brought the Aximmetrys placeholder files to DaVinci Resolve, it shows the frame rate of the files varies! The files had random frame rates like 26 and 27 etc. Only the files that were recorded without also recording internally with Ursa had consistently the correct frame rate.

Wouldn´t this suggest a possible frame rate issue for tracking data as well? I don´t know how to check it.

So what could be causing this? How can this be fixed?

We´ve been doing fine with just recording 2160P to Hyperdecks, but we would need to get this sorted out to get to work with Braw and experiment with 8K etc.

If this is a bug, it´s insanely dangerous! If it is something I have overlooked, hope to get help to correct it!

Thank you,

Emil

Nestruction Studios

TwentyStudios

What is generating the time code in this setup? If it’s generated internally in the Ursa or externally generated and sent as pass through via the Ursa, maybe the time code gets messed up when you record internally?

Nestruction Studios

Hi man! Hope you're having the summer of your life :P

Sorry, seems I wasn't clear there. Yes, Ursa is generating the time code. It has continuously running time code so it is running even when recording is not on, and it just starts sending it via sdi when pressing record on Ursa.

I did expect something like that and have tried pressing record on Ursa before pressing record on Aximmetry to get the timecode already running before starting to record tracking data but it didn't have an impact.

I could try generating the timecode somewhere else but the shitty thing with the Ursa 12K is that it can't receive external time code and genlock simultaneously. If a different TC generator fixed this issue then working around this limitation could still be a valid option.

I could try next with just Aximmetry generated TC.

Thank you again!

Emil

TwentyStudios

If the only variable that causes the recording to fail is that you record internally on the Ursa, the only conclusion must be that something isn’t right with the signal going into Aximmetry. My guess is that something gets broken with the embedded timecode. Have you tried looking at the embedded timecode when you record the same thing internally and to an external recorder simultaneously? Open both files in Resolve and check that the time code makes sense and is consistent between both files.

Eifert@Aximmetry

Hi,

You don't need a third-party program to compare the timecodes; you can compare the timecodes within Aximmetry itself. I would recommend comparing the frame rates as well. For example:
Critical tracking data recording issue

Note, that with the Cursor pin of the Video Player modules, you can easily change the playback position, as shown above.

Warmest regards,

Nestruction Studios

Thanks guys, I will try this and compare the timecode.

However, I'm thinking how could the timecode be wrong in the incoming signal when the live preview works perfectly? It is easy to see that the live preview is absolutely perfect, issue is only when using the recorded tracking data.

TwentyStudios

Bad time code wouldn’t affect the live preview whatsoever. It’s just used when lining up the recorded video with the recorded tracking data.

Nestruction Studios

Oh ok I understand it now! Makes sense. Then this definitely seems like the camera is the issue and it messes up the timecode when recording on to a medium internally, like you suggested. Might experiment with different mediums and settings then to see if something works.

Emil

marc.colemont

If using URSA camera, I would use an ATEM that generates the timecode. That way you can also do remote shading through SDI input (limited on the 12K version), and the timecode of the Atem is automatically embedded again on the SDI output to the Aximmetry. That works rock solid.

Nestruction Studios

Thanks for the tip!

Critical tracking data recording issue

Cookie consent