Mailing List Archive

cx18: Working on sliced VBI: is this correct?
In working on Sliced VBI for the cx18 driver, I've pared down and
commented the "struct vbi_info" definition. Did I understand
everything that's going on based on the revised definition below?

(BTW the mini MPEG-2 PS parser function borrowed from ivtv to look for
splice points was very elegant given the task it had to perform -
impressive.)

Regards,
Andy


#define CX18_VBI_FRAMES 32

struct vbi_info {
/* Current state of v4l2 VBI settings for this device */
struct v4l2_format in;
struct v4l2_sliced_vbi_format *sliced_in; /* pointer to in.fmt.sliced */
u32 count; /* Count of VBI data lines: 60 Hz: 12 or 50 Hz: 18 */
u32 start[2]; /* First VBI data line per field: 10 & 273 or 6 & 318 */

/*
* A note about "sliced" VBI data as implemented in this driver:
*
* Currently we collect the sliced VBI in the form of Ancillary Data
* packets, inserted by the AV core decoder/digitizer/slicer in the
* horizontal blanking region of the VBI lines, in "raw" mode as far as
* the Encoder is concerned. We don't tell the Encoder itself
* to provide sliced VBI. (AV Core: sliced mode - Encoder: raw mode)
*
* We then process the ancillary data ourselves to send the sliced data
* to the user application directly or build up MPEG-2 private stream 1
* packets to splice into (only!) MPEG-2 PS streams for the user app.
*
* (That's how ivtv essentially does it.)
*
* The Encoder should be able to extract certain sliced VBI data for
* us and provide it in a separate stream or splice it into any type of
* MPEG PS or TS stream, however:
* I haven't tested it,
* the Encoder may not handle every type of sliced VBI data,
* it would require some significant changes to this driver, and
* it requires some small additions to the V4L2 spec.
* But it's worth doing it someday, as manually splicing into a TS may
* not be practical in the driver.
*/

/*
* Number of "raw" VBI samples per horizontal line we tell the Enc to
* grab from the decoder/digitizer/slicer output for raw or sliced VBI
*/
u32 raw_decoder_line_size; /* 1444 = 4 byte SAV + 720 Y + 720 U/V */
u32 sliced_decoder_line_size; /* 272 for 60 Hz, 284 for 50 Hz */

/*
* Raster Reference/Protection (RP) bytes, used in Start/End Active
* Video codes emitted from the digitzer, that flag the start of VBI
* sample or VBI ancilliary data regions in the digitial ratser line.
*/
u8 raw_decoder_sav_odd_field;
u8 raw_decoder_sav_even_field;
u8 sliced_decoder_eav_odd_field;
u8 sliced_decoder_eav_even_field;

u32 frame; /* Count of VBI buffers/frames received from the Encoder */

/*
* Vars for creation and insertion of MPEG Private Stream 1 packets
* of sliced VBI data into an MPEG PS
*/

/* Boolean: create and insert Private Stream 1 packets into the PS */
int insert_mpeg;

/*
* Buffer for the maximum of 2 * 18 * packet_size sliced VBI lines.
* Used in cx18-vbi.c only for collecting sliced data, and as a source
* during conversion of sliced VBI data into MPEG Priv Stream 1 packets.
* We don't need to save state here, but the array may have been a bit
* too big (2304 bytes) to alloc from the stack.
*/
struct v4l2_sliced_vbi_data sliced_data[36];

/*
* A ring buffer of driver-generated MPEG-2 PS
* Program Pack/Private Stream 1 packets for sliced VBI data insertion
* into the MPEG PS stream.
*
* In each sliced_mpeg_data[] buffer is:
* 16 byte MPEG-2 PS Program Pack Header
* 16 byte MPEG-2 Private Stream 1 PES Header
* 4 byte magic number: "itv0" or "ITV0"
* 4 byte even field line mask, if "itv0"
* 4 byte odd field line mask, if "itv0"
* 36 lines, if "ITV0"; or <36 lines, if "itv0"; of sliced VBI data
*
* Each line in the payload is
* 1 byte line header derived from the SDID (WSS, CC, VPS, etc.)
* 42 bytes of line data
*
* That's a maximum 1552 bytes of payload in the Private Stream 1 packet
* (a holdover from ivtv), and a maximum 1584 bytes total.
*/
#define CX18_SLICED_MPEG_DATA_MAXSZ 1584
u8 *sliced_mpeg_data[CX18_VBI_FRAMES];
u32 sliced_mpeg_size[CX18_VBI_FRAMES];

/* Count of Program Pack/Program Stream 1 packets inserted into PS */
u32 inserted_frame;

/*
* A dummy driver stream transfer buffer with a copy of the next
* sliced_mpeg_data[] buffer for output to userland apps.
* Only used in cx18-fileops.c, but its state needs to persist at times.
*/
struct cx18_buffer sliced_mpeg_buf;
};



