Same with the ACER tablet cameras.

Alan

This is a huge disappointment for my project. Robot head made to have tablet intergrated..I don't have place to put ezb camera....

Both my acer w3 and Dell tablets won't do video in any resolution...

Does anyone know what video resolutions they do support? What's with this non-standard video cameras on hardware like that - geez whiz!

I am not sure they are non standard. That was your answer when we first reported this last year. This evening I'll fire up the Acer with some other video tools and see if I can determine what is supported.

Alan

here are display resolutions: https://en.wikipedia.org/wiki/Graphics_display_resolution

QVGA and VGA are the most popular of any video capture or display device. If they do not support those, it's a non standar - this is because resolutions are inherit. They are fractions of each other, which is relative to memory size for scaling. If you can tell me what resolution to expect, i can look into adding support for it.

So, I can obviously only answer for the Acer, but using the old AMCAP app that used to ship with every web cam, and looking at the Video Pin properties, it supports the following resolutions:

448x252 (that is probably the weird one) 640x480 (normal, and supported by ARC but still causes the crash) 1280x720 1920x1080

The frame rate may be the issue. it is showing as 29.970 and the up/down arrows to adjust frame rate are not available. If I type in a different frame rate it jumps back to 29.970, so I can't try changing it.

Alan

The frame rate of ARC is slave to the frame rate of the capture device. The option in ARC merely skips frames, it doesn't actually control the framerate.

This was because the original ARC many years ago tried to control the frame rate with great difficulty. Most brand name camera manufacturers were great at meeting direct show requirements - however, that's not helpful for cheap china cameras and such which is pretty much 90% of anyone from this forum that has external usb webcams on their robot.

So the solution was grab the frame at any rate that it can be processed, and skip any frames outside of processing capability. This gives the device permission to do what the heck it wants - all ARC cares is that an image is loaded into the register.

If the 640x480 is causing a crash, yet it is still supported - i'm quite confused because ARC uses the native microsoft direct show driver, without any modifications. Does the crash produce an error log? That might be useful to help me diagnose.

I can add 1280x720 as a resolution - but i doubt any of your or our computers are powerful enough to process that resolution at a usable framerate.

Quick math...

320x240: 76,800 pixels at 3 bytes per pixel = 230,400 byte filesize per frame

1280x720: 921,600 pixels at 3 bytes per pixel = 2,764,800 byte filesize per frame

That's 12 times the file size per frame. So if your computer, like mine, is processing ARC video at 5% cpu, multiply that by 12...

And video processing in ARC is multi threaded. There is a thread for the video capture, a thread for accepting the frame, and a thread for processing the frame. So it's cross core distributed as much as possible - at least without splitting each "Tracking type" into a separate thread, which i guess would introduce a whole new pile of thread blocking performance issues which will be counter-productive.

A little off topic... but it's an option if you really want 1280x720 resolution added to ARC. My concern is that people will actually select it and think "it's an option, so it must work" - and then be quite upset that they're cpu is 100% and getting 1 frame per second