Re: offering bounty for GPL'd dual em28xx support
On Wed, 22 Jul 2009, Mauro Carvalho Chehab wrote: Em Wed, 22 Jul 2009 11:06:12 -0400 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: On Wed, Jul 22, 2009 at 11:01 AM, Jelle de Jongjelledej...@powercraft.nl wrote: Funky timing of those mails :D. I saw only after sending my mail that Steve was talking about analog and that this is indeed different. Dual analog tuner support should be possible right? Maybe with some other analog usb chipsets? I don't know what the usb blocksize is or if they are isochronous transfers or bulk or control. I assume the video must be uncompressed transferred over usb because the decoding chip is on the usb device is not capable of doing compression encoding after the analog video decoding? Are there usb devices that do such tricks? There were older devices that did compression, mainly designed to fit the stream inside of 12Mbps USB. However, they required onboard RAM to buffer the frame which added considerable cost (in addition to the overhead of doing the compression), and as a result pretty much all of the USB 2.0 designs I have seen do not do any on-chip compression. The example which comes to mind is the Hauppauge Win-TV USB which uses the usbvision chipset. pvrusb2 also has compression, provided by an external mpeg encoder. Those devices are USB 2.0 I know this is a fairly old thread, but I've been away on vacation and I'm catching up on e-mail right now. So forgive me if this has already been answered... The Hauppauge Win-TV PVR-USB2 is the most well-known device in this category and it's what the pvrusb2 driver originally targeted. This device uses a dedicated mpeg encoder chip within the device, so the video stream coming from the hardware is actually compressed video (mpeg format, mostly DVD-style mpeg2). The question of USB 1.1 vs USB 2.0 is actually due to the device's microcontroller (the bridge chip) not the mpeg encoder. In the pvrusb2 case, that controller is a Cypress FX2 which includes an on-chip USB 2.0 high-speed device interface. But the mpeg encoder actually doesn't REQUIRE USB 2.0 high-speed. The default encoder settings configured by the pvrusb2 driver actually work quite well over USB 1.1, since the resulting video stream requires significantly less bandwidth than the 12Mbps that USB 1.1 can theoretically supply. I've actually successfully tested such a configuration here. The hardware works fine over USB 1.1. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: offering bounty for GPL'd dual em28xx support
Devin Heitmueller wrote: snip The issue occurs with various different drivers. Basically the issue is the device attempts to reserve a certain amount of bandwidth on the USB bus for the isoc stream, and in the case of analog video at 640x480 this adds up to about 200Mbps. As a result, connecting multiple devices can result in exceeding the available bandwidth on the USB bus. Depending on your how many devices you are trying to connect, what your target capture resolution is, and whether you can put each device on its own USB bus will dictate what solution you can go with. Hi all, So I felt like doing a field test, with my dvb-t test system. Bus 001 Device 008: ID 2040:6502 Hauppauge WinTV HVR-900 Bus 001 Device 007: ID 2304:0226 Pinnacle Systems, Inc. [hex] PCTV 330e Bus 001 Device 005: ID 0b05:173f ASUSTek Computer, Inc. Bus 001 Device 003: ID 2304:0236 Pinnacle Systems, Inc. [hex] Bus 001 Device 002: ID 15a4:9016 I have now three devices with dvb-t channels running with different channels and audio on an atom based cpu without problems. two: dvb-usb-dib0700 and one: dvb-usb-af9015 the dvb-usb-af9015 takes way more cpu interrupts because of the usb block size. prove: http://imagebin.ca/img/xM9Q7_A.jpg I will be demonstrating this at har2009 (see demonstration village) Devin could you login onto the dvb-t test system and see if you can get those em28xx device running with your new code? I will probably make an other test system with some more cpu power to see if even more usb devices are possible, or I may use my nice powerful multiseat quad core system for it. Best regards, Jelle de Jong -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: offering bounty for GPL'd dual em28xx support
Em Wed, 22 Jul 2009 12:10:38 +0200 Jelle de Jong jelledej...@powercraft.nl escreveu: Devin Heitmueller wrote: snip The issue occurs with various different drivers. Basically the issue is the device attempts to reserve a certain amount of bandwidth on the USB bus for the isoc stream, and in the case of analog video at 640x480 this adds up to about 200Mbps. As a result, connecting multiple devices can result in exceeding the available bandwidth on the USB bus. Depending on your how many devices you are trying to connect, what your target capture resolution is, and whether you can put each device on its own USB bus will dictate what solution you can go with. Hi all, So I felt like doing a field test, with my dvb-t test system. Bus 001 Device 008: ID 2040:6502 Hauppauge WinTV HVR-900 Bus 001 Device 007: ID 2304:0226 Pinnacle Systems, Inc. [hex] PCTV 330e Bus 001 Device 005: ID 0b05:173f ASUSTek Computer, Inc. Bus 001 Device 003: ID 2304:0236 Pinnacle Systems, Inc. [hex] Bus 001 Device 002: ID 15a4:9016 I have now three devices with dvb-t channels running with different channels and audio on an atom based cpu without problems. two: dvb-usb-dib0700 and one: dvb-usb-af9015 the dvb-usb-af9015 takes way more cpu interrupts because of the usb block size. prove: http://imagebin.ca/img/xM9Q7_A.jpg I will be demonstrating this at har2009 (see demonstration village) Devin could you login onto the dvb-t test system and see if you can get those em28xx device running with your new code? I will probably make an other test system with some more cpu power to see if even more usb devices are possible, or I may use my nice powerful multiseat quad core system for it. Best regards, Jelle de Jong Jelle, DVB-T is less consuming than analog, since the streams are mpeg compressed. The issue with em28xx is that, on analog mode, all data come uncompressed. So, the worse case is a NTSC stream with 16 bit YUY2 frame with using 720x480x30x2 Mbps (e. g. 207 Mbps) for the payload, plus some additional bandwidth for the transport headers. On HD, mpeg stream are up to 23 Mbps on DTV systems (ISDB full-seg is the worse case on DTV). So, analog demands about 9x more bandwidth than digital at USB bus. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: offering bounty for GPL'd dual em28xx support
On Wed, Jul 22, 2009 at 6:10 AM, Jelle de Jongjelledej...@powercraft.nl wrote: So I felt like doing a field test, with my dvb-t test system. Bus 001 Device 008: ID 2040:6502 Hauppauge WinTV HVR-900 Bus 001 Device 007: ID 2304:0226 Pinnacle Systems, Inc. [hex] PCTV 330e Bus 001 Device 005: ID 0b05:173f ASUSTek Computer, Inc. Bus 001 Device 003: ID 2304:0236 Pinnacle Systems, Inc. [hex] Bus 001 Device 002: ID 15a4:9016 I have now three devices with dvb-t channels running with different channels and audio on an atom based cpu without problems. two: dvb-usb-dib0700 and one: dvb-usb-af9015 the dvb-usb-af9015 takes way more cpu interrupts because of the usb block size. prove: http://imagebin.ca/img/xM9Q7_A.jpg I will be demonstrating this at har2009 (see demonstration village) Devin could you login onto the dvb-t test system and see if you can get those em28xx device running with your new code? I will probably make an other test system with some more cpu power to see if even more usb devices are possible, or I may use my nice powerful multiseat quad core system for it. Hello Jelle, Please understand that your experiment isn't really an appropriate test. The original user was referring to analog capture mode, in which the uncompressed video is coming across the USB bus. Analog mode uses about 200Mbps while digital mode uses only 10-20Mbps. If you had tried capturing analog video with those devices you would have seen similar results to what Steve described. I haven't forgotten about your test environment, and I look forward to getting the HVR-900 R2 and PCTV 330e working. I have been sick in bed for the last two days and have done no LinuxTV related work. I look forward to getting back to it this week. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: offering bounty for GPL'd dual em28xx support
On Wed, Jul 22, 2009 at 4:48 PM, Mauro Carvalho Chehabmche...@infradead.org wrote: Em Wed, 22 Jul 2009 12:10:38 +0200 Jelle de Jong jelledej...@powercraft.nl escreveu: Devin Heitmueller wrote: snip The issue occurs with various different drivers. Basically the issue is the device attempts to reserve a certain amount of bandwidth on the USB bus for the isoc stream, and in the case of analog video at 640x480 this adds up to about 200Mbps. As a result, connecting multiple devices can result in exceeding the available bandwidth on the USB bus. Depending on your how many devices you are trying to connect, what your target capture resolution is, and whether you can put each device on its own USB bus will dictate what solution you can go with. Hi all, So I felt like doing a field test, with my dvb-t test system. Bus 001 Device 008: ID 2040:6502 Hauppauge WinTV HVR-900 Bus 001 Device 007: ID 2304:0226 Pinnacle Systems, Inc. [hex] PCTV 330e Bus 001 Device 005: ID 0b05:173f ASUSTek Computer, Inc. Bus 001 Device 003: ID 2304:0236 Pinnacle Systems, Inc. [hex] Bus 001 Device 002: ID 15a4:9016 I have now three devices with dvb-t channels running with different channels and audio on an atom based cpu without problems. two: dvb-usb-dib0700 and one: dvb-usb-af9015 the dvb-usb-af9015 takes way more cpu interrupts because of the usb block size. prove: http://imagebin.ca/img/xM9Q7_A.jpg I will be demonstrating this at har2009 (see demonstration village) Devin could you login onto the dvb-t test system and see if you can get those em28xx device running with your new code? I will probably make an other test system with some more cpu power to see if even more usb devices are possible, or I may use my nice powerful multiseat quad core system for it. Best regards, Jelle de Jong Jelle, DVB-T is less consuming than analog, since the streams are mpeg compressed. The issue with em28xx is that, on analog mode, all data come uncompressed. So, the worse case is a NTSC stream with 16 bit YUY2 frame with using 720x480x30x2 Mbps (e. g. 207 Mbps) for the payload, plus some additional bandwidth for the transport headers. On HD, mpeg stream are up to 23 Mbps on DTV systems (ISDB full-seg is the worse case on DTV). 207Mbps?? 720*480*30 = 20736000 bytes == 19.78 Mbyte == 158.20 Mbit sure there's some overhead but your calculation is wrong. Markus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: offering bounty for GPL'd dual em28xx support
Devin Heitmueller wrote: On Wed, Jul 22, 2009 at 6:10 AM, Jelle de Jongjelledej...@powercraft.nl wrote: So I felt like doing �a field test, with my dvb-t test system. Bus 001 Device 008: ID 2040:6502 Hauppauge WinTV HVR-900 Bus 001 Device 007: ID 2304:0226 Pinnacle Systems, Inc. [hex] PCTV 330e Bus 001 Device 005: ID 0b05:173f ASUSTek Computer, Inc. Bus 001 Device 003: ID 2304:0236 Pinnacle Systems, Inc. [hex] Bus 001 Device 002: ID 15a4:9016 I have now three devices with dvb-t channels running with different channels and audio on an atom based cpu without problems. two: dvb-usb-dib0700 and one: dvb-usb-af9015 the dvb-usb-af9015 takes way more cpu interrupts because of the usb block size. prove: http://imagebin.ca/img/xM9Q7_A.jpg I will be demonstrating this at har2009 (see demonstration village) Devin could you login onto the dvb-t test system and see if you can get those em28xx device running with your new code? I will probably make an other test system with some more cpu power to see if even more usb devices are possible, or I may use my nice powerful multiseat quad core system for it. Hello Jelle, Please understand that your experiment isn't really an appropriate test. The original user was referring to analog capture mode, in which the uncompressed video is coming across the USB bus. Analog mode uses about 200Mbps while digital mode uses only 10-20Mbps. If you had tried capturing analog video with those devices you would have seen similar results to what Steve described. I haven't forgotten about your test environment, and I look forward to getting the HVR-900 R2 and PCTV 330e working. I have been sick in bed for the last two days and have done no LinuxTV related work. I look forward to getting back to it this week. Cheers, Devin Funky timing of those mails :D. I saw only after sending my mail that Steve was talking about analog and that this is indeed different. Dual analog tuner support should be possible right? Maybe with some other analog usb chipsets? I don't know what the usb blocksize is or if they are isochronous transfers or bulk or control. I assume the video must be uncompressed transferred over usb because the decoding chip is on the usb device is not capable of doing compression encoding after the analog video decoding? Are there usb devices that do such tricks? Best regards, Jelle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: offering bounty for GPL'd dual em28xx support
On Wed, Jul 22, 2009 at 11:01 AM, Jelle de Jongjelledej...@powercraft.nl wrote: Funky timing of those mails :D. I saw only after sending my mail that Steve was talking about analog and that this is indeed different. Dual analog tuner support should be possible right? Maybe with some other analog usb chipsets? I don't know what the usb blocksize is or if they are isochronous transfers or bulk or control. I assume the video must be uncompressed transferred over usb because the decoding chip is on the usb device is not capable of doing compression encoding after the analog video decoding? Are there usb devices that do such tricks? There were older devices that did compression, mainly designed to fit the stream inside of 12Mbps USB. However, they required onboard RAM to buffer the frame which added considerable cost (in addition to the overhead of doing the compression), and as a result pretty much all of the USB 2.0 designs I have seen do not do any on-chip compression. The example which comes to mind is the Hauppauge Win-TV USB which uses the usbvision chipset. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: offering bounty for GPL'd dual em28xx support
On Wed, Jul 22, 2009 at 1:43 AM, Mauro Carvalho Chehabmche...@infradead.org wrote: I did last year some code optimizations and tests in order to support more than one em28xx device: http://www.mail-archive.com/linux-...@vger.kernel.org/msg01634.html In summary, a 480 Mbps Usb 2.0 bus can be used up to 80% of its maximum bandwidth, and a single video stream eats more than 40% of the maximum available bandwidth, according with Usb 2.0 isoc transfer tables. On that time, I did a patch that auto-adjusts the amount of used bandwidth based on the resolution. So, in thesis, if you select 320x200, you'll eat less bandwidth and you may have two devices connected at the same usb bus. Before my patch, a video stream whose resolution is 720x480x30fps,16 bits/pixel, meaning about 166 Mbps stream rate (without USB oveheads) was eating 60% of the maximum allowed bus speed (80% of 480 Mbps). The rationale is that USB 2.0 has a limit on the maximum number of isoc packets and packet size per second, based on timing issues. I remember I did some tests that succeeded on eating less bandwidth, and that it did work with more than one em28xx hardware. There are a few missing features to allow the em28xx driver to eat less bandwidth: 1) As we now support formats with 8 and 12 bits per pixel, we may optimize the code as well to consider the number of bpp at the calculus on em28xx_set_alternate(). In thesis, all we need to do is to replace the magic number 2 on the first calculus: unsigned int min_pkt_size = dev-width * 2 + 4; /* When image size is bigger than a certain value, the frame size should be increased, otherwise, only green screen will be received. */ if (dev-width * 2 * dev-height 720 * 240 * 2) min_pkt_size *= 2; So, changing the first calculus to: unsigned int min_pkt_size = ((dev-width * dev-format-depth + 7) 3) + 4; and being sure that the function is properly called at the proper places (it should be, already) will probably eat about half of the bandwidth, if you select an 8 bpp output format (currently, only bayer formats are supported). There's one issue here: most apps don't support bayer format, so we need libv4l to convert. However, I'm not sure if libv4l will select bayer format, or will keep using yuy2 for input. It would be nice to add some control on libv4l to allow controlling the input format based on the user needs (less bandwidth or less quality). I'm copying Hans here, since he maintains libv4l. The second calculus were obtained experimentally. Not sure what is needed there. Maybe Devin can came up with a better formula. 2) to select also fps and calculate bandwidth accordingly. For this to work, we need to discover a way to slow down the frame rate and see if this will really allow using more devices. On my tests on implementing em28xx Silvercrest webcam support, some weeks ago, I discovered that slowing down the frame rate at the sensor is enough to slow it down at em28xx driver. So, it is on my TODO list to add fps selection at the driver, at least for devices with mt9v011 sensor. I wish I had more than one em28xx webcam here for tests, but I currently have just one (thanks to Hans that borrowed it to Douglas, that borrowed it to me). If this strategy of slowing down the fps by changing the sensos also works with analog demods, grabber devices can also benefit of such gains. In this case, the solution is to add, if possible, a frame rate selection at saa7115 and tvp5150 drivers. At the time I wrote the tvp5150 driver, I haven't cared to provide such controls. I'll need to double check its datasheets to be sure if this is possible. Hello Mauro, As far as I know, the em28xx has no capability to adjust the frame rate. It will forward the frames at whatever rate the ITU656 stream is delivered from the decoder. I also don't think the tvp5150 will deliver frames at any rather other than the NTSC/PAL standard in question (but I would have to double-check the tvp5150 datasheet to be sure). I would like to spend some time looking closer at the formula used to calculate the set_alternate() call. I just haven't had the time to invest in such an investigation given all the other stuff I am working on right now (in particular the three or four em28xx devices I am adding support for, the xc4000 driver work, and hvr-950q analog fixes). I didn't know about the 80% utilization cap for isoc, so thanks for providing the reference to that previous thread, which has some pretty interesting information. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: offering bounty for GPL'd dual em28xx support
Em Wed, 22 Jul 2009 12:02:48 -0400 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: Hello Mauro, As far as I know, the em28xx has no capability to adjust the frame rate. It will forward the frames at whatever rate the ITU656 stream is delivered from the decoder. Ok. So, the fps changing will be limited to the decoder and/or sensor that supports it. I also don't think the tvp5150 will deliver frames at any rather other than the NTSC/PAL standard in question (but I would have to double-check the tvp5150 datasheet to be sure). On a very quick check on saa7114/saa7115 and tvp5150, I couldn't find any way do do spatial decimation to reduce fps. So, it seems that we'll have this feature only with webcams where such type of control is common. I would like to spend some time looking closer at the formula used to calculate the set_alternate() call. I just haven't had the time to invest in such an investigation given all the other stuff I am working on right now (in particular the three or four em28xx devices I am adding support for, the xc4000 driver work, and hvr-950q analog fixes). Maybe that magic calculus took from experimentation are due to vbi and/or audio streams. It would be nice to adjust it to be less conservative. I didn't know about the 80% utilization cap for isoc, so thanks for providing the reference to that previous thread, which has some pretty interesting information. Anytime. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: offering bounty for GPL'd dual em28xx support
Em Wed, 22 Jul 2009 11:06:12 -0400 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: On Wed, Jul 22, 2009 at 11:01 AM, Jelle de Jongjelledej...@powercraft.nl wrote: Funky timing of those mails :D. I saw only after sending my mail that Steve was talking about analog and that this is indeed different. Dual analog tuner support should be possible right? Maybe with some other analog usb chipsets? I don't know what the usb blocksize is or if they are isochronous transfers or bulk or control. I assume the video must be uncompressed transferred over usb because the decoding chip is on the usb device is not capable of doing compression encoding after the analog video decoding? Are there usb devices that do such tricks? There were older devices that did compression, mainly designed to fit the stream inside of 12Mbps USB. However, they required onboard RAM to buffer the frame which added considerable cost (in addition to the overhead of doing the compression), and as a result pretty much all of the USB 2.0 designs I have seen do not do any on-chip compression. The example which comes to mind is the Hauppauge Win-TV USB which uses the usbvision chipset. pvrusb2 also has compression, provided by an external mpeg encoder. Those devices are USB 2.0 Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: offering bounty for GPL'd dual em28xx support
On Wed, 2009-07-22 at 13:18 -0300, Mauro Carvalho Chehab wrote: I didn't know about the 80% utilization cap for isoc, so thanks for providing the reference to that previous thread, which has some pretty interesting information. Anytime. Yeah have to agree, thanks so much for the illuminating and informative discussion everyone! -- Steve Castellotti Technical Director Eyemagnet - New Zealand -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: offering bounty for GPL'd dual em28xx support
On Wed, 2009-07-22 at 13:18 -0300, Mauro Carvalho Chehab wrote: I didn't know about the 80% utilization cap for isoc, so thanks for providing the reference to that previous thread, which has some pretty interesting information. Anytime. Yeah have to agree, thanks so much for the illuminating and informative discussion everyone! -- Steve Castellotti Technical Director Eyemagnet - New Zealand -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
offering bounty for GPL'd dual em28xx support
Hello everyone- Apologies in advance for spamming the list, but we're after adding dual device support for the existing, GPL'd em28xx tuner driver currently in the mainline Linux kernel. We do not have this development resource in house and had hoped perhaps someone on the list might be capable and interested (or able to point us in the appropriate direction). By way of more detail, it seems that multiple times in the past, other users have also requested this feature, but it is still not currently available in the current GPL'd driver. For some time support may have been present in the em28xx-new driver, provided by Markus Rechberger, but I have since been told it is discontinued, and does not compile anymore with the latest kernels. This message thread as recently as April 9th, 2009, seems to indicate interest is still present at the community level, but no resolution was reached by the tail of the conversation: http://www.mail-archive.com/linux-media@vger.kernel.org/msg04245.html Going further back, it does seem that the em28xx-new driver at one point successfully addressed this issue, so supporting multiple devices should be possible with driver modification: http://mcentral.de/pipermail/em28xx/2008-November/002111.html We can confirm that a development system running Fedora 11 with the latest stable kernel (2.6.29.5-191.fc11.i686.PAE), with identical em28xx devices connected still exhibits the error message v4l2: ioctl queue buffer failed: No space left on device when attempting to display video input on two identical em28xx devices simultaneously. On the other hand, display is successful through either device when trying to display individually (with both still connected). We are a small company, which relies on the Linux platform for the core of our products and services. Occasionally a situation presents itself for us to contribute back to the Open Source community (in however small a fashion), either by releasing existing code or contracting a small amount of work to be performed and subsequently released under the GPL. This is one such instance. If anyone is interested in contributing such work and is prepared to quote for what they feel their time would be worth, please do not hesitate to contact me. Again, apologies if this message appears to be a misuse of the mailing list, hopefully our intentions are understandable! Cheers -- Steve Castellotti s...@eyemagnet.com Technical Director Eyemagnet Limited http://www.eyemagnet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: offering bounty for GPL'd dual em28xx support
On Tue, Jul 21, 2009 at 9:09 PM, Steve Castellottis...@eyemagnet.com wrote: Hello everyone- Apologies in advance for spamming the list, but we're after adding dual device support for the existing, GPL'd em28xx tuner driver currently in the mainline Linux kernel. We do not have this development resource in house and had hoped perhaps someone on the list might be capable and interested (or able to point us in the appropriate direction). By way of more detail, it seems that multiple times in the past, other users have also requested this feature, but it is still not currently available in the current GPL'd driver. For some time support may have been present in the em28xx-new driver, provided by Markus Rechberger, but I have since been told it is discontinued, and does not compile anymore with the latest kernels. This message thread as recently as April 9th, 2009, seems to indicate interest is still present at the community level, but no resolution was reached by the tail of the conversation: http://www.mail-archive.com/linux-media@vger.kernel.org/msg04245.html Going further back, it does seem that the em28xx-new driver at one point successfully addressed this issue, so supporting multiple devices should be possible with driver modification: http://mcentral.de/pipermail/em28xx/2008-November/002111.html We can confirm that a development system running Fedora 11 with the latest stable kernel (2.6.29.5-191.fc11.i686.PAE), with identical em28xx devices connected still exhibits the error message v4l2: ioctl queue buffer failed: No space left on device when attempting to display video input on two identical em28xx devices simultaneously. On the other hand, display is successful through either device when trying to display individually (with both still connected). We are a small company, which relies on the Linux platform for the core of our products and services. Occasionally a situation presents itself for us to contribute back to the Open Source community (in however small a fashion), either by releasing existing code or contracting a small amount of work to be performed and subsequently released under the GPL. This is one such instance. If anyone is interested in contributing such work and is prepared to quote for what they feel their time would be worth, please do not hesitate to contact me. Again, apologies if this message appears to be a misuse of the mailing list, hopefully our intentions are understandable! Cheers -- Steve Castellotti s...@eyemagnet.com Technical Director Eyemagnet Limited http://www.eyemagnet.com Hello Steve, The issue occurs with various different drivers. Basically the issue is the device attempts to reserve a certain amount of bandwidth on the USB bus for the isoc stream, and in the case of analog video at 640x480 this adds up to about 200Mbps. As a result, connecting multiple devices can result in exceeding the available bandwidth on the USB bus. Depending on your how many devices you are trying to connect, what your target capture resolution is, and whether you can put each device on its own USB bus will dictate what solution you can go with. I've done a considerable amount of work with the mainline em28xx driver, so if you would like to discuss your desired configuration further and what we might be able to do to accommodate those requirements (including possibly optimizing the driver to better support more devices), feel free to email me off-list. Regards, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: offering bounty for GPL'd dual em28xx support
On 07/21/2009 06:42 PM, Devin Heitmueller wrote: On Tue, Jul 21, 2009 at 9:09 PM, Steve Castellottis...@eyemagnet.com wrote: We can confirm that a development system running Fedora 11 with the latest stable kernel (2.6.29.5-191.fc11.i686.PAE), with identical em28xx devices connected still exhibits the error message v4l2: ioctl queue buffer failed: No space left on device when attempting to display video input on two identical em28xx devices simultaneously. On the other hand, display is successful through either device when trying to display individually (with both still connected). Hello Steve, The issue occurs with various different drivers. Basically the issue is the device attempts to reserve a certain amount of bandwidth on the USB bus for the isoc stream, and in the case of analog video at 640x480 this adds up to about 200Mbps. As a result, connecting multiple devices can result in exceeding the available bandwidth on the USB bus. Depending on your how many devices you are trying to connect, what your target capture resolution is, and whether you can put each device on its own USB bus will dictate what solution you can go with. I've done a considerable amount of work with the mainline em28xx driver, so if you would like to discuss your desired configuration further and what we might be able to do to accommodate those requirements (including possibly optimizing the driver to better support more devices), feel free to email me off-list. Regards, Devin Devin- Thanks for the quick response. Happy to take the conversation off-list, but first, to clarify what may be useful to future web searchers: So if I'm working with a USB 2.0 bus, which should have a theoretical maximum of 480 Mbps, if the only two ports connected are both em28xx capture devices running at (say) 640x480, shouldn't that be sufficient for displaying both streams simultaneously? Talking in the general sense of course, perhaps some details vary from system to system - any idea what sort of variables might affect that however? I would assume most systems only have a single USB bus (regardless of whether plugs are present on the front/back/side). If a given system has a second USB bus or chipset, them perhaps plugging the second device into that would solve the problem, but that surely that would be a rare situation? Most of the systems we use do not have expansion slots, so adding a PCI USB board is not possible (in which case we would probably just add a PCI TV Capture board anyway!). That said, if you do have some thoughts or suggestions as to how we might be able to investigate specific hardware, or there is some other way you think you might be able to help address this particular problem (ideally in a way that benefits the larger community too!) please let me know. Thanks again Steve -- Steve Castellotti s...@eyemagnet.com Technical Director Eyemagnet Limited http://www.eyemagnet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: offering bounty for GPL'd dual em28xx support
On Tue, Jul 21, 2009 at 10:19 PM, Steve Castellottis...@eyemagnet.com wrote: On 07/21/2009 06:42 PM, Devin Heitmueller wrote: On Tue, Jul 21, 2009 at 9:09 PM, Steve Castellottis...@eyemagnet.com wrote: We can confirm that a development system running Fedora 11 with the latest stable kernel (2.6.29.5-191.fc11.i686.PAE), with identical em28xx devices connected still exhibits the error message v4l2: ioctl queue buffer failed: No space left on device when attempting to display video input on two identical em28xx devices simultaneously. On the other hand, display is successful through either device when trying to display individually (with both still connected). Hello Steve, The issue occurs with various different drivers. Basically the issue is the device attempts to reserve a certain amount of bandwidth on the USB bus for the isoc stream, and in the case of analog video at 640x480 this adds up to about 200Mbps. As a result, connecting multiple devices can result in exceeding the available bandwidth on the USB bus. Depending on your how many devices you are trying to connect, what your target capture resolution is, and whether you can put each device on its own USB bus will dictate what solution you can go with. I've done a considerable amount of work with the mainline em28xx driver, so if you would like to discuss your desired configuration further and what we might be able to do to accommodate those requirements (including possibly optimizing the driver to better support more devices), feel free to email me off-list. Regards, Devin Devin- Thanks for the quick response. Happy to take the conversation off-list, but first, to clarify what may be useful to future web searchers: So if I'm working with a USB 2.0 bus, which should have a theoretical maximum of 480 Mbps, if the only two ports connected are both em28xx capture devices running at (say) 640x480, shouldn't that be sufficient for displaying both streams simultaneously? Talking in the general sense of course, perhaps some details vary from system to system - any idea what sort of variables might affect that however? I would assume most systems only have a single USB bus (regardless of whether plugs are present on the front/back/side). If a given system has a second USB bus or chipset, them perhaps plugging the second device into that would solve the problem, but that surely that would be a rare situation? Most of the systems we use do not have expansion slots, so adding a PCI USB board is not possible (in which case we would probably just add a PCI TV Capture board anyway!). That said, if you do have some thoughts or suggestions as to how we might be able to investigate specific hardware, or there is some other way you think you might be able to help address this particular problem (ideally in a way that benefits the larger community too!) please let me know. Thanks again Steve -- Steve Castellotti s...@eyemagnet.com Technical Director Eyemagnet Limited http://www.eyemagnet.com I agree that *in theory* you should be able to do two devices. A back of the envelope calculation of 640x480 at 30fps in YUVY capture should be about 148Mbps. That said, I don't think the scenario you are describing has really been tested/debugged previously. If I had to guess, my suspicion would be a bug in the driver code that calculates which USB alternate mode to operate in, which results in the driver reserving more bandwidth than necessary. I would have dig into the code and do some testing in order to have a better idea where the problem is. Do you have a specific em28xx product in mind that you intend to use? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: offering bounty for GPL'd dual em28xx support
On 07/21/2009 07:32 PM, Devin Heitmueller wrote: I agree that *in theory* you should be able to do two devices. A back of the envelope calculation of 640x480 at 30fps in YUVY capture should be about 148Mbps. That said, I don't think the scenario you are describing has really been tested/debugged previously. If I had to guess, my suspicion would be a bug in the driver code that calculates which USB alternate mode to operate in, which results in the driver reserving more bandwidth than necessary. I would have dig into the code and do some testing in order to have a better idea where the problem is. Do you have a specific em28xx product in mind that you intend to use? Well in theory there's no difference between theory and practice, but in practice there is (c: More than happy to coordinate some testing of a variety of em28xx devices we have handy around the office if it would help isolate any bugs. We could throw some QA resource at the problem if nothing else. One of the devices we're supposed to be able to acquire in bulk is no-name brand that simply says VC-211A on the label. lsusb output looks like this: ID eb1a:2861 eMPIA Technology, Inc. The other says GrabBeeX+ deluxe and has this identifier: ID eb1a:2821 eMPIA Technology, Inc. We have a 2-3 others on hand as well. Once again, thanks for the responsiveness and please let me know what we can do to contribute. Cheers Steve -- Steve Castellotti s...@eyemagnet.com Technical Director Eyemagnet Limited http://www.eyemagnet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: offering bounty for GPL'd dual em28xx support
On Tue, Jul 21, 2009 at 11:47 PM, Steve Castellottis...@eyemagnet.com wrote: On 07/21/2009 07:32 PM, Devin Heitmueller wrote: I agree that *in theory* you should be able to do two devices. A back of the envelope calculation of 640x480 at 30fps in YUVY capture should be about 148Mbps. That said, I don't think the scenario you are describing has really been tested/debugged previously. If I had to guess, my suspicion would be a bug in the driver code that calculates which USB alternate mode to operate in, which results in the driver reserving more bandwidth than necessary. I would have dig into the code and do some testing in order to have a better idea where the problem is. Do you have a specific em28xx product in mind that you intend to use? Well in theory there's no difference between theory and practice, but in practice there is (c: More than happy to coordinate some testing of a variety of em28xx devices we have handy around the office if it would help isolate any bugs. We could throw some QA resource at the problem if nothing else. One of the devices we're supposed to be able to acquire in bulk is no-name brand that simply says VC-211A on the label. lsusb output looks like this: ID eb1a:2861 eMPIA Technology, Inc. The other says GrabBeeX+ deluxe and has this identifier: ID eb1a:2821 eMPIA Technology, Inc. We have a 2-3 others on hand as well. Once again, thanks for the responsiveness and please let me know what we can do to contribute. Well, I think I own something like nine different em28xx products, so I should be able to hook a couple of them up at the same time and debug the issue. The only issue at this point is that I already have a rather full plate of issues I am currently working. I'll see if I can schedule some cycles in the next couple of weeks to take a look (unless someone else wants to step up and debug the issue). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: offering bounty for GPL'd dual em28xx support
Em Tue, 21 Jul 2009 20:47:05 -0700 Steve Castellotti s...@eyemagnet.com escreveu: On 07/21/2009 07:32 PM, Devin Heitmueller wrote: I agree that *in theory* you should be able to do two devices. A back of the envelope calculation of 640x480 at 30fps in YUVY capture should be about 148Mbps. That said, I don't think the scenario you are describing has really been tested/debugged previously. If I had to guess, my suspicion would be a bug in the driver code that calculates which USB alternate mode to operate in, which results in the driver reserving more bandwidth than necessary. I would have dig into the code and do some testing in order to have a better idea where the problem is. Do you have a specific em28xx product in mind that you intend to use? Steve, I did last year some code optimizations and tests in order to support more than one em28xx device: http://www.mail-archive.com/linux-...@vger.kernel.org/msg01634.html In summary, a 480 Mbps Usb 2.0 bus can be used up to 80% of its maximum bandwidth, and a single video stream eats more than 40% of the maximum available bandwidth, according with Usb 2.0 isoc transfer tables. On that time, I did a patch that auto-adjusts the amount of used bandwidth based on the resolution. So, in thesis, if you select 320x200, you'll eat less bandwidth and you may have two devices connected at the same usb bus. Before my patch, a video stream whose resolution is 720x480x30fps,16 bits/pixel, meaning about 166 Mbps stream rate (without USB oveheads) was eating 60% of the maximum allowed bus speed (80% of 480 Mbps). The rationale is that USB 2.0 has a limit on the maximum number of isoc packets and packet size per second, based on timing issues. I remember I did some tests that succeeded on eating less bandwidth, and that it did work with more than one em28xx hardware. There are a few missing features to allow the em28xx driver to eat less bandwidth: 1) As we now support formats with 8 and 12 bits per pixel, we may optimize the code as well to consider the number of bpp at the calculus on em28xx_set_alternate(). In thesis, all we need to do is to replace the magic number 2 on the first calculus: unsigned int min_pkt_size = dev-width * 2 + 4; /* When image size is bigger than a certain value, the frame size should be increased, otherwise, only green screen will be received. */ if (dev-width * 2 * dev-height 720 * 240 * 2) min_pkt_size *= 2; So, changing the first calculus to: unsigned int min_pkt_size = ((dev-width * dev-format-depth + 7) 3) + 4; and being sure that the function is properly called at the proper places (it should be, already) will probably eat about half of the bandwidth, if you select an 8 bpp output format (currently, only bayer formats are supported). There's one issue here: most apps don't support bayer format, so we need libv4l to convert. However, I'm not sure if libv4l will select bayer format, or will keep using yuy2 for input. It would be nice to add some control on libv4l to allow controlling the input format based on the user needs (less bandwidth or less quality). I'm copying Hans here, since he maintains libv4l. The second calculus were obtained experimentally. Not sure what is needed there. Maybe Devin can came up with a better formula. 2) to select also fps and calculate bandwidth accordingly. For this to work, we need to discover a way to slow down the frame rate and see if this will really allow using more devices. On my tests on implementing em28xx Silvercrest webcam support, some weeks ago, I discovered that slowing down the frame rate at the sensor is enough to slow it down at em28xx driver. So, it is on my TODO list to add fps selection at the driver, at least for devices with mt9v011 sensor. I wish I had more than one em28xx webcam here for tests, but I currently have just one (thanks to Hans that borrowed it to Douglas, that borrowed it to me). If this strategy of slowing down the fps by changing the sensos also works with analog demods, grabber devices can also benefit of such gains. In this case, the solution is to add, if possible, a frame rate selection at saa7115 and tvp5150 drivers. At the time I wrote the tvp5150 driver, I haven't cared to provide such controls. I'll need to double check its datasheets to be sure if this is possible. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
