On Sun, Jun 13, 2010 at 11:09 AM, Eugeniy Meshcheryakov
<eugen@xxxxxxxxxx> wrote:
> Hi,
>
> I was waiting with reply to look at improvements you made in the driver.
> But the problem did not go away. Actually it became worser. In recent
> kernels the picture is not only shifted, but amount of shift changes
> with the time. Every second or so picture is shifted 1-2 pixels right
> or left. This problem is introduced with this patch:
>
> V4L/DVB: em28xx: rework buffer pointer tracking for offset to start of video
> 5fee334039550bdd5efed9e69af7860a66a9de37
>
> After reverting this patch the picture does not move anymore. Also there
> is still green line on the bottom, and still some pixels that should be
> on the right edge are on the left edge.
>
> I'm using mplayer to watch tv. If it helps, it is cable tv in Germany.
> Some maplyer parameters related to tv:
> norm=pal-bg:device=/dev/video1:tdevice=/dev/vbi0:width=640:height=480:alsa=yes:adevice=hw.2,0:amode=1:immediatemode=0:audiorate=48000
>
> Regards,
> Eugeniy Meshcheryakov
Hello Eugeniy,
I finally found a couple of hours to debug this issue. Please try the
attached patch and report back whether it addresses the problem you
were seeing with the fields shifting left/right.
Regarding the green lines at the bottom, this is an artifact of the
VBI changes, resulting from the fact that there is some important VBI
content inside of the Active Video area (line 23 WSS in particular),
and the chip cannot handle providing it both in YUYV format for the
video area as well as in 8 bit greyscale for the VBI. As a result, we
had to drop the lines from the video area.
What probably needs to happen is I will need to change the driver to
inject black lines into each field to make up for the two lines per
field we're not sending in the video area. In the meantime though,
you can work around the issue by cropping out the lines with the
following command:
/usr/bin/mplayer -vo xv,x11 tv:// -tv
driver=v4l2:device=/dev/video0:norm=PAL:width=720:height=576:input=1
-vf crop=720:572:0:0
(in particular, look at the "-vf crop=720:572:0:0" portion)
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
Fix case where fields were not at the correct start location.
From: Devin Heitmueller <dheitmueller@xxxxxxxxxxxxxx>
This patch address an arithmetic error for the case where the only remaining
content in the USB packet was the "225Axxxx" start of active video. In cases
where that happened to be at the end of the frame, we would inject it into the
videobuf (which is incorrect). This caused fields to be intermittently
rendered off by two pixels.
Thanks to Eugeniy Meshcheryakov for bringing this issue to my attention
Priority: high
Signed-off-by: Devin Heitmueller <dheitmueller@xxxxxxxxxxxxxx>
Cc: Eugeniy Meshcheryakov <eugen@xxxxxxxxxx>
diff -r b594029d762f linux/drivers/media/video/em28xx/em28xx-video.c
--- a/linux/drivers/media/video/em28xx/em28xx-video.c Thu May 13 16:59:15 2010 -0300
+++ b/linux/drivers/media/video/em28xx/em28xx-video.c Sun Jun 13 15:42:27 2010 -0400
@@ -684,12 +684,12 @@
}
if (buf != NULL && dev->capture_type == 2) {
- if (len > 4 && p[0] == 0x88 && p[1] == 0x88 &&
+ if (len >= 4 && p[0] == 0x88 && p[1] == 0x88 &&
p[2] == 0x88 && p[3] == 0x88) {
p += 4;
len -= 4;
}
- if (len > 4 && p[0] == 0x22 && p[1] == 0x5a) {
+ if (len >= 4 && p[0] == 0x22 && p[1] == 0x5a) {
em28xx_isocdbg("Video frame %d, len=%i, %s\n",
p[2], len, (p[2] & 1) ?
"odd" : "even");
