Hi Mauro, > 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, ... To be fair, it is very hard to implement something you cannot test yourself, and most people can only test PAL/NTSC. >> 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. Very interesting. I honestly thought that all TVs everywhere (except perhaps very old ones) would be able to handle 'standard' PAL or NTSC on their Composite and S-Video inputs. > >> 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. Currently it does only PAL and NTSC. Although it can do SECAM it is never actually enabled. > 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? Generally, not being able to test all the possible standards. Or not being aware of this problem at all :-). I agree that this driver should be enhanced to support more standards. Chaithrika, can you take a look at this based on Mauro's input? Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
