- Posts: 2
- Joined: Tue Aug 16, 2022 10:33 am
- Real Name: Mark de Roussier
Hi folk,
there are several replies to queries about the function named in the title, but so far none of them have helped. My environment is Linux ( Fedora 36 ), and I'm using the 12.4 SDK.
In my VideoInputFrameArrived callback, the first thing I do is to call these functions :
What I'm expecting is that the latter call should return a time which is *earlier* than the time I get from the first call. I'm expecting that the behaviour of GetHardwareReferenceTimestamp is to retrieve a time that was attached to this particular video frame after it was captured, but before it is delivered to userland via the callback.
Instead, what I see consistently is that the time I get from GetHardwareReferenceTimestamp is later than the time I get from my gettime call. Massively later - by about 1.14 *seconds*. Here's a sample of some raw data, which I dump on exit ( i.e. after I've stopped receiving frames ) :
Even if GetHardwareReferenceTimestamp was actually just calling clock_gettime and not using a historical value, I would not expect to see such a large difference.
Anyone got a clue ? .
Cheers,
Mark
there are several replies to queries about the function named in the title, but so far none of them have helped. My environment is Linux ( Fedora 36 ), and I'm using the 12.4 SDK.
In my VideoInputFrameArrived callback, the first thing I do is to call these functions :
- Code: Select all
clock_gettime( CLOCK_MONOTONIC, &g_T3[index] );
videoFrame->GetHardwareReferenceTimestamp( 1000000000, &g_T2[index], &g_Tf[index] );
What I'm expecting is that the latter call should return a time which is *earlier* than the time I get from the first call. I'm expecting that the behaviour of GetHardwareReferenceTimestamp is to retrieve a time that was attached to this particular video frame after it was captured, but before it is delivered to userland via the callback.
Instead, what I see consistently is that the time I get from GetHardwareReferenceTimestamp is later than the time I get from my gettime call. Massively later - by about 1.14 *seconds*. Here's a sample of some raw data, which I dump on exit ( i.e. after I've stopped receiving frames ) :
- Code: Select all
T3-part(s) T3-part(ns) T2(ns) Tf(ns) T3(ns) T3-T2(ns)
70943 93454070 70944234265969 20000000 70943093454070 -1140811899
70941 913455235 70943054248841 20000000 70941913455235 -1140793606
70941 933414928 70943074247986 20000000 70941933414928 -1140833058
70941 953446536 70943094246369 20000000 70941953446536 -1140799833
70941 973443780 70943114249290 20000000 70941973443780 -1140805510
70941 993448589 70943134246762 20000000 70941993448589 -1140798173
70942 13431095 70943154249764 20000000 70942013431095 -1140818669
70942 33436935 70943174249580 20000000 70942033436935 -1140812645
70942 53450209 70943194250377 20000000 70942053450209 -1140800168
Even if GetHardwareReferenceTimestamp was actually just calling clock_gettime and not using a historical value, I would not expect to see such a large difference.
Anyone got a clue ? .
Cheers,
Mark