Problem with em28xx card, PAL and teletext
Commit Message
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
Comments
Hi,
13 ?????? 2010 ? 15:46 -0400 Devin Heitmueller ???????(-??):
> 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.
Thanks, that patch fixes the shifting problem, all the pixels are in the
right place.
> 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.
Anything that makes the picture centered will be great.
> 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
Thanks for the tip. It worked with 640x480. But when I tried to use
720x576 I got a picture with a lot of noise made of horizontal white
lines. However maybe it is because of damaged USB connector...
Also teletext is still unreadable (both with 640x480 and 720x576). Does
mplayer support teletext correctly? And can it work with resolution
640x480?
Regards,
Eugeniy Meshcheryakov
On Sun, Jun 13, 2010 at 11:21 PM, Eugeniy Meshcheryakov
<eugen@debian.org> wrote:
> Thanks, that patch fixes the shifting problem, all the pixels are in the
> right place.
Ok, I'll issue a PULL request to get that upstream. Thanks for testing.
>> 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
> Thanks for the tip. It worked with 640x480. But when I tried to use
> 720x576 I got a picture with a lot of noise made of horizontal white
> lines. However maybe it is because of damaged USB connector...
If you email me a screenshot (preferably off list due to the size), I
can probably provide some additional advice. Also please provide the
exact mplayer command you used so I can try to reproduce it here.
> Also teletext is still unreadable (both with 640x480 and 720x576). Does
> mplayer support teletext correctly? And can it work with resolution
> 640x480?
I don't know how good mplayer's teletext support is. When I did the
original work, I did the testing using "mtt", and in fact I had to do
it over an SSH link since I didn't have a teletext feed here. It
should work at 640x480 though.
I would suggest you try it with mtt/tvtime at 720x576 and see if it
works. If it does, then we have a starting point to narrow down
whether it's an issue with the application, the selected capture
resolution, the driver itself, or something strange about the teletext
feed itself.
Cheers,
Devin
Hello Devin,
14 ?????? 2010 ? 10:19 -0400 Devin Heitmueller ???????(-??):
> > Thanks for the tip. It worked with 640x480. But when I tried to use
> > 720x576 I got a picture with a lot of noise made of horizontal white
> > lines. However maybe it is because of damaged USB connector...
>
> If you email me a screenshot (preferably off list due to the size), I
> can probably provide some additional advice. Also please provide the
> exact mplayer command you used so I can try to reproduce it here.
The lines do not look white for me now, it is probably depends on
picture. You can see screenshots here:
http://people.debian.org/~eugen/em28xx/
I had the following in mplayer config file:
ao=alsa
vo=xv
framedrop=1
panscan=0
tv=width=640:height=480:norm=pal-bg:device=/dev/video1:tdevice=/dev/vbi0:alsa=yes:adevice=hw.2,0:amode=1:immediatemode=0:audiorate=48000:chanlist=europe-west:channels=<long list of channels>
lavdopts=threads=2
vf=yadif=0,screenshot=1
Regards,
Eugeniy Meshcheryakov
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>
@@ -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");