On Fri, 18 Feb 2005 10:25:54 +0100, Nick Rosier wrote: > Jelle, > > I did the test twice with the patched and unpatched driver.The patch > seems to break 150-support. I cannot capture anything from the 150 > (forgot to test my 350, might do that later today).
Interesting thanks. Then that probably means that, since the 150/250 doesn't generate the vsync, that the old use of "vsync_count" in the encoder thread has nothing to do with the vsync (more precise: with my patch, the flag is only set in the irq handler when a vsync interrupt arrives, the original driver has an 'atomic_dec()' on the flag, resulting in the condition becoming true for reasons other than a vsync interrupt)... I'll look into it and post my thoughts, or an updated patch. Jelle. > > N. > > On Thu, 17 Feb 2005 00:24:14 -0500, Jelle <[EMAIL PROTECTED]> wrote: >> Hi, >> >> Well, inspired by the prep_dma and vsync osd split stuff in the x11 >> driver, I took a close look a the vsync-related code in the ivtv driver. >> >> There are multiple processes waiting on the same wake_up(), and they are >> modifying the event condition flag (vsync_count) in different places. >> >> That can cause processes to sometimes miss the wake_up(), because the >> condition may not be true anymore by the time the process gets scheduled >> in. If the osd code sometimes misses a wake_up(), that would result in >> the jittery display that I've been seeing a lot... >> >> Also, on my current hardware, I've had the ivtv decoder stall on me >> within a couple of minutes with all recent ivtv versions, and it seemed >> to be worse when the encoder was running (plus some people posting >> suggested link between osd and the decoder). >> >> I also noticed that osd playback seemed much smoother if the encoder >> wasn't running. >> >> With that kind of behaviour, the above vsync and vsync_count issue makes >> a lot of sense. >> >> So I changed the code to have different flags for the encoder, decoder, >> and osd, and two waitqueues, one for the osd that gets woken up first so >> that the osd always gets served before the encoder or decoder, and then >> the regular wake_up(). >> >> My osd output now is a lot better than with the unpatched ivtv driver, >> enough for me to not want to go back to using the decoder (also because >> now I can use mythtv's transcoding and time stretch). I did do a quick >> test with the decoder and it didn't stall like it did often in the >> unpatched ivtv. >> >> There are still some drawbacks, the cpu utilization of X11 is pretty >> high during osd playback, and when the system get busy, some tearing >> appears. I think I'd like to see xv/yuv support, and I guess the current >> rgb osd transfer can sometimes get interrupted by the scheduler for too >> long for the next vsync (maybe it's possible to make the osd thread >> sched_rr or sched_fifo?) >> >> Anyway: Attached is the patch, against 0.3.2d. >> >> If you have any problems with osd and/or the pvr350 decoder, I suggest >> you give this a try (note when using osd and mythtv, do _not_ let mythtv >> do any deinterlacing for best results). >> >> Note that I also use the patched x11 ivtvdev driver that does not split >> large osd transfers up. >> >> Jelle. >> >> ---------------- ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ ivtv-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ivtv-devel
