Re: V4L Camera frame timestamp question
On Thu, 10 Jun 2010 03:24:05 + (UTC) jiajun zhujia...@gmail.com wrote: I'm currently using the V4L-DVB driver to control a few logitech webcams and playstation eye cameras on a Gubuntu system. Everything works just fine except one thing: the buffer timestamp value seems wrong. [snip] this should be the timestamp of when the image is taken (similar to gettimeofday() function) but the value I got is something way smaller (e.g. 75000) than what it should be (e.g. 1275931384) Is this a known problem? Hi, No, I did not know it! Thank you. I will try to fix it for the kernel 2.6.35. Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L Camera frame timestamp question
2010/6/10 Jean-Francois Moine moin...@free.fr: On Thu, 10 Jun 2010 03:24:05 + (UTC) jiajun zhujia...@gmail.com wrote: I'm currently using the V4L-DVB driver to control a few logitech webcams and playstation eye cameras on a Gubuntu system. Everything works just fine except one thing: the buffer timestamp value seems wrong. [snip] this should be the timestamp of when the image is taken (similar to gettimeofday() function) but the value I got is something way smaller (e.g. 75000) than what it should be (e.g. 1275931384) Is this a known problem? Hi, No, I did not know it! Thank you. I will try to fix it for the kernel 2.6.35. You can't use gettimeofday for timestamps or you will have big problems if your clock changes when you are grabbing video. You must use a monotonic clock, this is what gspca and uvc are doing, they now use ktime, a monotonic highres clock. This prevents time shifts that can break the video stream playback, also gettimeofday as problems in multicore cpus since for most processors the internal cpus are not exactly in sync. So PLEASE leave it like it is now, also other drivers should really move into using ktime nad not gettimeofday. You are converting the timestamp to seconds this will produce a smaller value, you should really convert it to ms, then you would get a value closer to what you want. Best Regards, Paulo Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L Camera frame timestamp question
Hi,
2010/6/10 Jiajun Zhu zhujia...@gmail.com:
Thanks for the discussion.
Based on my testing, the image timestamps or ktime is the system uptime in
nanosecond, is this correct?
For my application, I need to synchronize the camera image with other data
which are all timestamped by gettimeofday().
Like I explained gettimeofday is not the proper way to set timestamps,
you should use a monotonic clock:
e.g.:
//timestamps in nanosec
uint64_t ns_time_monotonic()
{
static struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, ts);
return ((uint64_t) ts.tv_sec * G_NSEC_PER_SEC + (uint64_t) ts.tv_nsec);
}
This will give you a similar timestamp to ktime.
How would you suggest me to do this?
I can think of two options:
1. Get the system uptime and compute the offset between gettimeofday() at
the start of my program, and then use this offset
to correct all the image timestamps.
The only linux userspace function I can find to get system uptime is to
read /proc/uptime file, which resolution is 0.01 seconds.
2. Hack the camera driver to use do_getimeofday() instead of ktime, and
ignore all the problems you guys mentioned earlier.
Any comments?
In my case to sync audio and video timestamps I just take the first
video ts and check it against the
initial audio ts (taken with the above function) , remember that for
timestamps the important thing is the delta between them,
so you can store the first one and just use the difference for the
next ones. e.g.:
//timestamps in nanosec
if (first_frame)
ts_ref = (uint64_t) buf.timestamp.tv_sec * 10 +
buf.timestamp.tv_usec *1000;
frame_ts = ((uint64_t) buf.timestamp.tv_sec * 10 +
buf.timestamp.tv_usec *1000) - ts_ref;
now you can also use ts_ref for audio timestamps.
If you really need to use getttimeofday (very bad idea), you just need
the timeofday for the first (ref_ts) timestamp
for the others just use the delta.
so when you grab the first frame also get the value of getimeofday()
(in the same time base), that's that simple, from then on just do:
initial_frame_timeofday + frame_ts
Best Regards,
Paulo
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
V4L Camera frame timestamp question
Hi, I'm currently using the V4L-DVB driver to control a few logitech webcams and playstation eye cameras on a Gubuntu system. Everything works just fine except one thing: the buffer timestamp value seems wrong. The way I get the timestamp value is through the v4l2_buffer struct like this: struct v4l2_buffer buf; CLEAR(buf); buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory = V4L2_MEMORY_MMAP; assert(ioctl(fd_, VIDIOC_DQBUF, buf)); printf(timestamp = %.3f, buf.timestamp.tv_sec + buf.timestamp.tv_usec / 100); this should be the timestamp of when the image is taken (similar to gettimeofday() function) but the value I got is something way smaller (e.g. 75000) than what it should be (e.g. 1275931384) Is this a known problem? Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
