Re: Any saa711x users out there?

Re: Any saa711x users out there?

[Andy Walls]

> I'll try to perform a quick test with my PVR-350 with NTSC and the YUV
> capture device BTW.

OK.  So my test setup:

a. DTV STB tuned to the SuperBowl :)

b. Composite out from the STB feeding my PVR-350/SAA7115 with an NTSC
CVBS input.

c. mplayer capturing raw YUV video from the PVR-350's composite input:
$ mplayer /dev/video32 -demuxer rawvideo -rawvideo w=720:h=480:format=hm12:ntsc


I did this:

# v4l2-dbg -d /dev/video32 -S
host0: cx23415    revision 0x00000000
i2c 0x21: saa7115    revision 0x00000000
i2c 0x40: msp4448g   revision 0x02173043
i2c 0x44: saa7129    revision 0x00000000

# v4l2-dbg -d /dev/video32 -c 0x21 --list-registers=min=0x00,max=0xff
ioctl: VIDIOC_DBG_G_REGISTER

          00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000: 10 48 80 20 90 90 eb e0 68 53 80 44 40 00 07 2e 
00000010: 06 00 9d 80 00 03 11 9c 40 80 77 42 a9 01 81 b1 
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00000030: cd 20 03 00 ce fb 30 00 03 10 00 00 00 00 00 00 
00000040: 20 ff ff ff ff ff ff ff ff dd dd dd dd dd dd dd 
00000050: dd dd dd dd dd ff ff ff 40 47 06 83 00 bd 35 00 
00000060: 00 00 00 00 00 00 a9 00 00 00 00 aa 00 00 00 00 
00000070: 00 00 aa 00 00 00 00 aa 00 00 00 00 00 00 00 00 
00000080: 30 01 00 00 20 21 c5 01 f0 00 00 00 00 00 00 3b 
00000090: 80 48 40 84 01 00 d0 02 05 00 0c 00 a0 05 0c 00 
000000a0: 01 00 00 00 80 40 40 00 00 02 00 00 00 01 00 00 
000000b0: 00 04 00 04 01 00 00 00 00 00 00 00 00 00 00 00 
000000c0: 00 08 00 80 02 00 d0 02 12 00 f8 00 d0 02 f8 00 
000000d0: 01 00 00 00 80 40 40 00 00 04 00 00 00 02 00 00 
000000e0: 00 04 00 04 01 00 00 00 00 00 00 00 00 00 00 00 
000000f0: ad 05 50 46 00 ad 01 4b 00 4b 00 4b 00 00 00 88 

# v4l2-dbg -d /dev/video32 -c 0x21 -g 2
ioctl: VIDIOC_DBG_G_REGISTER
Register 0x00000002 = 80h (128d  10000000b)

# v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0xc0
Register 0x00000002 set to 0xc0

# v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x80
Register 0x00000002 set to 0x80

# v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0xc0
Register 0x00000002 set to 0xc0

# v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x0
Register 0x00000002 set to 0x0

# v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x40
Register 0x00000002 set to 0x40

# v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x00
Register 0x00000002 set to 0x0

# v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x40
Register 0x00000002 set to 0x40

# v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x00
Register 0x00000002 set to 0x0

# v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x40
Register 0x00000002 set to 0x40

# v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x0
Register 0x00000002 set to 0x0

# v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x80
Register 0x00000002 set to 0x80

# v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x40
Register 0x00000002 set to 0x40

# v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x80
Register 0x00000002 set to 0x80

# v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0xc0
Register 0x00000002 set to 0xc0

# v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x40
Register 0x00000002 set to 0x40

# v4l2-dbg -d /dev/video32 -c 0x21 -s 2 0x80
Register 0x00000002 set to 0x80


My observations:

1. With the amplifier on and anti-alias filter off things looked fine.
2. With the amplifier on and anti-alias filter on things looked fine.
3. With the amplifier off and anti-alias filter off things looked fine.
4. With the amplifier off and anti-alias filter on the screen washed brighter/whiter.

I guess the anti-alias filter peaks the luma a little or attenuates the color a little.
The amplifier and AGC is probably essential when using the anti-alias filter.

Regards,
Andy

Re: Any saa711x users out there?

[Devin Heitmueller]

Hi Andy,

Thanks for taking the time to do some testing in your environment.

On Sun, Feb 7, 2010 at 7:10 PM, Andy Walls <awalls@radix.net> wrote:
> My observations:
>
> 1. With the amplifier on and anti-alias filter off things looked fine.
> 2. With the amplifier on and anti-alias filter on things looked fine.
> 3. With the amplifier off and anti-alias filter off things looked fine.
> 4. With the amplifier off and anti-alias filter on the screen washed brighter/whiter.
>
> I guess the anti-alias filter peaks the luma a little or attenuates the color a little.
> The amplifier and AGC is probably essential when using the anti-alias filter.

This all looks like good news, suggesting that under most conditions
people won't notice the difference (except in the signal conditions I
saw, in which case they will see a rather significant positive
improvement).  And since we don't let users independently control the
AA filter nor the amplifier, we can be confident that there won't be a
case when the amplifier is on but the AA filter is off.

My vote is to just push the one line change then flipping on the AA
filter in the saa7115_init_misc array of registers (essentially the
patch below):

http://kernellabs.com/hg/~dheitmueller/em28xx-test/rev/42272c1dd883

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Any saa711x users out there?

[Devin Heitmueller]

Hello all,

I am doing some quality improvements for a couple of the
em28xx/saa7113 designs, and I found a pretty serious problem which
appears to have been there for some time.

In fact, the regression was introduced when the saa7115 support was
added in 2005 (hg revision 2750).  This change resulted in the
anti-alias filtering being disabled by default for the saa7113 (the
saa7115_init_misc block clears bit 7 of register 0x02).  Without this
change, vertical lines appear in the chroma on a fixed interval.

The big issue is that the driver is shared with other saa7113
products, as well as products that have the saa7111, saa7114, and
saa7115.  So I have to figure out whether to just force on the AA
filter for the saa7113, or whether it should be enabled for the
others, or whether I can even turn it on for saa7113 in general or
need to hack something in there to only do it for the two or three
products I am testing with.

So here's where I could use some help:  If you have a product that
uses one of the above chips, please speak up.  I will be setting up a
test tree where people can try out the change and see if it makes
their situation better, worse, or no change.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: Any saa711x users out there?

[Mauro Carvalho Chehab]

Devin Heitmueller wrote:
> Hello all,
> 
> I am doing some quality improvements for a couple of the
> em28xx/saa7113 designs, and I found a pretty serious problem which
> appears to have been there for some time.
> 
> In fact, the regression was introduced when the saa7115 support was
> added in 2005 (hg revision 2750).  This change resulted in the
> anti-alias filtering being disabled by default for the saa7113 (the
> saa7115_init_misc block clears bit 7 of register 0x02).  Without this
> change, vertical lines appear in the chroma on a fixed interval.
> 
> The big issue is that the driver is shared with other saa7113
> products, as well as products that have the saa7111, saa7114, and
> saa7115.  So I have to figure out whether to just force on the AA
> filter for the saa7113, or whether it should be enabled for the
> others, or whether I can even turn it on for saa7113 in general or
> need to hack something in there to only do it for the two or three
> products I am testing with.
> 
> So here's where I could use some help:  If you have a product that
> uses one of the above chips, please speak up.  I will be setting up a
> test tree where people can try out the change and see if it makes
> their situation better, worse, or no change.

The better is to allow enabling/disabling the anti-alias via ctrl.
Whatever default is chosen, the driver may adjust the control default
at the board initialization, or even blocking the control when the
other mode of operation is broken.

I have here a few devices with saa7113 and saa7114. I think I have
also one device with saa7111, but I need to check. If I'm right, it will
take some time for me to prepare the saa7111 environment. The saa7113/7114
devices are easier to setup, as they are usb.

-- 

Cheers,
Mauro

Re: Any saa711x users out there?

[Devin Heitmueller]

On Tue, Feb 2, 2010 at 7:29 PM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> The better is to allow enabling/disabling the anti-alias via ctrl.
> Whatever default is chosen, the driver may adjust the control default
> at the board initialization, or even blocking the control when the
> other mode of operation is broken.
>
> I have here a few devices with saa7113 and saa7114. I think I have
> also one device with saa7111, but I need to check. If I'm right, it will
> take some time for me to prepare the saa7111 environment. The saa7113/7114
> devices are easier to setup, as they are usb.

I actually am not very familiar with how custom controls work for v4l
devices in terms of board specific configuration, as I'm more familiar
with the way that you can provide a config struct during dvb_attach()
for DVB devices.  I've obviously seen how they can be set from
userland, but have never dug into the specific as to how a bridge
would set the parameters.

I actually have a test tree here which includes the change (as well as
a couple of unrelated em28xx fixes I'm working on).

http://www.kernellabs.com/hg/~dheitmueller/em28xx-test

The change in that tree just flips on the Anti-alias filter bit in the
saa7115_misc_init struct, so it ends up being applied for
7113/7114/7115.  However, I'm wondering if it makes sense to just have
it on by default for all three boards (which is a *much* simpler
change than adding a custom control and making sure it gets set
properly by the bridge in all the various cases such as surviving a
powerdown/powerup of the chip).

BTW, the tree above just forces the bit on for all three boards - I'm
not proposing that should be the final fix, but it is enough to allow
people to evaluate the effects of the change.

I've got a PVR-350 board with a saa7115 which I will do some testing
on.  If I see the artifacts on that board without the change, that
bolsters the argument that the current default may just be wrong in
general.

Mauro, the hg logs suggest that you added the saa7115 support (and in
fact appear to have introduced the issue in question).  Do you
remember what board you were using when you added the support?  Also,
how did you arrive at the defaults that you used?  Were they based on
some sort of i2c bus trace, or did you just set them by reading the
datasheet?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: Any saa711x users out there?

[Mauro Carvalho Chehab]

Devin Heitmueller wrote:
> On Tue, Feb 2, 2010 at 7:29 PM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> The better is to allow enabling/disabling the anti-alias via ctrl.
>> Whatever default is chosen, the driver may adjust the control default
>> at the board initialization, or even blocking the control when the
>> other mode of operation is broken.
>>
>> I have here a few devices with saa7113 and saa7114. I think I have
>> also one device with saa7111, but I need to check. If I'm right, it will
>> take some time for me to prepare the saa7111 environment. The saa7113/7114
>> devices are easier to setup, as they are usb.
> 
> I actually am not very familiar with how custom controls work for v4l
> devices in terms of board specific configuration, as I'm more familiar
> with the way that you can provide a config struct during dvb_attach()
> for DVB devices.  I've obviously seen how they can be set from
> userland, but have never dug into the specific as to how a bridge
> would set the parameters.

Just call:

v4l2_device_call_all(&dev->v4l2_dev, 0, core, g_ctrl, ctrl);

For get a control, and:

v4l2_device_call_all(&dev->v4l2_dev, 0, core, s_ctrl, ctrl);

to set a control.

> I actually have a test tree here which includes the change (as well as
> a couple of unrelated em28xx fixes I'm working on).
> 
> http://www.kernellabs.com/hg/~dheitmueller/em28xx-test
> 
> The change in that tree just flips on the Anti-alias filter bit in the
> saa7115_misc_init struct, so it ends up being applied for
> 7113/7114/7115.  However, I'm wondering if it makes sense to just have
> it on by default for all three boards (which is a *much* simpler
> change than adding a custom control and making sure it gets set
> properly by the bridge in all the various cases such as surviving a
> powerdown/powerup of the chip).

The chip powerup/powerdown should preserve all controls, anyway. I think
we need a general logic here to save/restore those values on those cases,
including hibernation/suspend. In the past, several of those drivers like
saa711x used to store the register values into a shadow array (although
the old code were ugly and haven't any suspend/resume logic).

Maybe we can resurrect this idea, in order to quickly recover from a 
powerdown/powerup situation. In general, the shadow array will have only
256 bytes on those chips.

> BTW, the tree above just forces the bit on for all three boards - I'm
> not proposing that should be the final fix, but it is enough to allow
> people to evaluate the effects of the change.

I'll test it later.

> I've got a PVR-350 board with a saa7115 which I will do some testing
> on.  If I see the artifacts on that board without the change, that
> bolsters the argument that the current default may just be wrong in
> general.

> 
> Mauro, the hg logs suggest that you added the saa7115 support (and in
> fact appear to have introduced the issue in question).  Do you
> remember what board you were using when you added the support?  Also,
> how did you arrive at the defaults that you used?  Were they based on
> some sort of i2c bus trace, or did you just set them by reading the
> datasheet?

Well, we used to have different drivers on that time. Basically, the code from all
saa711x drivers got merged and the init arrays were added as seen at the original 
driver. Then, fix patches were applied in order to make everybody happy.

A large number of tests were done on that time, as we've got contributions from
several developers. For sure we used some PVR boards, pvrusb2, WinTV USB2 and 
some bttv based boards with saa711x chips. Later, we've got feedback also from 
NT100x boards (usbvision driver) and I suspect we had tests with other drivers as well.
Some Zoran boards also use saa711x chips, and, after the port to V4L2, they're now
using the same driver.

-- 

Cheers,
Mauro

Re: Any saa711x users out there?

[Andy Walls]

On Tue, 2010-02-02 at 17:51 -0500, Devin Heitmueller wrote:
> Hello all,
> 
> I am doing some quality improvements for a couple of the
> em28xx/saa7113 designs, and I found a pretty serious problem which
> appears to have been there for some time.
> 
> In fact, the regression was introduced when the saa7115 support was
> added in 2005 (hg revision 2750).  This change resulted in the
> anti-alias filtering being disabled by default for the saa7113 (the
> saa7115_init_misc block clears bit 7 of register 0x02).  Without this
> change, vertical lines appear in the chroma on a fixed interval.
> 
> The big issue is that the driver is shared with other saa7113
> products, as well as products that have the saa7111, saa7114, and
> saa7115.  So I have to figure out whether to just force on the AA
> filter for the saa7113, or whether it should be enabled for the
> others, or whether I can even turn it on for saa7113 in general or
> need to hack something in there to only do it for the two or three
> products I am testing with.
> 
> So here's where I could use some help:  If you have a product that
> uses one of the above chips, please speak up.  I will be setting up a
> test tree where people can try out the change and see if it makes
> their situation better, worse, or no change.

I have a PVR-350 with an SAA7115 IIRC.  Other ivtv boards have SAA7114
chips.  I don't see any in ivtv-cards.c that have an SAA7113 explcitily
listed.

Whether or not an anti-alias filter is needed is a completely knowable
answer given:

1. The TV norm and hence the Luma and Chroma signal characteristics
2. The A/D sample rate
3. The parameters of any decimations or non-integer resampling being
performed

If you don't undersample, i.e. Fs/2 > single-sided BW of the signal
being sampled, then you don't need an anti alias filter before you
sample, otherwise you do.

The same sort of thing goes for decimation of digital samples.  If the
decimation is going to cause aliases to fold down into the spectrum, you
need a digital LPF before the decimation to band limit the digital
signal.


This should not be a "user control", this should be a configuration
setting that is knowable by the bridge driver and/or the module driving
the SAA7113.


With all that said, if you have a baseband Luma or Chroma signal with
strong spurious high frequency components (crappy source, or you're
overdriving the front end and getting intermods), then keep the
anti-alias filter turned on as the assumption of a bandlimited input
signal is violated in this case.

In the SAA7113 the anti-alias filter introduces a delay of 50 ns.  At
13.5 Mpixels/sec, or 74.1 ns/pixel, that's less than 1 pixel time of
delay.

Just turn it on in and leave it on in the SAA7113 to handle the
unexpected input signal case.

Regards,
Andy


> Devin

Re: Any saa711x users out there?

[Devin Heitmueller]

On Wed, Feb 3, 2010 at 8:51 PM, Andy Walls <awalls@radix.net> wrote:
> With all that said, if you have a baseband Luma or Chroma signal with
> strong spurious high frequency components (crappy source, or you're
> overdriving the front end and getting intermods), then keep the
> anti-alias filter turned on as the assumption of a bandlimited input
> signal is violated in this case.

In this case, I'm seeing it with both the analog signal generator
(which one might consider a fairly pristine source), as well coming
off the s-video output of a DirectTV box (in which case the signal is
being generated only a few feet away from the saa7113).

> In the SAA7113 the anti-alias filter introduces a delay of 50 ns.  At
> 13.5 Mpixels/sec, or 74.1 ns/pixel, that's less than 1 pixel time of
> delay.
>
> Just turn it on in and leave it on in the SAA7113 to handle the
> unexpected input signal case.

This would be my vote (assuming we try it with the other parts and
confirm no regressions are introduced).  My only concern is the way
the code is currently written, the saa7113 initialization block
actually does enable it by default, and then some code for the saa7115
tramples the register, turning it off (see saa7115_init_misc at
saa7115.c:600).  I think the decision we have to make is which of the
following paths to take:

1.  Enable it in the saa7115_init_misc, thereby enabling it for the
7113, 7114, and 7115.

2.  Exclude the saa7115_init_misc block from being run at all against the 7113

3.  Let the saa7115_init_misc block get run, and then flip the bit
back for the 7113.

My thinking at this point is that the AA filter should probably be on
by default regardless of the chip, in which case we would just need to
make the one line change to enable it in the saa7115_init_misc block.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: Any saa711x users out there?

[Andy Walls]

On Thu, 2010-02-04 at 10:24 -0500, Devin Heitmueller wrote:
> On Wed, Feb 3, 2010 at 8:51 PM, Andy Walls <awalls@radix.net> wrote:
> > With all that said, if you have a baseband Luma or Chroma signal with
> > strong spurious high frequency components (crappy source, or you're
> > overdriving the front end and getting intermods), then keep the
> > anti-alias filter turned on as the assumption of a bandlimited input
> > signal is violated in this case.
> 
> In this case, I'm seeing it with both the analog signal generator
> (which one might consider a fairly pristine source), as well coming
> off the s-video output of a DirectTV box (in which case the signal is
> being generated only a few feet away from the saa7113).

Hmmm.  The AGC (or static gain level?) of the amplifier in the SAA7113
before the anti-alias filter may be set too high causing the clipping
(intermods) there.  It may be worth looking at the gain setting for that
amp.


> > In the SAA7113 the anti-alias filter introduces a delay of 50 ns.  At
> > 13.5 Mpixels/sec, or 74.1 ns/pixel, that's less than 1 pixel time of
> > delay.
> >
> > Just turn it on in and leave it on in the SAA7113 to handle the
> > unexpected input signal case.
> 
> This would be my vote (assuming we try it with the other parts and
> confirm no regressions are introduced).  My only concern is the way
> the code is currently written, the saa7113 initialization block
> actually does enable it by default, and then some code for the saa7115
> tramples the register, turning it off (see saa7115_init_misc at
> saa7115.c:600).  I think the decision we have to make is which of the
> following paths to take:
> 
> 1.  Enable it in the saa7115_init_misc, thereby enabling it for the
> 7113, 7114, and 7115.
> 
> 2.  Exclude the saa7115_init_misc block from being run at all against the 7113
> 
> 3.  Let the saa7115_init_misc block get run, and then flip the bit
> back for the 7113.
> 
> My thinking at this point is that the AA filter should probably be on
> by default regardless of the chip, in which case we would just need to
> make the one line change to enable it in the saa7115_init_misc block.

Probably.

The visible effects of the anti-alais filter could possibly be:

1. Less range of color, if high freqs of the color get attenuated.
(Most people likely will not perceive this as most people are not that
sensitive to small color variations.)

2. Loss of rapid variations in Luma - softer edges between light and
dark areas on a scan line - if higher freqs of the Luma get attenuated.

but given that the anti-alais filter is essentially flat out to about
5.6 MHz and has a slow rolloff (only 3 dB down at about 6.9 MHz), I
doubt anyone would ever notice it is on with NTSC.


Since you have a signal generator, you should run experiments with PAL-D
and SECAM-D with a grid containing vertical lines since those both have
a 6.0 MHz video bandwidth.  SECAM also has FM color, so you might see
the greatest affect of an antialias filter on color on the Cyan color
bar in SECAM-D.

Regards,
Andy

> Devin

Re: Any saa711x users out there?

[Devin Heitmueller]

Hey Andy,

On Thu, Feb 4, 2010 at 11:15 PM, Andy Walls <awalls@radix.net> wrote:
> Hmmm.  The AGC (or static gain level?) of the amplifier in the SAA7113
> before the anti-alias filter may be set too high causing the clipping
> (intermods) there.  It may be worth looking at the gain setting for that
> amp.

It's possible.  One thing I did as a test though was I did a capture
of the i2c traffic under Windows (using the same reference video
source), and then compared the register programming (via some scripts
I whipped up).  There were some other registers that were different,
but the only one that made *any* visible difference in the output was
the AA flag.

> The visible effects of the anti-alais filter could possibly be:
>
> 1. Less range of color, if high freqs of the color get attenuated.
> (Most people likely will not perceive this as most people are not that
> sensitive to small color variations.)
>
> 2. Loss of rapid variations in Luma - softer edges between light and
> dark areas on a scan line - if higher freqs of the Luma get attenuated.
>
> but given that the anti-alais filter is essentially flat out to about
> 5.6 MHz and has a slow rolloff (only 3 dB down at about 6.9 MHz), I
> doubt anyone would ever notice it is on with NTSC.

To give you a better idea of what I'm talking about, look at this image:

http://imagebin.org/83458

The above image was taken with the generator via the s-video input
(ruling out the possibility that it's any sort of product of
intermodulation).

For the sake of comparison, here's the exact same signal source
against an a similar em28xx design but with the tvp5150.

http://imagebin.org/83459

> Since you have a signal generator, you should run experiments with PAL-D
> and SECAM-D with a grid containing vertical lines since those both have
> a 6.0 MHz video bandwidth.  SECAM also has FM color, so you might see
> the greatest affect of an antialias filter on color on the Cyan color
> bar in SECAM-D.

Believe it or not, I'm actually having trouble with the generator
right now with anything but NTSC.  I'm going back and forth with
Promax on repair options.  So I cannot do any PAL or SECAM testing
right now.

On a separate note, I really should look at extending the v4l2
capture-example to a version that let's me do a direct capture of the
YUYV frame and convert the output into a zero-loss RGB format.  It's
too easy to be mislead by things the applications are doing like
deinterlacing, rescaling, blending, and compression of the screenshot
when saving to a file.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: Any saa711x users out there?

[Franklin Meng]

I also have a device that has the SAA7113 chip in it.  Kworld 315U.  

I suggested a patch to add a an s_power function to the code but it looks like the patch didn't work.  I have to do some cleanup to it and resubmit it.  

Franklin Meng

--- On Thu, 2/4/10, Devin Heitmueller <dheitmueller@kernellabs.com> wrote:

> From: Devin Heitmueller <dheitmueller@kernellabs.com>
> Subject: Re: Any saa711x users out there?
> To: "Andy Walls" <awalls@radix.net>
> Cc: "Linux Media Mailing List" <linux-media@vger.kernel.org>
> Date: Thursday, February 4, 2010, 8:34 PM
> Hey Andy,
> 
> On Thu, Feb 4, 2010 at 11:15 PM, Andy Walls <awalls@radix.net>
> wrote:
> > Hmmm.  The AGC (or static gain level?) of the
> amplifier in the SAA7113
> > before the anti-alias filter may be set too high
> causing the clipping
> > (intermods) there.  It may be worth looking at the
> gain setting for that
> > amp.
> 
> It's possible.  One thing I did as a test though was I
> did a capture
> of the i2c traffic under Windows (using the same reference
> video
> source), and then compared the register programming (via
> some scripts
> I whipped up).  There were some other registers that
> were different,
> but the only one that made *any* visible difference in the
> output was
> the AA flag.
> 
> > The visible effects of the anti-alais filter could
> possibly be:
> >
> > 1. Less range of color, if high freqs of the color get
> attenuated.
> > (Most people likely will not perceive this as most
> people are not that
> > sensitive to small color variations.)
> >
> > 2. Loss of rapid variations in Luma - softer edges
> between light and
> > dark areas on a scan line - if higher freqs of the
> Luma get attenuated.
> >
> > but given that the anti-alais filter is essentially
> flat out to about
> > 5.6 MHz and has a slow rolloff (only 3 dB down at
> about 6.9 MHz), I
> > doubt anyone would ever notice it is on with NTSC.
> 
> To give you a better idea of what I'm talking about, look
> at this image:
> 
> http://imagebin.org/83458
> 
> The above image was taken with the generator via the
> s-video input
> (ruling out the possibility that it's any sort of product
> of
> intermodulation).
> 
> For the sake of comparison, here's the exact same signal
> source
> against an a similar em28xx design but with the tvp5150.
> 
> http://imagebin.org/83459
> 
> > Since you have a signal generator, you should run
> experiments with PAL-D
> > and SECAM-D with a grid containing vertical lines
> since those both have
> > a 6.0 MHz video bandwidth.  SECAM also has FM color,
> so you might see
> > the greatest affect of an antialias filter on color on
> the Cyan color
> > bar in SECAM-D.
> 
> Believe it or not, I'm actually having trouble with the
> generator
> right now with anything but NTSC.  I'm going back and
> forth with
> Promax on repair options.  So I cannot do any PAL or
> SECAM testing
> right now.
> 
> On a separate note, I really should look at extending the
> v4l2
> capture-example to a version that let's me do a direct
> capture of the
> YUYV frame and convert the output into a zero-loss RGB
> format.  It's
> too easy to be mislead by things the applications are doing
> like
> deinterlacing, rescaling, blending, and compression of the
> screenshot
> when saving to a file.
> 
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


      

Re: Any saa711x users out there?

[Andy Walls]

On Thu, 2010-02-04 at 23:34 -0500, Devin Heitmueller wrote:
> Hey Andy,


> > The visible effects of the anti-alais filter could possibly be:
> >
> > 1. Less range of color, if high freqs of the color get attenuated.
> > (Most people likely will not perceive this as most people are not that
> > sensitive to small color variations.)
> >
> > 2. Loss of rapid variations in Luma - softer edges between light and
> > dark areas on a scan line - if higher freqs of the Luma get attenuated.
> >
> > but given that the anti-alais filter is essentially flat out to about
> > 5.6 MHz and has a slow rolloff (only 3 dB down at about 6.9 MHz), I
> > doubt anyone would ever notice it is on with NTSC.

Hi Devin,

I think I miscommunicated in the above.  To be more precise, I should
have said:

"The visible effects of the anti-alias filter, on a signal that does not
have unexpected high frequency components out of the normal channel
bandwidth, could possibly be:"

In other words "here's what someone might notice as degredation due to
an AA filter, if they had a proper signal throughout the entire
amplifier chain."




> To give you a better idea of what I'm talking about, look at this image:
> 
> http://imagebin.org/83458

OK.  It look pretty regular which is surprising, but nice for analysis.
It's approximate frequency after having been being folded down is about:

42 cycles/line / 704 pixels/line * 13.5 Mpixels/sec ~= 805.4 kHz ~= 1 MHz

which means it's likely a pretty high frequency, several MHz above the
Nyquist rate, before being folded down by the sampling.



> The above image was taken with the generator via the s-video input
> (ruling out the possibility that it's any sort of product of
> intermodulation).

You are correct that intermodulation product is the wrong term in the
case of basedband S-Video.

However, clipping caused by an overdriven amplifier will introduce high
frequency components - be the peak of the time domain signal caused by
mixing of unwanted TV stations or just a very strong or overamplified
basedband signal.  


> For the sake of comparison, here's the exact same signal source
> against an a similar em28xx design but with the tvp5150.
> 
> http://imagebin.org/83459

Much nicer.


> > Since you have a signal generator, you should run experiments with PAL-D
> > and SECAM-D with a grid containing vertical lines since those both have
> > a 6.0 MHz video bandwidth.  SECAM also has FM color, so you might see
> > the greatest affect of an antialias filter on color on the Cyan color
> > bar in SECAM-D.
> 
> Believe it or not, I'm actually having trouble with the generator
> right now with anything but NTSC.  I'm going back and forth with
> Promax on repair options.  So I cannot do any PAL or SECAM testing
> right now.

:(

I'll try to perform a quick test with my PVR-350 with NTSC and the YUV
capture device BTW.

Then I'll go outside and shovel more snow. :P

Regards,
Andy