Hi, I recently bought a TV capture card (ATI TV Wonder VE) and have noticed some strange artifacts when recording video. Every now and then, I'd see a short horizontal line across parts of the image. I managed to capture a frame of one -- screengrab of it is http://ijr.dnsalias.org/snapshot1.png -- and saw that the line was basically the proper image data, just offset a bit from the frame. So I fiddled around with things a bit more in the capture application, and eventually I memset the mmap'd video buffers to 0 after I had finished with the data and before I rebuffered the video buffer. Once I had done that, the artifacts became a lot more apparent -- lots of green lines across the picture (capturing and displaying YUV420 video, so all 0's is a bright green color with a black line through it). So, I figure the 'offset' data in the that screengrab really isn't offset, but leftover data from the previous time the video buffer had been filled by the bttv driver. So, without memsetting the video buffers, I was seeing portions of video that were essentially 1/15 of a second older than the current frame. I made the same modification to xawtv (added a memset in v4l2_queue_buffer right before the VIDIOC_QBUF ioctl to clear the buffer out) and saw the same artifacts as I had seen in my program. Although, they didn't appear as frequently. But, if I disabled xv, they were pretty apparent, and I managed to capture an image of that -- http://ijr.dnsalias.org/snapshot2.png. The lines are black, but they're quite apparent in that screenshot. Some more (hopefully) pertinant information on my setup: I'm using an ATI TV Wonder VE (ie, el cheapo) capture card, 2.4.18-pre8-ac5 with the latest v4l2 patch I could find, and bttv driver version 0.8.40. I had been using 2.4.18-pre8-ac1 with the bttv driver that came with that kernel version, but decided to upgrade to the latest of everything while trying to track this problem down. The box is an athlon xp 1800+, using an Abit nv7-133r motherboard -- Nvidia nforce 415 chipset. So, there's cpu to spare during capture. The application I'm using to capture originally used the v4l1 mmap'd interface to get data, but I upgraded it to use the v4l2 streaming/select interface during the course of tracking this down. The app's a PVR dealie that I'm writing, based off of an enhanced NuppelVideo codec, but since I can reproduce the problem in xawtv, it's decided that it's not a problem in that code.. Anyone have an idea of what might be causing this? I don't know what to do next, so if anyone out there has an idea of a cause or how to fix it, I'd greatly appreciate it. I _was_ able to significantly reduce the impact of these artifacts by blending the previous frame into the current frame, but as can be expected that basically kills motion in the video.. Thanks, Isaac
