V4L Camera frame timestamp question

V4L Camera frame timestamp question

[jiajun]

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 /
1000000);

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!

Re: V4L Camera frame timestamp question

[Jean-Francois Moine]

On Thu, 10 Jun 2010 03:24:05 +0000 (UTC)
jiajun <zhujiajun@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/

Re: V4L Camera frame timestamp question

[Paulo Assis]

2010/6/10 Jean-Francois Moine <moinejf@free.fr>:
> On Thu, 10 Jun 2010 03:24:05 +0000 (UTC)
> jiajun <zhujiajun@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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: V4L Camera frame timestamp question

[Paulo Assis]

Hi,

2010/6/10 Jiajun Zhu <zhujiajun@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 * 1000000000 +
buf.timestamp.tv_usec *1000;

frame_ts =  ((uint64_t) buf.timestamp.tv_sec * 1000000000 +
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