I am currently using a Femto Mega and the new Devices.AzureKinect.Femto library. I’m having some difficulty playing back a recording. I’m recording using the k4awrapper’s commandline k4arecorder with standard settings. The recordings play fine in the k4awrapper’s k4aviewer and the file data in the viewer looks correct(30fps, standard formats etc.) When brought into vvvv, the AzureKinectPlayer will not play the file because the k4arecorder is apparently using an absolute timestamp value from the device’s internal clock rather than starting from 0. It’s displaying a crazy current time value with a correct duration value:
The mkv file from the k4arecorder has a tag K4A_START_OFFSET_NS which gives the nanosecond value of the start time. It seems this needs to be handled at playback by subtracting from the timestamp of each frame, as there is no option in the k4arecorder’s settings to record a file without it.
I looked into the AzureKinectPlayer class and found a “GetTag” node under Playback. I copied the entire class and put the GetTag into a Using(Select) region to get the K4A_START_OFFSET_NS value then scaled it by 0.000000001 for seconds:
I need to subtract this offset from the timestamp of each frame. However I really do not understand the complex architecture of the Player and PlayerControl nodes. I’m pretty sure it needs to happen in one of those somewhere, but not making the actual timestamp negative or messing up the looping, etc.
Any ideas on where this offset subtraction might go? (Or if no vvvv solution exists, perhaps a third party way to modify the mkv file’s timestamp data?)
Hey, I’ve still been looking at this and the player makes more sense now having studied it a bit. The Microsoft.Azure.Kinect.Sensor.Record.dll file has get_StartTimestampOffset set_StartTimestampOffset. The node SetStartTimestampOffset takes an input of type RecordConfiguration. I cannot find this anywhere in the player.
I will have to find some different way of doing what I am trying to do, as I have to finish everything by EOD tomorrow for the dance/tech performance my university research job is doing on Saturday. However, I’m really interested in getting it working, as my university/job has at least 12 of these orbbecs and everyone is having various issues with them, across platforms really.
I’m hoping my file is bad. If anyone has recorded mkv files successfully on a femto mega using the k4awrapper recorder, and it plays correctly in the vvvv femto player, without this timestamp issue, I would greatly appreciate any insights you might have on it:)
if you look into the definition of Player (Internal) inside the definition of AzureKinectPlayer in VL.Devices.AzureKinect.vl you can see there is already something regarding GetStartTimestampOffset. i don’t currently have a device at hand. can you check if this is probably not doing the right thing?
Thanks for looking at this joreg! I will grab a device from work on Monday and try all of your suggestions. I think the issue in the first case was that it was adding the multi device sync offset whether I wanted it or not. I wasn’t able to get any successful recording with the straight kinect recorder, but perhaps I was doing something wrong. I will look at it again!
Okay, after some investigation:
I tried to record with the regular Kinect Azure SDK recorder but couldn’t use its recorder or viewer because it requires the matching non-orbbec firmware on the camera and didn’t recognize the camera.
The GetStartTimestampOffset returned a completely different, smaller value than the K4A_START_OFFSET_NS, which matches the main player’s “current time” output. I tried out adding it to GetStartTimestampOffset, converting both to milliseconds first then back to a timespan. So now the “current time” output of the player node reads 0.00 correctly at the start, but the file still does not play, and now returns a white blank image. Previously it showed the last(?) frame.
These mkv files do play fine in windows media player and in regular VL.Video player as a color mkv as well as the k4aWrapper k4a viewer. When I get a chance I will try out a different mega, and also a bolt to see if it behaves any differently.
currently trying to play recorded .mkv from femto bolt - also no luck
i am getting one frame of depth/ir image, no color
after some tinkering with the node, I was able to get this error in the log:
2025/08/21 21:20:33.207 [CRT] (Sys) 0 vvvv OverflowException: “Arithmetic operation resulted in an overflow.”
StackTrace:
Microsoft.Azure.Kinect.Sensor.Image { public System.TimeSpan get_Exposure() { … } }
VL.Devices.AzureKinect.ImageDecompression { public static Microsoft.Azure.Kinect.Sensor.Image Decompress(Microsoft.Azure.Kinect.Sensor.Image image) { … } }
VL.Devices.AzureKinect.KinectImageExtensions { public static bool TryToDecompress(Microsoft.Azure.Kinect.Sensor.Image image, Microsoft.Azure.Kinect.Sensor.Image& decompressedImage) { … } }
VL.Devices.AzureKinect.KinectImageExtensions+<>c { internal System.IObservable<Microsoft.Azure.Kinect.Sensor.Capture> b__14_0(Microsoft.Azure.Kinect.Sensor.Capture c) { … } }
System.Reactive.Linq.ObservableImpl.SelectMany`2+ObservableSelector+_ { public virtual void OnNext(TSource value) { … } }
System.Runtime.ExceptionServices.ExceptionDispatchInfo { public void Throw() { … } }
System.OverflowException: Arithmetic operation resulted in an overflow.
at Microsoft.Azure.Kinect.Sensor.Image.set_Exposure(TimeSpan value)
at VL.Devices.AzureKinect.ImageDecompression.Decompress(Image image)
at VL.Devices.AzureKinect.KinectImageExtensions.TryToDecompress(Image image, Image& decompressedImage)
at VL.Devices.AzureKinect.KinectImageExtensions.<>c.b__14_0(Capture c)
at System.Reactive.Linq.ObservableImpl.SelectMany`2.ObservableSelector._.OnNext(TSource value)
— End of stack trace from previous location —
at VL.Lang.Platforms.RuntimeHost.SharedStep()
For what it’s worth, I was always getting the same overflow exception as StiX. I’ve uploaded a 5 second clip from the femto mega, recorded using the k4a viewer for comparison if that helps. moving.mkv - moving - Frame.io
I found out that without installing Visual Studio on PC, K4A is not working at all (including the VL implementation). Redistributables are not enough. In dependencies, they mention VS2017 as the building tool. Is it possible the playback is dependant on version of visual studio installed?
finally had a chance to debug and fix this. VL.Devices.AzureKinect.Femto 1.8.1 now plays back recordings correctly. thanks @saba_davi and @StiX for your inputs on this!
