With a live camera stream, does this property represent the latest grabbed/retrieved frame’s time in any way which relates to the camera’s time keeping? or is it just a host timestamp?
don’t count on it. AFAIK that property is only used on files, not on devices.
if you need to know, you’ll have to check the source code for the specific backend you want, and then check if the media API used by that backend supports what you want.
Actually I could verify (on one machine) that this value is indeed the camera time (interpreted only relative to next and previous values, like a host’s python monotonic clock) by recording a timer phone app in the camera stream. The jumps in the value of CAP_PROP_POS_MSEC across grabs perfectly coincides with the camera stream’s recorded timer app time that it is capturing.
By making a video of a phone’s timer app, these things can be verified (or, refuted on other machines and versions). If you have a video viewer that can go frame by frame, that is.
Would you happen to know of any hardware accessory better serving as a wall-clock kind of timer for a streaming camera, for reproducing the timing of shots more elegantly than randomly placing your typical Amazon general purpose timer in the scene?
random arduino with a bunch of LEDs hooked up to the GPIOs, making them light up in a gray code pattern that advances once a millisecond? I’d recommend using all the outputs. millisecond increments, 10 bits roll over in a second. keep total GPIO current source/sink capability of the entire arduino in mind. modern LEDs don’t need 10 mA, they do fine with 1 mA or even 100 µA.
the clock of the arduino will be reasonably stable/monotonic, but the rate will not be calibrated.
don’t reach for 7-segment modules. they come with their own drivers, which likely refresh the entire panel at ~200 Hz, and you might not be able to precisely predict the latency between writing to I2C, and the LEDs doing the thing.
there are RTC modules that can be programmed to output clocks at 1 Hz up and above 1 kHz. those modules are factory-calibrated, so that won’t be as much ahead/behind as the bare arduino.
there are also clock radio receiver modules and GPS receiver modules. both can emit a 1 Hz signal (or higher) with exact phase. if you feel fancy, you can digitally keep a phase difference w.r.t. the RTC, so now you have a rock solid rate and phase.
of course, if the camera were able to take a “genlock” signal…
Thanks, very creative. I think I’ll get a wall timer and kitchen timer on Amazon after all 
But it sure deserves a kickstarer I’d add a mini-projector which projects the time onto the lens’ edge while automagically catering for its curve and letting you choose the color of the projection.
On the serious side again, I can further say that the the times coming from CAP_PROP_POS_MSEC in my multi-camera recording setup clearly seem to be host normalized ― they are not raw times from a camera’s monotonic clock, but rather they are fully (or tightly enough) normalized to the host’s monotonic clock ― regardless of the different camera’s start times.
In other words, with multiple cameras being grabed and retrieved, the CAP_PROP_POS_MSEC values from different cameras really indicate a shared time axis (verified with a a single phone’s stopwatch app showing clearly on both cameras, using exaggerated camera start time spreads among the cameras, and a frame-by-frame video player against the host-logged CAP_PROP_POS_MSEC time of each grab).
Perhaps that’s thanks to (OpenCV or) v4l2 normalizing the timestamps from the cameras, or the cameras initializing their monotonic clocks from the host, or some other reason like the shared buffers getting timestamped directly on the host side upon any frame being put in the shared buffer, but it definitely looks like that on my machine, using my specific Logitech webcam models, at least.
So these CAP_PROP_POS_MSEC values taken any time before a next grab, are very useful in this particular setup, directly playing as the precise time that each frame from each camera was physically taken on its CMOS, at least per my ~millisecond time resolution accuracy requirement, verified with a stop-watch application showing in all stream-captured frames on both cams being concurrently polled for their stream.
This has been probably baked-in for a long while already, as per the source comment: