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) EM28XX_R27_OUTFMT 0x34 EM28XX_R10_VINMODE 0x00 EM28XX_R28_XMIN 0x01 EM28XX_R29_XMAX 0xB3 EM28XX_R2A_YMIN 0x01 EM28XX_R2B_YMAX 0x47 (We set 0x8e, i think) EM28XX_R1C_HSTART 0x00 EM28XX_R1D_VSTART 0x01 (We set 0x02) EM28XX_R1E_CWIDTH 0xB4 EM28XX_R1F_CHEIGHT 0x48 (We set 0x8f, or 0x90) EM28XX_R1B_OFLOW 0x00 (Tuner and AC97 config takes place here) EM28XX_R0E_AUDIOSRC 0x8f EM28XX_R21_YOFFSET 0x08 (We set 0x10) EM28XX_R20_YGAIN 0x10 EM28XX_R22_UVGAIN 0x10 EM28XX_R14_GAMMA 0x32 (We set 0x20) EM28XX_R25_SHARPNESS 0x02 (We set 0x00) EM28XX_R26_COMPR 0x00 EM28XX_R27_OUTFMT 0x34 EM28XX_R11_VINCTRL 0x11 EM28XX_R1B_OFLOW 0x00 EM28XX_R12_VINENABLE 0x67 EM28XX_R22_UVGAIN 0x10 EM28XX_R20_YGAIN 0x10 EM28XX_R0E_AUDIOSRC 0x8f > > 2. Different outfmt used > > > > It seems that ffmpeg defaults to v4l default, which somehow > > apparently resulted in EM28XX_OUTFMT_RGB_8_RGRG set. When forcing > > ffmpeg to set yuyv422 or EM28XX_OUTFMT_YUV422_Y0UY1V the color > > distortions vanished. I'm unsure if the distiortion comes from > > ffmpeg doing some automatic conversions, or from v4l kernel driver. > > The easiest way to test the drivers output formats is to use qv4l2 > with the device opened in raw mode (command line option '-r' or 'Open > raw device' from the 'File' menu). > In raw mode, you can be sure that the selected format is always the > actually used format (otherwise libv4l2 is used which selects what it > thinks is the best source format for the conversion into the selected > format. Ah, ok. So libv4l2 can be doing stuff underneath also. I think in my setup yuv420p is the preferred one (encoding to h264 with baseline profile). Now that I figured what goes wrong, this is not a big issue. > I hate to say that, but currently you shouldn't expect anything else > than the 16 bit formats to work properly. :( > The code assumes 16 bit pixel width in several places (initially > YUV422 was the only supported format). > Some of these bugs are easy to find (e.g. in em28xx_copy_video() ), > some are hidden... > I didn't have enough time yet to track them all down and all my > attempts to fix parts of the code resulted in an even worse picture > so far. Oh, would it then make sense to disable all the non-16bpp formats for the time being? Basically, I got mostly OK picture, but areas with all-black and all-white next to each other got distorted (e.g. subtitles). > > Though, it might be an idea to set the default outfmt to something > > that is known to work. So I'm wondering if this could be fixed > > easily? YUYV422 should have also better quality, so it would make > > sense to select it instead of the other one. > > The driver selects EM28XX_OUTFMT_YUV422_Y0UY1V as default format, so > it must be ffmpeg that selects EM28XX_OUTFMT_RGB_8_RGRG. Yes, starting to sound like that. > > So seems that now the device is working properly. Basically we need > > the following changes: > > 1. saa7113 id ignore (or autodetect, and fallback to forced type) > > 2. saa7113 not writing to the registers 14-17 in case it's not the > > original chip (id not present) > > You should talk to the saa7115 maintainer about that. get_maintainers.pl says that Mauro and this list is the place to talk to. So here I am doing it :) > > 3. em28xx crop height/vstart to divided by 2 in interlaced mode > > 4. (optionally) em28xx outfmt should default to YUYV422 > > Both isn't necessary (as explained above). > What definitely needs to be fixed in the em28xx driver are the > non-16bit-formats. Yeah, seems to be the case. - 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
