-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RangeError [ERR_OUT_OF_RANGE]: The value of "byteLength" is out of range. It must be >= 1 and <= 6. Received 8 #4
Comments
@pjsg: this is an upstream error in I've also backported it to Further details about the different versions in this issue comment. Do they work for you? |
@joelpurra I tried the forked code locally on my Mac - Seems like the export just creates an empty file now for me. |
@joelpurra I also get an empty export -- but if you add --verbose, then you get
|
- Test forked backport of the 8 bit read/write fix in `node-uvc-control`. See - #4 - makenai/node-uvc-control#28
I added the following line in
and, rather surprisingly, it output:
i.e. the buffer only had 1 byte in it, in spite of being asked to read 2 bytes. If I just make this return None, then I get
which looks plausible. |
@scarrawaySF: that is the same result as reported in #3. Do you also use a Microsoft® LifeCam Studio(TM)? (Asking to verify that you didn't happen to use the wrong vendor/product ids, although I think there would also be another error trying to @pjsg: the |
@joelpurra Yes I'm also using the Lifecam Studio - happy coincidence I suppose. |
@pjsg: you'll find the per-control byte sizes in the same |
To reduce impact from other fixes in that branch, I've separated the relevant commit in my Successfully tested the branches in both Linux (Ubuntu 19.10) and macOS (10.14.6 Mojave) using a Logitech c920. Tested in both Node.js v12.16.1 and v13.11.0.
Am not exactly an expert in the low-level UVC/USB fields; am mostly relying on the source code of |
I changed readints to
and things are (sort of) working. This change to After saying all of that, I have found that setting the lifecam studio brightness to 20 is too dark, and setting it to 21 is much too light. The setting only works in autoExposureMode 1. Hmm... |
In my case, it was the backlightCompensation control that has a length of 1 (and a range of 1 -> 1!) |
@pjsg: the UVC standard seems to say 2 bytes in 4.2.2.3.1 Backlight Compensation Control on page 96 (or 111) in |
@pjsg: redefining I think there's a chance that the second byte has a null
const originalFourBytes = Buffer.from("abcd");
console.log(originalFourBytes.length, originalFourBytes);
const readThreeBytes = originalFourBytes.slice(0, 3);
console.log(readThreeBytes.length, readThreeBytes);
const readFourBytes = originalFourBytes.slice(0, 4);
console.log(readFourBytes.length, readFourBytes);
// NOTE: only receive four bytes, not five.
const readFiveBytes = originalFourBytes.slice(0, 5);
console.log(readFiveBytes.length, readFiveBytes); The above hints to having to pad the bytes read from the camera, presumably with This also relates to the "actual" length of the data read from the camera. Apparently there are recent |
I've updated the test branch. Am now adding extra The output doesn't change for me though, neither in Linux nor macOS. Does it help anyone else?
1 Since the bytes come from a lower level in the computer hardware (and software) architecture, the byte order and endianess might matter. If so, I am not sure how, and think it should be (have been) handled on a lower level already. |
I ran
|
@pjsg: are the control's values from the above Interestingly, a whole bunch of the controls are listed twice (with the same name and values) in the Single
Duplicated
By the way, just found this note about Microsoft LifeCam Studio (045e:0772). Might be a hardware/firmware issue?
|
This is the exact data that I get from
The backlight compensation is shown by v4l2-ctl as being between 1 and 10 rather than 1 to 1.
The interesting differences are that v4l2-ctl shows the exposure_mode as 3 and type menu. I suspect that this is really meaning bit 3 (i.e. a value of 8). The backlight compensation shows as value 5 in vtl2-ctl whereas uvcc shows 1. There are some extra parameters shown in the v4l2-ctl, but I expect that those could be added fairly easily. |
Wonder if the Yeah, the auto exposure mode is a bitmap (4.2.2.1.2 Auto-Exposure Mode Control, page 82/97). The
The upcoming v2 version of |
I thought that you were using your own version of uvc-control..... I'm going to try and see how this camera behaves on windows. I think that I can capture the USB transactions with wireshark -- and see how they differ from the transactions on OSX. |
The windows capture shows backlight compensation being returned as two bytes with the range of 0 to 10. Curiously enough there did appear to be multiple endpoints and may behaved differently. I'm not sure if that is the root cause or not. When I plug in the camera into OSX and I'm capturing in wireshark, then it enumerates the controls and pulls back the range of 0 - 10 for backlight compensation. I now understand what is going on (but I don't know how to fix it). If I change the getUnitOverride method to:
Then the output of uvcc ranges is
This is much better and seems to align with what windows sees. The CameraFactory doesn't seem to set these options and I don't know which layer ought to set those options. But I think that fixes this would help immensely. |
I think that you need to do a "get configuration descriptor" operation. When the camera is plugged in, the OS seems to do this, and it returns (partially expanded) the blob below. I expanded the bit that shows how to get the value 4 for the Processing Unit. The OS seemed to do two requests -- the first request was for a length of 9 which returned the CONFIGURATION DESCRIPTOR below -- which includes the total length of the descriptor. The second request was for that length. I've also pasted this operation below.
Get request
|
I am not a JS developer and the intricacies of libusb are a bit beyond me, but I want to say thank you both for the great work and also for such an involved thread. I added from above,
and suddenly I'm able to run
on my Microsoft Lifecam to adjust the crazy white balance. :) A few of the other settings don't work as expected, but that was really the biggest one |
I changed
to
|
Nice work @joelpurra |
Thank you guys for testing the fixes: @pjsg, @Blisse, @nick-gray!
@pjsg: yes, but I don't want to maintain a fork. All changes should be merged into the upstream
@pjsg: nice digging! Would not have thought to go as deep as using wireshark. I've cut out a bunch of lines and kept what seems relevant to this issue.
These things seem to have been taken care of in
There's plenty of intricacies in the UVC/USB standards, down to the bits and bytes level in hardware. Applying the unit id or control byte size fixes above might work for some cameras, but would instead break support for for example my camera. Dynamically detecting these per-camera values is indeed the way to go, meaning it's time to upgrade to Created an experimental v2-next version of
git clone "git@github.com:joelpurra/uvcc.git"
cd uvcc
git checkout feature/uvc-control-v2-next
rm -r node_modules/
npm install
./index.js --verbose ranges
./index.js --verbose export Please include the vendor and product ids with each post. Does the output look ok? Does it require any fixes? |
My output is:
It is missing attributes like the zoom control..... -- but this can be fixed in uvc-control/index.js -- adjust the initialization of this.ids to be:
Then I get:
|
@pjsg: it seems your Judging by the missing controls, which belong to the input terminal, I suspect you made a change affecting While not up to par with git clone "git@github.com:joelpurra/uvcc.git"
cd uvcc
git checkout feature/uvc-control-v2-next
git pull
rm -r node_modules/
npm install
./index.js --verbose ranges
./index.js --verbose export
# NOTE: not all settings can be set if they're in auto-mode -- fix pending.
./index.js --verbose export | ./index.js --verbose import There are still bugs, both in Hope this also works for cameras other than the c920 =) |
My change was to change an |
- Fixes typo which affected `CT` control types. Fixes joelpurra/uvcc#4 See - joelpurra/uvcc#4
Released |
I'm running this on Max OSX 10.14.6 and the export command crashes (I have a Microsoft Lifecam Studio plugged in)
Any thoughts? I'm prepared to do debugging....
The text was updated successfully, but these errors were encountered: