Most recent kernel where this bug did not occur: Unknown Distribution: Slackware 10.1 Hardware Environment: Athlon 2000+, 512Mo, Miro DC30 video card Software Environment: lavrec (mjpegtools 1.6.3-rc3) Problem Description: SECAM videos acquired with lavrec are vertically (downward) offseted by roughly 20/50 lines. The bottom of the image doesn't appear, and the upper is filled with garbage image, which is apparently related to the bottom of the frame (or of the previous frame). Steps to reproduce: Try to acquire a SECAM video (French video standard) with a Miro DC30, for instance with the following command: lavrec -f a -i s -d 1 -U -n 256 -b 1024 -c 2 -g 768x576 test.avi (-i s is the standard selection option, -f a indicates we want MJPEG AVI, -U force read call instead of mmap for sound capture (otherwise it crashes), other are defaults). I append dmesg output and a image extracted from the video to show more precisely what is the problem.
Created attachment 6264 [details] Image sample from the bad video As you can see, the whole image should be upper, and the upper garbage should not be visible. It seems there is a synchronization problem with the SECAM signal or something like that (btw, the VCR and the computer are on the same ground). This problem doesn't appear in PAL mode (however, SECAM videos are recorded in black and white).
Created attachment 6265 [details] dmesg output for hardware info. Do not care of the sleep inside spinlock logs: I submitted another patch. It doesn't seem to prevent lavrec from recording (in fact, this bug triggers only at close).
Created attachment 6266 [details] lspci -v for hardware description
Just tested with mjpegtools 1.8.0. Same results.
Hi, PAL does not appear to have this issue, so maybe the PAL -> SECAM offsets are different (I never tested SECAM, to be honest). Which driver options do you use?
(or can you add "options zr36067 debug=4" to your modprobe.conf so I can see which settings are used internally?)
I do not use any special option, except card=3 to select Miro DC30 card. I'll try the debug=4 option this WE (I do not have access to the hardware during the week).
The problem is related the IC VPX3220 is initialized. There basiacally the default values which are guessed from PAL (you find the vpx3220 datasheet there: http://mjpeg.sourceforge.net/driver-zoran/index.php) In the vpx3220.c file you should find someting called: "static const unsigned short init_secam" I would say that the first value: 0x88, 23, /* Window 1 vertical begin */ is to large. So you need to to use a lower value. But I can't tell which one, because I only have PAL. You find more information about that in the datasheet page 35 and 23. When you have found the correct value please tell use, that we can fix that.
In fact, I fear vanilla source code does not match yours (at least for 2.6.14-rc4), since the line you mention: >I would say that the first value: >0x88, 23, /* Window 1 vertical begin */ >is to large. doesn't exist. In fact, there is the following for init_secam: 0x88, 23 - 16, /* Window 1 vertical begin */ Which is different from NTSC and PAL init values. The "- 16" offset seems to have been copied and shouldn't be there. In fact, I tried with exactly the same line as with PAL (ie: 0x88, 23, /* Window 1 vertical begin */ ) and the default disappears. The value is indeed correct therefore, it was just corrupted by an extra "-16"... Thanks a lot, removing this offset fix the problem. I let you close the bug after pushing the fix to mainline, because if I close it myself, that may be forgotten. I'll try to use more the driver and see if anything else goes wrong (I do not have audio for instance, must check this too).
Audio is not yet supported. I'll push this on to mainline. Thanks for testing.
Created attachment 6304 [details] hm... Hey, I noticed that the CVS and kernel driver are totally not in sync when it comes to those tables. Assuming the CVS is correct, I've patched the kernel to contain the same tables. Can you test that this patch fixes it, also? Thanks.
Created attachment 6305 [details] oops OK, so same patch but now with correct filename in header. Sorry for the confusion. Please use this instead of the above.
It works with the second patch you posted, at least in SECAM (cannot test for PAL or NTSC, for the same reason you cannot test in SECAM). Thank you for telling me audio is not supported (I was investigating why lavrec refused to work without -U option, btw other tools refuse this option). Video works nicely.
This works in PAL just fine. Thanks for testing, I've submitted the final patch to linux-kernel just a minute ago.
OK, works with 2.6.14-rc5. Thanks a lot.