Mailing List Archive

On Saturday 07 March 2009 02:31:41 Andy Walls wrote:
> On Fri, 2009-03-06 at 15:41 +0100, Hans Verkuil wrote:
> > On Friday 06 March 2009 04:39:34 Andy Walls wrote:
> > > Yes, they should be exported to userspace as well, so apps like
> > > MythTV don't have to keep their own copies as well. I'm going to
> > > work on a V4L2 spec change to add structures and defines for the
> > > packets indicated by V4L2_MPEG_STREAM_VBI_FMT_IVTV, and then add it
> > > to some API header. Maybe in linux/include/linux/videodev2.h with all
> > > the other VBI data formats.
> > >
> > > Unless someone really disagrees.
> >
> > These VBI defines should be moved to videodev2.h. In hindsight this
> > should never have been added to ivtv.h. Originally only ivtv used this,
> > but now cx18 does as well, and in theory any MPEG encoder device can
> > use it.
>
> Hans, Mauro, and whoever:
>
> Before I get too far down the road of writing the spec modifications and
> perhaps modifying drivers, in the diff below:
>
> 1. Are the modifications to the headers acceptable?
>
> 2. Are they correct? (I *think* they are.)

Acked-by: Hans Verkuil <hverkuil@xs4all.nl>

Very nice. I was also toying with the idea to rename 'IVTV' in these defines
to something different, but that makes too much of a mess. I think it is
sufficient to add a sentence to the spec along the lines of:

"This format was first introduced in the ivtv driver, hence the use of IVTV
in these defines. It is however not limited to the ivtv driver, any MPEG
encoder can use it."

And I think that it also doesn't hurt if some of my explanations from my
earlier email are added to the spec as well. The format looks really weird
if you do not understand the PVR350 (cx23415) limitation.

Regards,

Hans

>
> Regards,
> Andy
>
>
> diff -r 5361470b10f4 linux/include/linux/ivtv.h
> --- a/linux/include/linux/ivtv.h Sun Mar 01 21:10:07 2009 -0500
> +++ b/linux/include/linux/ivtv.h Fri Mar 06 20:27:20 2009 -0500
> @@ -60,10 +60,10 @@
>
> #define IVTV_IOC_DMA_FRAME _IOW ('V', BASE_VIDIOC_PRIVATE+0, struct
> ivtv_dma_frame)
>
> -/* These are the VBI types as they appear in the embedded VBI private
> packets. */ -#define IVTV_SLICED_TYPE_TELETEXT_B (1)
> -#define IVTV_SLICED_TYPE_CAPTION_525 (4)
> -#define IVTV_SLICED_TYPE_WSS_625 (5)
> -#define IVTV_SLICED_TYPE_VPS (7)
> +/* Deprecated defines: applications should use the defines from
> videodev2.h */ +#define IVTV_SLICED_TYPE_TELETEXT_B
> V4L2_MPEG_VBI_IVTV_TELETEXT_B +#define IVTV_SLICED_TYPE_CAPTION_525
> V4L2_MPEG_VBI_IVTV_CAPTION_525 +#define IVTV_SLICED_TYPE_WSS_625
> V4L2_MPEG_VBI_IVTV_WSS_625 +#define IVTV_SLICED_TYPE_VPS
> V4L2_MPEG_VBI_IVTV_VPS
>
> #endif /* _LINUX_IVTV_H */
> diff -r 5361470b10f4 linux/include/linux/videodev2.h
> --- a/linux/include/linux/videodev2.h Sun Mar 01 21:10:07 2009 -0500
> +++ b/linux/include/linux/videodev2.h Fri Mar 06 20:27:20 2009 -0500
> @@ -1348,6 +1348,53 @@
> };
>
> /*
> + * Sliced VBI data inserted into MPEG Streams
> + */
> +
> +/*
> + * V4L2_MPEG_STREAM_VBI_FMT_IVTV:
> + *
> + * Structure of payload contained in an MPEG 2 Private Stream 1 PES
> Packet in an + * MPEG-2 Program Pack that contains
> V4L2_MPEG_STREAM_VBI_FMT_IVTV Sliced VBI + * data
> + *
> + * Note, the MPEG-2 Program Pack and Private Stream 1 PES packet header
> + * definitions are not included here. See the MPEG-2 specifications for
> details + * on these headers.
> + */
> +
> +/* Line type IDs */
> +#define V4L2_MPEG_VBI_IVTV_TELETEXT_B (1)
> +#define V4L2_MPEG_VBI_IVTV_CAPTION_525 (4)
> +#define V4L2_MPEG_VBI_IVTV_WSS_625 (5)
> +#define V4L2_MPEG_VBI_IVTV_VPS (7)
> +
> +struct v4l2_mpeg_vbi_itv0_line {
> + __u8 id; /* One of V4L2_MPEG_VBI_IVTV_* above */
> + __u8 data[42]; /* Sliced VBI data for the line */
> +} __attribute__ ((packed));
> +
> +struct v4l2_mpeg_vbi_itv0 {
> + __u32 linemask[2]; /* Bitmasks of which VBI service lines are present
> */ + struct v4l2_mpeg_vbi_itv0_line line[35];
> +} __attribute__ ((packed));
> +
> +struct v4l2_mpeg_vbi_ITV0 {
> + struct v4l2_mpeg_vbi_itv0_line line[36];
> +} __attribute__ ((packed));
> +
> +#define V4L2_MPEG_VBI_IVTV_MAGIC0 "itv0"
> +#define V4L2_MPEG_VBI_IVTV_MAGIC1 "ITV0"
> +
> +struct v4l2_mpeg_vbi_fmt_ivtv {
> + __u8 magic[4];
> + union {
> + struct v4l2_mpeg_vbi_itv0 itv0;
> + struct v4l2_mpeg_vbi_ITV0 ITV0;
> + };
> +} __attribute__ ((packed));
> +
> +/*
> * A G G R E G A T E S T R U C T U R E S
> */
>
>
>
>
>
>
> --
> 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



--
Hans Verkuil - video4linux developer - sponsored by TANDBERG

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

On Sat, 7 Mar 2009 09:49:30 +0100
Hans Verkuil <hverkuil@xs4all.nl> wrote:

> On Saturday 07 March 2009 02:31:41 Andy Walls wrote:
> > On Fri, 2009-03-06 at 15:41 +0100, Hans Verkuil wrote:
> > > On Friday 06 March 2009 04:39:34 Andy Walls wrote:
> > > > Yes, they should be exported to userspace as well, so apps like
> > > > MythTV don't have to keep their own copies as well. I'm going to
> > > > work on a V4L2 spec change to add structures and defines for the
> > > > packets indicated by V4L2_MPEG_STREAM_VBI_FMT_IVTV, and then add it
> > > > to some API header. Maybe in linux/include/linux/videodev2.h with all
> > > > the other VBI data formats.
> > > >
> > > > Unless someone really disagrees.
> > >
> > > These VBI defines should be moved to videodev2.h. In hindsight this
> > > should never have been added to ivtv.h. Originally only ivtv used this,
> > > but now cx18 does as well, and in theory any MPEG encoder device can
> > > use it.
> >
> > Hans, Mauro, and whoever:
> >
> > Before I get too far down the road of writing the spec modifications and
> > perhaps modifying drivers, in the diff below:
> >
> > 1. Are the modifications to the headers acceptable?
> >
> > 2. Are they correct? (I *think* they are.)
>
> Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
>
> Very nice. I was also toying with the idea to rename 'IVTV' in these defines
> to something different, but that makes too much of a mess. I think it is
> sufficient to add a sentence to the spec along the lines of:
>
> "This format was first introduced in the ivtv driver, hence the use of IVTV
> in these defines. It is however not limited to the ivtv driver, any MPEG
> encoder can use it."
>
> And I think that it also doesn't hurt if some of my explanations from my
> earlier email are added to the spec as well. The format looks really weird
> if you do not understand the PVR350 (cx23415) limitation.

IMO, it is better to remove the IVTV from the name or to replace to something
else, since it is meant to be used by other drivers.

> +#define V4L2_MPEG_VBI_IVTV_MAGIC0 "itv0"
> +#define V4L2_MPEG_VBI_IVTV_MAGIC1 "ITV0"

Hmm... maybe we could just name it as format ITV0, as marked at the magic
values above. What do you think?


Cheers,
Mauro

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

On Monday 09 March 2009 05:30:54 Mauro Carvalho Chehab wrote:
> On Sat, 7 Mar 2009 09:49:30 +0100
>
> Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > On Saturday 07 March 2009 02:31:41 Andy Walls wrote:
> > > On Fri, 2009-03-06 at 15:41 +0100, Hans Verkuil wrote:
> > > > On Friday 06 March 2009 04:39:34 Andy Walls wrote:
> > > > > Yes, they should be exported to userspace as well, so apps like
> > > > > MythTV don't have to keep their own copies as well. I'm going to
> > > > > work on a V4L2 spec change to add structures and defines for the
> > > > > packets indicated by V4L2_MPEG_STREAM_VBI_FMT_IVTV, and then add
> > > > > it to some API header. Maybe in linux/include/linux/videodev2.h
> > > > > with all the other VBI data formats.
> > > > >
> > > > > Unless someone really disagrees.
> > > >
> > > > These VBI defines should be moved to videodev2.h. In hindsight this
> > > > should never have been added to ivtv.h. Originally only ivtv used
> > > > this, but now cx18 does as well, and in theory any MPEG encoder
> > > > device can use it.
> > >
> > > Hans, Mauro, and whoever:
> > >
> > > Before I get too far down the road of writing the spec modifications
> > > and perhaps modifying drivers, in the diff below:
> > >
> > > 1. Are the modifications to the headers acceptable?
> > >
> > > 2. Are they correct? (I *think* they are.)
> >
> > Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
> >
> > Very nice. I was also toying with the idea to rename 'IVTV' in these
> > defines to something different, but that makes too much of a mess. I
> > think it is sufficient to add a sentence to the spec along the lines
> > of:
> >
> > "This format was first introduced in the ivtv driver, hence the use of
> > IVTV in these defines. It is however not limited to the ivtv driver,
> > any MPEG encoder can use it."
> >
> > And I think that it also doesn't hurt if some of my explanations from
> > my earlier email are added to the spec as well. The format looks really
> > weird if you do not understand the PVR350 (cx23415) limitation.
>
> IMO, it is better to remove the IVTV from the name or to replace to
> something else, since it is meant to be used by other drivers.
>
> > +#define V4L2_MPEG_VBI_IVTV_MAGIC0 "itv0"
> > +#define V4L2_MPEG_VBI_IVTV_MAGIC1 "ITV0"
>
> Hmm... maybe we could just name it as format ITV0, as marked at the magic
> values above. What do you think?

I don't really see much of an improvement here. I think it is better to put
a note in the spec (and perhaps in videodev2.h) that while it originated
with ivtv it is not specific to that driver.

But I do not have a really strong opinion here.

Regards,

Hans

--
Hans Verkuil - video4linux developer - sponsored by TANDBERG

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

On Mon, 2009-03-09 at 08:25 +0100, Hans Verkuil wrote:
> On Monday 09 March 2009 05:30:54 Mauro Carvalho Chehab wrote:
> > On Sat, 7 Mar 2009 09:49:30 +0100
> >
> > Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > On Saturday 07 March 2009 02:31:41 Andy Walls wrote:
> > > > On Fri, 2009-03-06 at 15:41 +0100, Hans Verkuil wrote:
> > > > > On Friday 06 March 2009 04:39:34 Andy Walls wrote:
> > > > > > Yes, they should be exported to userspace as well, so apps like
> > > > > > MythTV don't have to keep their own copies as well. I'm going to
> > > > > > work on a V4L2 spec change to add structures and defines for the
> > > > > > packets indicated by V4L2_MPEG_STREAM_VBI_FMT_IVTV, and then add
> > > > > > it to some API header. Maybe in linux/include/linux/videodev2.h
> > > > > > with all the other VBI data formats.
> > > > > >
> > > > > > Unless someone really disagrees.
> > > > >
> > > > > These VBI defines should be moved to videodev2.h. In hindsight this
> > > > > should never have been added to ivtv.h. Originally only ivtv used
> > > > > this, but now cx18 does as well, and in theory any MPEG encoder
> > > > > device can use it.
> > > >
> > > > Hans, Mauro, and whoever:
> > > >
> > > > Before I get too far down the road of writing the spec modifications
> > > > and perhaps modifying drivers, in the diff below:
> > > >
> > > > 1. Are the modifications to the headers acceptable?
> > > >
> > > > 2. Are they correct? (I *think* they are.)
> > >
> > > Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
> > >
> > > Very nice. I was also toying with the idea to rename 'IVTV' in these
> > > defines to something different, but that makes too much of a mess. I
> > > think it is sufficient to add a sentence to the spec along the lines
> > > of:
> > >
> > > "This format was first introduced in the ivtv driver, hence the use of
> > > IVTV in these defines. It is however not limited to the ivtv driver,
> > > any MPEG encoder can use it."
> > >
> > > And I think that it also doesn't hurt if some of my explanations from
> > > my earlier email are added to the spec as well. The format looks really
> > > weird if you do not understand the PVR350 (cx23415) limitation.
> >
> > IMO, it is better to remove the IVTV from the name or to replace to
> > something else, since it is meant to be used by other drivers.
> >
> > > +#define V4L2_MPEG_VBI_IVTV_MAGIC0 "itv0"
> > > +#define V4L2_MPEG_VBI_IVTV_MAGIC1 "ITV0"
> >
> > Hmm... maybe we could just name it as format ITV0, as marked at the magic
> > values above. What do you think?
>
> I don't really see much of an improvement here. I think it is better to put
> a note in the spec (and perhaps in videodev2.h) that while it originated
> with ivtv it is not specific to that driver.
>
> But I do not have a really strong opinion here.

I don't have a terribly strong opinion either. I'm almost done the spec
changes (see the diff inline below), but I can easily change things.

I don't particularly want to purge IVTV from the
V4L2_CID_MPEG_STREAM_VBI_FMT MPEG control enumeration:

enum v4l2_mpeg_stream_vbi_fmt {
[...]
V4L2_MPEG_STREAM_VBI_FMT_IVTV = 1,
};

as that would be a specification change vs. an addition. Also adding a
new ...FMT_ITV0 symbol to the enumeration, that overlaps with a value of
1, creates problems for the controls code. IMO, IVTV is there to stay in
that enumeration.


I can change every other IVTV reference to ITV0 in a sensible way (I
think). Let me know, if you really want this. I won't be finishing it
and posting it for final draft review for a day or two.

Regards,
Andy





diff -r 5361470b10f4 linux/include/linux/ivtv.h
--- a/linux/include/linux/ivtv.h Sun Mar 01 21:10:07 2009 -0500
+++ b/linux/include/linux/ivtv.h Mon Mar 09 16:42:40 2009 -0400
@@ -60,10 +60,10 @@

#define IVTV_IOC_DMA_FRAME _IOW ('V', BASE_VIDIOC_PRIVATE+0, struct ivtv_dma_frame)

-/* These are the VBI types as they appear in the embedded VBI private packets. */
-#define IVTV_SLICED_TYPE_TELETEXT_B (1)
-#define IVTV_SLICED_TYPE_CAPTION_525 (4)
-#define IVTV_SLICED_TYPE_WSS_625 (5)
-#define IVTV_SLICED_TYPE_VPS (7)
+/* Deprecated defines: applications should use the defines from videodev2.h */
+#define IVTV_SLICED_TYPE_TELETEXT_B V4L2_MPEG_VBI_IVTV_TELETEXT_B
+#define IVTV_SLICED_TYPE_CAPTION_525 V4L2_MPEG_VBI_IVTV_CAPTION_525
+#define IVTV_SLICED_TYPE_WSS_625 V4L2_MPEG_VBI_IVTV_WSS_625
+#define IVTV_SLICED_TYPE_VPS V4L2_MPEG_VBI_IVTV_VPS

#endif /* _LINUX_IVTV_H */
diff -r 5361470b10f4 linux/include/linux/videodev2.h
--- a/linux/include/linux/videodev2.h Sun Mar 01 21:10:07 2009 -0500
+++ b/linux/include/linux/videodev2.h Mon Mar 09 16:42:40 2009 -0400
@@ -1348,6 +1348,53 @@
};

/*
+ * Sliced VBI data inserted into MPEG Streams
+ */
+
+/*
+ * V4L2_MPEG_STREAM_VBI_FMT_IVTV:
+ *
+ * Structure of payload contained in an MPEG 2 Private Stream 1 PES Packet in an
+ * MPEG-2 Program Pack that contains V4L2_MPEG_STREAM_VBI_FMT_IVTV Sliced VBI
+ * data
+ *
+ * Note, the MPEG-2 Program Pack and Private Stream 1 PES packet header
+ * definitions are not included here. See the MPEG-2 specifications for details
+ * on these headers.
+ */
+
+/* Line type IDs */
+#define V4L2_MPEG_VBI_IVTV_TELETEXT_B (1)
+#define V4L2_MPEG_VBI_IVTV_CAPTION_525 (4)
+#define V4L2_MPEG_VBI_IVTV_WSS_625 (5)
+#define V4L2_MPEG_VBI_IVTV_VPS (7)
+
+struct v4l2_mpeg_vbi_itv0_line {
+ __u8 id; /* One of V4L2_MPEG_VBI_IVTV_* above */
+ __u8 data[42]; /* Sliced VBI data for the line */
+} __attribute__ ((packed));
+
+struct v4l2_mpeg_vbi_itv0 {
+ __u32 linemask[2]; /* Bitmasks of which VBI service lines are present */
+ struct v4l2_mpeg_vbi_itv0_line line[35];
+} __attribute__ ((packed));
+
+struct v4l2_mpeg_vbi_ITV0 {
+ struct v4l2_mpeg_vbi_itv0_line line[36];
+} __attribute__ ((packed));
+
+#define V4L2_MPEG_VBI_IVTV_MAGIC0 "itv0"
+#define V4L2_MPEG_VBI_IVTV_MAGIC1 "ITV0"
+
+struct v4l2_mpeg_vbi_fmt_ivtv {
+ __u8 magic[4];
+ union {
+ struct v4l2_mpeg_vbi_itv0 itv0;
+ struct v4l2_mpeg_vbi_ITV0 ITV0;
+ };
+} __attribute__ ((packed));
+
+/*
* A G G R E G A T E S T R U C T U R E S
*/

