Hi Alexey,
Thanks a lot for your testing and report ! :)
Your test and mine show that webcams seem to be implementing the UVC
spec correctly regarding timestamping.
I mean :
(*) Putting PTS for each packet
(*) Putting SCR for each packet
(*) Having the same PTS for each packet of the same frame
(*) Having different SCR for each packet of the same frame
Well, about FID/EOF bugs, I guess a change of PTS can be interpreted as
"the beginning of a new frame", so it may be useful in case of a webcam
having troubles signaling new frames using the usual FID/EOF bits.
I am new to this (UVC), so you may need to confirm with someone else
(Laurent ?) what I just wrote, but to me it makes sense to interpret a
change of PTS as a "new frame".
Reading the code I noticed a few "quirks" used to workaround webcams not
implementing correctly the UVC spec regarding FID and EOF bits.
Are there webcams which have both problems ? (not making FID toggle, and
not specifying EOF ?)
Thanks !
Regards,
Yann
On 06/12/2011 09:53 PM, Alexey Fisher wrote:
Hi Yann,
here is the log from one of my cams. It is really cheap webcam
integrated in my netbooḱ. lsusb info and kernel log are attached.
If i understand correctly, PTS can be used to work with some FID/EOF
bugs?
On So, 2011-06-12 at 17:33 +0200, Yann Sionneau wrote:
Hi Alexey,
Agreed, but bear in mind this patch I submitted is not for inclusion and
merge in the git tree, it is just for testing purpose, it will never be
merged in the git.
This is just a one shot patch to show some informations and then you can
throw it away once you have the informations.
But yes I could make it use the uvc_trace() API, it won't kill me :)
Thanks for your feed back on the patch, do you have the time to test it
on your webcams and to publish part of your syslog ?
Regards,
Yann
Le 12/06/11 08:24, Alexey Fisher a écrit :
Hi,
please use "uvc_trace(UVC_TRACE_DESCR," or pr_debug instead of printk.
So you can enable verbosity only if you need.
On Di, 2011-06-07 at 17:56 +0200, Yann Sionneau wrote:
Hi again,
here is as attached file a new patch that applies to linux 2.6.39 tree
(linux-2.6.git, tag v2.6.39).
This patch now prints at the end of each stream :
(*) total number of PTS (taking into account each packet)
(*) total number of SCR
(*) total number of ERR
(*) number of packets without PTS (nb_missing_pts)
(*) number of packets without SCR (nb_missing_scr)
It will print as well for each packet (beware, it will hugely flood your
syslog) :
(*) SCR
(*) diff with previous packet's SCR
(*) PTS
(*) diff with previous packet's PTS
Beware, to see the "end of stream" statistics, you have to scroll up a
little bit, it will be somewhere in the end of the per-packet
information flood.
Some results inline in the e-mail.
On 06/06/2011 11:22 PM, Yann Sionneau wrote:
Le 06/06/11 19:42, Laurent Pinchart a écrit :
Hi Yann,
Thanks for the patch.
On Friday 03 June 2011 15:48:59 Yann Sionneau wrote:
Hi Laurent and the UVC list,
Here is a patch [snip]
You should take all UVC packets into account, not just the first one for each
frame.
Yes I don't know why in my head I thought only the first uvc packet
would have a header for the frame with timestamps and such, but it makes
no sense, each packet has its own header and the start of frame is just
signaled by the toggling of the FID :)
the important information are
- do all frames have a PTS timestamp in their first packet ?
It seems so yes, at least on the two webcams I tried with the patch.
- do all non-empty packets for a frame have a PTS timestamp, and is it
constant through the whole frame as it should be ?
Let's modify the patch to count the PTS and SCR of all packets instead
of only one per frame in order to sort this out !
I tested with the Logitech HD Pro C910, all packets have a PTS.
PTS are indeed constant through the whole frame as it should be.
- how many SCR timestamps do we have per frame ? are they constant through the
whole frame or do they vary as they should ?
Same here !
With the same webcam, all packets have a SCR.
The SCR value does vary through each frame, as it should do.
The difference between the previous SCR is usually the same, except at a
regular interval where there is a "jump" in SCR values.
for example, SCR - SCR_prev would be 7 times the same difference, and
then it will change for just one time, and then go back to the old
difference for 7 times etc.
[snip]
Thanks for your review and comments, will submit a new patch ASAP !
_______________________________________________
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
