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