diff -r 5361470b10f4 v4l2-spec/Makefile
--- a/v4l2-spec/Makefile Sun Mar 01 21:10:07 2009 -0500
+++ b/v4l2-spec/Makefile Mon Mar 09 16:42:40 2009 -0400
@@ -274,6 +274,7 @@
v4l2_input \
v4l2_jpegcompression \
v4l2_modulator \
+ v4l2_mpeg_vbi_fmt_ivtv \
v4l2_output \
v4l2_outputparm \
v4l2_pix_format \
diff -r 5361470b10f4 v4l2-spec/dev-sliced-vbi.sgml
--- a/v4l2-spec/dev-sliced-vbi.sgml Sun Mar 01 21:10:07 2009 -0500
+++ b/v4l2-spec/dev-sliced-vbi.sgml Mon Mar 09 16:42:40 2009 -0400
@@ -48,7 +48,7 @@
supported.</para>
</section>

- <section>
+ <section id="sliced-vbi-format-negotitation">
<title>Sliced VBI Format Negotiation</title>

<para>To find out which data services are supported by the
@@ -386,6 +386,278 @@

</section>

+ <section>
+ <title>Sliced VBI Data in MPEG Streams</title>
+
+ <para>If a device can produce an MPEG output stream, it may be
+capable of providing <link
+linkend="sliced-vbi-format-negotitation">negotiated sliced VBI
+services</link> as data embedded in the MPEG stream. Users or
+applications control this sliced VBI data insertion with the <link
+linkend="v4l2-mpeg-stream-vbi-fmt">V4L2_CID_MPEG_STREAM_VBI_FMT</link>
+control.</para>
+
+ <para>If the driver does not provide the <link
+linkend="v4l2-mpeg-stream-vbi-fmt">V4L2_CID_MPEG_STREAM_VBI_FMT</link>
+control, or only allows that control to be set to <link
+linkend="v4l2-mpeg-stream-vbi-fmt"><constant>
+V4L2_MPEG_STREAM_VBI_FMT_NONE</constant></link>, then the device
+cannot embed sliced VBI data in the MPEG stream.</para>
+
+ <para>The <link linkend="v4l2-mpeg-stream-vbi-fmt">
+V4L2_CID_MPEG_STREAM_VBI_FMT</link> control does not implicitly set
+the device driver to capture nor cease capturing sliced VBI data. The
+control only indicates to embed sliced VBI data in the MPEG stream, if
+an application has negotiated sliced VBI service be captured.</para>
+
+ <para>It may also be the case that a device can embed sliced VBI
+data in only certain types of MPEG streams: for example in an MPEG-2
+PS but not an MPEG-2 TS. In this situation, if sliced VBI data
+insertion is requested, the sliced VBI data will be embedded in MPEG
+stream types when supported, and silently omitted from MPEG stream
+types where sliced VBI data insertion is not supported by the device.
+</para>
+
+ <para>The following subsections specify the format of the
+embedded sliced VBI data.</para>
+
+ <section>
+ <title>MPEG Stream Embedded, Sliced VBI Data Format: NONE</title>
+ <para>The <link linkend="v4l2-mpeg-stream-vbi-fmt"><constant>
+V4L2_MPEG_STREAM_VBI_FMT_NONE</constant></link> embedded sliced VBI
+format shall be interpreted by drivers as a control to cease
+embedding sliced VBI data in MPEG streams. Neither the device nor
+driver shall insert "empty" embedded sliced VBI data packets in the
+MPEG stream when this format is set. No MPEG stream data structures
+are specified for this format.</para>
+ </section>
+
+ <section>
+ <title>MPEG Stream Embedded, Sliced VBI Data Format: IVTV</title>
+ <para>The <link linkend="v4l2-mpeg-stream-vbi-fmt"><constant>
+V4L2_MPEG_STREAM_VBI_FMT_IVTV</constant></link> embedded sliced VBI
+format, when supported, indicates to the driver to embed up to 36
+lines of sliced VBI data per frame in an MPEG-2 <emphasis>Private
+Stream 1 PES</emphasis> packet encapsulated in an MPEG-2 <emphasis>
+Program Pack</emphasis> in the MPEG stream.</para>
+
+ <para><emphasis>Historical context</emphasis>: This format
+specification originates from a custom, embedded, sliced VBI data
+format used by the <filename>ivtv</filename> driver. This format
+has already been informally specified in the kernel sources in the
+file <filename>Documentation/video4linux/cx2341x/README.vbi</filename>
+. The maximum size of the payload and other aspects of this format
+are driven by the CX23415 MPEG decoder's capabilities and limitations
+with respect to extracting, decoding, and displaying sliced VBI data
+embedded within an MPEG stream.</para>
+
+ <para>This format's use is <emphasis>not</emphasis> exclusive to
+the <filename>ivtv</filename> driver <emphasis>nor</emphasis>
+exclusive to CX2341x devices, as the sliced VBI data packet insertion
+into the MPEG stream is implemented in driver software. At least the
+<filename>cx18</filename> driver provides sliced VBI data insertion
+into an MPEG-2 PS in this format as well.</para>
+
+ <para>The following definitions specify the payload of the
+MPEG-2 <emphasis>Private Stream 1 PES</emphasis> packets that contain
+sliced VBI data when <link linkend="v4l2-mpeg-stream-vbi-fmt">
+<constant>V4L2_MPEG_STREAM_VBI_FMT_IVTV</constant></link> is set.
+(The MPEG-2 <emphasis>Private Stream 1 PES</emphasis> packet header
+and encapsulating MPEG-2 <emphasis>Program Pack</emphasis> header are
+not detailed here. Please refer to the MPEG-2 specifications for
+details on those packet headers.)</para>
+
+ <para>The payload of the MPEG-2 <emphasis>Private Stream 1 PES
+</emphasis> packets that contain sliced VBI data is specified by
+&v4l2-mpeg-vbi-fmt-ivtv;. The payload is variable
+length, depending on the actual number of lines of sliced VBI data
+present in a video frame. The payload may be padded at the end with
+unspecified fill bytes to align the end of the payload to a 4-byte
+boundary. The payload shall never exceed 1552 bytes (2 fields with
+18 lines/field with 43 bytes of data/line and a 4 byte magic number).
+</para>
+
+ <table frame="none" pgwide="1" id="v4l2-mpeg-vbi-fmt-ivtv">
+ <title>struct <structname>v4l2_mpeg_vbi_fmt_ivtv</structname></title>
+ <tgroup cols="4">
+ &cs-ustr;
+ <tbody valign="top">
+ <row>
+ <entry>__u8</entry>
+ <entry><structfield>magic</structfield>[4]</entry>
+ <entry></entry>
+ <entry>A "magic" constant from <xref
+ linkend="v4l2-mpeg-vbi-fmt-ivtv-magic"> that indicates
+this is a valid sliced VBI data payload and also indicates which
+member of the anonymous union, <structfield>itv0</structfield> or
+<structfield>ITV0</structfield>, to use for the payload data.</entry>
+ </row>
+ <row>
+ <entry>union</entry>
+ <entry>(anonymous)</entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry>struct <link linkend="v4l2-mpeg-vbi-itv0">
+ <structname>v4l2_mpeg_vbi_itv0</structname></link>
+ </entry>
+ <entry><structfield>itv0</structfield></entry>
+ <entry>comment</entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry>struct <link linkend="v4l2-mpeg-vbi-ITV0-1">
+ <structname>v4l2_mpeg_vbi_ITV0</structname></link>
+ </entry>
+ <entry><structfield>ITV0</structfield></entry>
+ <entry>comment</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <table frame="none" pgwide="1" id="v4l2-mpeg-vbi-fmt-ivtv-magic">
+ <title>Magic Constants for &v4l2-mpeg-vbi-fmt-ivtv;
+ <structfield>magic</structfield> field</title>
+ <tgroup cols="3">
+ &cs-def;
+ <thead>
+ <row>
+ <entry align="left">Defined Symbol</entry>
+ <entry align="left">Value</entry>
+ <entry align="left">Description</entry>
+ </row>
+ </thead>
+ <tbody valign="top">
+ <row>
+ <entry><constant>V4L2_MPEG_VBI_IVTV_MAGIC0</constant>
+ </entry>
+ <entry>"itv0"</entry>
+ <entry>Indicates the <structfield>itv0</structfield>
+ member of the union in &v4l2-mpeg-vbi-fmt-ivtv; is valid. Line
+masks are provided in this form of the payload indicating which VBI
+lines are provided.</entry>
+ </row>
+ <row>
+ <entry><constant>V4L2_MPEG_VBI_IVTV_MAGIC1</constant>
+ </entry>
+ <entry>"ITV0"</entry>
+ <entry>Indicates the <structfield>ITV0</structfield>
+member of the union in &v4l2-mpeg-vbi-fmt-ivtv; is valid and
+that 36 VBI lines are provided. No line masks are provided in this
+form of the payload; all valid line mask bits are implcitly set.
+</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <table frame="none" pgwide="1" id="v4l2-mpeg-vbi-itv0">
+ <title>struct <structname>v4l2_mpeg_vbi_itv0</structname>
+ </title>
+ <tgroup cols="3">
+ &cs-str;
+ <tbody valign="top">
+ <row>
+ <entry>__u32</entry>
+ <entry><structfield>linemask</structfield>[2]</entry>
+ <entry>comment</entry>
+ </row>
+ <row>
+ <entry>struct <link linkend="v4l2-mpeg-vbi-itv0-line">
+ <structname>v4l2_mpeg_vbi_itv0_line</structname></link>
+ </entry>
+ <entry><structfield>line</structfield>[35]</entry>
+ <entry>comment: up to 35 lines</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <table frame="none" pgwide="1" id="v4l2-mpeg-vbi-ITV0-1">
+ <title>struct <structname>v4l2_mpeg_vbi_ITV0</structname>
+ </title>
+ <tgroup cols="3">
+ &cs-str;
+ <tbody valign="top">
+ <row>
+ <entry>struct <link linkend="v4l2-mpeg-vbi-itv0-line">
+ <structname>v4l2_mpeg_vbi_itv0_line</structname></link>
+ </entry>
+ <entry><structfield>line</structfield>[36]</entry>
+ <entry>comment: all 36 lines</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <table frame="none" pgwide="1" id="v4l2-mpeg-vbi-itv0-line">
+ <title>struct <structname>v4l2_mpeg_vbi_itv0_line</structname>
+ </title>
+ <tgroup cols="3">
+ &cs-str;
+ <tbody valign="top">
+ <row>
+ <entry>__u8</entry>
+ <entry><structfield>id</structfield></entry>
+ <entry>comment</entry>
+ </row>
+ <row>
+ <entry>__u8</entry>
+ <entry><structfield>data</structfield>[42]</entry>
+ <entry>comment</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <table frame="none" pgwide="1" id="ITV0-Line-Identifier-Constants">
+ <title>Line Identifiers for struct <link
+ linkend="v4l2-mpeg-vbi-itv0-line"><structname>
+v4l2_mpeg_vbi_itv0_line</structname></link> <structfield>id
+</structfield> field</title>
+ <tgroup cols="3">
+ &cs-def;
+ <thead>
+ <row>
+ <entry align="left">Defined Symbol</entry>
+ <entry align="left">Value</entry>
+ <entry align="left">Description</entry>
+ </row>
+ </thead>
+ <tbody valign="top">
+ <row>
+ <entry><constant>V4L2_MPEG_VBI_IVTV_TELETEXT_B</constant>
+ </entry>
+ <entry>1</entry>
+ <entry></entry>
+ </row>
+ <row>
+ <entry><constant>V4L2_MPEG_VBI_IVTV_CAPTION_525</constant>
+ </entry>
+ <entry>4</entry>
+ <entry></entry>
+ </row>
+ <row>
+ <entry><constant>V4L2_MPEG_VBI_IVTV_WSS_625</constant>
+ </entry>
+ <entry>5</entry>
+ <entry></entry>
+ </row>
+ <row>
+ <entry><constant>V4L2_MPEG_VBI_IVTV_VPS</constant>
+ </entry>
+ <entry>7</entry>
+ <entry></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </section>
+ </section>
+
+
<!--
Local Variables:
mode: sgml



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

