Re: DVB nGene CI : TS Discontinuities issues

Re: DVB nGene CI : TS Discontinuities issues

[Issa Gorissen]

[-- Attachment #1: Type: text/plain, Size: 2071 bytes --]

From: Ralph Metzler <rjkm@metzlerbros.de>
> 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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: dvbloop.c --]
[-- Type: text/x-csrc; name="dvbloop.c", Size: 2445 bytes --]

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <signal.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <time.h>

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 = 250000;
	
	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

[Sébastien RAILLARD (COEXSI)]

> -----Original Message-----
> From: Issa Gorissen [mailto:flop.m@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 <rjkm@metzlerbros.de>
> > 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

Re: DVB nGene CI : TS Discontinuities issues

[Issa Gorissen]

On 11/05/11 15:12, Issa Gorissen wrote:
> From: Ralph Metzler <rjkm@metzlerbros.de>
>> 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

Re: DVB nGene CI : TS Discontinuities issues

[Ralph Metzler]

Issa Gorissen writes:
 > On 11/05/11 15:12, Issa Gorissen wrote:
 > > From: Ralph Metzler <rjkm@metzlerbros.de>
 > >> 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 <stdio.h>
#include <ctype.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <stdint.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <pthread.h>

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&0xffff))
			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;
		}
		for (off=0; off<len; off+=188) {
			proc_buf(buf+off, &d);
		}
	}	
}

#define SNUM 671
void send(void)
{
	uint8_t buf[188*SNUM], *cts;
	int i;
	uint32_t c=0;
	int fdo;

	fdo=open("/dev/dvb/adapter4/sec0", O_WRONLY);


	while (1) {
		for (i=0; i<SNUM; i++) {
			cts=buf+i*188;
			memcpy(cts, ts, 188);
			cts[4]=(c>>24);
			cts[5]=(c>>16);
			cts[6]=(c>>8);
			cts[7]=c;
			//write(fdo, fill, 188);
			//printf("S %d\n", c); 
			c++;
			//usleep(100000+0xffff&rand());
			//usleep(1000);
		}
		write(fdo, buf, 188*SNUM);
	}
}


int main()
{
	pthread_t th;

	memset(ts+8, 180, 0x5a);
	pthread_create(&th, NULL, get_ts, NULL);
	send();
}

 

Re: DVB nGene CI : TS Discontinuities issues

[Anssi Hannula]

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 0000: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 <stdio.h>
> #include <ctype.h>
> #include <string.h>
> #include <unistd.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <stdint.h>
> #include <stdlib.h>
> #include <fcntl.h>
> #include <sys/ioctl.h>
> #include <pthread.h>
> 
> 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&0xffff))
> 			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;
> 		}
> 		for (off=0; off<len; off+=188) {
> 			proc_buf(buf+off, &d);
> 		}
> 	}	
> }
> 
> #define SNUM 671
> void send(void)
> {
> 	uint8_t buf[188*SNUM], *cts;
> 	int i;
> 	uint32_t c=0;
> 	int fdo;
> 
> 	fdo=open("/dev/dvb/adapter4/sec0", O_WRONLY);
> 
> 
> 	while (1) {
> 		for (i=0; i<SNUM; i++) {
> 			cts=buf+i*188;
> 			memcpy(cts, ts, 188);
> 			cts[4]=(c>>24);
> 			cts[5]=(c>>16);
> 			cts[6]=(c>>8);
> 			cts[7]=c;
> 			//write(fdo, fill, 188);
> 			//printf("S %d\n", c); 
> 			c++;
> 			//usleep(100000+0xffff&rand());
> 			//usleep(1000);
> 		}
> 		write(fdo, buf, 188*SNUM);
> 	}
> }
> 
> 
> int main()
> {
> 	pthread_t th;
> 
> 	memset(ts+8, 180, 0x5a);
> 	pthread_create(&th, NULL, get_ts, NULL);
> 	send();
> }
> 
>  
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Anssi Hannula

Re: DVB nGene CI : TS Discontinuities issues

[Ralph Metzler]

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

cxd2099 CI on DDBridge not working (was: Re: DVB nGene CI : TS Discontinuities issues)

[Anssi Hannula]

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