Re: OMAP3 ISP ghosting

[Enrico]

On Wed, Oct 12, 2011 at 11:42 PM, Gary Thomas  wrote:
> Any ideas on this?  My naive attempt (diffs attached) just hangs up.
> These changes disable BT-656 mode in the CCDC and tell the TVP5150
> to output raw YUV 4:2:2 data including all SYNC signals.

I tried that too, you will need to change many of the is_bt656 into
is_fldmode. For isp configuration it seems that the only difference
between the two is (more or less) just the REC656 register. I made a
hundred attempts and in the end i had a quite working capture (just
not centered) but ghosting always there.

I made another test and by luck i got a strange thing, look at the
following image:

http://postimage.org/image/2d610pjk4/

(It's noisy because of a hardware problem)

I made it with these changes:

//ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1);
ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1);
//ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1);
ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1);

So you have an image with a field with no offset, and a field with offsets.

Now if you look between my thumb and my forefinger behind them there's
a monoscope picture and in one field you can see 2 black squares, in
the other one you can see 3 black squares. So the two field that will
be composing a single image differ very much.

Now the questions are: is this expected to happen on an analogue video
source and we can't do anything (apart from software deinterlacing)?
is this a problem with tvp5150? Is this a problem with the isp?

Enrico
--
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: OMAP3 ISP ghosting

[Gary Thomas]

On 2011-10-13 02:42, Enrico wrote:

On Wed, Oct 12, 2011 at 11:42 PM, Gary Thomas  wrote:

Any ideas on this?  My naive attempt (diffs attached) just hangs up.
These changes disable BT-656 mode in the CCDC and tell the TVP5150
to output raw YUV 4:2:2 data including all SYNC signals.


I tried that too, you will need to change many of the is_bt656 into
is_fldmode. For isp configuration it seems that the only difference
between the two is (more or less) just the REC656 register. I made a
hundred attempts and in the end i had a quite working capture (just
not centered) but ghosting always there.

I made another test and by luck i got a strange thing, look at the
following image:

http://postimage.org/image/2d610pjk4/

(It's noisy because of a hardware problem)

I made it with these changes:

//ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1);
ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1);
//ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1);
ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1);

So you have an image with a field with no offset, and a field with offsets.

Now if you look between my thumb and my forefinger behind them there's
a monoscope picture and in one field you can see 2 black squares, in
the other one you can see 3 black squares. So the two field that will
be composing a single image differ very much.

Now the questions are: is this expected to happen on an analogue video
source and we can't do anything (apart from software deinterlacing)?
is this a problem with tvp5150? Is this a problem with the isp?


Yes, there does seem to be significant movement/differences between these
two images.  Are you saying that these should be the two halves of one frame
that would be stitched together by de-interlacing?  Perhaps the halves are
out of sync and the bottom one of this image really goes with the top of
the next (frame13)?

The ghosting problem is still evident, even in this split image.  Notice
that every other scan line is really poor - basically junk.  When this gets
merged as part of the de-interlace, the ghosts appear.


--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
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: OMAP3 ISP ghosting

[Enrico]

On Thu, Oct 13, 2011 at 1:44 PM, Gary Thomas  wrote:
> On 2011-10-13 02:42, Enrico wrote:
>>
>> On Wed, Oct 12, 2011 at 11:42 PM, Gary Thomas  wrote:
>>>
>>> Any ideas on this?  My naive attempt (diffs attached) just hangs up.
>>> These changes disable BT-656 mode in the CCDC and tell the TVP5150
>>> to output raw YUV 4:2:2 data including all SYNC signals.
>>
>> I tried that too, you will need to change many of the is_bt656 into
>> is_fldmode. For isp configuration it seems that the only difference
>> between the two is (more or less) just the REC656 register. I made a
>> hundred attempts and in the end i had a quite working capture (just
>> not centered) but ghosting always there.
>>
>> I made another test and by luck i got a strange thing, look at the
>> following image:
>>
>> http://postimage.org/image/2d610pjk4/
>>
>> (It's noisy because of a hardware problem)
>>
>> I made it with these changes:
>>
>> //ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1);
>> ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1);
>> //ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1);
>> ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1);
>>
>> So you have an image with a field with no offset, and a field with
>> offsets.
>>
>> Now if you look between my thumb and my forefinger behind them there's
>> a monoscope picture and in one field you can see 2 black squares, in
>> the other one you can see 3 black squares. So the two field that will
>> be composing a single image differ very much.
>>
>> Now the questions are: is this expected to happen on an analogue video
>> source and we can't do anything (apart from software deinterlacing)?
>> is this a problem with tvp5150? Is this a problem with the isp?
>
> Yes, there does seem to be significant movement/differences between these
> two images.  Are you saying that these should be the two halves of one frame
> that would be stitched together by de-interlacing?  Perhaps the halves are
> out of sync and the bottom one of this image really goes with the top of
> the next (frame13)?

They are two fields that normally will be "merged" into a frame, but
with those settings i made the isp "expand" (SDOFST) just one of the
fields.

One possible thing is that, as you say, "the bottom one of this image
really goes with the top of the next".

But one thing to consider is that it is normal for interlaced video to
have such "effects", that's why progressive scan was invented.


> The ghosting problem is still evident, even in this split image.  Notice
> that every other scan line is really poor - basically junk.  When this gets
> merged as part of the de-interlace, the ghosts appear.

I don't think so. The bottom part is "expanded" by the isp, so it's ok
to have green half lines, that's where the top part will go if it is
"expanded" by the isp.

Looking at the single images (top and bottom) i don't see ghosting
artifacts (not only in that image but in a sequence of 16 frames),
just a little blurry in moving parts but that's expected in an
interlaced video. So it seems to me that the images arrive correctly
at the isp and the deinterlacing causes ghosting.

Enrico
--
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: recent cx23385?

[Devin Heitmueller]

On Thu, Oct 13, 2011 at 1:59 AM, James  wrote:
> Is there a newer cx23385 driver than the one in kernel-3.0.4?
> I bought a http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1250 and it
> shows video for about 5 seconds and then locks up the system.

You cannot install individual drivers (Linux doesn't work like Windows
in this regards).  You have to either install the latest kernel or you
can swap out the whole media subsystem with a later version.

http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
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: OMAP3 ISP ghosting

[Gary Thomas]

On 2011-10-13 06:32, Enrico wrote:

On Thu, Oct 13, 2011 at 1:44 PM, Gary Thomas  wrote:

On 2011-10-13 02:42, Enrico wrote:


On Wed, Oct 12, 2011 at 11:42 PM, Gary Thomaswrote:


Any ideas on this?  My naive attempt (diffs attached) just hangs up.
These changes disable BT-656 mode in the CCDC and tell the TVP5150
to output raw YUV 4:2:2 data including all SYNC signals.


I tried that too, you will need to change many of the is_bt656 into
is_fldmode. For isp configuration it seems that the only difference
between the two is (more or less) just the REC656 register. I made a
hundred attempts and in the end i had a quite working capture (just
not centered) but ghosting always there.

I made another test and by luck i got a strange thing, look at the
following image:

http://postimage.org/image/2d610pjk4/

(It's noisy because of a hardware problem)

I made it with these changes:

//ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1);
ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1);
//ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1);
ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1);

So you have an image with a field with no offset, and a field with
offsets.

Now if you look between my thumb and my forefinger behind them there's
a monoscope picture and in one field you can see 2 black squares, in
the other one you can see 3 black squares. So the two field that will
be composing a single image differ very much.

Now the questions are: is this expected to happen on an analogue video
source and we can't do anything (apart from software deinterlacing)?
is this a problem with tvp5150? Is this a problem with the isp?


Yes, there does seem to be significant movement/differences between these
two images.  Are you saying that these should be the two halves of one frame
that would be stitched together by de-interlacing?  Perhaps the halves are
out of sync and the bottom one of this image really goes with the top of
the next (frame13)?


They are two fields that normally will be "merged" into a frame, but
with those settings i made the isp "expand" (SDOFST) just one of the
fields.

One possible thing is that, as you say, "the bottom one of this image
really goes with the top of the next".

But one thing to consider is that it is normal for interlaced video to
have such "effects", that's why progressive scan was invented.



The ghosting problem is still evident, even in this split image.  Notice
that every other scan line is really poor - basically junk.  When this gets
merged as part of the de-interlace, the ghosts appear.


I don't think so. The bottom part is "expanded" by the isp, so it's ok
to have green half lines, that's where the top part will go if it is
"expanded" by the isp.

Looking at the single images (top and bottom) i don't see ghosting
artifacts (not only in that image but in a sequence of 16 frames),
just a little blurry in moving parts but that's expected in an
interlaced video. So it seems to me that the images arrive correctly
at the isp and the deinterlacing causes ghosting.


Is there any way to prove this by doing the de-interlacing in software?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
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: support for tv tuner tda18211 in Iconbit U100 analog stick

[Antti Palosaari]

CX23102 + TDA18211 (== DVB-T only version of TDA18271)

Maybe someone have better knowledge about that as I am not any familiar 
with CX23102 nor analog TV side.


Antti

On 10/09/2011 03:56 AM, Ling Sequera wrote:

I try to post this at linux-media@vger.kernel.org
, but the system rejects the
sending, Excuse me for send this to you, I have understood that you are
one of the developers of the tda18271 module.

I have a "Mygica u719c usb analog tv stick", lsusb output identify this
device as: "ID 1f4d:0237 G-Tek Electronics Group". Googling, I found
that this device is the same "Iconbit Analog Stick U100 FM
",
which has support in the kernel since version 3.0 as shown here
. I opened the
device to corfirm this information, and effectively, it has to chips,
the demod Conexan "CX23102" and the DVB-T tuner NPX "TDA-18211". I
installed the precompiled version of kernel 3.0.4, and the device was
reconized, but only works in the modes: composite and s-video. I check
the source code and I found that it don't support tv tuner mode
(.tuner_type=TUNER_ABSENT in 513 line of the cx231xx-cards.c

source file), I want to add support for this. The TDA-18211 tuner has
support in the kernel in the module tda18271 according to the thread of
this mailing list
. I
have never written a module, but I have basic knowledge in C, so I need
a book, reference, api, or something, to write the missing code to add
support for this device as tv tuner. Also I need help understanding how
to read usb-snoop log files and identify the necessary parameters for
configure the code. Thanks in advance.

Best regards.



--
http://palosaari.fi/
--
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: OMAP3 ISP ghosting

[Javier Martinez Canillas]

On Thu, Oct 13, 2011 at 2:52 PM, Gary Thomas  wrote:
> On 2011-10-13 06:32, Enrico wrote:
>>
>> On Thu, Oct 13, 2011 at 1:44 PM, Gary Thomas  wrote:
>>>
>>> On 2011-10-13 02:42, Enrico wrote:

 On Wed, Oct 12, 2011 at 11:42 PM, Gary Thomas
  wrote:
>
> Any ideas on this?  My naive attempt (diffs attached) just hangs up.
> These changes disable BT-656 mode in the CCDC and tell the TVP5150
> to output raw YUV 4:2:2 data including all SYNC signals.

 I tried that too, you will need to change many of the is_bt656 into
 is_fldmode. For isp configuration it seems that the only difference
 between the two is (more or less) just the REC656 register. I made a
 hundred attempts and in the end i had a quite working capture (just
 not centered) but ghosting always there.

 I made another test and by luck i got a strange thing, look at the
 following image:

 http://postimage.org/image/2d610pjk4/

 (It's noisy because of a hardware problem)

 I made it with these changes:

 //ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1);
 ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1);
 //ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1);
 ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1);

 So you have an image with a field with no offset, and a field with
 offsets.

 Now if you look between my thumb and my forefinger behind them there's
 a monoscope picture and in one field you can see 2 black squares, in
 the other one you can see 3 black squares. So the two field that will
 be composing a single image differ very much.

 Now the questions are: is this expected to happen on an analogue video
 source and we can't do anything (apart from software deinterlacing)?
 is this a problem with tvp5150? Is this a problem with the isp?
>>>
>>> Yes, there does seem to be significant movement/differences between these
>>> two images.  Are you saying that these should be the two halves of one
>>> frame
>>> that would be stitched together by de-interlacing?  Perhaps the halves
>>> are
>>> out of sync and the bottom one of this image really goes with the top of
>>> the next (frame13)?
>>
>> They are two fields that normally will be "merged" into a frame, but
>> with those settings i made the isp "expand" (SDOFST) just one of the
>> fields.
>>
>> One possible thing is that, as you say, "the bottom one of this image
>> really goes with the top of the next".
>>
>> But one thing to consider is that it is normal for interlaced video to
>> have such "effects", that's why progressive scan was invented.
>>
>>
>>> The ghosting problem is still evident, even in this split image.  Notice
>>> that every other scan line is really poor - basically junk.  When this
>>> gets
>>> merged as part of the de-interlace, the ghosts appear.
>>
>> I don't think so. The bottom part is "expanded" by the isp, so it's ok
>> to have green half lines, that's where the top part will go if it is
>> "expanded" by the isp.
>>
>> Looking at the single images (top and bottom) i don't see ghosting
>> artifacts (not only in that image but in a sequence of 16 frames),
>> just a little blurry in moving parts but that's expected in an
>> interlaced video. So it seems to me that the images arrive correctly
>> at the isp and the deinterlacing causes ghosting.
>

Hello,

Yes, I noticed that the images arrive correctly but disabling the
interlaced mode fldmode == 0 and not setting an offset to copy the
odd/even fields

ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 0);
ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 0);
ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 0);
ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 0);

If you do so, you will see a image that is composed of both odd and
even frames each of them half the size of the deinterlaced image. So
the TVP is producing the correct YUV data and also the ISP is decoding
correctly using the BT.656 embedded sync info.

My guess is that has to do with the buffers. I guess there are two
ways to probe this.

1- Hack yavta to memset to 0 every buffer before passing to V4L2 layer.

> Is there any way to prove this by doing the de-interlacing in software?

2- Deinterlace by software.

As I said before deactivate the interlaced mode and get the two
frames, then you can copy 1440 bytes (one line) from the first
sub-frame (lines[0]) and then copy one line of the second sub-frame
(lines[height/2-1]), and so on.

Since YUV data is RAW you can manipulate this way.

Best regards,

-- 
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain
--
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

PCTV 520e on Linux

[Claus Olesen]

I'm looking for a USB stick for DVB-C on Linux,
have good experience with the PCTV nanoStick T2 290e for DVB-T on
Linux (except for the replug issue)
http://www.pctvsystems.com/Products/ProductsEuropeAsia/Digitalproducts/PCTVnanoStickT2/tabid/248/language/en-GB/Default.aspx
and wonder if anyone know the status of support, if any, of the PCTV
QuatroStick nano 520e for DVB-C on Linux?
http://www.pctvsystems.com/Products/ProductsEuropeAsia/Hybridproducts/PCTVQuatroSticknano/tabid/254/language/en-GB/Default.aspx
--
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 0/3] omap3isp: add BT656 support

[Javier Martinez Canillas]

On Tue, Oct 11, 2011 at 5:08 PM, Enrico Butera  wrote:
> This patch series add support for BT656 to omap3isp. It is based
> on patches from Deepthy Ravi and Javier Martinez Canillas.
>
> To be applied on top of omap3isp-omap3isp-yuv branch at:
>
> git.linuxtv.org/pinchartl/media.git
>
> Enrico Butera (2):
>  omap3isp: ispvideo: export isp_video_mbus_to_pix
>  omap3isp: ispccdc: configure CCDC registers and add BT656 support
>
> Javier Martinez Canillas (1):
>  omap3isp: ccdc: Add interlaced field mode to platform data
>
>  drivers/media/video/omap3isp/ispccdc.c  |  143 
> ++-
>  drivers/media/video/omap3isp/ispccdc.h  |    1 +
>  drivers/media/video/omap3isp/ispreg.h   |    1 +
>  drivers/media/video/omap3isp/ispvideo.c |    2 +-
>  drivers/media/video/omap3isp/ispvideo.h |    4 +-
>  include/media/omap3isp.h                |    3 +
>  6 files changed, 129 insertions(+), 25 deletions(-)
>
> --
> 1.7.4.1
>

Hello Laurent, Sakari and Deepthy,

Did you take a look at Enrico's patches?

We (Enrico, Gary and me) really want to add support both for
interlaced mode and BT.656 video data format to the ISP driver.

We are putting a lot of effort to this task but need the help of
someone who knows better than use the ISP internals. So, we will be
very happy if you can help us with this. We will address any issue you
find with the patches.

Right know we can get video in YUV format (CCDC BT.656 decoding and
deinterlacing is already working) from the CCDC ouput pad
(/dev/video2) but we have some ghosting effect and don't know what is
causing this nor how to fix.

Thank a lot and best regards,

-- 
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain
--
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: OMAP3 ISP ghosting

[Gary Thomas]

On 2011-10-13 07:47, Javier Martinez Canillas wrote:

On Thu, Oct 13, 2011 at 2:52 PM, Gary Thomas  wrote:

On 2011-10-13 06:32, Enrico wrote:


On Thu, Oct 13, 2011 at 1:44 PM, Gary Thomaswrote:


On 2011-10-13 02:42, Enrico wrote:


On Wed, Oct 12, 2011 at 11:42 PM, Gary Thomas
  wrote:


Any ideas on this?  My naive attempt (diffs attached) just hangs up.
These changes disable BT-656 mode in the CCDC and tell the TVP5150
to output raw YUV 4:2:2 data including all SYNC signals.


I tried that too, you will need to change many of the is_bt656 into
is_fldmode. For isp configuration it seems that the only difference
between the two is (more or less) just the REC656 register. I made a
hundred attempts and in the end i had a quite working capture (just
not centered) but ghosting always there.

I made another test and by luck i got a strange thing, look at the
following image:

http://postimage.org/image/2d610pjk4/

(It's noisy because of a hardware problem)

I made it with these changes:

//ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 1);
ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 1);
//ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 1);
ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 1);

So you have an image with a field with no offset, and a field with
offsets.

Now if you look between my thumb and my forefinger behind them there's
a monoscope picture and in one field you can see 2 black squares, in
the other one you can see 3 black squares. So the two field that will
be composing a single image differ very much.

Now the questions are: is this expected to happen on an analogue video
source and we can't do anything (apart from software deinterlacing)?
is this a problem with tvp5150? Is this a problem with the isp?


Yes, there does seem to be significant movement/differences between these
two images.  Are you saying that these should be the two halves of one
frame
that would be stitched together by de-interlacing?  Perhaps the halves
are
out of sync and the bottom one of this image really goes with the top of
the next (frame13)?


They are two fields that normally will be "merged" into a frame, but
with those settings i made the isp "expand" (SDOFST) just one of the
fields.

One possible thing is that, as you say, "the bottom one of this image
really goes with the top of the next".

But one thing to consider is that it is normal for interlaced video to
have such "effects", that's why progressive scan was invented.



The ghosting problem is still evident, even in this split image.  Notice
that every other scan line is really poor - basically junk.  When this
gets
merged as part of the de-interlace, the ghosts appear.


I don't think so. The bottom part is "expanded" by the isp, so it's ok
to have green half lines, that's where the top part will go if it is
"expanded" by the isp.

Looking at the single images (top and bottom) i don't see ghosting
artifacts (not only in that image but in a sequence of 16 frames),
just a little blurry in moving parts but that's expected in an
interlaced video. So it seems to me that the images arrive correctly
at the isp and the deinterlacing causes ghosting.




Hello,

Yes, I noticed that the images arrive correctly but disabling the
interlaced mode fldmode == 0 and not setting an offset to copy the
odd/even fields

ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENEVEN, 0);
ccdc_config_outlineoffset(ccdc, pix.bytesperline, EVENODD, 0);
ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDEVEN, 0);
ccdc_config_outlineoffset(ccdc, pix.bytesperline, ODDODD, 0);