On Monday 09 March 2009 21:47:55 Andy Walls wrote:
> On Mon, 2009-03-09 at 08:25 +0100, Hans Verkuil wrote:
> > On Monday 09 March 2009 05:30:54 Mauro Carvalho Chehab wrote:
> > > On Sat, 7 Mar 2009 09:49:30 +0100
> > >
> > > Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > > On Saturday 07 March 2009 02:31:41 Andy Walls wrote:
> > > > > On Fri, 2009-03-06 at 15:41 +0100, Hans Verkuil wrote:
> > > > > > On Friday 06 March 2009 04:39:34 Andy Walls wrote:
> > > > > > > Yes, they should be exported to userspace as well, so apps
> > > > > > > like MythTV don't have to keep their own copies as well. I'm
> > > > > > > going to work on a V4L2 spec change to add structures and
> > > > > > > defines for the packets indicated by
> > > > > > > V4L2_MPEG_STREAM_VBI_FMT_IVTV, and then add it to some API
> > > > > > > header. Maybe in linux/include/linux/videodev2.h with all the
> > > > > > > other VBI data formats.
> > > > > > >
> > > > > > > Unless someone really disagrees.
> > > > > >
> > > > > > These VBI defines should be moved to videodev2.h. In hindsight
> > > > > > this should never have been added to ivtv.h. Originally only
> > > > > > ivtv used this, but now cx18 does as well, and in theory any
> > > > > > MPEG encoder device can use it.
> > > > >
> > > > > Hans, Mauro, and whoever:
> > > > >
> > > > > Before I get too far down the road of writing the spec
> > > > > modifications and perhaps modifying drivers, in the diff below:
> > > > >
> > > > > 1. Are the modifications to the headers acceptable?
> > > > >
> > > > > 2. Are they correct? (I *think* they are.)
> > > >
> > > > Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
> > > >
> > > > Very nice. I was also toying with the idea to rename 'IVTV' in
> > > > these defines to something different, but that makes too much of a
> > > > mess. I think it is sufficient to add a sentence to the spec along
> > > > the lines of:
> > > >
> > > > "This format was first introduced in the ivtv driver, hence the use
> > > > of IVTV in these defines. It is however not limited to the ivtv
> > > > driver, any MPEG encoder can use it."
> > > >
> > > > And I think that it also doesn't hurt if some of my explanations
> > > > from my earlier email are added to the spec as well. The format
> > > > looks really weird if you do not understand the PVR350 (cx23415)
> > > > limitation.
> > >
> > > IMO, it is better to remove the IVTV from the name or to replace to
> > > something else, since it is meant to be used by other drivers.
> > >
> > > > +#define V4L2_MPEG_VBI_IVTV_MAGIC0 "itv0"
> > > > +#define V4L2_MPEG_VBI_IVTV_MAGIC1 "ITV0"
> > >
> > > Hmm... maybe we could just name it as format ITV0, as marked at the
> > > magic values above. What do you think?
> >
> > I don't really see much of an improvement here. I think it is better to
> > put a note in the spec (and perhaps in videodev2.h) that while it
> > originated with ivtv it is not specific to that driver.
> >
> > But I do not have a really strong opinion here.
>
> I don't have a terribly strong opinion either. I'm almost done the spec
> changes (see the diff inline below), but I can easily change things.
>
> I don't particularly want to purge IVTV from the
> V4L2_CID_MPEG_STREAM_VBI_FMT MPEG control enumeration:
>
> enum v4l2_mpeg_stream_vbi_fmt {
> [...]
> V4L2_MPEG_STREAM_VBI_FMT_IVTV = 1,
> };
>
> as that would be a specification change vs. an addition. Also adding a
> new ...FMT_ITV0 symbol to the enumeration, that overlaps with a value of
> 1, creates problems for the controls code. IMO, IVTV is there to stay in
> that enumeration.

