OT: guvcview timing bug?

Upon complaint (or request), starting in a new thread:

As stated before, i am programming a Linux laptop for surveillance. I am using "time guvcview --no_display --exit_on_close -f jpeg -c 1 -m 1 -i img.jpg" to capture images as fast as possible. However,

"-c 0 -m 1" ignore all options "-c 1 -m 1" take 2.7 seconds "-c 1 -m 60" take 1 min and 2.7 seconds "-c 2 -m 1" take 4.7 seconds "-c 3 -m 1" take 6.7 seconds

Seems like there are extra 2 c seconds delays in most cases. Does it sound like a bug?

Reply to
edward.ming.lee
Loading thread data ...

Maybe. Is it possibly auto-probing for camera(s) and timing out when it doesn't find all of them it supports? (For example, if it supports up to four cameras, and you only have one, there might be some delay while it looks for the three other cameras that aren't there.)

If you want to get a lot of detail, use "strace". It runs a program you specify and shows you *all* the system calls the program is making, as it makes them. It tries to print as many of the system call arguments in a human-readable form as possible, so instead of stuff like "open(0xdeadbeef, 32)" you get "open("/dev/foo1", O_RDONLY)" - it's not too hard to see what the program is trying to do. strace also has options to print the time of day with each line, optionally with microsecond resolution, or the time each system call takes, (-t, -tt,

-ttt, -T), so you can see where the "time hogs" are. Read the strace man page - it has a lot of options.

You can use strace just like you are using "time" now. strace outputs all its stuff to standard error, so it's useful to redirect it, or use the -o option to strace to put its output in a file:

strace -tt -T guvcview --no_display --exit_on_close -f jpeg -c 1 -m 1 -i img.jpg 2>guvcview-strace.txt

(or)

strace -tt -T -o guvcview-strace.txt guvcview --no_display --exit_on_close -f jpeg -c 1 -m 1 -i img.jpg

If you don't have strace now, it should be available from the same place other packages (.deb/.rpm) come from in your distribution.

Matt Roberds

Reply to
mroberds

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.