Am 03.04.2013 10:27, schrieb Timo Teras: > On Tue, 02 Apr 2013 18:39:25 +0200 > Frank Schäfer <fschaefer.oss@xxxxxxxxxxxxxx> wrote: > >> Am 02.04.2013 07:43, schrieb Timo Teras: >>> On Mon, 01 Apr 2013 19:26:53 +0200 >>> Frank Schäfer <fschaefer.oss@xxxxxxxxxxxxxx> wrote: >>> >>>> Am 30.03.2013 10:54, schrieb Timo Teras: >>>>> On Thu, 28 Mar 2013 12:22:52 -0300 >>>>> Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> wrote: >>>>> >>>>>>> On the W7 driver, I don't get any of the above mentioned >>>>>>> problems. >>>>>>> >>>>>>> I looked at the saa7113 register init sequence, and copied that >>>>>>> over to linux saa7113 init, but that did not remove the >>>>>>> problems. There were only few changes. >>>>>> So, maybe it does a different crop setup at em28xx. >>>>> I did an analysis of the register setups of em28xx and found the >>>>> following differences: >>>>> >>>>> 1. Different crop settings >>>>> >>>>> EM28XX_R1D_VSTART, EM28XX_R1F_CHEIGHT and EM28XX_R2B_YMAX set by >>>>> W7 driver were divided by two compared to the linux driver. Seems >>>>> that linux driver did just this before commit c2a6b54. I also >>>>> found the patch https://patchwork.kernel.org/patch/1272051/ to >>>>> restore the original behaviour, but somehow it was disregarded >>>>> and commit 0bc9c89 was done instead. The mentioned patch though >>>>> does not fix R1D setting though. >>>> Can you post the settings the Windows driver uses for these >>>> registers ? Don't worry about registers 0x28-0x2B, different values >>>> shouldn' matter. See >>>> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/57039. >>> Yes, it would seem registers 0x28-0x2B do not have great >>> significance in the video we get out of it. >>> >>> The full sequence the W7 driver does for PAL video is: >>> >>> EM28XX_R20_YGAIN 0x00 >>> EM28XX_R22_UVGAIN 0x00 >>> EM28XX_R06_I2C_CLK 0x40 >>> EM28XX_R15_RGAIN 0x20 >>> EM28XX_R16_GGAIN 0x20 >>> EM28XX_R17_BGAIN 0x20 >>> EM28XX_R18_ROFFSET 0x00 >>> EM28XX_R19_GOFFSET 0x00 >>> EM28XX_R1A_BOFFSET 0x00 >>> EM28XX_R23_UOFFSET 0x00 >>> EM28XX_R24_VOFFSET 0x00 >>> EM28XX_R26_COMPR 0x00 >>> EM28XX_R13_??? 0x08 (Note: we do not set this at all) >> I've seen this write to reg 0x13 with my webcams, too. >> Unfortunately, we don't know what it means. But according to my tests, >> it is not needed. > Right, it is not strictly needed. > >>> EM28XX_R27_OUTFMT 0x34 >>> EM28XX_R10_VINMODE 0x00 >> We set vinmode to 0x10 (see em28xx_init_dev() in em28xx-cards.c). >> No idea what the values mean. Might be worth testing with 0x00. > Did not try, but seems it did not make any great difference either. > >>> EM28XX_R28_XMIN 0x01 >>> EM28XX_R29_XMAX 0xB3 >>> EM28XX_R2A_YMIN 0x01 >>> EM28XX_R2B_YMAX 0x47 (We set 0x8e, i think) >> Yes, we set to EM28XX_R2B_YMAX to 0x8f, the other values are the same >> as used by the driver. >> 0x47 is 0x8f / 2, so what the Windows driver seems to do here is to >> use the field height instead of the image height (interlaced mode) >> which is the same what we did in the past in our driver. >> >> Anyway, some other device like the MSI DigiVox ATSC (PAL or NTSC ?, >> interlaced), Silvercrest webcam 1.3MPix (640x480, progressive) use the >> following values: 0x01, 0xFF, 0x01, 0xFF. >> And the Speedlink VAD Laplace webcam for example uses the following >> values: 0x1B, 0x83, 0x13, 0x63 (320x240, 640x480, progressive) >> 0x6B, 0xD3, 0x57, 0xA7 (1280x1024, progressive) >> 0x93, 0xFB, 0x6D, 0xBD (1600x1200, progressive) >> >> So which formula should we use ? Suggestions ? ;) > Not really. And yes, seems it does not matter much. I took the below > referred image grabs with unmodified em28xx, and they look pretty much > the same compared to the results of em28xx patched as described before. > >> As said before, we didn't notice any difference in the device behavior >> when changing the values so far. So let's stay with the current >> formula. > Yeah. > >>> EM28XX_R1C_HSTART 0x00 >>> EM28XX_R1D_VSTART 0x01 (We set 0x02) >> In VBI mode, yes, without VBI we use 0x00. >> I don't know if a 1 Pixel offset makes a big difference. >> But looking at the comment in em28xx_resolution_set(), an offset of 2 >> pixels seems to make a bigger difference for VBI devices, which makes >> my alert bells ringing... > I did not test VBI, so I'm unsure if it works or not. The em2860 supports VBI, so VBI mode is used. You can force the normal mode with module parameter disable_vbi=1 >> [snip] >>> Oh, would it then make sense to disable all the non-16bpp formats >>> for the time being? >> Maybe. >> But in practice, nearly all TV/DVB application (or libv4l2) are >> selecting a 16 bit format, so this doesn't cause too much trouble. >> ffmpeg however seems to be the exception ;) The other exception might >> be webcam applications. > Seems the exception is applications using libv4l2 and requesting > primarly a format that is not native to the device. Sure, int this case it's up to libv4l2 to select an approriate driver source format for the conversion. But I doubt lib4vl2 will select one of the 8 bit formats when the the destination format is a 16 bit format. ;) >> I'm also getting a "usable" image with the 8 bit formats, so it's not >> completely broken. >> >> Anyway, sooner or later we will have to fix the 8 bit formats, because >> for webcams with higher resolutions (e.g. >= 1280x1024) 16 bit formats >> cannot be used anymore... ;) >> >>> Basically, I got mostly OK picture, but areas with all-black and >>> all-white next to each other got distorted (e.g. subtitles). >> Could you send us a screenshot ? >> Looks different with my devices... > Seems ffmpeg by default wants yuv420p, and libv4l2 does some > conversions automatically to get there. The relevant grab is: > http://dev.alpinelinux.org/~tteras/image-yuv420p.jpg > You can see the red/blue pixels with subtitles. There's also some > quality loss on other sharp edges, like the edge of the white shirt. Yeah, looks the same with my devices. > Using --pix_fmt rgb24 seems to result in similar issues. > > This is the same (paused image from DVD player) grabbed again with > --pix_fmt yuyv422: http://dev.alpinelinux.org/~tteras/image-yuyv422.jpg > which nice. Except the green line at the bottom which I'm seeing, too. Try the module parameter disable_vbi=1 and the distortion/artifacts/offset should change a bit. I wouldn't wonder if we encounter multiple issues here which are interfering with each other... :( > When comparing these two picture, you see that the frame is offset with > one or two pixels in x-direction. Perhaps this is a byte offset, and in > RGB format causes color values to be connected to wrong pixel. > > As final note, now I hooked the device on faster machine, and the AC97 > detection seems random. It seemed to work with the slower machine > reliably after I had it do the saa7113 initialization. So sounds like > some sort of timing issue. More details please. ;) Do you mean that "Config register raw data" (see dmesg output) value varies ? Regards, Frank > - Timo -- 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