If you do so, you will see a image that is composed of both odd and
even frames each of them half the size of the deinterlaced image. So
the TVP is producing the correct YUV data and also the ISP is decoding
correctly using the BT.656 embedded sync info.


I tried these changes and what I get is the top of each frame looks quite
good, but the bottom is always blank.  Have a look at
  http://www.mlbassoc.com/misc/test-static.mp4
  http://www.mlbassoc.com/misc/test-movement.mp4

Any ideas about how to get the other 1/2 of the frames?

The one thing I see is that in the 'test-movement' file, there doesn't seem
to be any ghosting (or tearing) even though this is from a pretty low quality
camera.  I'm hopeful that I can get the remainder of the data and attempt
the software interlace and come up with really good image.



My guess is that has to do with the buffers. I guess there are two
ways to probe this.

1- Hack yavta to memset to 0 every buffer before passing to V4L2 layer.


Is there any way to prove this by doing the de-interlacing in software?


2- Deinterlace by software.

As I said before deactivate the interlaced mode and get the two
frames, then you can copy 1440 bytes (one line) from the first
sub-frame (lines[0]) and then copy one line of the second sub-frame
(lines[height/2-1]), and so on.

Since YUV data is RAW you can manipulate this way.

Best r

Re: PCTV 520e on Linux

[Devin Heitmueller]

On Thu, Oct 13, 2011 at 10:49 AM, Claus Olesen  wrote:
> I'm looking for a USB stick for DVB-C on Linux,
> have good experience with the PCTV nanoStick T2 290e for DVB-T on
> Linux (except for the replug issue)

I believe the replug issue is probably fixed if you're using the
current media_build tree.

> http://www.pctvsystems.com/Products/ProductsEuropeAsia/Digitalproducts/PCTVnanoStickT2/tabid/248/language/en-GB/Default.aspx
> and wonder if anyone know the status of support, if any, of the PCTV
> QuatroStick nano 520e for DVB-C on Linux?
> http://www.pctvsystems.com/Products/ProductsEuropeAsia/Hybridproducts/PCTVQuatroSticknano/tabid/254/language/en-GB/Default.aspx

No support currently.  I have the stick, but haven't had any time to work on it.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
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: PCTV 520e on Linux

[Antti Palosaari]

On 10/13/2011 06:57 PM, Devin Heitmueller wrote:

and wonder if anyone know the status of support, if any, of the PCTV
QuatroStick nano 520e for DVB-C on Linux?
http://www.pctvsystems.com/Products/ProductsEuropeAsia/Hybridproducts/PCTVQuatroSticknano/tabid/254/language/en-GB/Default.aspx


No support currently.  I have the stick, but haven't had any time to work on it.


Is that EM28xx + DRX-K + TDA18217 ? And analog parts...

regards
Antti

--
http://palosaari.fi/
--
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: PCTV 520e on Linux

[Devin Heitmueller]

On Thu, Oct 13, 2011 at 12:07 PM, Antti Palosaari  wrote:
>> No support currently.  I have the stick, but haven't had any time to work
>> on it.
>
> Is that EM28xx + DRX-K + TDA18217 ? And analog parts...

You were close:  em2884, drx-k, xc5000, and for analog it uses the afv4910b.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
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: PCTV 520e on Linux

[Antti Palosaari]

On 10/13/2011 07:15 PM, Devin Heitmueller wrote:

On Thu, Oct 13, 2011 at 12:07 PM, Antti Palosaari  wrote:

No support currently.  I have the stick, but haven't had any time to work
on it.


Is that EM28xx + DRX-K + TDA18217 ? And analog parts...


You were close:  em2884, drx-k, xc5000, and for analog it uses the afv4910b.


Then it should be peace of cake at least for digital side.


Antti
--
http://palosaari.fi/
--
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: recent cx23385?

[James]

On 10/13/11 08:48, Devin Heitmueller wrote:

On Thu, Oct 13, 2011 at 1:59 AM, James  wrote:

Is there a newer cx23385 driver than the one in kernel-3.0.4?
I bought ahttp://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1250  and it
shows video for about 5 seconds and then locks up the system.

You cannot install individual drivers (Linux doesn't work like Windows
in this regards).  You have to either install the latest kernel or you
can swap out the whole media subsystem with a later version.

http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers

Devin

Where do I see the date/version of the media subsystem?

It is not video related, w_scan works sometimes but freezes the kernel 
sometimes.

This is booting right to a console.
Is there a program to do a stress test on the hardware and print lots of 
messages as it's working?



$ modinfo cx23885
filename:   
/lib/modules/3.0.4/kernel/drivers/media/video/cx23885/cx23885.ko

license:GPL
author: Steven Toth 
description:v4l2 driver module for cx23885 based TV cards
license:GPL
author: Steven Toth 
description:Driver for cx23885 based TV cards
alias:  pci:v14F1d8880sv*sd*bc*sc*i*
alias:  pci:v14F1d8852sv*sd*bc*sc*i*
depends:
videobuf-core,videobuf-dma-sg,stv0367,lnbp21,cx2341x,tveeprom,lgdt330x,videobuf-dvb,stv0900,zl10353,mt2131,ds3000,dib7000p,btcx-risc,tda10048,cx24116,s5h1411,s5h1409,stv6110

vermagic:   3.0.4 SMP mod_unload
parm:   ci_dbg:Enable CI debugging (int)
parm:   ci_irq_enable:Enable IRQ from CAM (int)
parm:   ir_888_debug:enable debug messages [CX23888 IR 
controller] (int)

parm:   mpegbufs:number of mpeg buffers, range 2-32 (int)
parm:   mpeglines:number of lines in an MPEG buffer, range 2-32 
(int)
parm:   mpeglinesize:number of bytes in each line of an MPEG 
buffer, range 512-1024 (int)

parm:   v4l_debug:enable V4L debug messages (int)
parm:   alt_tuner:Enable alternate tuner configuration (int)
parm:   adapter_nr:DVB adapter numbers (array of short)
parm:   i2c_debug:enable debug messages [i2c] (int)
parm:   i2c_scan:scan i2c bus at insmod time (int)
parm:   debug:enable debug messages (int)
parm:   card:card type (array of int)
parm:   vbibufs:number of vbi buffers, range 2-32 (int)
parm:   vbi_debug:enable debug messages [vbi] (int)
parm:   video_nr:video device numbers (array of int)
parm:   vbi_nr:vbi device numbers (array of int)
parm:   radio_nr:radio device numbers (array of int)
parm:   video_debug:enable debug messages [video] (int)
parm:   irq_debug:enable debug messages [IRQ handler] (int)
parm:   vid_limit:capture memory limit in megabytes (int)
parm:   enable_885_ir:Enable integrated IR controller for supported
CX2388[57] boards that are wired for it:
HVR-1250 (reported safe)
TeVii S470 (reported unsafe)
This can cause an interrupt storm with some cards.
Default: 0 [Disabled] (int)

