Conversation
…ery the time at which the stream was opened, in seconds since Jan 1 1970 (midnight, UTC). Useful for RTSP and other live video where absolute timestamps are needed. Only applicable to ffmpeg backends
|
How this can be useful for computer vision algorithms? |
|
Alalek: |
| CAP_PROP_HW_ACCELERATION_USE_OPENCL=52, //!< (**open-only**) If non-zero, create new OpenCL context and bind it to current thread. The OpenCL context created with Video Acceleration context attached it (if not attached yet) for optimized GPU data copy between HW accelerated decoder and cv::UMat. | ||
| CAP_PROP_OPEN_TIMEOUT_MSEC=53, //!< (**open-only**) timeout in milliseconds for opening a video capture (applicable for FFmpeg back-end only) | ||
| CAP_PROP_READ_TIMEOUT_MSEC=54, //!< (**open-only**) timeout in milliseconds for reading from a video capture (applicable for FFmpeg back-end only) | ||
| CAP_PROP_STREAM_OPEN_TIME =55, //<! (read-only) time in seconds since Jan 1 1970 when stream was opened. Applicable for FFmpeg backend only. Useful for RTSP and other live streams |
There was a problem hiding this comment.
in seconds
Lets use nanoseconds to keep this value accurate and avoid division (FFmpeg uses microseconds internally)
There was a problem hiding this comment.
Ok. I changed the name of the cap prop (added _NSEC to the end) to reflect the units
There was a problem hiding this comment.
I looked on that once more.
int64_t is good for nanoseconds, but double which is used to return property values - doesn't. Double's 53 mantissa bits are reached in 104 days (it is not good for timestamps since 1970).
Details about similar problem: https://groups.google.com/g/python-ideas/c/RLRBS15Gofc
Seconds / milliseconds is not enough accurate for sensors (without fractional part).
Perhaps, microseconds (_USEC) should work.
There was a problem hiding this comment.
Using seconds/milliseconds with the fractional part would necessitate a division (is there a compiler macro #ifdef-type thing to allow that?), so I don't think we'd want to go with that. Microseconds fits in a double until ~2170 (log2 [86400*1e6 * 365 * 200] is less than 53). I'm going to change to microseconds
…change the cap prop name to CAP_PROP_STREAM_OPEN_TIME_NSEC
…r too soon, and milliseconds/seconds requires a division)
| #endif // USE_AV_HW_CODECS | ||
| case CAP_PROP_STREAM_OPEN_TIME_USEC: | ||
| //ic->start_time_realtime is in microseconds | ||
| return ((double)ic->start_time_realtime); |
There was a problem hiding this comment.
Please fix whitespace issue (to make builds green): http://pullrequest.opencv.org/buildbot/builders/precommit_docs/builds/31979
There was a problem hiding this comment.
git diff --check did not catch this - is that a bug? I'm assuming that the extra space at the end of line 1595 was the offending whitespace.
There was a problem hiding this comment.
It works (need to specify the "base" commit):
$ git checkout 567ffd8134d67d76277181930dd4f4eb618fe26f
Note: switching to '567ffd8134d67d76277181930dd4f4eb618fe26f'.
HEAD is now at 567ffd8134 use microseconds for CAP_PROP_STREAM_OPEN_TIME (nanoseconds rolls over too soon, and milliseconds/seconds requires a division)
$ git diff --check 6fbfc58602e719b9d58099a3c43e5c764718c4ba
modules/videoio/src/cap_ffmpeg_impl.hpp:1596: trailing whitespace.
+ return ((double)ic->start_time_realtime);
There was a problem hiding this comment.
It works (need to specify the "base" commit):
$ git checkout 567ffd8134d67d76277181930dd4f4eb618fe26f Note: switching to '567ffd8134d67d76277181930dd4f4eb618fe26f'. HEAD is now at 567ffd8134 use microseconds for CAP_PROP_STREAM_OPEN_TIME (nanoseconds rolls over too soon, and milliseconds/seconds requires a division) $ git diff --check 6fbfc58602e719b9d58099a3c43e5c764718c4ba modules/videoio/src/cap_ffmpeg_impl.hpp:1596: trailing whitespace. + return ((double)ic->start_time_realtime);
Sorry - do I need to do something on this PR, or are you saying that, in order to get the whitespace check to work, I need to use git diff --check [base_commit] ?
There was a problem hiding this comment.
do I need to do something on this PR
No. This PR is merged. Thank you for contribution!
See here about automatic local whitespace checks: https://github.com/opencv/opencv/wiki/How_to_contribute#q3-i-was-asked-to-remove-whitespace-issues-how-can-i-do-that
I added CAP_PROP_STREAM_OPEN_TIME to the capture properties enumeration and support for it in the
getProperty()method of the FFmpeg VideoCapture object.Motivation - RTSP (RTP) stream timestamps are relative to start of stream, which is undesirable when trying to correlate the stream to external data streams.
Testing - I'm happy to add a test case, but as the return value of
cap.get(cv2::CAP_PROP_STREAM_OPEN_TIME)is nondeterministic, I'm unsure if it needs one/how to do it. I tested locally (with an IP camera and an RTSP stream) and it works. Please advise if more extensive testing/sample code is needed.