_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: cx18: Working on sliced VBI: is this correct? [ In reply to ]
On Monday 26 January 2009 04:38:17 Andy Walls wrote:
> In working on Sliced VBI for the cx18 driver, I've pared down and
> commented the "struct vbi_info" definition. Did I understand
> everything that's going on based on the revised definition below?

See comments below.

> (BTW the mini MPEG-2 PS parser function borrowed from ivtv to look for
> splice points was very elegant given the task it had to perform -
> impressive.)

Thanks! But it's still an ugly hack. Although the cx23415/6 is supposed
to be able to insert the sliced VBI data into the MPEG stream by itself,
it created a corrupt MPEG stream when I tried that at the time. However,
I've never tried it with the latest firmware, so it might be fixed by now.

The cx23418 has a similar feature and I would certainly attempt to test
that first. It makes life a lot easier if the firmware can handle it
properly.

>
> Regards,
> Andy
>
>
> #define CX18_VBI_FRAMES 32
>
> struct vbi_info {
> /* Current state of v4l2 VBI settings for this device */
> struct v4l2_format in;
> struct v4l2_sliced_vbi_format *sliced_in; /* pointer to in.fmt.sliced */
> u32 count; /* Count of VBI data lines: 60 Hz: 12 or 50 Hz: 18 */
> u32 start[2]; /* First VBI data line per field: 10 & 273 or 6 & 318 */
>
> /*
> * A note about "sliced" VBI data as implemented in this driver:
> *
> * Currently we collect the sliced VBI in the form of Ancillary Data
> * packets, inserted by the AV core decoder/digitizer/slicer in the
> * horizontal blanking region of the VBI lines, in "raw" mode as far as
> * the Encoder is concerned. We don't tell the Encoder itself
> * to provide sliced VBI. (AV Core: sliced mode - Encoder: raw mode)
> *
> * We then process the ancillary data ourselves to send the sliced data
> * to the user application directly or build up MPEG-2 private stream 1
> * packets to splice into (only!) MPEG-2 PS streams for the user app.

Correct. The cx23415/6 fw does not support TS so I only needed to splice it
in the PS stream.

> *
> * (That's how ivtv essentially does it.)
> *
> * The Encoder should be able to extract certain sliced VBI data for
> * us and provide it in a separate stream or splice it into any type of
> * MPEG PS or TS stream, however:
> * I haven't tested it,
> * the Encoder may not handle every type of sliced VBI data,
> * it would require some significant changes to this driver, and
> * it requires some small additions to the V4L2 spec.

Actually, it shouldn't be too difficult to test it and the advantages will
outweight the extra time (which I think is mostly getting rid of unnecessary
code). From what I remember when I did the original testing I just sent the
command to enable VBI embedding and there it appeared. Corrupt, admittedly,
but it was easy to test.

> * But it's worth doing it someday, as manually splicing into a TS may
> * not be practical in the driver.
> */
>
> /*
> * Number of "raw" VBI samples per horizontal line we tell the Enc to
> * grab from the decoder/digitizer/slicer output for raw or sliced VBI
> */
> u32 raw_decoder_line_size; /* 1444 = 4 byte SAV + 720 Y + 720 U/V */
> u32 sliced_decoder_line_size; /* 272 for 60 Hz, 284 for 50 Hz */
>
> /*
> * Raster Reference/Protection (RP) bytes, used in Start/End Active
> * Video codes emitted from the digitzer, that flag the start of VBI
> * sample or VBI ancilliary data regions in the digitial ratser line.
> */
> u8 raw_decoder_sav_odd_field;
> u8 raw_decoder_sav_even_field;
> u8 sliced_decoder_eav_odd_field;
> u8 sliced_decoder_eav_even_field;

All six fields above can be replaced with constants since cx18 supports only one
encoder, the cx23418 itself.

> u32 frame; /* Count of VBI buffers/frames received from the Encoder */
>
> /*
> * Vars for creation and insertion of MPEG Private Stream 1 packets
> * of sliced VBI data into an MPEG PS
> */
>
> /* Boolean: create and insert Private Stream 1 packets into the PS */
> int insert_mpeg;
>
> /*
> * Buffer for the maximum of 2 * 18 * packet_size sliced VBI lines.
> * Used in cx18-vbi.c only for collecting sliced data, and as a source
> * during conversion of sliced VBI data into MPEG Priv Stream 1 packets.
> * We don't need to save state here, but the array may have been a bit
> * too big (2304 bytes) to alloc from the stack.
> */
> struct v4l2_sliced_vbi_data sliced_data[36];
>
> /*
> * A ring buffer of driver-generated MPEG-2 PS
> * Program Pack/Private Stream 1 packets for sliced VBI data insertion
> * into the MPEG PS stream.
> *
> * In each sliced_mpeg_data[] buffer is:
> * 16 byte MPEG-2 PS Program Pack Header
> * 16 byte MPEG-2 Private Stream 1 PES Header
> * 4 byte magic number: "itv0" or "ITV0"
> * 4 byte even field line mask, if "itv0"
> * 4 byte odd field line mask, if "itv0"
> * 36 lines, if "ITV0"; or <36 lines, if "itv0"; of sliced VBI data
> *
> * Each line in the payload is
> * 1 byte line header derived from the SDID (WSS, CC, VPS, etc.)
> * 42 bytes of line data
> *
> * That's a maximum 1552 bytes of payload in the Private Stream 1 packet
> * (a holdover from ivtv), and a maximum 1584 bytes total.
> */
> #define CX18_SLICED_MPEG_DATA_MAXSZ 1584
> u8 *sliced_mpeg_data[CX18_VBI_FRAMES];
> u32 sliced_mpeg_size[CX18_VBI_FRAMES];

The reason behind the seemingly magical number 1584 is the PVR-350. The
PVR-350 can extract embedded VBI data while decoding an MPEG stream and
pass them back to the user (the /dev/vbi8 device), or actually using it to
program the video output with CC data. However, the PVR-350 will only
return up to 1552 bytes, even though the private packet might be longer.
It's just cut off.

Being able to read the embedded VBI data from the cx18 driver in the
PVR-350 is something that is very desirable.

> /* Count of Program Pack/Program Stream 1 packets inserted into PS */
> u32 inserted_frame;
>
> /*
> * A dummy driver stream transfer buffer with a copy of the next
> * sliced_mpeg_data[] buffer for output to userland apps.
> * Only used in cx18-fileops.c, but its state needs to persist at times.
> */
> struct cx18_buffer sliced_mpeg_buf;
> };

Regards,

Hans

--
Hans Verkuil - video4linux developer - sponsored by TANDBERG

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: cx18: Working on sliced VBI: is this correct? [ In reply to ]
On Mon, 2009-01-26 at 11:48 +0100, Hans Verkuil wrote:
> On Monday 26 January 2009 04:38:17 Andy Walls wrote:
> > In working on Sliced VBI for the cx18 driver, I've pared down and
> > commented the "struct vbi_info" definition. Did I understand
> > everything that's going on based on the revised definition below?
>
> See comments below.
>
> > (BTW the mini MPEG-2 PS parser function borrowed from ivtv to look for
> > splice points was very elegant given the task it had to perform -
> > impressive.)
>
> Thanks! But it's still an ugly hack.

OK. On the macro level, splicing in one's own packets is a hack. :)


> Although the cx23415/6 is supposed
> to be able to insert the sliced VBI data into the MPEG stream by itself,
> it created a corrupt MPEG stream when I tried that at the time. However,
> I've never tried it with the latest firmware, so it might be fixed by now.

Did you always use the 10 bit VIP-1.1 mode of the digitizer, or did you
also try VIP-1.0, VIP-2.0, BT.656 and 8 bit mode as well?

I did some reading on the checksum that's in the ancillary data. In
10-bit mode, it's a 10 bit value computed with all 10 bits of the values
summed. I noted I wouldn't be able to check it, because I don't have
access to the two LSB's after the binary point for all the values in
question. It could be that Encoder firmware couldn't check the CS value
in the ancillary data either. Maybe 8-bit mode would help. Maybe
precisely controlling the value of the Task bit in the RP codes as one
can do in VIP-2.0 mode, would help.




