All of lore.kernel.org
 help / color / mirror / Atom feed
From: Devin Heitmueller <dheitmueller@kernellabs.com>
To: Eugeniy Meshcheryakov <eugen@debian.org>
Cc: linux-media@vger.kernel.org
Subject: Re: Problem with em28xx card, PAL and teletext
Date: Sun, 13 Jun 2010 15:46:54 -0400	[thread overview]
Message-ID: <AANLkTimgmQzy5sAh_lU_RHYj-ZD9XZavvLmgs7tSNNdZ@mail.gmail.com> (raw)
In-Reply-To: <20100613150938.GA5483@localhost.localdomain>

[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]

On Sun, Jun 13, 2010 at 11:09 AM, Eugeniy Meshcheryakov
<eugen@debian.org> 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

[-- Attachment #2: isocfix.patch --]
[-- Type: text/x-patch, Size: 1366 bytes --]

Fix case where fields were not at the correct start location.

From: Devin Heitmueller <dheitmueller@kernellabs.com>

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@kernellabs.com>
Cc: Eugeniy Meshcheryakov <eugen@debian.org>

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");

  reply	other threads:[~2010-06-13 19:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-17 14:59 Problem with em28xx card, PAL and teletext Eugeniy Meshcheryakov
2010-03-17 15:43 ` Devin Heitmueller
2010-06-13 15:09   ` Eugeniy Meshcheryakov
2010-06-13 19:46     ` Devin Heitmueller [this message]
2010-06-14  3:21       ` Eugeniy Meshcheryakov
2010-06-14 14:19         ` Devin Heitmueller
2010-06-16 13:40           ` Eugeniy Meshcheryakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTimgmQzy5sAh_lU_RHYj-ZD9XZavvLmgs7tSNNdZ@mail.gmail.com \
    --to=dheitmueller@kernellabs.com \
    --cc=eugen@debian.org \
    --cc=linux-media@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.