Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hans Verkuil escreveu:
On Thursday 23 April 2009 13:35:02 Mauro Carvalho Chehab wrote:
On Sun, 19 Apr 2009 12:46:00 +0200
Hans Verkuil <hverkuil@xxxxxxxxx> wrote:

Hi Mauro,

Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following:

- v4l: TI THS7303 video amplifier driver code
+static int ths7303_setvalue(struct v4l2_subdev *sd, v4l2_std_id std)
+{
+       int err = 0;
+       u8 val;
+       struct i2c_client *client;
+
+       client = v4l2_get_subdevdata(sd);
+
+       if ((std & V4L2_STD_NTSC) || (std & V4L2_STD_PAL)) {
+               val = 0x02;
+               v4l2_dbg(1, debug, sd, "setting value for SDTV format\n");
+       } else {
+               val = 0x00;
+               v4l2_dbg(1, debug, sd, "disabling all channels\n");
+       }
+

Hmm... Are you sure that the above check is ok? The standards you're allowing
are: PAL/BGDKHI and NTSC (except for NTSC/443). So, standards like PAL/N,
PAL/N', PAL/60, PAL/M will stay away.

If what you want is all standards but SECAM, then the correct syntax would be something like:
	if (std & (V4L2_STD_ALL & ~V4L2_STD_SECAM))

- Analog Devices ADV7343 video encoder driver
+#define SD_STD_NTSC            (0x00)
+#define SD_STD_PAL_BDGHI       (0x01)
+#define SD_STD_PAL_M           (0x02)
+#define SD_STD_PAL_N           (0x03)

Hmm... from the comments at the beginning of the .c file, it seems that the
hardware supports all standards but SECAM. The above register definitions also
specifies PAL/M and PAL/M as supported standards.
However, by looking at the std_into table:

+static const struct adv7343_std_info
+       adv7343_composite_std_info[] = {
+       {
+               SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
+       },
+       {
+               SD_STD_PAL_BDGHI, 0xCB, 0x8A, 0x09, 0x2A, V4L2_STD_PAL,
+       },
+};
+
+static const struct adv7343_std_info
+       adv7343_component_std_info[] = {
+       {
+               SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
+       },
+       {
+               SD_STD_PAL_BDGHI, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_PAL,
+       },
+};

Hmm.. on the last table, you are using a FSC = 3,579,545.45 Hz for both PAL and
NTSC? This seems wrong to my eyes.

Also, both tables have several supported standards missed.

Mauro,

Are there TVs in Brazil that are unable to handle standard NTSC-M on the
composite or S-Video inputs?
Yes. There are models that only handles PAL-M.

There are no encoders in v4l-dvb that do
something special for PAL-M.
Maybe because nobody tested they and reported an issue? Before I started working on this,
most drivers were broken with PAL/M: saa7113, cx88, ivtv, ...
All just check against 525 vs 625 line standards.
And I can't imagine that that will cause problems for Brazilian TVs.
If you don't encode with PAL/M, then some TV sets won't work. Also, even on TV sets that supports multiple standards, sometimes we need to disable autodetection of NTSC, because this is broken on some TV sets. I've personally experienced this trouble with two TV sets, including a brand-new LCD1080p TV set I bought this year. On some conditions, if you let auto NTSC/PAL-M enabled, it miss-detects the color carrier, and changes to the other standard (missing the colors) for some seconds, and then returns back. So, you have moments with colors and moments without.

It should also be noticed that there are several devices (TV sets, DVD players, etc) manufactured abroad that people assumes that PAL/M color carrier is equal to NTSC (AFAIK, the same occurs with PAL/Nc). Since the color carriers are somewhat different, this produces a very annoying effect: the color image will present a static image as a image with colors moving, since there will be a frequency shift between the horizontal frequency rate and the pixel sampling rate (that are derived from the color carrier on several decoders), causing color detection misleading at the pixels. So, the pixels at the boundary of a shape have their colors oscillating.

I think these drivers should just use V4L2_STD_525_60 and V4L2_STD_625_50,
just like saa7127 does.
I have no device here with saa7127, so I'm not sure how this works with other standards. But, expecially on encoding, you should be able to produce the right standard. I can't see it producing a right standard if you just use V4L2_STD_525_60 and V4L2_STD_625_50 with s-video. At least on one place, you should say to the encoder what should be the color carrier frequency and if it will encode with PAL, NTSC or SECAM.


By the way, what's the rationale of not allowing the driver to encode on all supported formats?


Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux