CAM appears to introduce packet loss
Hi all, For quite some time now, I'm fighting with my DVB-C setup and I think I've eliminated any hardware issues that could be the origin of the issue I'm seeing. Here is my setup: Hardware: * KNC1 TV-Station DVB-C with KNC1 CineView CI (I also tried the SATELCO EasyWatch PCI (DVB-C) with SATELCO EasyWatch CI which is exactly the same hardware, just different brand) * Conax 4.00e CAM (tested in a DVB-C capable TV, works fine) * Smartcard from the DVB provider (http://www.sasag.ch, tested and properly accessible through `gnutv -cammenu`) * Dell PE700, P4 2.80GHz, 4GB RAM Software: * Mythbuntu 9.10 (karmic) * kernel 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 16:20:31 UTC 2009 i686 GNU/Linux My DVB provider uses the free-to-view system for all channels except the local TV channel which is transmitted unencrypted. When the CAM is not inserted in the CI, I'm getting a perfect video stream ([PS/PES: ITU-T Rec. H.262 | ISO/IEC 13818-2 or ISO/IEC 11172-2 video stream]) for that unencrypted channel. dvbsnoop tells me that the stream is coming in at a fairly constant bandwidth of 4852 kbit/s. The moment I insert the CAM into the CI, the bandwidth drops to an average of 4070 kbit/s. I did analyze both streams with Peter Daniel's MPEG-2 Transport Stream packet analyser. As expected, the former stream has no continuity issues whereas the latter does. I see the continuity counter jump from 12 to 15 for example. The resulting video stream is visually distorted, I've uploaded an example at https://sites.google.com/site/msslinux/linuxmce/SFInfo.mpeg?attredirects=0d=1 to give you an idea. I get exactly the same result for any free-to-view channel which makes me suspect that the CAM/Smartcard does properly decrypt the stream. However, something appears not to be able to keep up. My DVB provider used QAM_256 which makes the bandwidth susceptible to the signal to noise ratio. The S/N ratio is at f5f5 without the CAM inserted and drops to f4f4 with the CAM inserted. I don't think that's the issue. I saw a few postings on the net about performance issues of budget cards with QAM_256 when using CI/CAM. Is that really the problem? How can I find out, i.e. further narrow down the problem? Any pointers will be appreciated. Thanks, Marc -- 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: CAM appears to introduce packet loss
Hello, Try to check raw speed coming from demod: echo 1 /sys/module/dvb_core/parameters/dvb_demux_speedcheck and then: tail -f /var/log/messages | grep -i speed or dmesg | grep -i speed what values do you see ? this TS going through CAM. CAM has a bitrate limitation which they can pass (this depends on CAM model). On Sun, 2010-01-31 at 13:12 +0100, Marc Schmitt wrote: Hi all, For quite some time now, I'm fighting with my DVB-C setup and I think I've eliminated any hardware issues that could be the origin of the issue I'm seeing. Here is my setup: Hardware: * KNC1 TV-Station DVB-C with KNC1 CineView CI (I also tried the SATELCO EasyWatch PCI (DVB-C) with SATELCO EasyWatch CI which is exactly the same hardware, just different brand) * Conax 4.00e CAM (tested in a DVB-C capable TV, works fine) * Smartcard from the DVB provider (http://www.sasag.ch, tested and properly accessible through `gnutv -cammenu`) * Dell PE700, P4 2.80GHz, 4GB RAM Software: * Mythbuntu 9.10 (karmic) * kernel 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 16:20:31 UTC 2009 i686 GNU/Linux My DVB provider uses the free-to-view system for all channels except the local TV channel which is transmitted unencrypted. When the CAM is not inserted in the CI, I'm getting a perfect video stream ([PS/PES: ITU-T Rec. H.262 | ISO/IEC 13818-2 or ISO/IEC 11172-2 video stream]) for that unencrypted channel. dvbsnoop tells me that the stream is coming in at a fairly constant bandwidth of 4852 kbit/s. The moment I insert the CAM into the CI, the bandwidth drops to an average of 4070 kbit/s. I did analyze both streams with Peter Daniel's MPEG-2 Transport Stream packet analyser. As expected, the former stream has no continuity issues whereas the latter does. I see the continuity counter jump from 12 to 15 for example. The resulting video stream is visually distorted, I've uploaded an example at https://sites.google.com/site/msslinux/linuxmce/SFInfo.mpeg?attredirects=0d=1 to give you an idea. I get exactly the same result for any free-to-view channel which makes me suspect that the CAM/Smartcard does properly decrypt the stream. However, something appears not to be able to keep up. My DVB provider used QAM_256 which makes the bandwidth susceptible to the signal to noise ratio. The S/N ratio is at f5f5 without the CAM inserted and drops to f4f4 with the CAM inserted. I don't think that's the issue. I saw a few postings on the net about performance issues of budget cards with QAM_256 when using CI/CAM. Is that really the problem? How can I find out, i.e. further narrow down the problem? Any pointers will be appreciated. Thanks, Marc -- 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 -- 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: CAM appears to introduce packet loss
Hi there, On Sun, Jan 31, 2010 at 1:43 PM, Abylai Ospan aos...@netup.ru wrote: Hello, Try to check raw speed coming from demod: echo 1 /sys/module/dvb_core/parameters/dvb_demux_speedcheck What do I need to do to make dvb_demux_speedcheck appear in /sys/module/dvb_core/parameters? Cheers, Marc -- 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: CAM appears to introduce packet loss
Looks like I need to build the DVB subsystem from the latest sources to get this option as it was recently added only (http://udev.netup.ru/cgi-bin/hgwebdir.cgi/v4l-dvb-aospan/rev/1d956b581b02). On it. On Sun, Jan 31, 2010 at 4:07 PM, Marc Schmitt marc.schm...@gmail.com wrote: What do I need to do to make dvb_demux_speedcheck appear in /sys/module/dvb_core/parameters? -- 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: CAM appears to introduce packet loss
On Sun, 2010-01-31 at 16:23 +0100, Marc Schmitt wrote: Looks like I need to build the DVB subsystem from the latest sources to get this option as it was recently added only (http://udev.netup.ru/cgi-bin/hgwebdir.cgi/v4l-dvb-aospan/rev/1d956b581b02). On it. yes. this option should show raw bitrate coming from demod and which passed to CI. In user level you may be measuring bitrate after software PID filtering ( may be not ). -- Abylai Ospan aos...@netup.ru NetUP Inc. -- 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: CAM appears to introduce packet loss
Compiling from source made me stumble across http://www.mail-archive.com/ubuntu-devel-disc...@lists.ubuntu.com/msg09422.html I just left out the firedtv driver as recommended. I'm getting the following kernel output after enabling dvb_demux_speedcheck: [ 330.366115] TS speed 40350 Kbits/sec [ 332.197693] TS speed 40085 Kbits/sec [ 334.011856] TS speed 40528 Kbits/sec [ 335.843466] TS speed 40107 Kbits/sec [ 337.665411] TS speed 40261 Kbits/sec [ 339.496959] TS speed 40107 Kbits/sec [ 341.318289] TS speed 40350 Kbits/sec Do you think the CI/CAM can not handle that? On Sun, Jan 31, 2010 at 4:32 PM, Abylai Ospan aos...@netup.ru wrote: On Sun, 2010-01-31 at 16:23 +0100, Marc Schmitt wrote: Looks like I need to build the DVB subsystem from the latest sources to get this option as it was recently added only (http://udev.netup.ru/cgi-bin/hgwebdir.cgi/v4l-dvb-aospan/rev/1d956b581b02). On it. yes. this option should show raw bitrate coming from demod and which passed to CI. In user level you may be measuring bitrate after software PID filtering ( may be not ). -- Abylai Ospan aos...@netup.ru NetUP Inc. -- 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: CAM appears to introduce packet loss
On Sun, 2010-01-31 at 17:25 +0100, Marc Schmitt wrote: Compiling from source made me stumble across http://www.mail-archive.com/ubuntu-devel-disc...@lists.ubuntu.com/msg09422.html I just left out the firedtv driver as recommended. I'm getting the following kernel output after enabling dvb_demux_speedcheck: [ 330.366115] TS speed 40350 Kbits/sec [ 332.197693] TS speed 40085 Kbits/sec [ 334.011856] TS speed 40528 Kbits/sec [ 335.843466] TS speed 40107 Kbits/sec [ 337.665411] TS speed 40261 Kbits/sec [ 339.496959] TS speed 40107 Kbits/sec [ 341.318289] TS speed 40350 Kbits/sec Do you think the CI/CAM can not handle that? 40 Mbit/sec is high bitrate for some CAM's. You can: 1. Try to contact with CAM vendor and check maximum bitrate which can be passed throught this CAM 2. Try to find reception card with hardware PID filtering and pass only interesting PID's throught CAM. Bitrate should be equal to bitrate of one channel - aprox. 4-5 mbit/sec ( not 40 mbit/sec). 3.may be some fixes can be made on TS output from demod. Demod's usually has tunable TS output timings/forms. You should check TS clock by oscilloscope and then try to change TS timings/forms in demod. -- Abylai Ospan aos...@netup.ru NetUP Inc. -- 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: CAM appears to introduce packet loss
On Sun, Jan 31, 2010 at 5:31 PM, Abylai Ospan aos...@netup.ru wrote: On Sun, 2010-01-31 at 17:25 +0100, Marc Schmitt wrote: Compiling from source made me stumble across http://www.mail-archive.com/ubuntu-devel-disc...@lists.ubuntu.com/msg09422.html I just left out the firedtv driver as recommended. I'm getting the following kernel output after enabling dvb_demux_speedcheck: [ 330.366115] TS speed 40350 Kbits/sec [ 332.197693] TS speed 40085 Kbits/sec [ 334.011856] TS speed 40528 Kbits/sec [ 335.843466] TS speed 40107 Kbits/sec [ 337.665411] TS speed 40261 Kbits/sec [ 339.496959] TS speed 40107 Kbits/sec [ 341.318289] TS speed 40350 Kbits/sec Do you think the CI/CAM can not handle that? 40 Mbit/sec is high bitrate for some CAM's. You can: 1. Try to contact with CAM vendor and check maximum bitrate which can be passed throught this CAM I tried that CAM in a TV with DVB-C support. The image was perfect so I suspect that the CAM itself can handle it unless the TV did HW PID filtering before sending the stream to the CAM, as you point out below... Is that to be expected? 2. Try to find reception card with hardware PID filtering and pass only interesting PID's throught CAM. Bitrate should be equal to bitrate of one channel - aprox. 4-5 mbit/sec ( not 40 mbit/sec). Do you have a recommendation for such a card? Would it be possible to do the filtering in software somehow? 3.may be some fixes can be made on TS output from demod. Demod's usually has tunable TS output timings/forms. You should check TS clock by oscilloscope and then try to change TS timings/forms in demod. Unfortunately, I don't have the necessary equipment/knowledge to do this. :( I'd assume the DVB provider could give me the TS clock? But then I'm at bit at a loss with change TS timings/forms in demod. What exactly are you referring to by demod. Thanks, Marc -- 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: CAM appears to introduce packet loss
You can: 1. Try to contact with CAM vendor and check maximum bitrate which can be passed throught this CAM I tried that CAM in a TV with DVB-C support. The image was perfect so I suspect that the CAM itself can handle it unless the TV did HW PID filtering before sending the stream to the CAM, as you point out below... Is that to be expected? Depends on TV vendor. But it's not impossible. 2. Try to find reception card with hardware PID filtering and pass only interesting PID's throught CAM. Bitrate should be equal to bitrate of one channel - aprox. 4-5 mbit/sec ( not 40 mbit/sec). Do you have a recommendation for such a card? try to search on linuxtv wiki. Would it be possible to do the filtering in software somehow? usually TS going from demod to CI directly without any programmable IC between. in this case you can't do PID filtering nor SW nor HW. 3.may be some fixes can be made on TS output from demod. Demod's usually has tunable TS output timings/forms. You should check TS clock by oscilloscope and then try to change TS timings/forms in demod. Unfortunately, I don't have the necessary equipment/knowledge to do this. :( I'd assume the DVB provider could give me the TS clock? But then I'm at bit at a loss with change TS timings/forms in demod. What exactly are you referring to by demod. demod is IC doing demodulation of signal and producing Transport Stream. In your card seems Philips TDA10021 is used as DVB-C demodulator. -- Abylai Ospan aos...@netup.ru NetUP Inc. -- 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
