Thank you for this data! Looks like 1.6% of all frames are lost. I noticed
that the jitter always start with a very long delay, and they seem to be
quite regular. I have attached a histogram over the time between the
jitters, and the jitter seems to occur at multiples of 80 frames. Hard to
say where it comes from, but it might be a buffering problem?
Hmm, yeah, that is interesting. Could be USB bus contention, or maybe disk activity or something.
> Whether or not this jitter is big enough to cause a problem depends on
> how synchronized you need frames from the cameras to be: the jitter I
> show above is quite tolerable for my purposes.
While I haven't calculated the tolerable amount yet, I think I probably need
to synchronize the image streams after they have been captured.
After processing my 15fps streams, I find that I can get the frames synchronized to within about 0.02 seconds, meaning that there's a spread of about 0.02 seconds between the frames that I'm assigning to the same time slot. That's good enough for me... :)
> I actually had a
> breakthrough last night, when I realized my audio/visual synch wasn't
> caused by the video frames being non-uniform, but rather that the audio
> I recorded from the USB mics isn't correct. When I matched the video up
> against the audio from a DV video camera filming the same scene,
> everything looked fine (wrt synch). Yay!
Good to know. But actually the video frames should be approximately 1.6%
faster than the audio, based on the data you posted. Maybe that amount is
harder to notice, but after two hours, the difference would be 115 seconds?
Well, because I'm timestamping the frames as I capture them, I can figure out which ones are missing and duplicate others to fill in. When the video is played, the duping makes it look like the scene is frozen, but it's only very brief, so that's cool.
Denis
_______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