Right. Unless Mauro objects strongly I think we should just keep it as is. I
don't see any particular advantage in changing it.

> I can change every other IVTV reference to ITV0 in a sensible way (I
> think). Let me know, if you really want this. I won't be finishing it
> and posting it for final draft review for a day or two.

Nice documentation! I think that when this goes in, then README.vbi can be
removed.

Regards,

Hans

--
Hans Verkuil - video4linux developer - sponsored by TANDBERG

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

On Mon, 9 Mar 2009 22:53:44 +0100
Hans Verkuil <hverkuil@xs4all.nl> wrote:

> On Monday 09 March 2009 21:47:55 Andy Walls wrote:
> > On Mon, 2009-03-09 at 08:25 +0100, Hans Verkuil wrote:
> > > On Monday 09 March 2009 05:30:54 Mauro Carvalho Chehab wrote:
> > > > On Sat, 7 Mar 2009 09:49:30 +0100
> > > >
> > > > Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > > > On Saturday 07 March 2009 02:31:41 Andy Walls wrote:
> > > > > > On Fri, 2009-03-06 at 15:41 +0100, Hans Verkuil wrote:
> > > > > > > On Friday 06 March 2009 04:39:34 Andy Walls wrote:
> > > > > > > > Yes, they should be exported to userspace as well, so apps
> > > > > > > > like MythTV don't have to keep their own copies as well. I'm
> > > > > > > > going to work on a V4L2 spec change to add structures and
> > > > > > > > defines for the packets indicated by
> > > > > > > > V4L2_MPEG_STREAM_VBI_FMT_IVTV, and then add it to some API
> > > > > > > > header. Maybe in linux/include/linux/videodev2.h with all the
> > > > > > > > other VBI data formats.
> > > > > > > >
> > > > > > > > Unless someone really disagrees.
> > > > > > >
> > > > > > > These VBI defines should be moved to videodev2.h. In hindsight
> > > > > > > this should never have been added to ivtv.h. Originally only
> > > > > > > ivtv used this, but now cx18 does as well, and in theory any
> > > > > > > MPEG encoder device can use it.
> > > > > >
> > > > > > Hans, Mauro, and whoever:
> > > > > >
> > > > > > Before I get too far down the road of writing the spec
> > > > > > modifications and perhaps modifying drivers, in the diff below:
> > > > > >
> > > > > > 1. Are the modifications to the headers acceptable?
> > > > > >
> > > > > > 2. Are they correct? (I *think* they are.)
> > > > >
> > > > > Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
> > > > >
> > > > > Very nice. I was also toying with the idea to rename 'IVTV' in
> > > > > these defines to something different, but that makes too much of a
> > > > > mess. I think it is sufficient to add a sentence to the spec along
> > > > > the lines of:
> > > > >
> > > > > "This format was first introduced in the ivtv driver, hence the use
> > > > > of IVTV in these defines. It is however not limited to the ivtv
> > > > > driver, any MPEG encoder can use it."
> > > > >
> > > > > And I think that it also doesn't hurt if some of my explanations
> > > > > from my earlier email are added to the spec as well. The format
> > > > > looks really weird if you do not understand the PVR350 (cx23415)
> > > > > limitation.
> > > >
> > > > IMO, it is better to remove the IVTV from the name or to replace to
> > > > something else, since it is meant to be used by other drivers.
> > > >
> > > > > +#define V4L2_MPEG_VBI_IVTV_MAGIC0 "itv0"
> > > > > +#define V4L2_MPEG_VBI_IVTV_MAGIC1 "ITV0"
> > > >
> > > > Hmm... maybe we could just name it as format ITV0, as marked at the
> > > > magic values above. What do you think?
> > >
> > > I don't really see much of an improvement here. I think it is better to
> > > put a note in the spec (and perhaps in videodev2.h) that while it
> > > originated with ivtv it is not specific to that driver.
> > >
> > > But I do not have a really strong opinion here.
> >
> > I don't have a terribly strong opinion either. I'm almost done the spec
> > changes (see the diff inline below), but I can easily change things.
> >
> > I don't particularly want to purge IVTV from the
> > V4L2_CID_MPEG_STREAM_VBI_FMT MPEG control enumeration:
> >
> > enum v4l2_mpeg_stream_vbi_fmt {
> > [...]
> > V4L2_MPEG_STREAM_VBI_FMT_IVTV = 1,
> > };
> >
> > as that would be a specification change vs. an addition. Also adding a
> > new ...FMT_ITV0 symbol to the enumeration, that overlaps with a value of
> > 1, creates problems for the controls code. IMO, IVTV is there to stay in
> > that enumeration.
>
> Right. Unless Mauro objects strongly I think we should just keep it as is. I
> don't see any particular advantage in changing it.

Ok. Let's then keep the IVTV naming.

>
> > I can change every other IVTV reference to ITV0 in a sensible way (I
> > think). Let me know, if you really want this. I won't be finishing it
> > and posting it for final draft review for a day or two.
>
> Nice documentation! I think that when this goes in, then README.vbi can be
> removed.
>
> Regards,
>
> Hans
>




Cheers,
Mauro

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

On Mon, 2009-03-09 at 22:53 +0100, Hans Verkuil wrote:
> On Monday 09 March 2009 21:47:55 Andy Walls wrote:

> I'm almost done the spec
> > changes (see the diff inline below), but I can easily change things.
> >

> Nice documentation!

Thanks! When I'm motivated, for some mysterious reason, to do some
documentation, I try to be thorough.


The linemask[2] bitmask specifications are giving me some mild
headaches. The linemaks output by the cx18 driver code for NTSC CC
don't seem to be consistent with README.vbi:

xxd -g4 foovbi.mpg | less

0000800: 000001ba 44000c66 240101d1 d3faffff ....D..f$.......
0000810: 000001bd 00428480 07210001 0001ffff .....B...!......
0000820: 69747630 00800000 00000000 04c146ad itv0..........F.
0000830: 107f1080 10821081 10841081 10851084 ................
0000840: 10811083 10711063 10541023 10471010 .....q.c.T.#.G..
0000850: 105a1022 10781004 000001ba 44000404 .Z.".x......D...
[...]
001a850: 84e015f9 24c26e47 000001ba 44000c66 ....$.nG....D..f
001a860: 240101d1 d3faffff 000001bd 006e8480 $............n..
001a870: 07210001 0001ffff 69747630 00800000 .!......itv0....
001a880: 02000000 04808066 1082107f 1080107e .......f.......~
001a890: 107c107f 107b1081 107d1080 107f107f .|...{...}......
001a8a0: 107f1080 10801082 10831081 10831004 ................
001a8b0: 85027110 86107f10 85107e10 82107d10 ..q.......~...}.
001a8c0: 7f107f10 81107f10 83107f10 83107f10 ................
001a8d0: 84107f10 84107e10 82100000 000001ba ......~.........
[...]
00210d0: 03db2840 76591671 c3eb4ec1 000001ba ..(@vY.q..N.....
00210e0: 44000c66 240101d1 d3faffff 000001bd D..f$...........
00210f0: 006e8480 07210001 0001ffff 69747630 .n...!......itv0
0021100: 00800000 02000000 04808066 107f1076 ...........f...v
0021110: 107c107d 107f1082 10801080 10811081 .|.}............
0021120: 108f109e 1fa810db e7b610f0 10a910d8 ................
0021130: 10911004 20206a10 83108110 83107f10 .... j.........
0021140: 83107e10 81107d10 7d107c10 7c107d10 ..~...}.}.|.|.}.
0021150: 7d107f10 7d108110 7d108210 7e100000 }...}...}...~...

(Ignore the PTS of 0 in the MPEG-2 Private Stream 1 PES header, I know
about that.)