> The cx23418 has a similar feature and I would certainly attempt to test
> that first. It makes life a lot easier if the firmware can handle it
> properly.

I believe MythTV already understands the ivtv way of doing VBI. Since,
I'm runinng out of time before Feb 17 to test analog CC over the air, I
figured I get the ivtv way working first, since the code is mostly set
to do that anyway and MythTV will be a test/verification tool.

> >
> > Regards,
> > Andy
> >
> >
> > #define CX18_VBI_FRAMES 32
> >
> > struct vbi_info {
> > /* Current state of v4l2 VBI settings for this device */
> > struct v4l2_format in;
> > struct v4l2_sliced_vbi_format *sliced_in; /* pointer to in.fmt.sliced */
> > u32 count; /* Count of VBI data lines: 60 Hz: 12 or 50 Hz: 18 */
> > u32 start[2]; /* First VBI data line per field: 10 & 273 or 6 & 318 */
> >
> > /*
> > * A note about "sliced" VBI data as implemented in this driver:
> > *
> > * Currently we collect the sliced VBI in the form of Ancillary Data
> > * packets, inserted by the AV core decoder/digitizer/slicer in the
> > * horizontal blanking region of the VBI lines, in "raw" mode as far as
> > * the Encoder is concerned. We don't tell the Encoder itself
> > * to provide sliced VBI. (AV Core: sliced mode - Encoder: raw mode)
> > *
> > * We then process the ancillary data ourselves to send the sliced data
> > * to the user application directly or build up MPEG-2 private stream 1
> > * packets to splice into (only!) MPEG-2 PS streams for the user app.
>
> Correct. The cx23415/6 fw does not support TS so I only needed to splice it
> in the PS stream.
>
> > *
> > * (That's how ivtv essentially does it.)
> > *
> > * The Encoder should be able to extract certain sliced VBI data for
> > * us and provide it in a separate stream or splice it into any type of
> > * MPEG PS or TS stream, however:
> > * I haven't tested it,
> > * the Encoder may not handle every type of sliced VBI data,
> > * it would require some significant changes to this driver, and
> > * it requires some small additions to the V4L2 spec.
>
> Actually, it shouldn't be too difficult to test it and the advantages will
> outweight the extra time (which I think is mostly getting rid of unnecessary
> code). From what I remember when I did the original testing I just sent the
> command to enable VBI embedding and there it appeared. Corrupt, admittedly,
> but it was easy to test.

Agree. Especially for the TS.


> > * But it's worth doing it someday, as manually splicing into a TS may
> > * not be practical in the driver.
> > */
> >
> > /*
> > * Number of "raw" VBI samples per horizontal line we tell the Enc to
> > * grab from the decoder/digitizer/slicer output for raw or sliced VBI
> > */
> > u32 raw_decoder_line_size; /* 1444 = 4 byte SAV + 720 Y + 720 U/V */
> > u32 sliced_decoder_line_size; /* 272 for 60 Hz, 284 for 50 Hz */
> >
> > /*
> > * Raster Reference/Protection (RP) bytes, used in Start/End Active
> > * Video codes emitted from the digitzer, that flag the start of VBI
> > * sample or VBI ancilliary data regions in the digitial ratser line.
> > */
> > u8 raw_decoder_sav_odd_field;
> > u8 raw_decoder_sav_even_field;
> > u8 sliced_decoder_eav_odd_field;
> > u8 sliced_decoder_eav_even_field;
>
> All six fields above can be replaced with constants since cx18 supports only one
> encoder, the cx23418 itself.

Yes, you're right. I can make them all named constants and just be
sensitive to which constant to use for sliced for 60 or 50 Hz.



> > u32 frame; /* Count of VBI buffers/frames received from the Encoder */
> >
> > /*
> > * Vars for creation and insertion of MPEG Private Stream 1 packets
> > * of sliced VBI data into an MPEG PS
> > */
> >
> > /* Boolean: create and insert Private Stream 1 packets into the PS */
> > int insert_mpeg;
> >
> > /*
> > * Buffer for the maximum of 2 * 18 * packet_size sliced VBI lines.
> > * Used in cx18-vbi.c only for collecting sliced data, and as a source
> > * during conversion of sliced VBI data into MPEG Priv Stream 1 packets.
> > * We don't need to save state here, but the array may have been a bit
> > * too big (2304 bytes) to alloc from the stack.
> > */
> > struct v4l2_sliced_vbi_data sliced_data[36];
> >
> > /*
> > * A ring buffer of driver-generated MPEG-2 PS
> > * Program Pack/Private Stream 1 packets for sliced VBI data insertion
> > * into the MPEG PS stream.
> > *
> > * In each sliced_mpeg_data[] buffer is:
> > * 16 byte MPEG-2 PS Program Pack Header
> > * 16 byte MPEG-2 Private Stream 1 PES Header
> > * 4 byte magic number: "itv0" or "ITV0"
> > * 4 byte even field line mask, if "itv0"
> > * 4 byte odd field line mask, if "itv0"
> > * 36 lines, if "ITV0"; or <36 lines, if "itv0"; of sliced VBI data
> > *
> > * Each line in the payload is
> > * 1 byte line header derived from the SDID (WSS, CC, VPS, etc.)
> > * 42 bytes of line data
> > *
> > * That's a maximum 1552 bytes of payload in the Private Stream 1 packet
> > * (a holdover from ivtv), and a maximum 1584 bytes total.
> > */
> > #define CX18_SLICED_MPEG_DATA_MAXSZ 1584
> > u8 *sliced_mpeg_data[CX18_VBI_FRAMES];
> > u32 sliced_mpeg_size[CX18_VBI_FRAMES];
>
> The reason behind the seemingly magical number 1584 is the PVR-350. The
> PVR-350 can extract embedded VBI data while decoding an MPEG stream and
> pass them back to the user (the /dev/vbi8 device), or actually using it to
> program the video output with CC data. However, the PVR-350 will only
> return up to 1552 bytes, even though the private packet might be longer.
> It's just cut off.
>
> Being able to read the embedded VBI data from the cx18 driver in the
> PVR-350 is something that is very desirable.

Ah, OK.


Thanks.

Regards,
Andy

> > /* Count of Program Pack/Program Stream 1 packets inserted into PS */
> > u32 inserted_frame;
> >
> > /*
> > * A dummy driver stream transfer buffer with a copy of the next
> > * sliced_mpeg_data[] buffer for output to userland apps.
> > * Only used in cx18-fileops.c, but its state needs to persist at times.
> > */
> > struct cx18_buffer sliced_mpeg_buf;
> > };
>
> Regards,
>
> Hans
>


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
cx18: Working on sliced VBI: is this correct? [ In reply to ]
> Date: Mon, 26 Jan 2009 20:47:54 -0500
> From: Andy Walls <awalls@radix.net>

