On Sat, 2009-04-18 at 02:10 -0400, faginbagin wrote:
> > It works, both sliced and raw. I've got to make improvements for
> > non-NTSC standards though.
>
> I've tried to figure out the difference between sliced & raw. I searched
> a while back, but never found a good explanation. I think I understand
> what sliced is. It's what MythTV uses. FWIW, I've written a little
> program that extracts the data and passes it off to libzvbi, used by xawtv.
Raw VBI means samples of the video signal voltage during the "active"
part of the lines during the vertical blanking interval. If you plot
these samples with voltage on the y-axis and time on the x-axis, you get
an oscilliscope type display.
Sliced VBI means that the digitizer hardware has "sliced" up the active
part of the line (in the vertical blanking interval) into various time
intervals and decoded the bits encoded onto the video signal. These
decoded bits are then stuffed into ancillary data byte packets in
horizontal blanking interval of the line in the vertical blanking
interval. This is the "sliced VBI data" that, after some manipulation
by the driver, can be passed to user space or stuffed into private
packets.
1. To "see" raw VBI data:
a. kill the mythbackend
b. ~/build/zvbi-0.2.30/test/osc -d /dev/vbi0 -2
(this will fail, but sets the driver to raw vbi mode)
c. mplayer /dev/video0 -cache 8192
d. ~/build/zvbi-0.2.30/test/osc -d /dev/vbi0 -2
(You have to start mplayer, because the CX23418 firmware won't send VBI
buffers without a video capture going on, unlike the CX23416. But once
a capture is started, you can't change the VBI mode.)
Use the up and down arrows to change the VBI line being displayed in the
lower part of the window, and the left and right arrow to move left and
right.
2. To decode CC from raw VBI data, for testing I use:
mplayer /dev/video0 -cache 8192
~/rpmbuild/BUILD/zvbi-0.2.30/contrib/zvbi-ntsc-cc --cc -d /dev/vbi0
And you'll see the user space software decoded CC from raw VBI data
samples. That assumes the driver is set for raw VBI data (the v4l2
default, but the mythbackend changes it to sliced).
3. To extract CC from sliced VBI data, for testing I use:
v4l2-ctl -d /dev/video0 --set-fmt-sliced-vbi=cc
to set the driver to sliced VBI mode, and then
mplayer /dev/video0 -cache 8192
~/rpmbuild/BUILD/zvbi-0.2.30/contrib/zvbi-ntsc-cc -S --cc -d /dev/vbi0
to see the decoded CC from the sliced VBI data.
I don't see a really easy way with v4l2-ctl to set the driver back to
raw VBI mode, but osc or zvbi-ntsc-cc without the -S switch can do that
for you, if the action is allowed by the at the time you execute the
command.
> > The interlock on insertion of private packets only in the PS is strictly
> > a cx18 driver software thing.
> >
> > I know the insertion will corrupt the MPEG TS and would likely not do
> > well with the MPEG-1 streams. So I put in an interlock to only let it
> > happen with the PS. If there are stream types where you know from
> > experience ivtv wouldn't corrupt the stream, let me know and I'll add it
> > back for cx18.
> >
> > Here's what I think about enabling private packet insertion without in
> > depth analysis of anything other than the PS and TS:
> >
> > OK 0: MPEG-2 Program Stream
> > No! 1: MPEG-2 Transport Stream
> > No? 2: MPEG-1 System Stream
> > ??? 3: MPEG-2 DVD-compatible Stream
> > No? 4: MPEG-1 VCD-compatible Stream
> > ??? 5: MPEG-2 SVCD-compatible Stream
>
> Well, I can confirm that the IVTV driver does add the VBI private
> packets to the DVD compatible stream and that MythTV will display the
> CCs. I haven't used the MPEG-1 stream types, so can't comment.
PLease try this patch. If you find it "works" and does not corrupt the
MPEG-2 DVD and MPEG-2 SVCD stream, then I'll apply it:
diff -r cda79523a93c linux/drivers/media/video/cx18/cx18-controls.c
--- a/linux/drivers/media/video/cx18/cx18-controls.c Thu Apr 16 18:30:38 2009 +0200
+++ b/linux/drivers/media/video/cx18/cx18-controls.c Sat Apr 18 23:12:07 2009 -0400
@@ -176,8 +176,10 @@
return -EBUSY;
if (fmt != V4L2_MPEG_STREAM_VBI_FMT_IVTV ||
- type != V4L2_MPEG_STREAM_TYPE_MPEG2_PS) {
- /* We don't do VBI insertion aside from IVTV format in a PS */
+ !(type == V4L2_MPEG_STREAM_TYPE_MPEG2_PS ||
+ type == V4L2_MPEG_STREAM_TYPE_MPEG2_DVD ||
+ type == V4L2_MPEG_STREAM_TYPE_MPEG2_SVCD)) {
+ /* We only do VBI insertion in IVTV format for MPEG2 && !TS */
cx->vbi.insert_mpeg = V4L2_MPEG_STREAM_VBI_FMT_NONE;
CX18_DEBUG_INFO("disabled insertion of sliced VBI data into "
"the MPEG stream\n");
diff -r cda79523a93c linux/drivers/media/video/cx18/cx18-fileops.c
--- a/linux/drivers/media/video/cx18/cx18-fileops.c Thu Apr 16 18:30:38 2009 +0200
+++ b/linux/drivers/media/video/cx18/cx18-fileops.c Sat Apr 18 23:12:07 2009 -0400
@@ -297,12 +297,16 @@
if (cx->vbi.insert_mpeg && s->type == CX18_ENC_STREAM_TYPE_MPG &&
!cx18_raw_vbi(cx) && buf != &cx->vbi.sliced_mpeg_buf) {
/*
- * Try to find a good splice point in the PS, just before
- * an MPEG-2 Program Pack start code, and provide only
+ * Try to find a good splice point in the MPEG-2 stream, just
+ * before an MPEG-2 Program Pack start code, and provide only
* up to that point to the user, so it's easy to insert VBI data
* the next time around.
+ *
+ * This will not work for an MPEG-2 TS and has only been
+ * verified by analysis to work for an MPEG-2 PS. A user
+ * reports it works for the MPEG-2 DVD compatible stream from
+ * a CX23416.
*/
- /* FIXME - This only works for an MPEG-2 PS, not a TS */
/*
* An MPEG-2 Program Stream (PS) is a series of
* MPEG-2 Program Packs terminated by an
> One way to decide might be how badly it might break applications like
> mplayer, xine, myth, dvdauthor or ccextractor.
Well, the real problem is that the "itv0" private packet insertion is
done in the cx18 driver software as is done in the ivtv driver. To do
really complex manipulations on the stream from the firmware in the
driver doesn't make too much sense. The criteria really needs to be
that the cx18 (or ivtv) driver doesn't corrupt the MPEG-2 stream.
I checked this by analysis for the MPEG-2 PS (OK) and the MPEG-2 TS (not
possible without much more work).
> Burning DVDs with CCs is a feature near and dear to my heart. I think
> the best solution would be if the Hauppauge hardware encoders embedded
> CCs in the video stream according to the EIA-608 standard.
Just for some background, even with "Sliced VBI" cx18 and ivtv really
only tell the digitizer to do VBI slicing and insert the anciallary data
packets. cx18 and ivtv then tell the CX2341x encoder to hand over "raw
VBI" samples, but we tell the encoder the "raw VBI" samples are sitting
where we know the ancillary data bytes holding the sliced VBI data from
the digitzer are at. (Confused yet?)
Anyway, the CX23416 encoder firmware is supposed to support stuffing
sliced data into (all?) MPEG stream types in some format. Not all VBI
data types are supported though. According to Hans, the CX23416 doesn't
work anyway (as far as he can tell). I have yet to test the CX23418
encoder firmware for handling sliced VBI - it may work.
> But they
> don't. I believe Panasonic DVD recording appliances do. If I play back a
> DVD burned by a Panasonic on another manufacturer's player, I will get
> CCs. So they both must implement a common standard like EIA-608.
> Panasonics also produce better video quality with better compression
> than the PVR-150. But they're appliances which are a lot less flexible
> than a computer.
OK, all rambling aside you are still free to do something like this in
user space:
1. Set-up the VBI type you'd like to capture.
2. Start capturing a stream (via /dev/videoN)
3. Start capturing the corresponding VBI stream (via /dev/vbiM)
4. Stitch them together anyway you like while capturing or as a post
post-process.
You can even have the driver embedding itv0 private stream packets while
capturing sliced VBI via /dev/vbiM - you won't lose any VBI data.
Regards,
Andy
> OK, I'm rambling, but maybe it will fuel more dialog on the topic?
>
> Helen
_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
> > It works, both sliced and raw. I've got to make improvements for
> > non-NTSC standards though.
>
> I've tried to figure out the difference between sliced & raw. I searched
> a while back, but never found a good explanation. I think I understand
> what sliced is. It's what MythTV uses. FWIW, I've written a little
> program that extracts the data and passes it off to libzvbi, used by xawtv.
Raw VBI means samples of the video signal voltage during the "active"
part of the lines during the vertical blanking interval. If you plot
these samples with voltage on the y-axis and time on the x-axis, you get
an oscilliscope type display.
Sliced VBI means that the digitizer hardware has "sliced" up the active
part of the line (in the vertical blanking interval) into various time
intervals and decoded the bits encoded onto the video signal. These
decoded bits are then stuffed into ancillary data byte packets in
horizontal blanking interval of the line in the vertical blanking
interval. This is the "sliced VBI data" that, after some manipulation
by the driver, can be passed to user space or stuffed into private
packets.
1. To "see" raw VBI data:
a. kill the mythbackend
b. ~/build/zvbi-0.2.30/test/osc -d /dev/vbi0 -2
(this will fail, but sets the driver to raw vbi mode)
c. mplayer /dev/video0 -cache 8192
d. ~/build/zvbi-0.2.30/test/osc -d /dev/vbi0 -2
(You have to start mplayer, because the CX23418 firmware won't send VBI
buffers without a video capture going on, unlike the CX23416. But once
a capture is started, you can't change the VBI mode.)
Use the up and down arrows to change the VBI line being displayed in the
lower part of the window, and the left and right arrow to move left and
right.
2. To decode CC from raw VBI data, for testing I use:
mplayer /dev/video0 -cache 8192
~/rpmbuild/BUILD/zvbi-0.2.30/contrib/zvbi-ntsc-cc --cc -d /dev/vbi0
And you'll see the user space software decoded CC from raw VBI data
samples. That assumes the driver is set for raw VBI data (the v4l2
default, but the mythbackend changes it to sliced).
3. To extract CC from sliced VBI data, for testing I use:
v4l2-ctl -d /dev/video0 --set-fmt-sliced-vbi=cc
to set the driver to sliced VBI mode, and then
mplayer /dev/video0 -cache 8192
~/rpmbuild/BUILD/zvbi-0.2.30/contrib/zvbi-ntsc-cc -S --cc -d /dev/vbi0
to see the decoded CC from the sliced VBI data.
I don't see a really easy way with v4l2-ctl to set the driver back to
raw VBI mode, but osc or zvbi-ntsc-cc without the -S switch can do that
for you, if the action is allowed by the at the time you execute the
command.
> > The interlock on insertion of private packets only in the PS is strictly
> > a cx18 driver software thing.
> >
> > I know the insertion will corrupt the MPEG TS and would likely not do
> > well with the MPEG-1 streams. So I put in an interlock to only let it
> > happen with the PS. If there are stream types where you know from
> > experience ivtv wouldn't corrupt the stream, let me know and I'll add it
> > back for cx18.
> >
> > Here's what I think about enabling private packet insertion without in
> > depth analysis of anything other than the PS and TS:
> >
> > OK 0: MPEG-2 Program Stream
> > No! 1: MPEG-2 Transport Stream
> > No? 2: MPEG-1 System Stream
> > ??? 3: MPEG-2 DVD-compatible Stream
> > No? 4: MPEG-1 VCD-compatible Stream
> > ??? 5: MPEG-2 SVCD-compatible Stream
>
> Well, I can confirm that the IVTV driver does add the VBI private
> packets to the DVD compatible stream and that MythTV will display the
> CCs. I haven't used the MPEG-1 stream types, so can't comment.
PLease try this patch. If you find it "works" and does not corrupt the
MPEG-2 DVD and MPEG-2 SVCD stream, then I'll apply it:
diff -r cda79523a93c linux/drivers/media/video/cx18/cx18-controls.c
--- a/linux/drivers/media/video/cx18/cx18-controls.c Thu Apr 16 18:30:38 2009 +0200
+++ b/linux/drivers/media/video/cx18/cx18-controls.c Sat Apr 18 23:12:07 2009 -0400
@@ -176,8 +176,10 @@
return -EBUSY;
if (fmt != V4L2_MPEG_STREAM_VBI_FMT_IVTV ||
- type != V4L2_MPEG_STREAM_TYPE_MPEG2_PS) {
- /* We don't do VBI insertion aside from IVTV format in a PS */
+ !(type == V4L2_MPEG_STREAM_TYPE_MPEG2_PS ||
+ type == V4L2_MPEG_STREAM_TYPE_MPEG2_DVD ||
+ type == V4L2_MPEG_STREAM_TYPE_MPEG2_SVCD)) {
+ /* We only do VBI insertion in IVTV format for MPEG2 && !TS */
cx->vbi.insert_mpeg = V4L2_MPEG_STREAM_VBI_FMT_NONE;
CX18_DEBUG_INFO("disabled insertion of sliced VBI data into "
"the MPEG stream\n");
diff -r cda79523a93c linux/drivers/media/video/cx18/cx18-fileops.c
--- a/linux/drivers/media/video/cx18/cx18-fileops.c Thu Apr 16 18:30:38 2009 +0200
+++ b/linux/drivers/media/video/cx18/cx18-fileops.c Sat Apr 18 23:12:07 2009 -0400
@@ -297,12 +297,16 @@
if (cx->vbi.insert_mpeg && s->type == CX18_ENC_STREAM_TYPE_MPG &&
!cx18_raw_vbi(cx) && buf != &cx->vbi.sliced_mpeg_buf) {
/*
- * Try to find a good splice point in the PS, just before
- * an MPEG-2 Program Pack start code, and provide only
+ * Try to find a good splice point in the MPEG-2 stream, just
+ * before an MPEG-2 Program Pack start code, and provide only
* up to that point to the user, so it's easy to insert VBI data
* the next time around.
+ *
+ * This will not work for an MPEG-2 TS and has only been
+ * verified by analysis to work for an MPEG-2 PS. A user
+ * reports it works for the MPEG-2 DVD compatible stream from
+ * a CX23416.
*/
- /* FIXME - This only works for an MPEG-2 PS, not a TS */
/*
* An MPEG-2 Program Stream (PS) is a series of
* MPEG-2 Program Packs terminated by an
> One way to decide might be how badly it might break applications like
> mplayer, xine, myth, dvdauthor or ccextractor.
Well, the real problem is that the "itv0" private packet insertion is
done in the cx18 driver software as is done in the ivtv driver. To do
really complex manipulations on the stream from the firmware in the
driver doesn't make too much sense. The criteria really needs to be
that the cx18 (or ivtv) driver doesn't corrupt the MPEG-2 stream.
I checked this by analysis for the MPEG-2 PS (OK) and the MPEG-2 TS (not
possible without much more work).
> Burning DVDs with CCs is a feature near and dear to my heart. I think
> the best solution would be if the Hauppauge hardware encoders embedded
> CCs in the video stream according to the EIA-608 standard.
Just for some background, even with "Sliced VBI" cx18 and ivtv really
only tell the digitizer to do VBI slicing and insert the anciallary data
packets. cx18 and ivtv then tell the CX2341x encoder to hand over "raw
VBI" samples, but we tell the encoder the "raw VBI" samples are sitting
where we know the ancillary data bytes holding the sliced VBI data from
the digitzer are at. (Confused yet?)
Anyway, the CX23416 encoder firmware is supposed to support stuffing
sliced data into (all?) MPEG stream types in some format. Not all VBI
data types are supported though. According to Hans, the CX23416 doesn't
work anyway (as far as he can tell). I have yet to test the CX23418
encoder firmware for handling sliced VBI - it may work.
> But they
> don't. I believe Panasonic DVD recording appliances do. If I play back a
> DVD burned by a Panasonic on another manufacturer's player, I will get
> CCs. So they both must implement a common standard like EIA-608.
> Panasonics also produce better video quality with better compression
> than the PVR-150. But they're appliances which are a lot less flexible
> than a computer.
OK, all rambling aside you are still free to do something like this in
user space:
1. Set-up the VBI type you'd like to capture.
2. Start capturing a stream (via /dev/videoN)
3. Start capturing the corresponding VBI stream (via /dev/vbiM)
4. Stitch them together anyway you like while capturing or as a post
post-process.
You can even have the driver embedding itv0 private stream packets while
capturing sliced VBI via /dev/vbiM - you won't lose any VBI data.
Regards,
Andy
> OK, I'm rambling, but maybe it will fuel more dialog on the topic?
>
> Helen
_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users