Re: Reliable work-horse capture device?
Andy Walls wrote: On Mon, 2009-09-14 at 21:02 -0700, David Liontooth wrote: Mauro Carvalho Chehab wrote: Hi David, Em Mon, 14 Sep 2009 19:41:13 -0700 David Liontooth lionte...@cogweb.net escreveu: We're setting up NTSC cable television capture devices in a handfull of remote locations, using four devices to capture around fifty hours a day on each location. Capture is scripted and will be ongoing for several years. We want to minimize the need for human intervention. I'm looking for advice on which capture device to use. My main candidates are ivtv (WinTV PVR 500) and USB, but I've not used any of the supported USB devices. Are there USB devices that are sufficiently reliable to hold up under continuous capture for years? Are the drivers robust? I need zvbi-ntsc-cc support, so a big thanks to Michael Krufty for just now adding it to em28xx. Do any other USB device chipsets have raw closed captioning support? I would also consider using the PCIe device Hauppauge WinTV-HVR-2200, but I need analog support. Appreciate any advice. If you look for stability, the most important item is to choose a good stable server distribution, like RHEL5. You'll be better serviced than using a desktop distro with some new (not so stable) kernel and tools. In terms of stability, the PCI devices are generally more reliable, and, among all drivers, bttv is the winner, since it is the older driver, so, in thesis, more bugs were solved on it. That's the reason why several surveillance systems are still today based on bttv. If you need a newer hardware, then you may choose saa7134, cx88 or ivtv devices. I don't recommend using an USB hardware for such hard usage: it will probably have a shorter life (since it is not as ventilated as a PCI device on a server cabinet), and you might experience troubles after long plays. In terms of USB with analog support, em28xx driver is the more stable, and we recently fixed some bugs on it, related to memory consumption along the time (it used to forget to free memory, resulting on crashes, after several stream start/stop's). There's a tool at v4l2-apps/test made to stress a video driver, made by Douglas. I suggest that you should run it with the board you'll choose to be sure that you won't have memory garbage along driver usage. Cheers, Mauro Thank you, Mauro! I much appreciate the advice. I also see I misattributed the zvbi-ntsc-cc support for em28xx -- kudos goes to Devin Heitmueller for great work on this. As for the ventilation issue for USB devices, that may not be a serious obstacle. If the USB sticks such as Hauppauge HVR-950 have reliable components, we could strip the plastic casing and mount the unit next to a fan inside the case. Memory leaks would be a serious problem on the other hand; thank you for pointing to the stress test. I would be happy to use bttv, but I can't find cards. I also need to grab audio off the PCI bus, which only some bttv cards support. We've been using saa7135 cards for several years with relatively few incidents, but they occasionally drop audio. I've been unable to find any pattern in the audio drops, so I haven't reported it -- I have no way to reproduce the error, but it happens regularly, affecting between 3 and 5% of recordings. Audio will sometimes drop in the middle of a recording and then resume, or else work fine on the next recording. Our fallback is ivtv. I was hoping to use USB so that we could get blades instead of 3U cases; it's also getting hard to find good motherboards with four PCI slots. I will point out that, for a fallback position, the cx18 driver also performs very reliably with essentially the same feature set as ivtv (since it started out as a cut and paste from ivtv). The HVR-1600 is the card with which I do most of my testing. It is a PCI bus device and can perform analog (with VBI) and digital capture simultaneously, but not 2 analog streams simultaneously. I know of two users who have at least 3 of these boards in one machine. (I mention the HVR-1600, in case you have a hard time finding the PVR-500 or similar analog only cards.) Of course for you, it sounds like one analog capture device per PCI slot is suboptimal. From a bus throughput perspective, I'd assume you'd really want a multiple analog input PCI or PCIe capture card, that could do compression on board. Regards, Andy Thanks Andy, that's a useful suggestion for a fallback. Cheers, Dave -- 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: Reliable work-horse capture device?
Hi David, Em Mon, 14 Sep 2009 19:41:13 -0700 David Liontooth lionte...@cogweb.net escreveu: We're setting up NTSC cable television capture devices in a handfull of remote locations, using four devices to capture around fifty hours a day on each location. Capture is scripted and will be ongoing for several years. We want to minimize the need for human intervention. I'm looking for advice on which capture device to use. My main candidates are ivtv (WinTV PVR 500) and USB, but I've not used any of the supported USB devices. Are there USB devices that are sufficiently reliable to hold up under continuous capture for years? Are the drivers robust? I need zvbi-ntsc-cc support, so a big thanks to Michael Krufty for just now adding it to em28xx. Do any other USB device chipsets have raw closed captioning support? I would also consider using the PCIe device Hauppauge WinTV-HVR-2200, but I need analog support. Appreciate any advice. If you look for stability, the most important item is to choose a good stable server distribution, like RHEL5. You'll be better serviced than using a desktop distro with some new (not so stable) kernel and tools. In terms of stability, the PCI devices are generally more reliable, and, among all drivers, bttv is the winner, since it is the older driver, so, in thesis, more bugs were solved on it. That's the reason why several surveillance systems are still today based on bttv. If you need a newer hardware, then you may choose saa7134, cx88 or ivtv devices. I don't recommend using an USB hardware for such hard usage: it will probably have a shorter life (since it is not as ventilated as a PCI device on a server cabinet), and you might experience troubles after long plays. In terms of USB with analog support, em28xx driver is the more stable, and we recently fixed some bugs on it, related to memory consumption along the time (it used to forget to free memory, resulting on crashes, after several stream start/stop's). There's a tool at v4l2-apps/test made to stress a video driver, made by Douglas. I suggest that you should run it with the board you'll choose to be sure that you won't have memory garbage along driver usage. 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: Reliable work-horse capture device?
Mauro Carvalho Chehab wrote: Hi David, Em Mon, 14 Sep 2009 19:41:13 -0700 David Liontooth lionte...@cogweb.net escreveu: We're setting up NTSC cable television capture devices in a handfull of remote locations, using four devices to capture around fifty hours a day on each location. Capture is scripted and will be ongoing for several years. We want to minimize the need for human intervention. I'm looking for advice on which capture device to use. My main candidates are ivtv (WinTV PVR 500) and USB, but I've not used any of the supported USB devices. Are there USB devices that are sufficiently reliable to hold up under continuous capture for years? Are the drivers robust? I need zvbi-ntsc-cc support, so a big thanks to Michael Krufty for just now adding it to em28xx. Do any other USB device chipsets have raw closed captioning support? I would also consider using the PCIe device Hauppauge WinTV-HVR-2200, but I need analog support. Appreciate any advice. If you look for stability, the most important item is to choose a good stable server distribution, like RHEL5. You'll be better serviced than using a desktop distro with some new (not so stable) kernel and tools. In terms of stability, the PCI devices are generally more reliable, and, among all drivers, bttv is the winner, since it is the older driver, so, in thesis, more bugs were solved on it. That's the reason why several surveillance systems are still today based on bttv. If you need a newer hardware, then you may choose saa7134, cx88 or ivtv devices. I don't recommend using an USB hardware for such hard usage: it will probably have a shorter life (since it is not as ventilated as a PCI device on a server cabinet), and you might experience troubles after long plays. In terms of USB with analog support, em28xx driver is the more stable, and we recently fixed some bugs on it, related to memory consumption along the time (it used to forget to free memory, resulting on crashes, after several stream start/stop's). There's a tool at v4l2-apps/test made to stress a video driver, made by Douglas. I suggest that you should run it with the board you'll choose to be sure that you won't have memory garbage along driver usage. Cheers, Mauro Thank you, Mauro! I much appreciate the advice. I also see I misattributed the zvbi-ntsc-cc support for em28xx -- kudos goes to Devin Heitmueller for great work on this. As for the ventilation issue for USB devices, that may not be a serious obstacle. If the USB sticks such as Hauppauge HVR-950 have reliable components, we could strip the plastic casing and mount the unit next to a fan inside the case. Memory leaks would be a serious problem on the other hand; thank you for pointing to the stress test. I would be happy to use bttv, but I can't find cards. I also need to grab audio off the PCI bus, which only some bttv cards support. We've been using saa7135 cards for several years with relatively few incidents, but they occasionally drop audio. I've been unable to find any pattern in the audio drops, so I haven't reported it -- I have no way to reproduce the error, but it happens regularly, affecting between 3 and 5% of recordings. Audio will sometimes drop in the middle of a recording and then resume, or else work fine on the next recording. Our fallback is ivtv. I was hoping to use USB so that we could get blades instead of 3U cases; it's also getting hard to find good motherboards with four PCI slots. Cheers, Dave -- 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: Reliable work-horse capture device?
Am Montag, den 14.09.2009, 21:02 -0700 schrieb David Liontooth: Mauro Carvalho Chehab wrote: Hi David, Em Mon, 14 Sep 2009 19:41:13 -0700 David Liontooth lionte...@cogweb.net escreveu: We're setting up NTSC cable television capture devices in a handfull of remote locations, using four devices to capture around fifty hours a day on each location. Capture is scripted and will be ongoing for several years. We want to minimize the need for human intervention. I'm looking for advice on which capture device to use. My main candidates are ivtv (WinTV PVR 500) and USB, but I've not used any of the supported USB devices. Are there USB devices that are sufficiently reliable to hold up under continuous capture for years? Are the drivers robust? I need zvbi-ntsc-cc support, so a big thanks to Michael Krufty for just now adding it to em28xx. Do any other USB device chipsets have raw closed captioning support? I would also consider using the PCIe device Hauppauge WinTV-HVR-2200, but I need analog support. Appreciate any advice. If you look for stability, the most important item is to choose a good stable server distribution, like RHEL5. You'll be better serviced than using a desktop distro with some new (not so stable) kernel and tools. In terms of stability, the PCI devices are generally more reliable, and, among all drivers, bttv is the winner, since it is the older driver, so, in thesis, more bugs were solved on it. That's the reason why several surveillance systems are still today based on bttv. If you need a newer hardware, then you may choose saa7134, cx88 or ivtv devices. I don't recommend using an USB hardware for such hard usage: it will probably have a shorter life (since it is not as ventilated as a PCI device on a server cabinet), and you might experience troubles after long plays. In terms of USB with analog support, em28xx driver is the more stable, and we recently fixed some bugs on it, related to memory consumption along the time (it used to forget to free memory, resulting on crashes, after several stream start/stop's). There's a tool at v4l2-apps/test made to stress a video driver, made by Douglas. I suggest that you should run it with the board you'll choose to be sure that you won't have memory garbage along driver usage. Cheers, Mauro Thank you, Mauro! I much appreciate the advice. I also see I misattributed the zvbi-ntsc-cc support for em28xx -- kudos goes to Devin Heitmueller for great work on this. As for the ventilation issue for USB devices, that may not be a serious obstacle. If the USB sticks such as Hauppauge HVR-950 have reliable components, we could strip the plastic casing and mount the unit next to a fan inside the case. Memory leaks would be a serious problem on the other hand; thank you for pointing to the stress test. I would be happy to use bttv, but I can't find cards. I also need to grab audio off the PCI bus, which only some bttv cards support. We've been using saa7135 cards for several years with relatively few incidents, but they occasionally drop audio. I've been unable to find any pattern in the audio drops, so I haven't reported it -- I have no way to reproduce the error, but it happens regularly, affecting between 3 and 5% of recordings. Audio will sometimes drop in the middle of a recording and then resume, or else work fine on the next recording. Hi Dave, hmm, losing audio on three to five percent of the recordings is a lot! When we started to talk to each other, we had only saa7134 PAL/SECAM devices over here. That has changed a lot, but still no System-M here. The kernel thread detecting audio on saa7133/35/31e behaves different from the one on saa7134. But if you let it run with audio_debug=1, you should have something in the logs when losing the audio. The kernel audio detection thread must have been started without success or id find the right thing again. I would assume caused by a weaker signal in between. Do you know about the insmod option audio_ddep? It is pretty hidden and I almost must look it up myself in the code. Cheers, Hermann Our fallback is ivtv. I was hoping to use USB so that we could get blades instead of 3U cases; it's also getting hard to find good motherboards with four PCI slots. Cheers, Dave -- 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: Reliable work-horse capture device?
Em Mon, 14 Sep 2009 21:02:52 -0700 David Liontooth lionte...@cogweb.net escreveu: As for the ventilation issue for USB devices, that may not be a serious obstacle. If the USB sticks such as Hauppauge HVR-950 have reliable components, we could strip the plastic casing and mount the unit next to a fan inside the case. Yes, this may work. Don't forget that, if you use USB devices, you'll probably need one separate USB buses per each device, due to USB limits in terms of the maximum number of isoc packets per second. If you don't require high quality, you could try to use a format that requires less than 16 bits per pixel or 320x240 pixels, in order to have more than one device per bus. I would be happy to use bttv, but I can't find cards. I also need to grab audio off the PCI bus, which only some bttv cards support. We've been using saa7135 cards for several years with relatively few incidents, but they occasionally drop audio. I've been unable to find any pattern in the audio drops, so I haven't reported it -- I have no way to reproduce the error, but it happens regularly, affecting between 3 and 5% of recordings. Audio will sometimes drop in the middle of a recording and then resume, or else work fine on the next recording. saa7134 has a thread to detect audio audio stereo mode. Maybe there is a bug somewhere there. Our fallback is ivtv. I was hoping to use USB so that we could get blades instead of 3U cases; it's also getting hard to find good motherboards with four PCI slots. The current best relation in terms of slots is the new cx25821. It has 8 simultaneous inputs at 60 fps per each PCIe board. If you don't need a tuner, this design could be very interesting. The driver was written by Conexant, and it is not yet present on any distribution (I just committed it today - at staging - since it needs some cleanups to match kernel CodingStyle). 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: Reliable work-horse capture device?
Mauro Carvalho Chehab wrote: Em Mon, 14 Sep 2009 21:02:52 -0700 David Liontooth lionte...@cogweb.net escreveu: As for the ventilation issue for USB devices, that may not be a serious obstacle. If the USB sticks such as Hauppauge HVR-950 have reliable components, we could strip the plastic casing and mount the unit next to a fan inside the case. Yes, this may work. Don't forget that, if you use USB devices, you'll probably need one separate USB buses per each device, due to USB limits in terms of the maximum number of isoc packets per second. If you don't require high quality, you could try to use a format that requires less than 16 bits per pixel or 320x240 pixels, in order to have more than one device per bus. Thanks for pointing this out. I would be happy to use bttv, but I can't find cards. I also need to grab audio off the PCI bus, which only some bttv cards support. We've been using saa7135 cards for several years with relatively few incidents, but they occasionally drop audio. I've been unable to find any pattern in the audio drops, so I haven't reported it -- I have no way to reproduce the error, but it happens regularly, affecting between 3 and 5% of recordings. Audio will sometimes drop in the middle of a recording and then resume, or else work fine on the next recording. saa7134 has a thread to detect audio audio stereo mode. Maybe there is a bug somewhere there. Interesting idea -- anything I can do to debug? Our fallback is ivtv. I was hoping to use USB so that we could get blades instead of 3U cases; it's also getting hard to find good motherboards with four PCI slots. The current best relation in terms of slots is the new cx25821. It has 8 simultaneous inputs at 60 fps per each PCIe board. If you don't need a tuner, this design could be very interesting. The driver was written by Conexant, and it is not yet present on any distribution (I just committed it today - at staging - since it needs some cleanups to match kernel CodingStyle). Wow, that's great to get support for this powerful device. We do need tuners, though -- we're capturing straight from RF television cable. Otherwise a beautiful product, even with h264 compression, which is what we need. Cheers, Dave -- 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