Or maybe it's that the linemasks are written to the file as little
endian, when the rest of the Program Pack and Private Stream 1 Packet
are written big-endian or bytewise.

So I guess should be reading the linemasks as 0x00008000 (line 6+15 =
21) and 0x00000002 (line 6+(32-18)+1 = 21).

Should the linemask[] values be specified as little endian in the output
stream?


MythTV has this odd input method for the linemask[] values:

void AvFormatDecoder::ProcessVBIDataPacket(
const AVStream *stream, const AVPacket *pkt)
{
(void) stream;

const uint8_t *buf = pkt->data;
uint64_t linemask = 0;
unsigned long long utc = lastccptsu;

// [i]tv0 means there is a linemask
// [I]TV0 means there is no linemask and all lines are present
if ((buf[0]=='t') && (buf[1]=='v') && (buf[2] == '0'))
{
/// TODO this is almost certainly not endian safe....
memcpy(&linemask, buf + 3, 8);
buf += 11;
}
else if ((buf[0]=='T') && (buf[1]=='V') && (buf[2] == '0'))
{
linemask = 0xffffffffffffffffLL;
buf += 3;
}
[...]

So if we say in the spec the linemask[] values must be little endian,
MythTV will continue to work on little endian machines (I think).

Regards,
Andy


> I think that when this goes in, then README.vbi can be
> removed.
>
> Regards,
>
> Hans



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

On Wednesday 11 March 2009 01:02:38 Andy Walls wrote:
> On Mon, 2009-03-09 at 22:53 +0100, Hans Verkuil wrote:
> > On Monday 09 March 2009 21:47:55 Andy Walls wrote:
> >
> > I'm almost done the spec
> >
> > > changes (see the diff inline below), but I can easily change things.
> >
> > Nice documentation!
>
> Thanks! When I'm motivated, for some mysterious reason, to do some
> documentation, I try to be thorough.
>
>
> The linemask[2] bitmask specifications are giving me some mild
> headaches. The linemaks output by the cx18 driver code for NTSC CC
> don't seem to be consistent with README.vbi:
>
> xxd -g4 foovbi.mpg | less
>
> 0000800: 000001ba 44000c66 240101d1 d3faffff ....D..f$.......
> 0000810: 000001bd 00428480 07210001 0001ffff .....B...!......
> 0000820: 69747630 00800000 00000000 04c146ad itv0..........F.
> 0000830: 107f1080 10821081 10841081 10851084 ................
> 0000840: 10811083 10711063 10541023 10471010 .....q.c.T.#.G..
> 0000850: 105a1022 10781004 000001ba 44000404 .Z.".x......D...
> [...]
> 001a850: 84e015f9 24c26e47 000001ba 44000c66 ....$.nG....D..f
> 001a860: 240101d1 d3faffff 000001bd 006e8480 $............n..
> 001a870: 07210001 0001ffff 69747630 00800000 .!......itv0....
> 001a880: 02000000 04808066 1082107f 1080107e .......f.......~
> 001a890: 107c107f 107b1081 107d1080 107f107f .|...{...}......
> 001a8a0: 107f1080 10801082 10831081 10831004 ................
> 001a8b0: 85027110 86107f10 85107e10 82107d10 ..q.......~...}.
> 001a8c0: 7f107f10 81107f10 83107f10 83107f10 ................
> 001a8d0: 84107f10 84107e10 82100000 000001ba ......~.........
> [...]
> 00210d0: 03db2840 76591671 c3eb4ec1 000001ba ..(@vY.q..N.....
> 00210e0: 44000c66 240101d1 d3faffff 000001bd D..f$...........
> 00210f0: 006e8480 07210001 0001ffff 69747630 .n...!......itv0
> 0021100: 00800000 02000000 04808066 107f1076 ...........f...v
> 0021110: 107c107d 107f1082 10801080 10811081 .|.}............
> 0021120: 108f109e 1fa810db e7b610f0 10a910d8 ................
> 0021130: 10911004 20206a10 83108110 83107f10 .... j.........
> 0021140: 83107e10 81107d10 7d107c10 7c107d10 ..~...}.}.|.|.}.
> 0021150: 7d107f10 7d108110 7d108210 7e100000 }...}...}...~...
>
> (Ignore the PTS of 0 in the MPEG-2 Private Stream 1 PES header, I know
> about that.)
>
> Or maybe it's that the linemasks are written to the file as little
> endian, when the rest of the Program Pack and Private Stream 1 Packet
> are written big-endian or bytewise.
>
> So I guess should be reading the linemasks as 0x00008000 (line 6+15 =
> 21) and 0x00000002 (line 6+(32-18)+1 = 21).
>
> Should the linemask[] values be specified as little endian in the output
> stream?

Yes, that must definitely be specified. And while you are at it, ivtv and
probably cx18 as well don't handle the endianness of linemask when writing
the VBI data, so that should be fixed. It will currently fail with a
big-endian system.

Regards,

Hans

>
>
> MythTV has this odd input method for the linemask[] values:
>
> void AvFormatDecoder::ProcessVBIDataPacket(
> const AVStream *stream, const AVPacket *pkt)
> {
> (void) stream;
>
> const uint8_t *buf = pkt->data;
> uint64_t linemask = 0;
> unsigned long long utc = lastccptsu;
>
> // [i]tv0 means there is a linemask
> // [I]TV0 means there is no linemask and all lines are present
> if ((buf[0]=='t') && (buf[1]=='v') && (buf[2] == '0'))
> {
> /// TODO this is almost certainly not endian safe....
> memcpy(&linemask, buf + 3, 8);
> buf += 11;
> }
> else if ((buf[0]=='T') && (buf[1]=='V') && (buf[2] == '0'))
> {
> linemask = 0xffffffffffffffffLL;
> buf += 3;
> }
> [...]
>
> So if we say in the spec the linemask[] values must be little endian,
> MythTV will continue to work on little endian machines (I think).
>
> Regards,
> Andy
>
> > I think that when this goes in, then README.vbi can be
> > removed.
> >
> > Regards,
> >
> > Hans



--
Hans Verkuil - video4linux developer - sponsored by TANDBERG

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