cxd2099 CI on DDBridge not working (was: Re: DVB nGene CI : TS Discontinuities issues)
27.02.2012 00:14, Ralph Metzler kirjoitti: > Anssi Hannula writes: > > > I had it running for an hour and had no discontinuities (except at > > > restarts, might have to look into buffer flushing). > > > I tested it with nGene and Octopus boards on an Asus ION2 board and on a > > > Marvell Kirkwood based ARM board. > > > > Should your test code (quoted below) work with e.g. Octopus DDBridge on > > vanilla 3.2.6 kernel, without any additional initialization needed > > through ca0 or so? > > > > When I try it here like that, the reader thread simply blocks > > indefinitely on the first read, while the writer thread continues to > > write packets into the device. > > Am I missing something, or is this a bug? > > > Yes, it should work as it is. > I assume you adjusted the adapter numbers of course. I did. Do you have any idea on what could be the cause of the issue or any debugging tips? I have also tried to do actual decrypting with the CI. As expected, the same thing happened, i.e. data was written but no data was read (CAM in ca0 also responds properly to VDR). -- Anssi Hannula -- 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: DVB nGene CI : TS Discontinuities issues
Anssi Hannula writes: > > I had it running for an hour and had no discontinuities (except at > > restarts, might have to look into buffer flushing). > > I tested it with nGene and Octopus boards on an Asus ION2 board and on a > > Marvell Kirkwood based ARM board. > > Should your test code (quoted below) work with e.g. Octopus DDBridge on > vanilla 3.2.6 kernel, without any additional initialization needed > through ca0 or so? > > When I try it here like that, the reader thread simply blocks > indefinitely on the first read, while the writer thread continues to > write packets into the device. > Am I missing something, or is this a bug? Yes, it should work as it is. I assume you adjusted the adapter numbers of course. Regards, Ralph -- 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: DVB nGene CI : TS Discontinuities issues
Hello,
13.05.2011 14:54, Ralph Metzler kirjoitti:
> Below my test code. You just need to adjust the device name.
>
> I had it running for an hour and had no discontinuities (except at
> restarts, might have to look into buffer flushing).
> I tested it with nGene and Octopus boards on an Asus ION2 board and on a
> Marvell Kirkwood based ARM board.
Should your test code (quoted below) work with e.g. Octopus DDBridge on
vanilla 3.2.6 kernel, without any additional initialization needed
through ca0 or so?
When I try it here like that, the reader thread simply blocks
indefinitely on the first read, while the writer thread continues to
write packets into the device.
Am I missing something, or is this a bug?
> Btw., what hardware exactly are you using?
> Which DVB card version, CI type, motherboard chipset?
I'm not sure what do you need, exactly, but here's the relevant section
of the kernel log. Motherboard chipset is Intel X58. Feel free to ask
for anything else.
[ 1333.801243] Digital Devices PCIE bridge driver, Copyright (C) 2010-11
Digital Devices GmbH
[ 1333.801302] DDBridge :08:00.0: PCI INT A -> GSI 32 (level, low)
-> IRQ 32
[ 1333.801314] DDBridge driver detected: Digital Devices Octopus DVB adapter
[ 1333.801357] HW 00010004 FW 00010001
[ 1333.802371] Port 0 (TAB 1): DUAL DVB-C/T
[ 1333.802819] Port 1 (TAB 2): CI
[ 1333.803785] Port 2 (TAB 3): DUAL DVB-C/T
[ 1333.804369] Port 3 (TAB 4): NO MODULE
[ 1333.805176] DVB: registering new adapter (DDBridge)
[ 1333.824506] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz
[ 1334.313799] DRXK driver version 0.9.4300
[ 1337.120786] DVB: registering adapter 0 frontend 0 (DRXK DVB-C)...
[ 1337.120996] DVB: registering adapter 0 frontend 0 (DRXK DVB-T)...
[ 1337.121165] DVB: registering new adapter (DDBridge)
[ 1337.151565] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz
[ 1337.653400] DRXK driver version 0.9.4300
[ 1340.467888] DVB: registering adapter 1 frontend 0 (DRXK DVB-C)...
[ 1340.468097] DVB: registering adapter 1 frontend 0 (DRXK DVB-T)...
[ 1340.468203] DVB: registering new adapter (DDBridge)
[ 1340.477045] Attached CXD2099AR at 40
[ 1340.477502] DVB: registering new adapter (DDBridge)
[ 1340.498717] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz
[ 1340.978018] DRXK driver version 0.9.4300
[ 1343.784964] DVB: registering adapter 3 frontend 0 (DRXK DVB-C)...
[ 1343.785168] DVB: registering adapter 3 frontend 0 (DRXK DVB-T)...
[ 1343.785322] DVB: registering new adapter (DDBridge)
[ 1343.805712] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz
[ 1344.295293] DRXK driver version 0.9.4300
[ 1347.062278] DVB: registering adapter 4 frontend 0 (DRXK DVB-C)...
[ 1347.062490] DVB: registering adapter 4 frontend 0 (DRXK DVB-T)...
[ 1347.816555] dvb_ca adapter 2: DVB CAM detected and initialised
successfully
> Regards,
> Ralph
>
>
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> uint8_t fill[188]={0x47, 0x1f, 0xff, 0x10,
>
> 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
>
> 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
>
> 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
>
> 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
>
> 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
>
> 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
>
> 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
>
> 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
>
> 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
>
> 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
>
> 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
> 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff };
>
> uint8_t ts[188]={0x47, 0x0a, 0xaa, 0x00 };
>
>
> void proc_buf(uint8_t *buf, uint32_t *d)
> {
> uint32_t c;
>
> if (buf[1]==0x1f && buf[2]==0xff) {
> //printf("fill\n");
> return;
> }
> if (buf[1]==0x9f && buf[2]==0xff) {
> //printf("fill\n");
> return;
> }
> if (buf[1]!=0x0a || buf[2]!=0xaa)
> return;
> c=(buf[4]<<24)|(buf[5]<<16)|(buf[6]<<8)|buf[7];
> if (c!=*d) {
> printf("CONT ERROR %08x %08x\n", c, *d);
> *d=c;
> } else {
> if (memcmp(ts+8, buf+8, 180))
> printf("error\n");
> if (!(c&0x))
> printf("R %d\n", c);
> }
> (*d)++;
> }
>
> void *get_ts(void *a)
> {
> uint8_t buf[188*1024];
> int len, off;
>
> int fdi=open("/dev/dvb/adapter4/sec0
Re: DVB nGene CI : TS Discontinuities issues
Issa Gorissen writes:
> On 11/05/11 15:12, Issa Gorissen wrote:
> > From: Ralph Metzler
> >> Issa Gorissen writes:
> >> > Could you please take a look at the cxd2099 issues ?
> >> >
> >> > I have attached a version with my changes. I have tested a lot of
> >> > different settings with the help of the chip datasheet.
> >> >
> >> > Scrambled programs are not handled correctly. I don't know if it is the
> >> > TICLK/MCLKI which is too high or something, or the sync detector ?
> >> Also,
> >> > as we have to set the TOCLK to max of 72MHz, there are way too much
> >> null
> >> > packets added. Is there a way to solve this ?
> >>
> >> I do not have any cxd2099 issues.
> >> I have a simple test program which includes a 32bit counter as payload
> >> and can pump data through the CI with full speed and have no packet
> >> loss. I only tested decoding with an ORF stream and an Alphacrypt CAM
> >> but also had no problems with this.
> >>
> >> Please take care not to write data faster than it is read. Starting two
> >> dds will not guarantee this. To be certain you could write a small
> >> program which never writes more packets than input buffer size minus
> >> the number of read packets (and minus the stuffing null packets on ngene).
> >>
> >> Before blaming packet loss on the CI data path also please make
> >> certain that you have no buffer overflows in the input part of
> >> the sec device.
> >> In the ngene driver you can e.g. add a printk in tsin_exchange():
> >>
> >> if (dvb_ringbuffer_free(&dev->tsin_rbuf) > len) {
> >> ...
> >> } else
> >> printk ("buffer overflow \n");
> >>
> >>
> >> Regards,
> >> Ralph
> Ralph,
>
OB > Done some more tests, from by test tool, I found out that I have to skip
> (rather often) bytes to find the sync one when reading from sec0. I
> thought I only needed to do that at the start of the stream, not in the
> middle; because I always read/write 188 bytes from it.
This should not happen.
Is there any difference regarding this alignment problem if the CI is inserted
or not?
> Could you share your test code ? I'm finding it difficult to interact
> with this sec0 implementation.
Below my test code. You just need to adjust the device name.
I had it running for an hour and had no discontinuities (except at
restarts, might have to look into buffer flushing).
I tested it with nGene and Octopus boards on an Asus ION2 board and on a
Marvell Kirkwood based ARM board.
Btw., what hardware exactly are you using?
Which DVB card version, CI type, motherboard chipset?
Regards,
Ralph
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
uint8_t fill[188]={0x47, 0x1f, 0xff, 0x10,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff };
uint8_t ts[188]={0x47, 0x0a, 0xaa, 0x00 };
void proc_buf(uint8_t *buf, uint32_t *d)
{
uint32_t c;
if (buf[1]==0x1f && buf[2]==0xff) {
//printf("fill\n");
return;
}
if (buf[1]==0x9f && buf[2]==0xff) {
//printf("fill\n");
return;
}
if (buf[1]!=0x0a || buf[2]!=0xaa)
return;
c=(buf[4]<<24)|(buf[5]<<16)|(buf[6]<<8)|buf[7];
if (c!=*d) {
printf("CONT ERROR %08x %08x\n", c, *d);
*d=c;
} else {
if (memcmp(ts+8, buf+8, 180))
printf("error\n");
if (!(c&0x))
printf("R %d\n", c);
}
(*d)++;
}
void *get_ts(void *a)
{
uint8_t buf[188*1024];
int len, off;
int fdi=open("/dev/dvb/adapter4/sec0", O_RDONLY);
uint32_t d=0;
while (1) {
len=read(fdi, buf, 188*1024);
if (len<0)
continue;
if (buf[0]!=0x47) { //should not happen
read(fdi, buf, 1);
continue;
}
Re: DVB nGene CI : TS Discontinuities issues
On 11/05/11 15:12, Issa Gorissen wrote:
> From: Ralph Metzler
>> Issa Gorissen writes:
>> > Could you please take a look at the cxd2099 issues ?
>> >
>> > I have attached a version with my changes. I have tested a lot of
>> > different settings with the help of the chip datasheet.
>> >
>> > Scrambled programs are not handled correctly. I don't know if it is the
>> > TICLK/MCLKI which is too high or something, or the sync detector ? Also,
>> > as we have to set the TOCLK to max of 72MHz, there are way too much null
>> > packets added. Is there a way to solve this ?
>>
>> I do not have any cxd2099 issues.
>> I have a simple test program which includes a 32bit counter as payload
>> and can pump data through the CI with full speed and have no packet
>> loss. I only tested decoding with an ORF stream and an Alphacrypt CAM
>> but also had no problems with this.
>>
>> Please take care not to write data faster than it is read. Starting two
>> dds will not guarantee this. To be certain you could write a small
>> program which never writes more packets than input buffer size minus
>> the number of read packets (and minus the stuffing null packets on ngene).
>>
>> Before blaming packet loss on the CI data path also please make
>> certain that you have no buffer overflows in the input part of
>> the sec device.
>> In the ngene driver you can e.g. add a printk in tsin_exchange():
>>
>> if (dvb_ringbuffer_free(&dev->tsin_rbuf) > len) {
>> ...
>> } else
>> printk ("buffer overflow \n");
>>
>>
>> Regards,
>> Ralph
Ralph,
Done some more tests, from by test tool, I found out that I have to skip
(rather often) bytes to find the sync one when reading from sec0. I
thought I only needed to do that at the start of the stream, not in the
middle; because I always read/write 188 bytes from it.
Could you share your test code ? I'm finding it difficult to interact
with this sec0 implementation.
Thx
--
Issa
--
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: DVB nGene CI : TS Discontinuities issues
From: Ralph Metzler
> Issa Gorissen writes:
> > Could you please take a look at the cxd2099 issues ?
> >
> > I have attached a version with my changes. I have tested a lot of
> > different settings with the help of the chip datasheet.
> >
> > Scrambled programs are not handled correctly. I don't know if it is the
> > TICLK/MCLKI which is too high or something, or the sync detector ? Also,
> > as we have to set the TOCLK to max of 72MHz, there are way too much null
> > packets added. Is there a way to solve this ?
>
> I do not have any cxd2099 issues.
> I have a simple test program which includes a 32bit counter as payload
> and can pump data through the CI with full speed and have no packet
> loss. I only tested decoding with an ORF stream and an Alphacrypt CAM
> but also had no problems with this.
>
> Please take care not to write data faster than it is read. Starting two
> dds will not guarantee this. To be certain you could write a small
> program which never writes more packets than input buffer size minus
> the number of read packets (and minus the stuffing null packets on ngene).
>
> Before blaming packet loss on the CI data path also please make
> certain that you have no buffer overflows in the input part of
> the sec device.
> In the ngene driver you can e.g. add a printk in tsin_exchange():
>
> if (dvb_ringbuffer_free(&dev->tsin_rbuf) > len) {
> ...
> } else
> printk ("buffer overflow \n");
>
>
> Regards,
> Ralph
Ralph,
Please find my testing tool for the decryption attached. The idea is to write
5 packets and read them back from the CAM.
My input is a raw ts captured with a gnutv I modified with a demux filter of
0x2000. Gnutv outputs at dvr and dvbloop reads from it, process via sec0 and
writes output to a file.
The channel I selected has been decrypted. Only problem is I have artifacts in
the image and the sound.
Do you have any idea of what I should improve from my test tool to fix that
issue ?
Thx,
--
Issa
#include
#include
#include
#include
#include
#include
#include
#include
static void signal_handler(int _signal);
static int quit_app = 0;
int main(int argc, char *argv[])
{
signal(SIGINT, signal_handler);
if (argc <= 3)
exit(1);
int in_fd = open(argv[1], O_RDONLY);
int out_fd = open(argv[2], O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
int tsi_fd = open(argv[3], O_RDWR);
int rlen = 0;
int wlen = 0;
int rtsilen = 0;
int wtsilen = 0;
int BUFFY = 188 * 5;
unsigned char buf[BUFFY];
struct timespec sl[1];
sl[0].tv_nsec = 25;
while (!quit_app)
{
// read from input (DVR or other)
rlen = 0;
while (rlen < BUFFY) {
int i = read(in_fd, buf + rlen, BUFFY - rlen);
if (!i) {
quit_app = 1;
continue;
}
rlen += i;
}
// write data to caio device
wlen = write(tsi_fd, buf, rlen);
if (wlen != rlen)
{
perror("Did not write same amount of data from input to caio!!!");
exit(1);
}/* else
printf("written %d bytes in tsi\n", wlen);
*/
// read data from caio device - should be decrypted
// finding sync byte
do {
buf[0] = 0;
while (buf[0] != 0x47) {
rtsilen = read(tsi_fd, buf, 1);
}
if (buf[0] == 0x47) {
do {
int i = read(tsi_fd, buf + rtsilen, 188 - rtsilen);
rtsilen += i;
// printf("reading %d bytes from tsi\n", i);
} while (rtsilen < 188);
break;
}
} while (1);
//printf("sync byte found: %02x \n", buf[0]);
wtsilen = 0;
int nulls = 0;
do {
if (buf[0] == 0x47 && buf[1] == 0x1F && buf[2] == 0xFF) {
++nulls;
if (nulls > 100)
break;
//printf("null packet ");
// DVB null packet, discard
} else {
// printf("\nfrom tsi out: %x %x %x \n", buf[0], buf[1], buf[2]);
// write packet to output
int i = write(out_fd, buf, 188);
if (i < 188) {
perror("Did not write 188 bytes to output file!!!");
}
wtsilen += i;
}
if (rlen == wtsilen || quit_app)
break;
rtsilen = 0;
do {
rtsilen += read(tsi_fd, buf + rtsilen, 188 - rtsilen);
} while (rtsilen < 188);
} while (1);
}
close(in_fd);
close(out_fd);
close(tsi_fd);
exit(0);
}
static void signal_handler(int _signal)
{
if (!quit_app)
{
quit_app = 1;
}
}
RE: DVB nGene CI : TS Discontinuities issues
> -Original Message-
> From: Issa Gorissen [mailto:flo...@usa.net]
> Sent: mercredi 11 mai 2011 15:13
> To: Ralph Metzler
> Cc: Linux Media Mailing List; S-bastien RAILLARD; Oliver Endriss
> Subject: Re: DVB nGene CI : TS Discontinuities issues
>
> From: Ralph Metzler
> > Issa Gorissen writes:
> > > Could you please take a look at the cxd2099 issues ?
> > >
> > > I have attached a version with my changes. I have tested a lot of
> > > different settings with the help of the chip datasheet.
> > >
> > > Scrambled programs are not handled correctly. I don't know if it is
> > the > TICLK/MCLKI which is too high or something, or the sync
> > detector ? Also, > as we have to set the TOCLK to max of 72MHz, there
> > are way too much null > packets added. Is there a way to solve this ?
> >
> > I do not have any cxd2099 issues.
> > I have a simple test program which includes a 32bit counter as payload
> > and can pump data through the CI with full speed and have no packet
> > loss. I only tested decoding with an ORF stream and an Alphacrypt CAM
> > but also had no problems with this.
> >
> > Please take care not to write data faster than it is read. Starting
> > two dds will not guarantee this. To be certain you could write a small
> > program which never writes more packets than input buffer size minus
> > the number of read packets (and minus the stuffing null packets on
> ngene).
> >
> > Before blaming packet loss on the CI data path also please make
> > certain that you have no buffer overflows in the input part of the sec
> > device.
> > In the ngene driver you can e.g. add a printk in tsin_exchange():
> >
> > if (dvb_ringbuffer_free(&dev->tsin_rbuf) > len) { ...
> > } else
> > printk ("buffer overflow \n");
> >
> >
> > Regards,
> > Ralph
>
>
> Ralph,
>
> Please find my testing tool for the decryption attached. The idea is to
> write
> 5 packets and read them back from the CAM.
>
> My input is a raw ts captured with a gnutv I modified with a demux
> filter of 0x2000. Gnutv outputs at dvr and dvbloop reads from it,
> process via sec0 and writes output to a file.
>
> The channel I selected has been decrypted. Only problem is I have
> artifacts in the image and the sound.
>
> Do you have any idea of what I should improve from my test tool to fix
> that issue ?
>
>
Good news, it seems that you managed to get it working!
You can check that your input and output TS files doesn't have issues or
discontinuities.
If you have access to a Windows running computer, you can test your TS files
with a small analyzer I wrote:
http://www.coexsi.fr/publications/mpegts-analyzer/
> Thx,
> --
> Issa
--
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: DVB nGene CI : TS Discontinuities issues
On 09/05/11 09:04, Sébastien RAILLARD (COEXSI) wrote: >> I don't know if CAT needs to be in the stream passed through sec0 as >> Sebastien mentioned, so I modified gnutv to add it to dvr. >> > Yes, the CAT table is mandatory, it must be sent to the CAM, as well as : > * the EMM PID referenced in the CAT > * all the private descriptors (binary blobs) in the PMT and, of course > * the ECM PID referenced in the PMT > > Of course, the CAM must be initialized, all the necessary CAM resources must > be initialized and a CA_PMT object must be sent through the CAM command > channel to ask for unscrambling of needed channels. > > That why it's better to send directly the raw TS output of the demodulator > directly in the CAM. > And then doing the demux filtering stuff on the TS stream coming from the > CAM (once unscrambled). Thx Sebastien, Will check this out with gnutv and report. I think gnutv does all the init stuff you mentioned about the CAM. I will check for the possibly missing PSI packets gnutv might exclude. -- Issa -- 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: DVB nGene CI : TS Discontinuities issues
> -Original Message-
> From: Issa Gorissen [mailto:flo...@usa.net]
> Sent: lundi 9 mai 2011 02:42
> To: Ralph Metzler
> Cc: Linux Media Mailing List; "Sébastien RAILLARD (COEXSI)"; Oliver
> Endriss; Martin Vidovic
> Subject: Re: DVB nGene CI : TS Discontinuities issues
>
> On 07/05/11 23:34, Ralph Metzler wrote:
> > I do not have any cxd2099 issues.
> > I have a simple test program which includes a 32bit counter as payload
> > and can pump data through the CI with full speed and have no packet
> > loss. I only tested decoding with an ORF stream and an Alphacrypt CAM
> > but also had no problems with this.
> >
> > Please take care not to write data faster than it is read. Starting
> > two dds will not guarantee this. To be certain you could write a small
> > program which never writes more packets than input buffer size minus
> > the number of read packets (and minus the stuffing null packets on
> ngene).
> >
> > Before blaming packet loss on the CI data path also please make
> > certain that you have no buffer overflows in the input part of the sec
> > device.
> > In the ngene driver you can e.g. add a printk in tsin_exchange():
> >
> > if (dvb_ringbuffer_free(&dev->tsin_rbuf) > len) { ...
> > } else
> > printk ("buffer overflow \n");
> >
> >
> > Regards,
> > Ralph
>
> Ralph,
>
> As mentioned earlier, the warning message in tsin_exchange() is somewhat
> useless because it is printed endlessly at module start.
>
> However, I've written the small test (attached) and took care to not
> write more than read (not taking account of null packets).
>
> I still cannot descrambled channels. I'm using the source from 2.6.39 rc
> 5 with the fix from Oliver
> [http://linuxtv.org/hg/~endriss/v4l-dvb/rev/3d3e6ec2d0a7]. I launched
> gnutv with output to dvr, and launched my tool to read from dvr,
> write/read from sec0, write to a file.
>
> The end result is a file which is clean of null packets, but cannot be
> played by mplayer (no audio, or no video, or both...)
>
> I don't know if CAT needs to be in the stream passed through sec0 as
> Sebastien mentioned, so I modified gnutv to add it to dvr.
>
Yes, the CAT table is mandatory, it must be sent to the CAM, as well as :
* the EMM PID referenced in the CAT
* all the private descriptors (binary blobs) in the PMT and, of course
* the ECM PID referenced in the PMT
Of course, the CAM must be initialized, all the necessary CAM resources must
be initialized and a CA_PMT object must be sent through the CAM command
channel to ask for unscrambling of needed channels.
That why it's better to send directly the raw TS output of the demodulator
directly in the CAM.
And then doing the demux filtering stuff on the TS stream coming from the
CAM (once unscrambled).
> Sebastien, Martin, could you try Ralph suggestion and post results as
> well. Thx.
>
>
> Please also find an update of ngene-dvb.c, the sec device now handles
> blocking/non blocking access.
>
> --
> Issa
--
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: DVB nGene CI : TS Discontinuities issues
On 07/05/11 23:34, Ralph Metzler wrote:
> I do not have any cxd2099 issues.
> I have a simple test program which includes a 32bit counter as payload
> and can pump data through the CI with full speed and have no packet
> loss. I only tested decoding with an ORF stream and an Alphacrypt CAM
> but also had no problems with this.
>
> Please take care not to write data faster than it is read. Starting two
> dds will not guarantee this. To be certain you could write a small
> program which never writes more packets than input buffer size minus
> the number of read packets (and minus the stuffing null packets on ngene).
>
> Before blaming packet loss on the CI data path also please make
> certain that you have no buffer overflows in the input part of
> the sec device.
> In the ngene driver you can e.g. add a printk in tsin_exchange():
>
> if (dvb_ringbuffer_free(&dev->tsin_rbuf) > len) {
> ...
> } else
> printk ("buffer overflow \n");
>
>
> Regards,
> Ralph
Ralph,
As mentioned earlier, the warning message in tsin_exchange() is somewhat
useless because it is printed endlessly at module start.
However, I've written the small test (attached) and took care to not
write more than read (not taking account of null packets).
I still cannot descrambled channels. I'm using the source from 2.6.39 rc
5 with the fix from Oliver
[http://linuxtv.org/hg/~endriss/v4l-dvb/rev/3d3e6ec2d0a7]. I launched
gnutv with output to dvr, and launched my tool to read from dvr,
write/read from sec0, write to a file.
The end result is a file which is clean of null packets, but cannot be
played by mplayer (no audio, or no video, or both...)
I don't know if CAT needs to be in the stream passed through sec0 as
Sebastien mentioned, so I modified gnutv to add it to dvr.
Sebastien, Martin, could you try Ralph suggestion and post results as
well. Thx.
Please also find an update of ngene-dvb.c, the sec device now handles
blocking/non blocking access.
--
Issa
#include
#include
#include
#include
#include
#include
#include
#include
static void signal_handler(int _signal);
static int quit_app = 0;
int main(int argc, char *argv[])
{
signal(SIGINT, signal_handler);
if (argc <= 3)
exit(1);
int in_fd = open(argv[1], O_RDONLY);
int out_fd = open(argv[2], O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
int tsi_fd = open(argv[3], O_RDWR);
int rlen = 0;
int wlen = 0;
int rtsilen = 0;
int wtsilen = 0;
int BUFFY = 188 * 20;
unsigned char buf[BUFFY];
struct timespec sl[1];
sl[0].tv_nsec = 25;
while (!quit_app)
{
// read from input (DVR or other)
rlen = read(in_fd, buf, BUFFY);
if (rlen > 0)
{
// write data to caio device
wlen = write(tsi_fd, buf, rlen);
if (wlen != rlen)
{
perror("Did not write same amount of data from input to caio!!!");
exit(1);
}/* else
printf("written %d bytes in tsi\n", wlen);
*/ }
if (rlen < BUFFY)
{
nanosleep(sl, NULL);
}
if (rlen < 188)
continue;
// read data from caio device - should be decrypted
// finding sync byte
do {
rtsilen = read(tsi_fd, buf, 1);
// printf("reading one byte: %02x from tsi\n", buf[0]);
if (rtsilen && (buf[0] == 0x47)) {
do {
int i = read(tsi_fd, buf + rtsilen, 188 - rtsilen);
rtsilen += i;
// printf("reading %d bytes from tsi\n", i);
} while (rtsilen < 188);
break;
}
} while (1);
//printf("sync byte found: %02x \n", buf[0]);
wtsilen = 0;
do {
// printf("from tsi out: %x %x %x \n", buf[0], buf[1], buf[2]);
if (buf[0] == 0x47 && buf[1] == 0x1F && buf[2] == 0xFF) {
// DVB null packet, discard
} else {
// write packet to output
wtsilen += write(out_fd, buf, 188);
}
if (rlen == wtsilen)
break;
rtsilen = 0;
do {
rtsilen += read(tsi_fd, buf + rtsilen, 188 - rtsilen);
} while (rtsilen < 188);
} while (1);
}
close(in_fd);
close(out_fd);
close(tsi_fd);
exit(0);
}
static void signal_handler(int _signal)
{
if (!quit_app)
{
quit_app = 1;
}
}
/*
* ngene-dvb.c: nGene PCIe bridge driver - DVB functions
*
* Copyright (C) 2005-2007 Micronas
*
* Copyright (C) 2008-2009 Ralph Metzler
* Modifications for new nGene firmware,
* support for EEPROM-copying,
* support for new dual DVB-S2 card prototype
*
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* version 2 only, as published by the Free Software Foundation.
*
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
Re: DVB nGene CI : TS Discontinuities issues
On 07/05/11 23:34, Ralph Metzler wrote:
> Before blaming packet loss on the CI data path also please make
> certain that you have no buffer overflows in the input part of
> the sec device.
> In the ngene driver you can e.g. add a printk in tsin_exchange():
>
> if (dvb_ringbuffer_free(&dev->tsin_rbuf) > len) {
> ...
> } else
> printk ("buffer overflow \n");
Ralph,
void *tsin_exchange(void *priv, void *buf, u32 len, u32 clock, u32 flags)
{
struct ngene_channel *chan = priv;
struct ngene *dev = chan->dev;
if (flags & DF_SWAP32)
swap_buffer(buf, len);
if (dev->ci.en && chan->number == 2) {
if (dvb_ringbuffer_free(&dev->tsin_rbuf) > len) {
dvb_ringbuffer_write(&dev->tsin_rbuf, buf, len);
wake_up_interruptible(&dev->tsin_rbuf.queue);
} else
printk (KERN_WARNING "ngene transport interface:
tsin_exchange: buffer overflow \n");
return 0;
}
if (chan->users > 0) {
dvb_dmx_swfilter(&chan->demux, buf, len);
}
return NULL;
}
just prints the buffer overflow warning just after the module is loaded,
no other action made.
--
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: DVB nGene CI : TS Discontinuities issues
On 03/05/11 12:59, Sébastien RAILLARD (COEXSI) wrote: > Dear all, > > I'm doing some tests with the CI interface of the "Linux4Media cineS2 DVB-S2 > Twin Tuner (v5)" card. > I notice some TS discontinuities during my tests. > > My setup: > - Aston Viaccess Pro CAM > - Linux4Media cineS2 DVB-S2 Twin Tuner (v5) card > - Latest git media_build source with DF_SWAP32 patch > - DVB-S source from ASTRA 19.2E / 12285.00-V-27500 > > Test #1: (idle) > Reading from sec0 (without CI init or sec0 input stream) using "dd" give me > a stream of NULL TS packets of roughly 62mbps or 7.8MB/s (seems normal > behavior) > Command line: dd if=/dev/dvb/adapter14/sec0 of=/root/test.ts bs=18800 > count=1 > > Test #2: (CAM removal) > After CAM initialization and some tests, if CAM is removed, the output sec0 > bandwidth isn't anymore 62mbps of NULL TS packets > Same command line as Test #1 is used. > It seems that the CI is badly reacting after hot remove of CAM. > After rebooting, everything is fine again. > > Test #3: (Test dvr0 stream) > - Setting up the DVB-S reception: gnutv -adapter 14 -channels channels.conf > -out dvr CHAINE > - Channel configuration: CHAINE:12285:v:0:27500:170:120:17030 > - Dumping the dvr0 output: dd if=/dev/dvb/adapter14/dvr0 of=/root/test.ts > bs=1880 count=1000 > => The dvr0 output bandwidth is roughly 300kB/s (normal for one filtered > channel) > => The resulting TS file is correct (no sync missing, no continuity error) > > Test #4: (Loop mode - No CAM inserted) > - Sending all TS packets from dvr0 to sec0: dd if=/dev/dvb/adapter14/dvr0 > of=/dev/dvb/adapter14/sec0 bs=1880 > - Setting up the DVB-S reception: gnutv -adapter 14 -channels channels.conf > -out dvr CHAINE > - Channel configuration: CHAINE:12285:v:0:27500:170:120:17030 > - Dumping the sec0 output: dd if=/dev/dvb/adapter14/sec0 of=/root/test.ts > bs=18800 count=1 > => The sec0 output bandwidth is roughly 7.8MB/s (normal as the CI output is > always 62mbps) > => The resulting TS file is filled at 96% by NULL TS packets (normal, > regarding the input stream bandwidth of 300kB/S) > => All the input PID seem to present in the output file > => But, there are some discontinuities in the TS packets (a lot and for all > the PID) > > Test #5: (Trough CAM - CAM is inserted) > - Sending all TS packets from dvr0 to sec0: dd if=/dev/dvb/adapter14/dvr0 > of=/dev/dvb/adapter14/sec0 bs=1880 > - Setting up the DVB-S reception: gnutv -adapter 14 -channels channels.conf > -out dvr CHAINE > - Channel configuration: CHAINE:12285:v:0:27500:170:120:17030 > - Waiting for CAM initialization (the CAM is correctly initialized and the > PMT packet is send to the CAM) > - Dumping the sec0 output: dd if=/dev/dvb/adapter14/sec0 of=/root/test.ts > bs=18800 count=1 > => The sec0 output bandwidth is roughly 7.8MB/s (normal as the CI output is > always 62mbps) > => The resulting TS file is filled at 96% by NULL TS packets (normal, > regarding the input stream bandwidth of 300kB/S) > => All the input PID seem to present in the output file > => The stream isn't decoded (normal as the CAT table isn't outputted by > gnutv) > => But, there are some discontinuities in the TS packets (a lot and for all > the PID) > > So, in summary, I'm observing discontinues when stream is going through the > sec0 device, if CAM is present or not. > Also, the CI adapter doesn't seem to react correctly when the CAM is hot > removed. > I can provide the TS files (from dvr0, from sec0 with CAM and without CAM) > if someone is interested. > > Does someone has a setup that show no discontinuities when a TS stream is > going through sec0? (with an input TS file) > I would like to test it as for me the CI interface doesn't seem to work for > the nGene cards. > > Best regards, > Sebastien. Ralph, Could you please take a look at the cxd2099 issues ? I have attached a version with my changes. I have tested a lot of different settings with the help of the chip datasheet. Scrambled programs are not handled correctly. I don't know if it is the TICLK/MCLKI which is too high or something, or the sync detector ? Also, as we have to set the TOCLK to max of 72MHz, there are way too much null packets added. Is there a way to solve this ? Thx -- Issa /* * cxd2099.c: Driver for the CXD2099AR Common Interface Controller * * Copyright (C) 2010 DigitalDevices UG * * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * version 2 only, as published by the Free Software Foundation. * * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
DVB nGene CI : TS Discontinuities issues
Dear all, I'm doing some tests with the CI interface of the "Linux4Media cineS2 DVB-S2 Twin Tuner (v5)" card. I notice some TS discontinuities during my tests. My setup: - Aston Viaccess Pro CAM - Linux4Media cineS2 DVB-S2 Twin Tuner (v5) card - Latest git media_build source with DF_SWAP32 patch - DVB-S source from ASTRA 19.2E / 12285.00-V-27500 Test #1: (idle) Reading from sec0 (without CI init or sec0 input stream) using "dd" give me a stream of NULL TS packets of roughly 62mbps or 7.8MB/s (seems normal behavior) Command line: dd if=/dev/dvb/adapter14/sec0 of=/root/test.ts bs=18800 count=1 Test #2: (CAM removal) After CAM initialization and some tests, if CAM is removed, the output sec0 bandwidth isn't anymore 62mbps of NULL TS packets Same command line as Test #1 is used. It seems that the CI is badly reacting after hot remove of CAM. After rebooting, everything is fine again. Test #3: (Test dvr0 stream) - Setting up the DVB-S reception: gnutv -adapter 14 -channels channels.conf -out dvr CHAINE - Channel configuration: CHAINE:12285:v:0:27500:170:120:17030 - Dumping the dvr0 output: dd if=/dev/dvb/adapter14/dvr0 of=/root/test.ts bs=1880 count=1000 => The dvr0 output bandwidth is roughly 300kB/s (normal for one filtered channel) => The resulting TS file is correct (no sync missing, no continuity error) Test #4: (Loop mode - No CAM inserted) - Sending all TS packets from dvr0 to sec0: dd if=/dev/dvb/adapter14/dvr0 of=/dev/dvb/adapter14/sec0 bs=1880 - Setting up the DVB-S reception: gnutv -adapter 14 -channels channels.conf -out dvr CHAINE - Channel configuration: CHAINE:12285:v:0:27500:170:120:17030 - Dumping the sec0 output: dd if=/dev/dvb/adapter14/sec0 of=/root/test.ts bs=18800 count=1 => The sec0 output bandwidth is roughly 7.8MB/s (normal as the CI output is always 62mbps) => The resulting TS file is filled at 96% by NULL TS packets (normal, regarding the input stream bandwidth of 300kB/S) => All the input PID seem to present in the output file => But, there are some discontinuities in the TS packets (a lot and for all the PID) Test #5: (Trough CAM - CAM is inserted) - Sending all TS packets from dvr0 to sec0: dd if=/dev/dvb/adapter14/dvr0 of=/dev/dvb/adapter14/sec0 bs=1880 - Setting up the DVB-S reception: gnutv -adapter 14 -channels channels.conf -out dvr CHAINE - Channel configuration: CHAINE:12285:v:0:27500:170:120:17030 - Waiting for CAM initialization (the CAM is correctly initialized and the PMT packet is send to the CAM) - Dumping the sec0 output: dd if=/dev/dvb/adapter14/sec0 of=/root/test.ts bs=18800 count=1 => The sec0 output bandwidth is roughly 7.8MB/s (normal as the CI output is always 62mbps) => The resulting TS file is filled at 96% by NULL TS packets (normal, regarding the input stream bandwidth of 300kB/S) => All the input PID seem to present in the output file => The stream isn't decoded (normal as the CAT table isn't outputted by gnutv) => But, there are some discontinuities in the TS packets (a lot and for all the PID) So, in summary, I'm observing discontinues when stream is going through the sec0 device, if CAM is present or not. Also, the CI adapter doesn't seem to react correctly when the CAM is hot removed. I can provide the TS files (from dvr0, from sec0 with CAM and without CAM) if someone is interested. Does someone has a setup that show no discontinuities when a TS stream is going through sec0? (with an input TS file) I would like to test it as for me the CI interface doesn't seem to work for the nGene cards. Best regards, Sebastien. -- 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
