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
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
