Re: [Linux-uvc-devel] Quirk for mjpeg bandwidth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Philip,
replace the patch from you collection with this one :)
play with it carefully.
To reduce bandwidth for jpeg set quirks to 0x440
you can also reduce probable compression ratio for calculator by setting
jpg_compression=1 or other number. default is 4.
with 1 i get some times corrupted images.
Am 17.11.2011 17:29, schrieb Philip Gladstone:
> I have put the patches that I am using on:
> http://pskreporter.info/uvc.pf
>
> Unfortunately, these patches also include a change to convert from
> uvc_trace to pr_debug, so there are a lot more changes than
> necessary.
>
> Philip
>
> On 11/17/2011 11:03 AM, Sandro Hawke wrote:
>>> Could I be a pain and ask for a link to the thread about the
>>> patch, or to the patch itself please.
>> I would very much appreciate this, too.
>>
>> - Sandro
- --
Regards,
Alexey
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7qYKIACgkQw8E0jNwoJm+8lgCglVquyr5CEsv1lBqVlftDWq5y
Ma8An0PHVjgKQW+InCIkF6HD/Y/752c9
=ds+g
-END PGP SIGNATURE-
diff --git a/drivers/media/video/uvc/uvc_driver.c b/drivers/media/video/uvc/uvc_driver.c
index a240d43..8bf364c 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -48,6 +48,7 @@ unsigned int uvc_no_drop_param;
static unsigned int uvc_quirks_param = -1;
unsigned int uvc_trace_param;
unsigned int uvc_timeout_param = UVC_CTRL_STREAMING_TIMEOUT;
+unsigned int uvc_jpeg_comp_param;
/*
* Video formats
@@ -365,6 +366,10 @@ static int uvc_parse_format(struct uvc_device *dev,
format->fcc = V4L2_PIX_FMT_MJPEG;
format->flags = UVC_FMT_FLAG_COMPRESSED;
format->bpp = 0;
+ if ((uvc_jpeg_comp_param > 0) && ( 16 >= uvc_jpeg_comp_param))
+ format->bpp = uvc_jpeg_comp_param;
+ else
+ format->bpp = 4;
ftype = UVC_VS_FRAME_MJPEG;
break;
@@ -2026,6 +2031,8 @@ module_param_named(trace, uvc_trace_param, uint, S_IRUGO|S_IWUSR);
MODULE_PARM_DESC(trace, "Trace level bitmask");
module_param_named(timeout, uvc_timeout_param, uint, S_IRUGO|S_IWUSR);
MODULE_PARM_DESC(timeout, "Streaming control requests timeout");
+module_param_named(jpg_compression, uvc_jpeg_comp_param, uint, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(jpg_compression, "JPG compression ratio for bandwidth quirk");
/*
* Driver initialization and cleanup
diff --git a/drivers/media/video/uvc/uvc_video.c b/drivers/media/video/uvc/uvc_video.c
index db0ba20..b417ca4 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -120,8 +120,10 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream,
ctrl->dwMaxVideoFrameSize =
frame->dwMaxVideoFrameBufferSize;
- if (!(format->flags & UVC_FMT_FLAG_COMPRESSED) &&
- stream->dev->quirks & UVC_QUIRK_FIX_BANDWIDTH &&
+ if ((!(format->flags & UVC_FMT_FLAG_COMPRESSED) ||
+ (format->fcc == V4L2_PIX_FMT_MJPEG)) &&
+ (stream->dev->quirks & UVC_QUIRK_FIX_BANDWIDTH ||
+ stream->dev->quirks & UVC_QUIRK_FIX_JPEG_BANDWIDTH) &&
stream->intf->num_altsetting > 1) {
u32 interval;
u32 bandwidth;
@@ -150,7 +152,8 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream,
* resolutions working while not preventing two simultaneous
* VGA streams at 15 fps.
*/
- bandwidth = max_t(u32, bandwidth, 1024);
+ if(!(stream->dev->quirks & UVC_QUIRK_DISABLE_URB_1024))
+ bandwidth = max_t(u32, bandwidth, 1024);
ctrl->dwMaxPayloadTransferSize = bandwidth;
}
diff --git a/drivers/media/video/uvc/uvcvideo.h b/drivers/media/video/uvc/uvcvideo.h
index 50c9490..a738ac8 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -122,9 +122,11 @@
#define UVC_QUIRK_BUILTIN_ISIGHT 0x0008
#define UVC_QUIRK_STREAM_NO_FID 0x0010
#define UVC_QUIRK_IGNORE_SELECTOR_UNIT 0x0020
+#define UVC_QUIRK_FIX_JPEG_BANDWIDTH 0x0040
#define UVC_QUIRK_FIX_BANDWIDTH 0x0080
#define UVC_QUIRK_PROBE_DEF 0x0100
#define UVC_QUIRK_RESTRICT_FRAME_RATE 0x0200
+#define UVC_QUIRK_DISABLE_URB_1024 0x0400
/* Format flags */
#define UVC_FMT_FLAG_COMPRESSED 0x0001
___
Linux-uvc-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quirk for mjpeg bandwidth
I have put the patches that I am using on: http://pskreporter.info/uvc.pf Unfortunately, these patches also include a change to convert from uvc_trace to pr_debug, so there are a lot more changes than necessary. Philip On 11/17/2011 11:03 AM, Sandro Hawke wrote: Could I be a pain and ask for a link to the thread about the patch, or to the patch itself please. I would very much appreciate this, too. - Sandro ___ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel -- Philip Gladstone Ham: N1DQ ___ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quirk for mjpeg bandwidth
> Could I be a pain and ask for a link to the thread about the patch, or > to the patch itself please. I would very much appreciate this, too. - Sandro ___ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quirk for mjpeg bandwidth
On 02/11/11 18:17, Philip Gladstone wrote: On 11/2/2011 12:19 PM, Andrew Burgess wrote: i looked at this for similar reasons as you a few months ago. as i recall, there was just one line to change to essentially disable the bandwidth limitations, just changing the calculated bandwidth to always be one (or something like that). my requirements changed and i never got as far as testing it with multiple cameras. if you can make this change and collect data about how well your system then works you might have a better chance to get some sort of sysfs control to disable bandwidth checks into mainstream. I have been running 3 Logitech C910s simultaneously capturing full resolution (5MP) video at the slowest rate (5 FPS) with one of the patch sets. It has been stable for me. Philip Hi Philip, Could I be a pain and ask for a link to the thread about the patch, or to the patch itself please. Thank you, Sebastian ___ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quirk for mjpeg bandwidth
On 11/2/2011 12:19 PM, Andrew Burgess wrote: i looked at this for similar reasons as you a few months ago. as i recall, there was just one line to change to essentially disable the bandwidth limitations, just changing the calculated bandwidth to always be one (or something like that). my requirements changed and i never got as far as testing it with multiple cameras. if you can make this change and collect data about how well your system then works you might have a better chance to get some sort of sysfs control to disable bandwidth checks into mainstream. I have been running 3 Logitech C910s simultaneously capturing full resolution (5MP) video at the slowest rate (5 FPS) with one of the patch sets. It has been stable for me. Philip -- Philip Gladstone Ham: N1DQ ___ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quirk for mjpeg bandwidth
On 02/11/11 16:19, Andrew Burgess wrote: On 11/02/2011 06:14:19 AM, Sebastian Arcus wrote: On 31/10/11 23:14, Sebastian Arcus wrote: > I seem to recall some discussion about a hack/patch/quirk to get > several of the newer HD cameras to work in mjpg mode on a single usb > hub/bus. i looked at this for similar reasons as you a few months ago. as i recall, there was just one line to change to essentially disable the bandwidth limitations, just changing the calculated bandwidth to always be one (or something like that). my requirements changed and i never got as far as testing it with multiple cameras. if you can make this change and collect data about how well your system then works you might have a better chance to get some sort of sysfs control to disable bandwidth checks into mainstream. hth Hi Andrew, Thanks for replying. I think I can just about make sense of the part about disabling the bandwidth limitation in code. My programming skills in C are less than basic (I assume the uvc driver is written in C?) - but I will try nevertheless to see if I can get anywhere. Sebastian ___ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quirk for mjpeg bandwidth
On 11/02/2011 06:14:19 AM, Sebastian Arcus wrote: On 31/10/11 23:14, Sebastian Arcus wrote: > I seem to recall some discussion about a hack/patch/quirk to get > several of the newer HD cameras to work in mjpg mode on a single usb > hub/bus. i looked at this for similar reasons as you a few months ago. as i recall, there was just one line to change to essentially disable the bandwidth limitations, just changing the calculated bandwidth to always be one (or something like that). my requirements changed and i never got as far as testing it with multiple cameras. if you can make this change and collect data about how well your system then works you might have a better chance to get some sort of sysfs control to disable bandwidth checks into mainstream. hth ___ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
Re: [Linux-uvc-devel] Quirk for mjpeg bandwidth
On 31/10/11 23:14, Sebastian Arcus wrote: I seem to recall some discussion about a hack/patch/quirk to get several of the newer HD cameras to work in mjpg mode on a single usb hub/bus. Does anybody know if this has made it into the uvc driver, and if yes, after which version. Just to clarify, I am after the patch which tries to overcome the cameras requesting too much bandwidth in mjpeg mode - not regular yuyv. I believe some of the original discussion referred to a Logitech C910. I need to run four MS Lifecam Studio's on the same usb root hub in 800x600 / 10fps mode - if possible. I believe there should be enough bandwidth - if I can just convince the cameras and the uvc driver to play together somehow. Many thanks in anticipation, Sebastian Bump. Anybody? It would be really nice if there was a quirk which just allowed the specification of a fixed bandwidth at user's choice, on loading the kernel module. Thus, one could find out through trial and error, by using different numbers, what bandwidth can be used with a certain camera model, at a certain resolution and fps - on mjpeg. I suspect this would break the standard, but there seems to be no other way to make an increasing number of really good quality HD cameras work on multiple camera setups - although the numbers indicate there should be enough bandwidth to make even 4 of them work at the same time, on same usb root hub, in mjpeg streaming mode. Any contributions much appreciated. Sebastian ___ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
