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. > 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. 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. > 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. > -- > > 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. > 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. Regards, Frank > I can post a patch for 3, but for others I'm not fully certain about > implementation details. With few pointers, I could probably produce > patches, though. But I would be also happy to just test what ever you > come up with. > > Thanks, > 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 -- 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
