[HG PULL] http://linuxtv.org/hg/~awalls/cx18-changes
Mauro, Please pull from http://linuxtv.org/hg/~awalls/cx18-changes for the following 2 changesets: 01/02: cx18: Add support for component video inputs http://linuxtv.org/hg/~awalls/cx18-changes?cmd=changeset;node=e253c7ba11c0 02/02: cx18: Add a component video input to the PVR2100 and DVR3200H card entries http://linuxtv.org/hg/~awalls/cx18-changes?cmd=changeset;node=145b18b20689 cx18-av-core.c | 33 + cx18-av-core.h | 19 +++ cx18-cards.c |4 +++- cx18-cards.h |4 ++-- 4 files changed, 53 insertions(+), 7 deletions(-) Thanks, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~awalls/cx18-pvr2100
Mauro, Please pull from http://linuxtv.org/hg/~awalls/cx18-pvr2100 for the following 2 changesets: 01/02: cx18: Fix tuner reset pin in card entry for the Leadtek PVR2100 http://linuxtv.org/hg/~awalls/cx18-pvr2100?cmd=changeset;node=7cc248252f21 02/02: saa7127: Add support for generating SECAM output for the SAA712[89] chips http://linuxtv.org/hg/~awalls/cx18-pvr2100?cmd=changeset;node=ad62ab7e4325 cx18/cx18-cards.c |2 +- saa7127.c | 47 --- 2 files changed, 41 insertions(+), 8 deletions(-) Thanks, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~awalls/cx18-feature
On Thu, 2009-12-31 at 20:40 -0500, Andy Walls wrote: Mauro, Please pull from http://linuxtv.org/hg/~awalls/cx18-feature for the following 8 changesets: [snip] These changes implement the VIDIOC_G_ENC_INDEX ioctl() for cx18 analog capture of MPEG-2 PS, MPEG-2 DVD and similar streams. There are some minor annoyances - the firmware appears to report everything is a B-frame, and driver limitations mean one can't capture an index when doing sliced VBI insertion - but the rest of it is working properly if anyone would ever need to use it. Oh, and I did find and fix a big memory leak (changeset 03/08) where all the DMA buffers for the DVB TS and INDEX streams were being leaked on module unload. Mauro, I'm adding one more patch to this pull request, since I have solved the I only get B frames indexed problem. :) Please pull from http://linuxtv.org/hg/~awalls/cx18-feature for the following 9 changesets: 01/09: cx18: Update MPEG Index stream buffers module option processing http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=eb875b71908a 02/09: cx18: Encapsulate check for a stream being enabled into an inline function http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=55c86b3e5a09 03/09: cx18: Fix TS and IDX stream buffer memory leak on module unload http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=9c341b693fcd 04/09: cx18: Allow MPEG index streams to be started and stopped internally http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=fc743523e7bd 05/09: cx18: Start IDX streams automatically as an internal associated stream http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=e18e865270ea 06/09: cx18: Perform automatic rotation of very old, unread IDX buffers http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=ee8c1c0eec7e 07/09: cx18: Add initial working VIDIOC_G_ENC_INDEX ioctl() support http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=dcb3c59fab66 08/09: cx18: Clean up dead code from ivtv once used for IDX processing http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=2b8531783c9d 09/09: cx18: Fix set indextable command to properly select I/P/B index entries http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=1acfabb1534b cx18-driver.c | 33 ++-- cx18-driver.h | 40 ++--- cx18-fileops.c | 235 - cx18-ioctl.c | 146 +++ cx18-mailbox.c |5 - cx18-queue.c |3 cx18-streams.c | 90 - cx18-streams.h | 10 ++ cx23418.h |3 9 files changed, 388 insertions(+), 177 deletions(-) Thanks, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~awalls/cx18-feature
Mauro, Please pull from http://linuxtv.org/hg/~awalls/cx18-feature for the following 8 changesets: 01/08: cx18: Update MPEG Index stream buffers module option processing http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=eb875b71908a 02/08: cx18: Encapsulate check for a stream being enabled into an inline function http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=55c86b3e5a09 03/08: cx18: Fix TS and IDX stream buffer memory leak on module unload http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=9c341b693fcd 04/08: cx18: Allow MPEG index streams to be started and stopped internally http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=fc743523e7bd 05/08: cx18: Start IDX streams automatically as an internal associated stream http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=e18e865270ea 06/08: cx18: Perform automatic rotation of very old, unread IDX buffers http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=ee8c1c0eec7e 07/08: cx18: Add initial working VIDIOC_G_ENC_INDEX ioctl() support http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=dcb3c59fab66 08/08: cx18: Clean up dead code from ivtv once used for IDX processing http://linuxtv.org/hg/~awalls/cx18-feature?cmd=changeset;node=2b8531783c9d cx18-driver.c | 33 ++-- cx18-driver.h | 40 ++--- cx18-fileops.c | 235 - cx18-ioctl.c | 146 +++ cx18-mailbox.c |5 - cx18-queue.c |3 cx18-streams.c | 86 cx18-streams.h | 10 ++ 8 files changed, 384 insertions(+), 174 deletions(-) These changes implement the VIDIOC_G_ENC_INDEX ioctl() for cx18 analog capture of MPEG-2 PS, MPEG-2 DVD and similar streams. There are some minor annoyances - the firmware appears to report everything is a B-frame, and driver limitations mean one can't capture an index when doing sliced VBI insertion - but the rest of it is working properly if anyone would ever need to use it. Oh, and I did find and fix a big memory leak (changeset 03/08) where all the DMA buffers for the DVB TS and INDEX streams were being leaked on module unload. Thanks, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~awalls/cx18-yuv2
Mauro, Please pull from http://linuxtv.org/hg/~awalls/cx18-yuv2 for the following 9 changesets: 01/09: cx18: Rename struct cx18_mdl to struct cx18_mdl_ent http://linuxtv.org/hg/~awalls/cx18-yuv2?cmd=changeset;node=0c3fc323e620 02/09: cx18: Rename struct cx18_queue.buffers to struct cx18_queue.depth http://linuxtv.org/hg/~awalls/cx18-yuv2?cmd=changeset;node=d6c3b39db8ab 03/09: cx18: Rename mdl_offset to mdl_base_idx or free_mdl_idx as appropriate http://linuxtv.org/hg/~awalls/cx18-yuv2?cmd=changeset;node=d2aaff136907 04/09: cx18: Add Memory Descriptor List (MDL) layer to buffer handling http://linuxtv.org/hg/~awalls/cx18-yuv2?cmd=changeset;node=7543832d06b2 05/09: cx18: Fix YUV capture so that encoder passes a single frame per transfer http://linuxtv.org/hg/~awalls/cx18-yuv2?cmd=changeset;node=f59481fcef0f 06/09: cx18: Adjust an MDL's final buffer size to force encoder transfer size http://linuxtv.org/hg/~awalls/cx18-yuv2?cmd=changeset;node=a612183c386b 07/09: cx18: Adjust encoder VBI MDL size to be exactly frame's worth of VBI data http://linuxtv.org/hg/~awalls/cx18-yuv2?cmd=changeset;node=0f7da532929c 08/09: cx18: Remove duplicate list traversal when processing incoming MDLs http://linuxtv.org/hg/~awalls/cx18-yuv2?cmd=changeset;node=9221d72831d9 09/09: cx18: Bump version number due to significant buffer handling changes. http://linuxtv.org/hg/~awalls/cx18-yuv2?cmd=changeset;node=6dddcc06660f (Most of) These changes ensure the YUV stream presented to the application will always provide whole frames, even though the cx18 driver may miss some buffer transfer notifications from the CX23418 due to system interrupt response latency. cx18-driver.c | 61 ++-- cx18-driver.h | 59 +--- cx18-dvb.c |5 cx18-fileops.c | 132 ++- cx18-ioctl.c |5 cx18-mailbox.c | 62 ++-- cx18-mailbox.h |6 cx18-queue.c | 394 ++--- cx18-queue.h | 67 ++--- cx18-scb.h |4 cx18-streams.c | 98 +- cx18-streams.h | 10 - cx18-vbi.c | 35 - cx18-vbi.h |2 cx18-version.h |2 cx23418.h |2 16 files changed, 682 insertions(+), 262 deletions(-) Thanks, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~awalls/cx18-av-core
Mauro, Please pull from http://linuxtv.org/hg/~awalls/cx18-av-core for the following 3 changesets: 01/03: cx18: Initial attempt to get sliced VBI working for 625 line systems http://linuxtv.org/hg/~awalls/cx18-av-core?cmd=changeset;node=7a6db40f48a4 02/03: cx18: Complete support for Sliced and Raw VBI for 625 line systems http://linuxtv.org/hg/~awalls/cx18-av-core?cmd=changeset;node=b6d187f227ed 03/03: cx18: Tweak color burst gate delay and initial color sub-carrier freq http://linuxtv.org/hg/~awalls/cx18-av-core?cmd=changeset;node=ec07356c9813 cx18-av-core.c | 155 + cx18-av-vbi.c |6 +- cx18-streams.c | 17 -- 3 files changed, 128 insertions(+), 50 deletions(-) Thanks, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~awalls/cx18-perf
Mauro, This is a resubmission of my previous PULL request. Please pull from: http://linuxtv.org/hg/~awalls/cx18-perf for the following: cx18: Increment version due to significant buffer handling changes cx18: Simplify the work handler for outgoing mailbox commands cx18: Convert per stream mutex locks to per queue spin locks cx18: Set up to wait for a one-shot response before sending a firmware cmd cx18: Add a work queue for deferring empty buffer handoffs to the firmware cx18: Rename the work queue to in_work_queue These are a series of patches to improve latency of incoming capture buffer handling from the time of firmware notification of DMA done, to the applications reading the data, by removing all possible sleeps in that processing. The sleeps, that can happen when trying to send empty buffers back to the firmware, now happen in an out_work_handler set of workqueue threads. Nothing has changed with these patches since my original request. The user who reported MythTV crashing could unfortunately not reproduce the problem for further investigation. I could not get these changes to crash MythTV in my testing. The only failure mode I could think of - an Oops or Bug when queueing and already queued work object - is not an issue according to LDD3 and the 2.6.27.9-159.fc10.x86_64 kernel source code. So I resubmitting for a PULL as is. Regards, Andy diffstat cx18-driver.c | 117 +++- cx18-driver.h | 17 +--- cx18-dvb.c |1 cx18-mailbox.c | 118 ++--- cx18-mailbox.h |4 - cx18-queue.c | 83 cx18-streams.c | 46 ++ cx18-streams.h | 24 ++- cx18-version.h |2 9 files changed, 278 insertions(+), 134 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~awalls/cx18-perf
On Wed, 2009-04-15 at 20:08 -0400, Andy Walls wrote: Mauro, Please pull from: http://linuxtv.org/hg/~awalls/cx18-perf for the following: cx18: Increment version due to significant buffer handling changes cx18: Simplify the work handler for outgoing mailbox commands cx18: Convert per stream mutex locks to per queue spin locks cx18: Set up to wait for a one-shot response before sending a firmware cmd cx18: Add a work queue for deferring empty buffer handoffs to the firmware cx18: Rename the work queue to in_work_queue These are a series of patches to improve latency of incoming capture buffer handling from the time of firmware notification of DMA done, to the applications reading the data, by removing all possible sleeps in that processing. The sleeps, that can happen when trying to send empty buffers back to the firmware, now happen in an out_work_handler set of workqueue threads. Regards, Andy Mauro, Please don not pull these changes yet. A user has reported a problem that concerns me. Until I fully investigate, I'd prefer this changeset not go forward. If it is already pulled, I let you know of any additional changes required as soon as possible. Thank you. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~awalls/cx18-perf
Mauro, Please pull from: http://linuxtv.org/hg/~awalls/cx18-perf for the following: cx18: Increment version due to significant buffer handling changes cx18: Simplify the work handler for outgoing mailbox commands cx18: Convert per stream mutex locks to per queue spin locks cx18: Set up to wait for a one-shot response before sending a firmware cmd cx18: Add a work queue for deferring empty buffer handoffs to the firmware cx18: Rename the work queue to in_work_queue These are a series of patches to improve latency of incoming capture buffer handling from the time of firmware notification of DMA done, to the applications reading the data, by removing all possible sleeps in that processing. The sleeps, that can happen when trying to send empty buffers back to the firmware, now happen in an out_work_handler set of workqueue threads. Regards, Andy diffstat cx18-driver.c | 117 +++- cx18-driver.h | 17 +--- cx18-dvb.c |1 cx18-mailbox.c | 118 ++--- cx18-mailbox.h |4 - cx18-queue.c | 83 cx18-streams.c | 46 ++ cx18-streams.h | 24 ++- cx18-version.h |2 9 files changed, 278 insertions(+), 134 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~awalls/cx18
Mauro, Please pull from: http://linuxtv.org/hg/~awalls/cx18 for cx18: Optimize processing of VBI buffers from the capture unit cx18, ivtv: Ensure endianess for linemasks in VBI embedded in MPEG stream Regards, Andy diffstat cx18/cx18-vbi.c | 105 +++- ivtv/ivtv-vbi.c |2 + 2 files changed, 53 insertions(+), 54 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] API changes for V4L2_MPEG_SLICED_VBI_FMT_IVTV definitions (Re: [PULL] http://linuxtv.org/hg/~awalls/cx18)
On Monday 09 March 2009 05:30:54 Mauro Carvalho Chehab wrote: On Sat, 7 Mar 2009 09:49:30 +0100 Hans Verkuil hverk...@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 hverk...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] API changes for V4L2_MPEG_SLICED_VBI_FMT_IVTV definitions (Re: [PULL] http://linuxtv.org/hg/~awalls/cx18)
On Mon, 9 Mar 2009 22:53:44 +0100
Hans Verkuil hverk...@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 hverk...@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 hverk...@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_MAGIC0itv0
+#define V4L2_MPEG_VBI_IVTV_MAGIC1ITV0
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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] API changes for V4L2_MPEG_SLICED_VBI_FMT_IVTV definitions (Re: [PULL] http://linuxtv.org/hg/~awalls/cx18)
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 hverk...@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_MAGIC0itv0
+#define V4L2_MPEG_VBI_IVTV_MAGIC1ITV0
+
+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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~awalls/cx18
On Friday 06 March 2009 04:39:34 Andy Walls wrote:
On Tue, 2009-03-03 at 21:50 -0300, Mauro Carvalho Chehab wrote:
On Sun, 01 Mar 2009 22:04:55 -0500
Andy Walls awa...@radix.net wrote:
Mauro,
Please pull from
http://linuxtv.org/hg/~awalls/cx18
for the following
cx18: Add interlock so sliced VBI insertion only happens for an MPEG
PS
cx18: Fix VPS service register code and ensure VBI consistentcy with
ivtv
Argh! This is really ugly!
+
+#include linux/ivtv.h /* For IVTV_SLICED_TYPE_* */
+
Yes. It is.
Why do you need to include a header for a device that has nothing to do
with cx18?
I don't.
My rationale was that the cx18 driver supports a VBI data format type
enumerated in the V4L2 spec and in linux/include/linux/videodev2.h,
namely:
enum v4l2_mpeg_stream_vbi_fmt {
[...]
V4L2_MPEG_STREAM_VBI_FMT_IVTV = 1, /* VBI in private packets,
IVTV format */ };
And some values used in that data format are in no other internal nor
exported header than linux/include/linux/ivtv.h. The data format itself
isn't delared at all in any kernel header AFAIK, but only in
linux/Documentation/video4linux/README.vbi in prose instead of C
declarations.
This doesn't belong here...
OK.
If those VBI parameters should be global to all devices, then it should
be, instead, at some subsystem header, and your patch should also touch
on the other drivers.
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.
Due to the popularity of the ivtv driver it has become a de-facto standard.
There are other standards for embedding e.g. closed captions in an MPEG
stream. But the advantage of this IVTV standard is that it allows any VBI
type to be embedded and supports the maximum number of VBI lines.
The somewhat awkward encoding is a result of a limitation of the PVR-350
MPEG decoder. That decoder can read back the embedded VBI data, but it only
reads back a limited number of bytes, any data beyond that maximum is
ignored. So the maximum size of the embedded VBI data had to be limited to
what the PVR-350 decoder supports.
It was always my intention to add support for other, more official, methods
of including closed captions into an MPEG stream, but by that time all the
main applications already supported this IVTV-specific format :-)
Looking back on this I wish I used a standard method of embedding this data,
even though that might have meant that the VBI packet size could have been
larger than the maximum supported by the PVR-350. It has been my experience
that in practice you never see PAL transmissions that use the maximum
number of VBI lines.
Oh well, you live and learn...
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] API changes for V4L2_MPEG_SLICED_VBI_FMT_IVTV definitions (Re: [PULL] http://linuxtv.org/hg/~awalls/cx18)
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.)
Regards,
Andy
diff -r 5361470b10f4 linux/include/linux/ivtv.h
--- a/linux/include/linux/ivtv.hSun Mar 01 21:10:07 2009 -0500
+++ b/linux/include/linux/ivtv.hFri 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_525V4L2_MPEG_VBI_IVTV_CAPTION_525
+#define IVTV_SLICED_TYPE_WSS_625V4L2_MPEG_VBI_IVTV_WSS_625
+#define IVTV_SLICED_TYPE_VPSV4L2_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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~awalls/cx18
On Tue, 2009-03-03 at 21:50 -0300, Mauro Carvalho Chehab wrote:
On Sun, 01 Mar 2009 22:04:55 -0500
Andy Walls awa...@radix.net wrote:
Mauro,
Please pull from
http://linuxtv.org/hg/~awalls/cx18
for the following
cx18: Add interlock so sliced VBI insertion only happens for an MPEG PS
cx18: Fix VPS service register code and ensure VBI consistentcy with ivtv
Argh! This is really ugly!
+
+#include linux/ivtv.h /* For IVTV_SLICED_TYPE_* */
+
Yes. It is.
Why do you need to include a header for a device that has nothing to do with
cx18?
I don't.
My rationale was that the cx18 driver supports a VBI data format type
enumerated in the V4L2 spec and in linux/include/linux/videodev2.h,
namely:
enum v4l2_mpeg_stream_vbi_fmt {
[...]
V4L2_MPEG_STREAM_VBI_FMT_IVTV = 1, /* VBI in private packets, IVTV
format */
};
And some values used in that data format are in no other internal nor
exported header than linux/include/linux/ivtv.h. The data format itself
isn't delared at all in any kernel header AFAIK, but only in
linux/Documentation/video4linux/README.vbi in prose instead of C
declarations.
This doesn't belong here...
OK.
If those VBI parameters should be global to all devices, then it should be,
instead, at some subsystem header, and your patch should also touch on the
other drivers.
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.
In the mean time I will issue a new PULL request omitting the portion of
the change you don't like.
Regards,
Andy
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~awalls/cx18
On Sun, 01 Mar 2009 22:04:55 -0500 Andy Walls awa...@radix.net wrote: Mauro, Please pull from http://linuxtv.org/hg/~awalls/cx18 for the following cx18: Add interlock so sliced VBI insertion only happens for an MPEG PS cx18: Fix VPS service register code and ensure VBI consistentcy with ivtv Argh! This is really ugly! + +#include linux/ivtv.h /* For IVTV_SLICED_TYPE_* */ + Why do you need to include a header for a device that has nothing to do with cx18? This doesn't belong here... If those VBI parameters should be global to all devices, then it should be, instead, at some subsystem header, and your patch should also touch on the other drivers. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~awalls/cx18
On Thu, 2009-02-26 at 22:25 -0300, Mauro Carvalho Chehab wrote: On Sat, 21 Feb 2009 21:22:22 -0500 Andy Walls awa...@radix.net wrote: cx18: Change log lines for internal subdevs and fix tveeprom reads + strncpy(c.name, cx18 tveeprom tmp, sizeof(c.name)); + c.name[sizeof(c.name)-1] = '\0'; Please use strlcpy() instead. Sure. I'm checking the change now. I'll issue a pull request later this weekend. cx18: Convert the integrated A/V decoder core interface to a v4l2_subdev There were some merge conflicts. I've fixed it by hand, but I suspect that you'll need to properly tune the default values for v4l2_ctrl_query_fill(). Please review my last patch and fix it accordingly with the limits of each V4L2_CID. Sorry I didn't get to this sooner (I was traveling). I see you've already fixed the values. Your fixes are as Hans had intended them for cx18. Thanks. Regards, Andy Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~awalls/cx18
Andy and Hans, On Sat, 21 Feb 2009 21:22:22 -0500 Andy Walls awa...@radix.net wrote: This set of changes will conflict with Hans' recent pull request that affects cx18-av-core.c. If your merge tools can't detect that the code Hans intends to patch simply differs in position by about 20 lines, then Hans' changes to cx18-av-core.c still should be easy enough to merge by hand. There were several merge conflicts and bisect breakages that happened during the merge of your trees. Most of the troubles were due the removal of a control function helper from core. It took me a large amount of time to fix those conflicts and to be sure that bisect were not broken during the -git export. Since I had to do some magic during this merge, it would be really interesting if you could double check if everything is ok. I've already backported the -git changes into -hg. If you find any issues, please send me a patch fixing they. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~awalls/cx18
Mauro, Please pull from: http://linuxtv.org/hg/~awalls/cx18 for the following: cx18: Disable AC3 controls as the firmware doesn't support AC3 cx18: Increment version number due to significant changes for v4l2_subdevs cx18: Get rid of unused variables related to video output cx18: Change log lines for internal subdevs and fix tveeprom reads cx18: Fix a memory leak of buffers used for sliced VBI insertion cx18: Convert GPIO connected functions to act as v4l2_subdevices cx18: Convert I2C devices to v4l2_subdevices cx18, v4l2-chip-ident: Finish conversion of AV decoder core to v4l2_subdev cx18: Slim down instance handling, build names from v4l2_device.name cx18: Convert the integrated A/V decoder core interface to a v4l2_subdev This is the conversion of cx18 to the new v4l_device/v4l2_subdev framework, along with a few minor changes. (Note, I added a new value in v4l2-chip-ident, outside of the cx18 directory.) This set of changes will conflict with Hans' recent pull request that affects cx18-av-core.c. If your merge tools can't detect that the code Hans intends to patch simply differs in position by about 20 lines, then Hans' changes to cx18-av-core.c still should be easy enough to merge by hand. Regards, Andy diffstat: drivers/media/video/cx18/cx18-audio.c | 50 - drivers/media/video/cx18/cx18-audio.h |2 drivers/media/video/cx18/cx18-av-core.c | 753 drivers/media/video/cx18/cx18-av-core.h | 16 drivers/media/video/cx18/cx18-av-firmware.c |7 drivers/media/video/cx18/cx18-cards.c | 42 - drivers/media/video/cx18/cx18-cards.h | 15 drivers/media/video/cx18/cx18-controls.c| 25 drivers/media/video/cx18/cx18-driver.c | 238 drivers/media/video/cx18/cx18-driver.h | 100 +++ drivers/media/video/cx18/cx18-fileops.c | 41 - drivers/media/video/cx18/cx18-firmware.c| 18 drivers/media/video/cx18/cx18-gpio.c| 347 drivers/media/video/cx18/cx18-gpio.h| 10 drivers/media/video/cx18/cx18-i2c.c | 315 ++- drivers/media/video/cx18/cx18-i2c.h |5 drivers/media/video/cx18/cx18-ioctl.c | 113 +++- drivers/media/video/cx18/cx18-streams.c | 12 drivers/media/video/cx18/cx18-vbi.c |3 drivers/media/video/cx18/cx18-version.h |4 drivers/media/video/cx18/cx18-video.c |3 include/media/v4l2-chip-ident.h |3 22 files changed, 1134 insertions(+), 988 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
