1

I am creating a program where I show some graphical content, and I record the face of the viewer with the webcam using DirectShow. It is very important that I know the time difference between what's on the screen to when the webcam records a frame.

I don't care at all about reducing latency or anything like that, it can be whatever it's going to be, but I need to know the capture latency as accurately as possible.

When frames come in, I can get the stream times of the frames, but all those frames are relative to some particular stream start time. How can I access the stream start time, for a capture device? That value is obviously somewhere in the bowels of directshow, because the filter graph computes it for every frame, but how can I get at it? I've searched through the docs but haven't found it's secret yet.

I've created my own IBaseFilter IReferenceClock implementing classes, which do little more than report tons of debugging info. Those seem to be doing what they need to be doing, but they don't provide enough information.

For what it is worth, I have tried to investigate this by inspecting the DirectShow Event Queue, but no events concerning the starting of the filter graph seem to be triggered, even when I start the graph.

The following image recorded using the test app might help understand what I'm doing. The graphical content right now is just a timer counting seconds. The webcam is recording the screen. At the particular moment that frame was captured, the system time was about 1.35 seconds or so. The time of the sample recorded in DirectShow was 1.1862 seconds (ignore the caption in the picture). How can I account for the difference of .1637 seconds in this example? The stream start time is key to deriving that value.

The system clock and the reference clock are both using the QueryPerformanceCounter() function, so I would not expect it to be timer wonkyness.

Shot captured by the webcam

Thank you.

whatsisname
  • 5,872
  • 2
  • 20
  • 27

2 Answers2

2

Filters in the graph share reference clock (unless you remove it, which is not what you want anyway) and stream times are relative to certain base start time of this reference clock. Start time corresponds to stream time of zero.

Normally, controlling application does not have access to this start time as filter graph manager chooses the value itself internally and passes to every filter in the graph as a parameter in IBaseFilter::Run call. If you have at least one filter of your own, you can get the value.

Getting absolute capture time in this case is a matter of simple math: frame time is base time + stream time, and you can always do IReferenceClock::GetTime to check current effective time.

If you don't have access to start time anyway and you don't want to add your own filter to the graph, there is a trick you can employ to define base start time yourself. This is what filter graph manager is doing anyway.

Starting the graphs in sync means using IMediaFilter::Run instead of IMediaControl::Run... Call IMediaFilter::Run on all graphs, passing this time... as the parameter.

Community
  • 1
  • 1
Roman R.
  • 68,205
  • 6
  • 94
  • 158
  • Setting the reference time in IMediaFilter doesn't do the job, but it seems it's as close as I'm going to get. There is some buffering somewhere which is not revealed in the presentation times. – whatsisname May 09 '17 at 21:44
0

try IReferenceClock::GetTime

Reference Clocks: https://msdn.microsoft.com/en-us/library/dd377506(v=vs.85).aspx

For more information here:

https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/1dc4123a-05cf-4036-a17e-a7648ca5db4e/how-do-i-know-current-time-stamp-referencetime-on-directshow-source-filter?forum=windowsdirectshowdevelopment

sailfish009
  • 2,561
  • 1
  • 24
  • 31
  • None of the IReferenceClock methods are sufficient. I am using a reference clock that is syncronized to the system clock but that's not doing the job as the filter graph sets its relative base time to something unknown. – whatsisname Apr 15 '17 at 05:16
  • Have you tried to set SetSyncSource(NULL); ? https://msdn.microsoft.com/en-us/library/windows/desktop/dd406921(v=vs.85).aspx – sailfish009 Apr 15 '17 at 05:25
  • Having no reference clock does not help. In that instance I'd have no stream time for my incoming samples so I'd have even less information to compute the offset. – whatsisname Apr 15 '17 at 05:36