From patchwork Sun Jun 13 19:46:54 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Devin Heitmueller X-Patchwork-Id: 3644 Return-path: Envelope-to: mchehab@infradead.org Delivery-date: Sun, 13 Jun 2010 19:47:01 +0000 Received: from bombadil.infradead.org [18.85.46.34] by localhost with IMAP (fetchmail-6.3.17) for (single-drop); Mon, 14 Jun 2010 05:21:26 +0300 (EEST) Received: from vger.kernel.org ([209.132.180.67]) by bombadil.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1ONt93-00082e-Ak; Sun, 13 Jun 2010 19:47:01 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754380Ab0FMTqz (ORCPT + 1 other); Sun, 13 Jun 2010 15:46:55 -0400 Received: from mail-yw0-f204.google.com ([209.85.211.204]:52027 "EHLO mail-yw0-f204.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754309Ab0FMTqz (ORCPT ); Sun, 13 Jun 2010 15:46:55 -0400 Received: by ywh42 with SMTP id 42so2864310ywh.15 for ; Sun, 13 Jun 2010 12:46:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.42.24 with SMTP id p24mr4121274agp.159.1276458414210; Sun, 13 Jun 2010 12:46:54 -0700 (PDT) Received: by 10.90.70.3 with HTTP; Sun, 13 Jun 2010 12:46:54 -0700 (PDT) In-Reply-To: <20100613150938.GA5483@localhost.localdomain> References: <20100317145900.GA7875@localhost.localdomain> <829197381003170843u73743ccand32e7d0d2e6d3ca6@mail.gmail.com> <20100613150938.GA5483@localhost.localdomain> Date: Sun, 13 Jun 2010 15:46:54 -0400 Message-ID: Subject: Re: Problem with em28xx card, PAL and teletext From: Devin Heitmueller To: Eugeniy Meshcheryakov Cc: linux-media@vger.kernel.org Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org On Sun, Jun 13, 2010 at 11:09 AM, Eugeniy Meshcheryakov 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 Fix case where fields were not at the correct start location. From: Devin Heitmueller 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 Cc: Eugeniy Meshcheryakov 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");