> I believe MythTV already understands the ivtv way of doing VBI. Since,
> I'm runinng out of time before Feb 17 to test analog CC over the air,

If you have a VCR, you can presumably just record a tapeful of -anything-
today that has CC and read it back at your leisure. Just make sure to
view the recording on a CC-capable TV so you know it all worked and
that the program(s) were actually transmitting CC...

If you don't have a VCR, I'm sure that I or any number of other people
could mail you a random VHS tape someday if you were to borrow a VCR
or pick one up at a yard sale or something.

(Not that I'd like to -dis-incentivize anything that improves handling
of CC data, since I depend on it for various machine-processing hacks
and too many video-processing packages seem to drop it on the floor.
So maybe you should forget any way of relaxing the deadline. :)

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: cx18: Working on sliced VBI: is this correct? [ In reply to ]
--- On Mon, 1/26/09, f-myth-users@media.mit.edu <f-myth-users@media.mit.edu> wrote:

> From: f-myth-users@media.mit.edu <f-myth-users@media.mit.edu>
> Subject: [ivtv-devel] cx18: Working on sliced VBI: is this correct?
> To: ivtv-devel@ivtvdriver.org
> Cc: ivtv-devel@ivtvdriver.org
> Date: Monday, January 26, 2009, 6:24 PM
> > Date: Mon, 26 Jan 2009 20:47:54 -0500
> > From: Andy Walls <awalls@radix.net>
>
> > I believe MythTV already understands the ivtv way
> of doing VBI. Since,
> > I'm runinng out of time before Feb 17 to test
> analog CC over the air,
>
> If you have a VCR, you can presumably just record a tapeful
> of -anything-
> today that has CC and read it back at your leisure. Just
> make sure to
> view the recording on a CC-capable TV so you know it all
> worked and
> that the program(s) were actually transmitting CC...
>
> If you don't have a VCR, I'm sure that I or any
> number of other people
> could mail you a random VHS tape someday if you were to
> borrow a VCR
> or pick one up at a yard sale or something.
>
> (Not that I'd like to -dis-incentivize anything that
> improves handling
> of CC data, since I depend on it for various
> machine-processing hacks
> and too many video-processing packages seem to drop it on
> the floor.
> So maybe you should forget any way of relaxing the
> deadline. :)
>

Well if the news hasn't reached you yet, the senate has pushed back the deadline once again for cutting analog broadcasts to June 12th. So no worries just yet.

Sam





_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: cx18: Working on sliced VBI: is this correct? [ In reply to ]
On Tuesday 27 January 2009 02:47:54 Andy Walls wrote:
> On Mon, 2009-01-26 at 11:48 +0100, Hans Verkuil wrote:
> > On Monday 26 January 2009 04:38:17 Andy Walls wrote:
> > > In working on Sliced VBI for the cx18 driver, I've pared down and
> > > commented the "struct vbi_info" definition. Did I understand
> > > everything that's going on based on the revised definition below?
> >
> > See comments below.
> >
> > > (BTW the mini MPEG-2 PS parser function borrowed from ivtv to look
> > > for splice points was very elegant given the task it had to perform -
> > > impressive.)
> >
> > Thanks! But it's still an ugly hack.
>
> OK. On the macro level, splicing in one's own packets is a hack. :)
>
> > Although the cx23415/6 is supposed
> > to be able to insert the sliced VBI data into the MPEG stream by
> > itself, it created a corrupt MPEG stream when I tried that at the time.
> > However, I've never tried it with the latest firmware, so it might be
> > fixed by now.
>
> Did you always use the 10 bit VIP-1.1 mode of the digitizer, or did you
> also try VIP-1.0, VIP-2.0, BT.656 and 8 bit mode as well?

I never changed the mode of the digitizer. That wasn't the problem, from
what I remember. It's a long time ago, but as I recall the firmware
actually did get the VBI data right, but the splicing in the MPEG stream
was wrong, so the stream was unplayable.

> I did some reading on the checksum that's in the ancillary data. In
> 10-bit mode, it's a 10 bit value computed with all 10 bits of the values
> summed. I noted I wouldn't be able to check it, because I don't have
> access to the two LSB's after the binary point for all the values in
> question. It could be that Encoder firmware couldn't check the CS value
> in the ancillary data either. Maybe 8-bit mode would help. Maybe
> precisely controlling the value of the Task bit in the RP codes as one
> can do in VIP-2.0 mode, would help.
>
> > The cx23418 has a similar feature and I would certainly attempt to test
> > that first. It makes life a lot easier if the firmware can handle it
> > properly.
>
> I believe MythTV already understands the ivtv way of doing VBI. Since,
> I'm runinng out of time before Feb 17 to test analog CC over the air, I
> figured I get the ivtv way working first, since the code is mostly set
> to do that anyway and MythTV will be a test/verification tool.

Do you already have the PVR-350? If so, then I can provide you with both
NTSC and PAL recordings containing CC and WSS/VPS data that you can use to
play on the PVR-350 and feedback to the cx18. Unfortunately, you cannot
test teletext that way since it isn't possible to output that on the
PVR-350. This is how I test CC here in PAL country.

Regards,

Hans

--
Hans Verkuil - video4linux developer - sponsored by TANDBERG

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel