* cx18 short-term resource available @ 2009-01-02 20:03 Dale Pontius 2009-01-04 18:08 ` Andy Walls 0 siblings, 1 reply; 4+ messages in thread From: Dale Pontius @ 2009-01-02 20:03 UTC (permalink / raw) To: video4linux-list Every now and then I fix my sister-in-law an her husband's computer, and every now and then they give me their cast-offs. I also have 2 HVR-1600 cards and 2 SA4250C set-top boxes, only 1 of each in active use. So for a few months, I can bring back online a spare system, and can use some spare time to assist. I'll have to reinstall the machine, but it has a valid XP-Home license, and can easily be made dual-boot. So I have: Dell Dimension 2300, HVR2300, SA4250C, and can temporarily dedicate all of this hardware to assist developers. I know cx18 work seems to be proceeding quite well on its own, but I also know that the IR blaster seems to need work. If I can be of assistance, please let me know. I can join the LIRC list, if appropriate. Related, to Andy Walls, A few months back you were helping me, we couldn't find my tuner, and I was essentially nowhere without that. I took both HVR-1600 cards over to a friend's house, and we plugged them into a WinXP machine, installed drivers, and also got nowhere with either card. I brought them home, plugged the second (the one I hadn't tried, yet) card into my machine, and it was fully functional. Then I plugged in the first, and it was fully functional, as well. In the past week I read more, and learned how to scan for ATSC stations, and so far have only QVC, but that's enough to verify that that side of one of the cards works. (I'll have to replug to test the ATSC on the other card, and I've been leaving my hardware alone during the cold - and staticy snap.) Anyway, both cards work, I don't know if it was that they touched a Windows machine and some secret bits got flipped by the Windows driver, or if all I needed was a simple replug in the first place. Question: Under MythTV, the HVR-1600 seems - fuzzy. My main card, a PixelPro, seems sharper, though there are more artifacts in the video, also. The HVR-1600 seems cleaner, just fuzzy. However, when I look at the HVR-1600 video at native resolution, it seems quite good and the fuzziness appears to be gone. Do you know if this an artifact of how MythTV scales video to fullscreen, or if there is something in the settings I should tweak? I have noticed that MythTV captures on the PixelPro at 480x480 by default, and at that resolution HVR-1600 captures are less than half the file size. Changing the HVR-1600 captures to 720x480 improves things somewhat, and the files are still smaller. Thanks, Dale Pontius -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: cx18 short-term resource available 2009-01-02 20:03 cx18 short-term resource available Dale Pontius @ 2009-01-04 18:08 ` Andy Walls 2009-01-05 2:21 ` Dale Pontius 0 siblings, 1 reply; 4+ messages in thread From: Andy Walls @ 2009-01-04 18:08 UTC (permalink / raw) To: Dale Pontius; +Cc: video4linux-list, linux-media On Fri, 2009-01-02 at 15:03 -0500, Dale Pontius wrote: > Every now and then I fix my sister-in-law an her husband's computer, and > every now and then they give me their cast-offs. I also have 2 HVR-1600 > cards and 2 SA4250C set-top boxes, only 1 of each in active use. So for > a few months, I can bring back online a spare system, and can use some > spare time to assist. I'll have to reinstall the machine, but it has a > valid XP-Home license, and can easily be made dual-boot. > > So I have: > Dell Dimension 2300, HVR2300, SA4250C, and can temporarily dedicate all > of this hardware to assist developers. I know cx18 work seems to be > proceeding quite well on its own, but I also know that the IR blaster > seems to need work. If I can be of assistance, please let me know. I > can join the LIRC list, if appropriate. Well, I haven't moved on making the IR blaster work better at all. Users have reported that the modified lirc_pvr150 module and stock lirc_pvr150 "firmware" image work. It doesn't have the latest STB codes though. There was some email on one of the lists about 4-5 months ago for what it would take to snoop off the new codes from the Zilog API in the HVR-1600 Windows driver. That would allow the lirc_pvr150 module to support the newer STBs with the HVR-1600. Ultimately, I want to get rid of the Zilog firmare in the blaster chip and replace it with some home grown stuff. I still have a ways to go on that. > Related, to Andy Walls, > A few months back you were helping me, we couldn't find my tuner, and I > was essentially nowhere without that. I took both HVR-1600 cards over > to a friend's house, and we plugged them into a WinXP machine, installed > drivers, and also got nowhere with either card. > > I brought them home, plugged the second (the one I hadn't tried, yet) > card into my machine, and it was fully functional. Then I plugged in > the first, and it was fully functional, as well. Cool. Dust/oxidation seems to really matter to proper PCI bus operation. When you get the chance, make sure all slots in you machine are free of dust. (I think it might matter to the PCI bus' reflected wave signaling.) > In the past week I > read more, and learned how to scan for ATSC stations, and so far have > only QVC, but that's enough to verify that that side of one of the cards > works. (I'll have to replug to test the ATSC on the other card, and > I've been leaving my hardware alone during the cold - and staticy snap.) Try to use the best signal possible: http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality (I need to update that page to take into considerations for avoiding a ground loop with the cable company, but that won't matter for OTA ATSC) > Anyway, both cards work, I don't know if it was that they touched a > Windows machine and some secret bits got flipped by the Windows driver, > or if all I needed was a simple replug in the first place. No. There is no state saved on the card aside from in the ATMEL EEPROM which should be write protected, and the EEPROM in the Zilog IR blater chipw hich is a pain to write. Most likely cleaning out dust and removing layers of oxidation/crud. > Question: > Under MythTV, the HVR-1600 seems - fuzzy. My main card, a PixelPro, > seems sharper, though there are more artifacts in the video, also. The > HVR-1600 seems cleaner, just fuzzy. However, when I look at the > HVR-1600 video at native resolution, it seems quite good and the > fuzziness appears to be gone. > > Do you know if this an artifact of how MythTV scales video to > fullscreen, or if there is something in the settings I should tweak? I > have noticed that MythTV captures on the PixelPro at 480x480 by default, > and at that resolution HVR-1600 captures are less than half the file > size. Changing the HVR-1600 captures to 720x480 improves things > somewhat, and the files are still smaller. I don't know about the PixelPro, but the HVR-1600 is performing MPEG compression (using hardware in the CX23418). You may want to play with the controls and view the results with mplayer until you're happy. To list all the controls: $ v4l2-ctl -d /dev/video0 -L To get more help on maipulating the controls $ v4l2-ctl --help BTW: don't try MPEG-1 video encoding. I found last night that it doesn't appear to work. Stick to MPEG-2 and play with the image size and bit rates. Regards, Andy > Thanks, > Dale Pontius > > -- -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: cx18 short-term resource available 2009-01-04 18:08 ` Andy Walls @ 2009-01-05 2:21 ` Dale Pontius 2009-01-06 1:19 ` Andy Walls 0 siblings, 1 reply; 4+ messages in thread From: Dale Pontius @ 2009-01-05 2:21 UTC (permalink / raw) To: Andy Walls; +Cc: video4linux-list, linux-media Andy Walls wrote: > On Fri, 2009-01-02 at 15:03 -0500, Dale Pontius wrote: >> Every now and then I fix my sister-in-law an her husband's computer, and >> every now and then they give me their cast-offs. I also have 2 HVR-1600 >> cards and 2 SA4250C set-top boxes, only 1 of each in active use. So for >> a few months, I can bring back online a spare system, and can use some >> spare time to assist. I'll have to reinstall the machine, but it has a >> valid XP-Home license, and can easily be made dual-boot. >> >> So I have: >> Dell Dimension 2300, HVR2300, SA4250C, and can temporarily dedicate all >> of this hardware to assist developers. I know cx18 work seems to be >> proceeding quite well on its own, but I also know that the IR blaster >> seems to need work. If I can be of assistance, please let me know. I >> can join the LIRC list, if appropriate. > > Well, I haven't moved on making the IR blaster work better at all. > Users have reported that the modified lirc_pvr150 module and stock > lirc_pvr150 "firmware" image work. It doesn't have the latest STB codes > though. > Where do I get this modified lirc_pvr150? I'm running Gentoo, and have looked in the packages for lirc and ivtv-utils, and haven't found any traces of lirc_pvr150, let alone a tweaked version. I've also fetched lirc-0.8.4a source, and only find references to the pvr150 in lirc_i2c. I found an STB list on the web for lirc_pvr150, and while my STB isn't specifically listed, similar models are, and there's an entry for "Comcast." > There was some email on one of the lists about 4-5 months ago for what > it would take to snoop off the new codes from the Zilog API in the > HVR-1600 Windows driver. That would allow the lirc_pvr150 module to > support the newer STBs with the HVR-1600. > I've seen references to that, but no new exchanges on the topic. I guess I figured the work hadn't gotten off the ground, yet. > Ultimately, I want to get rid of the Zilog firmare in the blaster chip > and replace it with some home grown stuff. I still have a ways to go on > that. > I'll hold off on that, if you please. Fear of my skill, not yours. I don't want to brick my card, and charging in with all 10 thumbs is likely to do that, for me. Still, is there any way I can help any of this with a semi-dedicated dual-boot system? I'm doing nothing immediately because of the cold weather and accompanying static, but it's due to warm up this week, and it'll be time to move. It's been up into the balmy teens yesterday and today, before that it was in single digits plus/minus. Tomorrow it's supposed to warm to around freezing. Even with a pot of water on the woodstove, it's been pretty shocking around here, at times. > > >> Related, to Andy Walls, >> A few months back you were helping me, we couldn't find my tuner, and I >> was essentially nowhere without that. I took both HVR-1600 cards over >> to a friend's house, and we plugged them into a WinXP machine, installed >> drivers, and also got nowhere with either card. >> >> I brought them home, plugged the second (the one I hadn't tried, yet) >> card into my machine, and it was fully functional. Then I plugged in >> the first, and it was fully functional, as well. > > Cool. Dust/oxidation seems to really matter to proper PCI bus > operation. When you get the chance, make sure all slots in you machine > are free of dust. (I think it might matter to the PCI bus' reflected > wave signaling.) > > >> In the past week I >> read more, and learned how to scan for ATSC stations, and so far have >> only QVC, but that's enough to verify that that side of one of the cards >> works. (I'll have to replug to test the ATSC on the other card, and >> I've been leaving my hardware alone during the cold - and staticy snap.) > > Try to use the best signal possible: > Is there any sort of Linux utility to measure signal strength? In some of my queries I've seen 100% signal, and I've seen references to a Windows signal strength utility. I've got a booster/splitter, and right now the gain is at minimum for 100% signal strength on NTSC capture. But I suppose it's possible that 100% means "full limiting" or "AGC engaged", and doesn't necessarily mean anything better than minimum fully usable signal. I don't know, and until I know more I'm reluctant to move the gain up. It's entirely possible/likely that this is all Comcast policy. > http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality > Of course I'm doing pretty much everything wrong. As I change pieces of infrastructure, I'll take steps to do it the right way. > (I need to update that page to take into considerations for avoiding a > ground loop with the cable company, but that won't matter for OTA ATSC) > > >> Anyway, both cards work, I don't know if it was that they touched a >> Windows machine and some secret bits got flipped by the Windows driver, >> or if all I needed was a simple replug in the first place. > > No. There is no state saved on the card aside from in the ATMEL EEPROM > which should be write protected, and the EEPROM in the Zilog IR blater > chipw hich is a pain to write. > > Most likely cleaning out dust and removing layers of oxidation/crud. > > > >> Question: >> Under MythTV, the HVR-1600 seems - fuzzy. My main card, a PixelPro, >> seems sharper, though there are more artifacts in the video, also. The >> HVR-1600 seems cleaner, just fuzzy. However, when I look at the >> HVR-1600 video at native resolution, it seems quite good and the >> fuzziness appears to be gone. >> >> Do you know if this an artifact of how MythTV scales video to >> fullscreen, or if there is something in the settings I should tweak? I >> have noticed that MythTV captures on the PixelPro at 480x480 by default, >> and at that resolution HVR-1600 captures are less than half the file >> size. Changing the HVR-1600 captures to 720x480 improves things >> somewhat, and the files are still smaller. > > I don't know about the PixelPro, but the HVR-1600 is performing MPEG > compression (using hardware in the CX23418). You may want to play with > the controls and view the results with mplayer until you're happy. > The PixelPro is a software card, so MythTV is saving RTJPEG. > To list all the controls: > > $ v4l2-ctl -d /dev/video0 -L > > To get more help on maipulating the controls > > $ v4l2-ctl --help > Is there some decent one-or-two stop shopping for what the controls mean? The v4l2-ctl will tell me what the controls are and how to tweak them, but not what most of those names are. Some of the terms are familiar from following the list, and some are familiar from transcoding prompts. But that still doesn't educate me about how to tweak them. Since I've got 2 HVR-1600 cards, I need to capture a show using MythTV on one, and cat'ing /dev/video2 to a file on the other. Then transcode the mpeg out of Myth, and I've got 3 versions to compare - in-Myth, direct captured, and exported from Myth. That should give me some better information. Right now I suspect it's the way MythTV scales MPEG2 vs RTJPEG to fullscreen. > Thanks, Dale > BTW: don't try MPEG-1 video encoding. I found last night that it > doesn't appear to work. Stick to MPEG-2 and play with the image size > and bit rates. > > Regards, > Andy > >> Thanks, >> Dale Pontius >> >> -- > -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: cx18 short-term resource available 2009-01-05 2:21 ` Dale Pontius @ 2009-01-06 1:19 ` Andy Walls 0 siblings, 0 replies; 4+ messages in thread From: Andy Walls @ 2009-01-06 1:19 UTC (permalink / raw) To: Dale Pontius; +Cc: video4linux-list, linux-media On Sun, 2009-01-04 at 21:21 -0500, Dale Pontius wrote: > Andy Walls wrote: > > On Fri, 2009-01-02 at 15:03 -0500, Dale Pontius wrote: > > > > Well, I haven't moved on making the IR blaster work better at all. > > Users have reported that the modified lirc_pvr150 module and stock > > lirc_pvr150 "firmware" image work. It doesn't have the latest STB codes > > though. > > > Where do I get this modified lirc_pvr150? You get the latest lirc_pvr150 and hope this old patch works: --- lirc/drivers/lirc_pvr150/lirc_pvr150.c.orig 2008-06-22 20:04:23.000000000 -0400 +++ lirc/drivers/lirc_pvr150/lirc_pvr150.c 2008-06-22 20:25:49.000000000 -0400 @@ -67,6 +67,7 @@ /* We need to be able to reset the crappy IR chip by talking to the ivtv driver */ struct ivtv; void ivtv_reset_ir_gpio(struct ivtv *itv); +void cx18_reset_ir_gpio(void *data); struct IR { @@ -197,7 +198,12 @@ static int add_to_buf(struct IR *ir) printk(KERN_ERR "lirc_pvr150: polling the IR receiver " "chip failed, trying reset\n"); - ivtv_reset_ir_gpio(i2c_get_adapdata(ir->c_rx.adapter)); + if (strncmp(ir->c_rx.name, "cx18", 4)) + ivtv_reset_ir_gpio( + i2c_get_adapdata(ir->c_rx.adapter)); + else + cx18_reset_ir_gpio( + i2c_get_adapdata(ir->c_rx.adapter)); set_current_state(TASK_UNINTERRUPTIBLE); schedule_timeout((100 * HZ + 999) / 1000); ir->need_boot = 1; @@ -983,7 +989,12 @@ static ssize_t write(struct file *filep, up(&ir->lock); return ret; } - ivtv_reset_ir_gpio(i2c_get_adapdata(ir->c_tx.adapter)); + if (strncmp(ir->c_tx.name, "cx18", 4)) + ivtv_reset_ir_gpio( + i2c_get_adapdata(ir->c_tx.adapter)); + else + cx18_reset_ir_gpio( + i2c_get_adapdata(ir->c_tx.adapter)); set_current_state(TASK_UNINTERRUPTIBLE); schedule_timeout((100 * HZ + 999) / 1000); ir->need_boot = 1; @@ -1434,6 +1445,7 @@ int init_module(void) { init_MUTEX(&tx_data_lock); request_module("ivtv"); + request_module("cx18"); request_module("firmware_class"); i2c_add_driver(&driver); return 0; > I'm running Gentoo, and have > looked in the packages for lirc and ivtv-utils, and haven't found any > traces of lirc_pvr150, let alone a tweaked version. Mark's braindump: http://www.blushingpenguin.com/mark/blog/?p=24 > I've also fetched > lirc-0.8.4a source, and only find references to the pvr150 in lirc_i2c. lirc_i2c only supports IR receive. lirc_pvr150 does both IR Rx and Tx. > I found an STB list on the web for lirc_pvr150, and while my STB isn't > specifically listed, similar models are, and there's an entry for "Comcast." > > > There was some email on one of the lists about 4-5 months ago for what > > it would take to snoop off the new codes from the Zilog API in the > > HVR-1600 Windows driver. That would allow the lirc_pvr150 module to > > support the newer STBs with the HVR-1600. > > > I've seen references to that, but no new exchanges on the topic. I > guess I figured the work hadn't gotten off the ground, yet. > > > Ultimately, I want to get rid of the Zilog firmare in the blaster chip > > and replace it with some home grown stuff. I still have a ways to go on > > that. > > > I'll hold off on that, if you please. Fear of my skill, not yours. I > don't want to brick my card, and charging in with all 10 thumbs is > likely to do that, for me. Sorry. I wasn't suggesting that. I'll be the only one bricking cards until I get the process nailed down. :) > Still, is there any way I can help any of this with a semi-dedicated > dual-boot system? In this message, a quote reply from Mark gives the short outline of what needs to be done to sniff out the newest codes: http://ivtvdriver.org/pipermail/ivtv-users/2008-July/008487.html You'll probably want to examine the whole thread. > I'm doing nothing immediately because of the cold > weather and accompanying static, but it's due to warm up this week, and > it'll be time to move. It's been up into the balmy teens yesterday and > today, before that it was in single digits plus/minus. Tomorrow it's > supposed to warm to around freezing. Even with a pot of water on the > woodstove, it's been pretty shocking around here, at times. Wow. I was out in Iowa once when the overnight temp was -15F in October. Where I live rarely gets below 0F even in the worst winters. > > > > > Try to use the best signal possible: > > > Is there any sort of Linux utility to measure signal strength? In some > of my queries I've seen 100% signal, and I've seen references to a > Windows signal strength utility. I've got a booster/splitter, and right > now the gain is at minimum for 100% signal strength on NTSC capture. > But I suppose it's possible that 100% means "full limiting" or "AGC > engaged", and doesn't necessarily mean anything better than minimum > fully usable signal. I don't know, and until I know more I'm reluctant > to move the gain up. It's entirely possible/likely that this is all > Comcast policy. The mxl5005s digital tuner on the HVR-1600 should be able to support a signal indication I think. But the driver doesn't provide anything right now. I was hoping Devin H. could get a datasheet from MaxLinear, so we could get that added. > > http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality > > > Of course I'm doing pretty much everything wrong. As I change pieces of > infrastructure, I'll take steps to do it the right way. > > (I need to update that page to take into considerations for avoiding a > > ground loop with the cable company, but that won't matter for OTA ATSC) Just remember to not ground the cable company's shield to your earth ground lest you create a ground loop, from your house to the cable company, that introduces noise. According to wikipedia: http://en.wikipedia.org/wiki/Ground_loop_(electricity) one would want an isolation transformer (with a frequency response wide enoguh to cover the entire band) and leave the cable company's coax shield unterminated (not to your earth ground). Then on your side of the isolation transformer, it would be OK to ground the shield for EMI reduction & lightning protection. > > I don't know about the PixelPro, but the HVR-1600 is performing MPEG > > compression (using hardware in the CX23418). You may want to play with > > the controls and view the results with mplayer until you're happy. > > > The PixelPro is a software card, so MythTV is saving RTJPEG. > > > To list all the controls: > > > > $ v4l2-ctl -d /dev/video0 -L > > > > To get more help on maipulating the controls > > > > $ v4l2-ctl --help > > > Is there some decent one-or-two stop shopping for what the controls > mean? The v4l2-ctl will tell me what the controls are and how to tweak > them, but not what most of those names are. Some of the terms are > familiar from following the list, and some are familiar from transcoding > prompts. But that still doesn't educate me about how to tweak them. Maybe the V4L2 API spec will help you figure out some of them: http://linuxtv.org/docs.php But in general: 1. higher bitrates mean less compression, low bitrates mean more compression. 2. Constant bit rate means compression is not allowed to burst above that fixed ceiling to preserve quality. Variable bitrate means the engine is allowed to burst higher from time to time to preserve quality. 3. MPEG-1 and MPEG-2 are video encoding specifications. You'll want MPEG-2. Use the PS for stored captures, use the TS for captures you want to stream over a network. 4. MPEG Layer II refers to audio encoding for MPEG-1 or MPEG-2. Use this for now as Dolby AC-3 support for the CX23418 is not complete. 5. The various filters give various effects to the compressed video to try and remove artifacts while saving space. > Since I've got 2 HVR-1600 cards, I need to capture a show using MythTV > on one, and cat'ing /dev/video2 to a file on the other. Then transcode > the mpeg out of Myth, and I've got 3 versions to compare - in-Myth, > direct captured, and exported from Myth. That should give me some > better information. Right now I suspect it's the way MythTV scales > MPEG2 vs RTJPEG to fullscreen. Transcoding will look crappy. Just use mplayer to play the file Myth stores under /var/video/ (or wherever on your system) Have fun. Stay warm. Regards, Andy > Thanks, > Dale -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-01-06 1:19 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-01-02 20:03 cx18 short-term resource available Dale Pontius 2009-01-04 18:08 ` Andy Walls 2009-01-05 2:21 ` Dale Pontius 2009-01-06 1:19 ` Andy Walls
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).