Writing to /dev/video48 will behave like that. The updates are not (or weren't when I last looked) synced to the vsync. The ioctl is synced to the vsync and should be less prone to this. There is also a reasonably large amount of buffering in the write code which adds a lag to the display.
The card is theoretically capable of multi buffering and we should be able to get it to switch buffer on the vsync but both Chris and I found it caused the card to lock up so we are not using that at the moment. If it happens with the ioctl then the only better solution at the moment is to move the code into the interrupt handler to reduce the time from the interrupt happening to the work being done but that is quite a big change. John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:ivtv-devel- > [EMAIL PROTECTED] On Behalf Of Matthew Hodgson > Sent: 20 May 2005 00:05 > To: [email protected] > Subject: [ivtv-devel] C lags Y when decoding YUV > > Hi all, > > Whilst investigating YUV decoding some more with 0.3.4p + John Harvey's > patch, I've come across the following bug: at any one point in time, the > displayed chrominance buffer appears to lag behind the displayed luminance > image by a fraction of a field. > > This seems to be because tearing occurs as the framebuffer is rendered at > the same time as being filled - and the tearing on the C happens later. I > assume this is due to the waitVsync check in dma_to_device() happening > somehow in the wrong place relative to when the DMA actually happens & the > framebuffer gets written - but I can't immediately see a better solution. > > This is easily reproducible using a test video of a vivid moving stripe > and > comparing between MPEG decoding & the YUV decoding. I've been using a > very > simple & naive VO testjig for mplayer to write to /dev/video48 - i'm > afraid > it's hardcoded to PAL at the moment; as is a sample test video: > > They can be downloaded from: > > http://opensource.mxtelecom.com/ivtv/vo_ivtvyuv.c > http://opensource.mxtelecom.com/ivtv/chromalag.mpg > > if anyone's interested in seeing what I'm talking about :) > > suggestions on how the timing code could be tweaked to minimise the > tearing/async would be very welcome... > > M. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > ivtv-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ivtv-devel ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ ivtv-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ivtv-devel
