On Sunday 28 February 2010, Martin Dauskardt wrote: > > > P.S. I -do- recall an obnoxious flickering of the upper 1/4 of the > > > screen that was often provoked by a loss of sync on the input---that > > > was in the days when I took RF directly from a cable, and one of our > > > local PBS stations had a tendency to transmit badly-corrupted bursts > > > of video (also really badly overmodulated, so much so that white areas > > > caused audio buzzing) a few times a day. I don't know offhand if it > > > -only- manifested on 350 capture, and I rather suspect not. (I could > > > possibly research it if it mattered, based on my records.) I haven't > > > seen it in quite some time, but I don't know if it's because I stopped > > > capturing on my 350 or because I switched to STB-only sources; the two > > > happened at pretty much the same time, I think. > > > > This sounds like the flicker this patch should also fix, but like the > > ghosting, only where it affects the entire recording. As before, this > > glitch isn't restricted to the tuner. My understanding is that with > > current drivers, this type of glitch is primarily a PVR350 problem. > > I described this flickering here: > http://www.gossamer-threads.com/lists/ivtv/devel/32970 > > PVR250 with cx23416 do not have this problem. But I know that earlier > revisions of the PVR250 with cx23415 (have a heatsink!) also have this > flickering when losing sync. > > The funny thing is that I cannot provoke this flickering even with a > current unpatched driver. So there is no difference with the patch. (I > can't say much about ghosting - I always use 720x576. I will see next > weekend if I can do more testings)
With the current driver the flicker seems to be rarer, but unfortunately I still see it occasionally. Ghosting is the most common problem. > @ Ian Armstrong: > Could you check if you can provoke the flickering without your patch, but > with a driver that has these changes: > http://linuxtv.org/hg/v4l-dvb/rev/7753cdcebd28 > http://linuxtv.org/hg/v4l-dvb/rev/ec42a97b1a36 I'll give it a try. One thing to note is that my patch can remove the glitch after it has been triggered. Although the patch is for stopping a capture, it has an effect on firmware behaviour when starting a capture. Here's an explanation of what I found. When the card is first started, it starts digitizing immediately whether a capture is requested or not. I wrote some code to pull the image direct from one of the yuv buffers without touching the firmware. This allowed me to view the video while stepping through the setup for a capture. Using this method I was able to identify the trigger points that can cause the problems. Checking further, it appeared that the problem is related to the incoming video stream. Hit the trigger at just right time and boom, capture broken. I wrote a simple program that would sync to the incoming video stream and then try to trigger the glitch at a certain position within the frame. Some positions virtually guarantee a glitch. Again, I was bypassing the firmware so no capture was in progress during this test. I did try running the glitch program with a proper capture, but all it did was confirm the results. One odd thing I noticed was video was sometimes still being digitized after a capture had been stopped. (I was only looking at one buffer, so I don't know what was happening in the others). I started poking around with the stop capture firmware call, trying various parameters. Then I noticed that a capture I started cleared the glitch. Normally, once you're glitched, you're screwed. I then managed to isolate which parameter variation caused this, and further refined it to the minimum required (the last parameter is a bitmask). I then ran the following sequence with the stock driver: 1.Load firmware 2.Start buffer monitor (capture OK) 3.Run glitch program (capture BAD) 4.Start capture (capture OK) - Note the glitch is removed. 5.Run glitch program (capture BAD) 6.Stop capture 7.Start capture (capture BAD) Capture is now broken across repeated stop/starts. (You can move the glitch program to between 6 & 7, so no capture is occurring when trying to break it, but it still triggers the glitch.) I then reran it with the patch in place: 1.Load firmware 2.Start buffer monitor (capture OK) 3.Run glitch program (capture BAD) 4.Start capture (capture OK) 5.Run glitch program (capture BAD) 6.Stop capture - Note this now has the additional firmware call 7.Start capture - (capture OK) Although the capture can be broken while in progress. Restarting now fixes it. It seems that the extra stop command makes the firmware reset/reinitialize something when the capture is started. You don't need it for the first capture because it's not setup anyway, so the first capture is never bad. You can see an example of the different problems at http://www.iarmst.demon.co.uk/test/pvr350.jpg The flicker you know, but the ghosting is more common but not always obvious with default settings, and it depends on the type of scene as to how visible it is. Both examples of ghosting shown were done with the temporal filter at 31, which is no good for normal usage, but good at highlighting the issue. You can get both the flicker and ghosting at the same time. The captures where all done at 720x576. btw my chosen method of trigger was the vbi setup. -- Ian _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