I did:
http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
/bin/sh: /sbin/lsmod: No such file or directory
Lot's of pr_fmt redefined errors.

I put the build log at: lockie.ca/test/v4l_build.txt.bz2

Something is not right though. :-(
$ modprobe cx23885
WARNING: Deprecated config file /etc/modprobe.conf, all config files 
belong into /etc/modprobe.d/.
WARNING: Error inserting altera_ci 
(/lib/modules/3.0.4/kernel/drivers/media/video/cx23885/altera-ci.ko): 
Invalid module format
WARNING: Error inserting media 
(/lib/modules/3.0.4/kernel/drivers/media/media.ko): Invalid module format
WARNING: Error inserting videodev 
(/lib/modules/3.0.4/kernel/drivers/media/video/videodev.ko): Invalid 
module format
WARNING: Error inserting v4l2_common 
(/lib/modules/3.0.4/kernel/drivers/media/video/v4l2-common.ko): Invalid 
module format
WARNING: Error inserting videobuf_core 
(/lib/modules/3.0.4/kernel/drivers/media/video/videobuf-core.ko): 
Invalid module format
WARNING: Error inserting videobuf_dvb 
(/lib/modules/3.0.4/kernel/drivers/media/video/videobuf-dvb.ko): Invalid 
module format
WARNING: Error inserting videobuf_dma_sg 
(/lib/modules/3.0.4/kernel/drivers/media/video/videobuf-dma-sg.ko): 
Invalid module format
WARNING: Error inserting cx2341x 
(/lib/modules/3.0.4/kernel/drivers/media/video/cx2341x.ko): Invalid 
module format
WARNING: Error inserting altera_stapl 
(/lib/modules/3.0.4/kernel/drivers/linux/drivers/misc/altera-stapl/altera-stapl.ko): 
Invalid module format
WARNING: Error inserting rc_core 
(/lib/modules/3.0.4/kernel/drivers/media/rc/rc-core.ko): Invalid module 
format
FATAL: Error inserting cx23885 
(/lib/modules/3.0.4/kernel/drivers/media/video/cx23885/cx23885.ko): 
Invalid module format


--
To unsubsc

Re: recent cx23385?

[James]

On 10/13/11 12:31, James wrote:

On 10/13/11 08:48, Devin Heitmueller wrote:

On Thu, Oct 13, 2011 at 1:59 AM, James  wrote:

Is there a newer cx23385 driver than the one in kernel-3.0.4?
I bought 
ahttp://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1250  and it

shows video for about 5 seconds and then locks up the system.

You cannot install individual drivers (Linux doesn't work like Windows
in this regards).  You have to either install the latest kernel or you
can swap out the whole media subsystem with a later version.

http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers 



Devin

Where do I see the date/version of the media subsystem?

It is not video related, w_scan works sometimes but freezes the kernel 
sometimes.

This is booting right to a console.
Is there a program to do a stress test on the hardware and print lots 
of messages as it's working?



$ modinfo cx23885
filename:   
/lib/modules/3.0.4/kernel/drivers/media/video/cx23885/cx23885.ko

license:GPL
author: Steven Toth 
description:v4l2 driver module for cx23885 based TV cards
license:GPL
author: Steven Toth 
description:Driver for cx23885 based TV cards
alias:  pci:v14F1d8880sv*sd*bc*sc*i*
alias:  pci:v14F1d8852sv*sd*bc*sc*i*
depends:
videobuf-core,videobuf-dma-sg,stv0367,lnbp21,cx2341x,tveeprom,lgdt330x,videobuf-dvb,stv0900,zl10353,mt2131,ds3000,dib7000p,btcx-risc,tda10048,cx24116,s5h1411,s5h1409,stv6110

vermagic:   3.0.4 SMP mod_unload
parm:   ci_dbg:Enable CI debugging (int)
parm:   ci_irq_enable:Enable IRQ from CAM (int)
parm:   ir_888_debug:enable debug messages [CX23888 IR 
controller] (int)

parm:   mpegbufs:number of mpeg buffers, range 2-32 (int)
parm:   mpeglines:number of lines in an MPEG buffer, range 
2-32 (int)
parm:   mpeglinesize:number of bytes in each line of an MPEG 
buffer, range 512-1024 (int)

parm:   v4l_debug:enable V4L debug messages (int)
parm:   alt_tuner:Enable alternate tuner configuration (int)
parm:   adapter_nr:DVB adapter numbers (array of short)
parm:   i2c_debug:enable debug messages [i2c] (int)
parm:   i2c_scan:scan i2c bus at insmod time (int)
parm:   debug:enable debug messages (int)
parm:   card:card type (array of int)
parm:   vbibufs:number of vbi buffers, range 2-32 (int)
parm:   vbi_debug:enable debug messages [vbi] (int)
parm:   video_nr:video device numbers (array of int)
parm:   vbi_nr:vbi device numbers (array of int)
parm:   radio_nr:radio device numbers (array of int)
parm:   video_debug:enable debug messages [video] (int)
parm:   irq_debug:enable debug messages [IRQ handler] (int)
parm:   vid_limit:capture memory limit in megabytes (int)
parm:   enable_885_ir:Enable integrated IR controller for 
supported

CX2388[57] boards that are wired for it:
HVR-1250 (reported safe)
TeVii S470 (reported unsafe)
This can cause an interrupt storm with some cards.
Default: 0 [Disabled] (int)

I did:
http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers 


/bin/sh: /sbin/lsmod: No such file or directory
Lot's of pr_fmt redefined errors.

I put the build log at: lockie.ca/test/v4l_build.txt.bz2

Something is not right though. :-(
$ modprobe cx23885
WARNING: Deprecated config file /etc/modprobe.conf, all config files 
belong into /etc/modprobe.d/.
WARNING: Error inserting altera_ci 
(/lib/modules/3.0.4/kernel/drivers/media/video/cx23885/altera-ci.ko): 
Invalid module format
WARNING: Error inserting media 
(/lib/modules/3.0.4/kernel/drivers/media/media.ko): Invalid module format
WARNING: Error inserting videodev 
(/lib/modules/3.0.4/kernel/drivers/media/video/videodev.ko): Invalid 
module format
WARNING: Error inserting v4l2_common 
(/lib/modules/3.0.4/kernel/drivers/media/video/v4l2-common.ko): 
Invalid module format
WARNING: Error inserting videobuf_core 
(/lib/modules/3.0.4/kernel/drivers/media/video/videobuf-core.ko): 
Invalid module format
WARNING: Error inserting videobuf_dvb 
(/lib/modules/3.0.4/kernel/drivers/media/video/videobuf-dvb.ko): 
Invalid module format
WARNING: Error inserting videobuf_dma_sg 
(/lib/modules/3.0.4/kernel/drivers/media/video/videobuf-dma-sg.ko): 
Invalid module format
WARNING: Error inserting cx2341x 
(/lib/modules/3.0.4/kernel/drivers/media/video/cx2341x.ko): Invalid 
module format
WARNING: Error inserting altera_stapl 
(/lib/modules/3.0.4/kernel/drivers/linux/drivers/misc/altera-stapl/altera-stapl.ko): 
Invalid module format
WARNING: Error inserting rc_core 
(/lib/modules/3.0.4/kernel/drivers/media/rc/rc-core.ko): Invalid 
module format
FATAL: Error inserting cx23885 
(/lib/modules/3.0.4/kernel/drivers/media/video/cx23885/cx23885.

cron job: media_tree daily build: WARNINGS

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:Thu Oct 13 19:00:19 CEST 2011
git hash:e30528854797f057aa6ffb6dc9f890e923c467fd
gcc version:  i686-linux-gcc (GCC) 4.6.1
host hardware:x86_64
host os:  3.0-4.slh.7-amd64

linux-git-armv5: WARNINGS
linux-git-armv5-davinci: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-armv5-omap2: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: WARNINGS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-i686: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.39.1-i686: WARNINGS
linux-3.0-i686: WARNINGS
linux-3.1-rc1-i686: WARNINGS
linux-2.6.31.12-x86_64: WARNINGS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: WARNINGS
linux-3.0-x86_64: WARNINGS
linux-3.1-rc1-x86_64: WARNINGS
spec-git: WARNINGS
sparse: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2

The V4L-DVB specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
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: PCTV 520e on Linux

[Devin Heitmueller]

On Thu, Oct 13, 2011 at 12:19 PM, Antti Palosaari  wrote:
>> You were close:  em2884, drx-k, xc5000, and for analog it uses the
>> afv4910b.
>
> Then it should be peace of cake at least for digital side.

I don't think we've ever done xc5000 on an em28xx before, so it's
entirely possible that the xc5000 clock stretching will expose bugs in
the em28xx i2c implementation (it uncovered bugs in essentially every
other bridge driver I did work on).

That, and we don't know how much is hard-coded into the drx-k driver
making it specific to the couple of device it's currently being used
with.

But yeah, it shouldn't be rocket science.  I added support for the
board in my OSX driver and it only took me a couple of hours.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
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: recent cx23385?

[Devin Heitmueller]

On Thu, Oct 13, 2011 at 12:31 PM, James  wrote:
> Where do I see the date/version of the media subsystem?

You can't.  The media_build stuff is just a script which backports
part of the latest kernel tree and applies some patches to make it
work with older kernels.  There is no real "version" for it.

> It is not video related, w_scan works sometimes but freezes the kernel
> sometimes.
> This is booting right to a console.
> Is there a program to do a stress test on the hardware and print lots of
> messages as it's working?

Not really, you can add the debug=1 modprobe option, but in reality
you probably need to get to the bottom of what is causing the hardware
lockup.

> I did:
> http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
> /bin/sh: /sbin/lsmod: No such file or directory
> Lot's of pr_fmt redefined errors.

lsmod is required.  Go install whatever package provides it.

> I put the build log at: lockie.ca/test/v4l_build.txt.bz2
>
> Something is not right though. :-(
> $ modprobe cx23885
> WARNING: Deprecated config file /etc/modprobe.conf, all config files belong
> into /etc/modprobe.d/.
> WARNING: Error inserting altera_ci
> (/lib/modules/3.0.4/kernel/drivers/media/video/cx23885/altera-ci.ko):
> Invalid module format
> WARNING: Error inserting media
> (/lib/modules/3.0.4/kernel/drivers/media/media.ko): Invalid module format
> WARNING: Error inserting videodev
> (/lib/modules/3.0.4/kernel/drivers/media/video/videodev.ko): Invalid module
> format
> WARNING: Error inserting v4l2_common
> (/lib/modules/3.0.4/kernel/drivers/media/video/v4l2-common.ko): Invalid
> module format
> WARNING: Error inserting videobuf_core
> (/lib/modules/3.0.4/kernel/drivers/media/video/videobuf-core.ko): Invalid
> module format
> WARNING: Error inserting videobuf_dvb
> (/lib/modules/3.0.4/kernel/drivers/media/video/videobuf-dvb.ko): Invalid
> module format
> WARNING: Error inserting videobuf_dma_sg
> (/lib/modules/3.0.4/kernel/drivers/media/video/videobuf-dma-sg.ko): Invalid
> module format
> WARNING: Error inserting cx2341x
> (/lib/modules/3.0.4/kernel/drivers/media/video/cx2341x.ko): Invalid module
> format
> WARNING: Error inserting altera_stapl
> (/lib/modules/3.0.4/kernel/drivers/linux/drivers/misc/altera-stapl/altera-stapl.ko):
> Invalid module format
> WARNING: Error inserting rc_core
> (/lib/modules/3.0.4/kernel/drivers/media/rc/rc-core.ko): Invalid module
> format
> FATAL: Error inserting cx23885
> (/lib/modules/3.0.4/kernel/drivers/media/video/cx23885/cx23885.ko): Invalid
> module format

Your build is screwed up.  Would recommend you do a "make clean" and
then "make && make install".  Then reboot.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
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: recent cx23385?

[James]

On 10/13/11 12:38, James wrote:

On 10/13/11 12:31, James wrote:

On 10/13/11 08:48, Devin Heitmueller wrote:

On Thu, Oct 13, 2011 at 1:59 AM, James  wrote:

Is there a newer cx23385 driver than the one in kernel-3.0.4?
I bought 
ahttp://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1250  and it

shows video for about 5 seconds and then locks up the system.

You cannot install individual drivers (Linux doesn't work like Windows
in this regards).  You have to either install the latest kernel or you
can swap out the whole media subsystem with a later version.

http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers 



Devin

Where do I see the date/version of the media subsystem?

It is not video related, w_scan works sometimes but freezes the 
kernel sometimes.

This is booting right to a console.
Is there a program to do a stress test on the hardware and print lots 
of messages as it's working?



$ modinfo cx23885
filename:   
/lib/modules/3.0.4/kernel/drivers/media/video/cx23885/cx23885.ko

license:GPL
author: Steven Toth 
description:v4l2 driver module for cx23885 based TV cards
license:GPL
author: Steven Toth 
description:Driver for cx23885 based TV cards
alias:  pci:v14F1d8880sv*sd*bc*sc*i*
alias:  pci:v14F1d8852sv*sd*bc*sc*i*
depends:
videobuf-core,videobuf-dma-sg,stv0367,lnbp21,cx2341x,tveeprom,lgdt330x,videobuf-dvb,stv0900,zl10353,mt2131,ds3000,dib7000p,btcx-risc,tda10048,cx24116,s5h1411,s5h1409,stv6110

vermagic:   3.0.4 SMP mod_unload
parm:   ci_dbg:Enable CI debugging (int)
parm:   ci_irq_enable:Enable IRQ from CAM (int)
parm:   ir_888_debug:enable debug messages [CX23888 IR 
controller] (int)

parm:   mpegbufs:number of mpeg buffers, range 2-32 (int)
parm:   mpeglines:number of lines in an MPEG buffer, range 
2-32 (int)
parm:   mpeglinesize:number of bytes in each line of an MPEG 
buffer, range 512-1024 (int)

parm:   v4l_debug:enable V4L debug messages (int)
parm:   alt_tuner:Enable alternate tuner configuration (int)
parm:   adapter_nr:DVB adapter numbers (array of short)
parm:   i2c_debug:enable debug messages [i2c] (int)
parm:   i2c_scan:scan i2c bus at insmod time (int)
parm:   debug:enable debug messages (int)
parm:   card:card type (array of int)
parm:   vbibufs:number of vbi buffers, range 2-32 (int)
parm:   vbi_debug:enable debug messages [vbi] (int)
parm:   video_nr:video device numbers (array of int)
parm:   vbi_nr:vbi device numbers (array of int)
parm:   radio_nr:radio device numbers (array of int)
parm:   video_debug:enable debug messages [video] (int)
parm:   irq_debug:enable debug messages [IRQ handler] (int)
parm:   vid_limit:capture memory limit in megabytes (int)
parm:   enable_885_ir:Enable integrated IR controller for 
supported

CX2388[57] boards that are wired for it:
HVR-1250 (reported safe)
TeVii S470 (reported unsafe)
This can cause an interrupt storm with some cards.
Default: 0 [Disabled] (int)

I did:
http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers 


/bin/sh: /sbin/lsmod: No such file or directory
Lot's of pr_fmt redefined errors.

I put the build log at: lockie.ca/test/v4l_build.txt.bz2

Something is not right though. :-(
$ modprobe cx23885
WARNING: Deprecated config file /etc/modprobe.conf, all config files 
belong into /etc/modprobe.d/.
WARNING: Error inserting altera_ci 
(/lib/modules/3.0.4/kernel/drivers/media/video/cx23885/altera-ci.ko): 
Invalid module format
WARNING: Error inserting media 
(/lib/modules/3.0.4/kernel/drivers/media/media.ko): Invalid module 
format
WARNING: Error inserting videodev 
(/lib/modules/3.0.4/kernel/drivers/media/video/videodev.ko): Invalid 
module format
WARNING: Error inserting v4l2_common 
(/lib/modules/3.0.4/kernel/drivers/media/video/v4l2-common.ko): 
Invalid module format
WARNING: Error inserting videobuf_core 
(/lib/modules/3.0.4/kernel/drivers/media/video/videobuf-core.ko): 
Invalid module format
WARNING: Error inserting videobuf_dvb 
(/lib/modules/3.0.4/kernel/drivers/media/video/videobuf-dvb.ko): 
Invalid module format
WARNING: Error inserting videobuf_dma_sg 
(/lib/modules/3.0.4/kernel/drivers/media/video/videobuf-dma-sg.ko): 
Invalid module format
WARNING: Error inserting cx2341x 
(/lib/modules/3.0.4/kernel/drivers/media/video/cx2341x.ko): Invalid 
module format
WARNING: Error inserting altera_stapl 
(/lib/modules/3.0.4/kernel/drivers/linux/drivers/misc/altera-stapl/altera-stapl.ko): 
Invalid module format
WARNING: Error inserting rc_core 
(/lib/modules/3.0.4/kernel/drivers/media/rc/rc-core.ko): Invalid 
module format
FATAL: Error inserting cx23885 
(/lib/modules/3.0.4/kernel/dr

/bin/lsmod

[James]

On 10/13/11 13:52, Devin Heitmueller wrote:

I did:
http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
/bin/sh: /sbin/lsmod: No such file or directory

lsmod is required.  Go install whatever package provides it.

I have it, Gentoo puts it at /bin/lsmod


--
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

help with azap

[James]

$ more channels.conf
CIII-HD:8500:8VSB:49:52+53:1
OTTAWA CBOFT-DT:18900:8VSB:49:53+52:3
CJOH:21300:8VSB:49:51+52:1
TVO:53300:8VSB:49:52+53:1
OTTAWA  CBOT-DT:53900:8VSB:49:52+53:3
Télé-Québec_HD:56900:8VSB:49:52+53:3
CHOT:62900:8VSB:49:52:3

$ azap -c channels.conf "CJOH"
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
ERROR: error while parsing Audio PID (not a number)

$ tzap -c channels.conf "CJOH"
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file 'channels.conf'
ERROR: error while parsing inversion (syntax error)

Why does tzap show what file it is reading the channel list from but 
azap doesn't?


What does "ERROR: error while parsing Audio PID (not a number)" mean?
--
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: help with azap

[Devin Heitmueller]

On Thu, Oct 13, 2011 at 2:14 PM, James  wrote:
> $ more channels.conf
> CIII-HD:8500:8VSB:49:52+53:1
> OTTAWA CBOFT-DT:18900:8VSB:49:53+52:3
> CJOH:21300:8VSB:49:51+52:1
> TVO    :53300:8VSB:49:52+53:1
> OTTAWA  CBOT-DT:53900:8VSB:49:52+53:3
> Télé-Québec_HD:56900:8VSB:49:52+53:3
> CHOT:62900:8VSB:49:52:3
>
> $ azap -c channels.conf "CJOH"
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> ERROR: error while parsing Audio PID (not a number)
>
> $ tzap -c channels.conf "CJOH"
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> reading channels from file 'channels.conf'
> ERROR: error while parsing inversion (syntax error)
>
> Why does tzap show what file it is reading the channel list from but azap
> doesn't?

If I recall, tzap and azap are actually from different codebases
(although I believe one was originally derived from the other).  That
is why the output is a little inconsistent.

That said, you should not be using tzap for ATSC/ClearQAM.  tzap is for DVB-T.

> What does "ERROR: error while parsing Audio PID (not a number)" mean?

I don't know where your channels.conf came from, but it appears to be
malformed.  You cannot have "52+53" as the audio PID.  If you just
want to get up and running, remove the "+53" part.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
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: PCTV 520e on Linux

[Benjamin Larsson]

On 10/13/2011 07:48 PM, Devin Heitmueller wrote:
> On Thu, Oct 13, 2011 at 12:19 PM, Antti Palosaari  wrote:
>>> You were close:  em2884, drx-k, xc5000, and for analog it uses the
>>> afv4910b.
>> Then it should be peace of cake at least for digital side.
> I don't think we've ever done xc5000 on an em28xx before, so it's
> entirely possible that the xc5000 clock stretching will expose bugs in
> the em28xx i2c implementation (it uncovered bugs in essentially every
> other bridge driver I did work on).
>
> That, and we don't know how much is hard-coded into the drx-k driver
> making it specific to the couple of device it's currently being used
> with.
>
> But yeah, it shouldn't be rocket science.  I added support for the
> board in my OSX driver and it only took me a couple of hours.
>
> Devin
>

Eddi De Pieri has patches for the HVR-930C that works somewhat. The
hardware in that stick is the same.

MvH
Benjamin Larsson
--
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: PCTV 520e on Linux

[Devin Heitmueller]

On Thu, Oct 13, 2011 at 7:06 PM, Benjamin Larsson  wrote:
> On 10/13/2011 07:48 PM, Devin Heitmueller wrote:
>> On Thu, Oct 13, 2011 at 12:19 PM, Antti Palosaari  wrote:
 You were close:  em2884, drx-k, xc5000, and for analog it uses the
 afv4910b.
>>> Then it should be peace of cake at least for digital side.
>> I don't think we've ever done xc5000 on an em28xx before, so it's
>> entirely possible that the xc5000 clock stretching will expose bugs in
>> the em28xx i2c implementation (it uncovered bugs in essentially every
>> other bridge driver I did work on).
>>
>> That, and we don't know how much is hard-coded into the drx-k driver
>> making it specific to the couple of device it's currently being used
>> with.
>>
>> But yeah, it shouldn't be rocket science.  I added support for the
>> board in my OSX driver and it only took me a couple of hours.
>>
>> Devin
>>
>
> Eddi De Pieri has patches for the HVR-930C that works somewhat. The
> hardware in that stick is the same.
>
> MvH
> Benjamin Larsson

While the basic chips used are different, they are completely
different hardware designs and likely have different GPIO
configurations as well as IF specs.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
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: help with azap

[James]

On 10/13/11 14:30, Devin Heitmueller wrote:

On Thu, Oct 13, 2011 at 2:14 PM, James  wrote:

$ more channels.conf
CIII-HD:8500:8VSB:49:52+53:1
OTTAWA CBOFT-DT:18900:8VSB:49:53+52:3
CJOH:21300:8VSB:49:51+52:1
TVO:53300:8VSB:49:52+53:1
OTTAWA  CBOT-DT:53900:8VSB:49:52+53:3
Télé-Québec_HD:56900:8VSB:49:52+53:3
CHOT:62900:8VSB:49:52:3



What does "ERROR: error while parsing Audio PID (not a number)" mean?

I don't know where your channels.conf came from, but it appears to be
malformed.  You cannot have "52+53" as the audio PID.  If you just
want to get up and running, remove the "+53" part.

Devin


I used:
w_scan -f a -c US -M
(mplayer format)

I redid it with:
w_scan -f a -c US -X
(czap/tzap/szap/xine)
and got:
CIII-HD:8500:8VSB:49:52:1
OTTAWA CBOFT-DT:18900:8VSB:49:53:3
CJOH:21300:8VSB:49:51:1
TVO:53300:8VSB:49:52:1
OTTAWA  CBOT-DT:53900:8VSB:49:52:3
Télé-Québec_HD:56900:8VSB:49:52:3
CHOT:62900:8VSB:49:52:3

It is weird there is not a standard format. :-)

--
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

freeze/crash

[James]

I have this: http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1250
I have kernel-3.0.4 and the daily media tree from 2011-10-13.

CIII-HD:8500:8VSB:49:52:1
OTTAWA CBOFT-DT:18900:8VSB:49:53:3
CJOH:21300:8VSB:49:51:1
TVO:53300:8VSB:49:52:1
OTTAWA  CBOT-DT:53900:8VSB:49:52:3
Télé-Québec_HD:56900:8VSB:49:52:3
CHOT:62900:8VSB:49:52:3

zap -channels channels.conf "CJOH'
Using frontend "Samsung 5H1409 QAM/8VSB Frontend", type ATSC
status | signal 000c | snr 000c | ber  | unc  |
crash

azap -c channels_X.conf "CJOH"
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 21300 Hz
video pid 0x0031 audio pid 0x0033
crash

It always crashes when I access the hardware but the place it crashes is 
random.


It could be the hardware but it is brand new.

--
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

livedvd with cx23885?

[James]

Does anyone know of a distro that has a livedvd with dvb stuff?

--
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

[PATCH] MAINTAINERS: add a maintainer for s5p-mfc driver

[Jeongtae Park]

Add a maintainer for s5p-mfc driver.

Signed-off-by: Jeongtae Park 
Cc: Marek Szyprowski 
Cc: Kamil Debski 
---
 MAINTAINERS |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5e207a8..ef16770 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1087,6 +1087,7 @@ F:drivers/media/video/s5p-fimc/
 ARM/SAMSUNG S5P SERIES Multi Format Codec (MFC) SUPPORT
 M: Kyungmin Park 
 M: Kamil Debski 
+M: Jeongtae Park 
 L: linux-arm-ker...@lists.infradead.org
 L: linux-media@vger.kernel.org
 S: Maintained
-- 
1.7.1

--
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: [Linaro-mm-sig] [PATCH 8/9] ARM: integrate CMA with DMA-mapping subsystem

[Subash Patel]

Hi Marek,

As informed to you in private over IRC, below piece of code broke during 
booting EXYNOS4:SMDKV310 with ZONE_DMA enabled.



On 10/06/2011 07:24 PM, Marek Szyprowski wrote:
...

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index fbdd12e..9c27fbd 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -21,6 +21,7 @@
  #include
  #include
  #include
+#include

  #include
  #include
@@ -371,6 +372,13 @@ void __init arm_memblock_init(struct meminfo *mi, struct 
machine_desc *mdesc)
if (mdesc->reserve)
mdesc->reserve();

+   /* reserve memory for DMA contigouos allocations */
+#ifdef CONFIG_ZONE_DMA
+   dma_contiguous_reserve(PHYS_OFFSET + mdesc->dma_zone_size - 1);
+#else
+   dma_contiguous_reserve(0);
+#endif
+
memblock_analyze();
memblock_dump_all();
  }

Regards,
Subash
--
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