Hi Andy, I was able to get some experimentation done yesterday and today. Below inline are my responses -
>> > > Ravi, > > I've pushed a patch to > > http://linuxtv.org/hg/~awalls/ivtv > > to fix SVideo chroma for the M113 boards. > > S-Video is OK now with this patch! In fact, the red/yellow artifacts seem significantly lesser in S-video connection, almost same quality now as a direct connection to TV. Strangely though, the original source of this video is still Composite from STB, I just routed it through a DVD recorder to get S-Video out to connect to the card. So it seems only the Composite input of the card has the artifacts issue. I plan to check the quality of the cabling tomorrow to eliminate any cable bandwidth issues. > >> posted some pics and a video clip here - >> snapshot-svideo - http://www.flickr.com/photos/26209...@n00/3704069849/ >> snapshot-composite - http://www.flickr.com/photos/26209...@n00/3704069841/ >> video-composite - http://www.flickr.com/photos/26209...@n00/3704069859/ >> >> (Can notice some dot artifacts in red/yellow region borders in all of >> the above. These are not present in direct source connection to TV) > > I see them in the color snapshot. (I can't see the flash video as I > don't have a flash player). The artifacts look, at least in part, due > to the MPEG compression that the CX23416 is performing on the video. If > you notice, there seems to be some subtle artifacts around the white > lettering and the black trim of the tools. The red '@' does look bad. > > You should use v4l2-ctl to list the controls (with menus) and start > playing with the MPEG settings and filters. I suspect if you don't > perform much compression at all, the artifacts will diminish. > I experimented with all the bitrate/filter options but none helped for this particular artifacts issue on Composite input. Maybe the artifacts in the snapshot I attached are different from the red/yellow artifacts that are seen in the video I attached (I will try to upload it somewhere where it does not convert to flash format). The only thing that seemed a help a bit was to use De-interlacing (Blend mode) in VLC. Other de-interlacing modes were not helping. So could this issue be related to swapped odd/even fields etc? I will check later to find a way to swap the fields. > > The assembly is obviously an NTSC tuner. > > NTSC and PAL have different bandwidths and chroma subcarrier > frequencies. The tuner assembly is going to have filters and passive > components appropriate for NTSC. > > Check the *.inf file that comes with the Windows driver for your card > (Subsystem ID C0341461) and see if it alludes to the tuner type. > It indeed seems to be NTSC tuner - Partsnic, NTSC, without FM. I will try and obtain an NTSC source to check the tuner picture tomorrow. > 48 ksps is the default. VLC might change it for the capture. When VLC, > or any other app, is capturing, you can use v4l2-ctl -d /dev/video0 > --log-status to see how the capture is configured. (v4l2 device nodes > are multiple open.) > > I'll look into what I might be able to do in the CX25840 driver about > fixing the PLL clocks. > > The volume is controllable with the controls available with v4l2-ctl. > I checked with this and it is in 48ksps all the time. After the latest patch the Audio too started working again for all the inputs. But since it worked intermittently in the past, I will observe it for a longer period of time. Also another point - I found a delay of about 1sec in the MPEG video stream compared to realtime, even with mplayer cache set to the minimum where it would still work (128). Is this related to the MPEG buffers in the card, and if so, is that controlled from this driver? Is this parameter something that needs to be (or can be) tuned in this driver? Thanks a lot for all your help! Regards Ravi _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
