On Mon, 14 Feb 2005 10:14:55 +0000, Matthew Hodgson <[EMAIL PROTECTED]> wrote:
On using IVTVFB_IOCTL_PREP_FRAME to write to my PVR-350's OSD immediately
after loading the modules, I can reliably copy a full PAL frame in about 85%
of the 40ms time window available
This is great, as I can write to the OSD and then wait for vsync in the remaining 15% and so largely eliminate tearing.
However, if I then fade the OSD and write some MPEG to /dev/video0,
(this should of course have said /dev/video16 in my original mail)
afterwards on writing to the OSD again the timings are all over the place -
and mostly take longer than 40ms to transfer the frame, meaning I can no
longer framesync or play back in realtime.
I've managed to work around this by noticing and using the new IVTVFB_IOCTL_PREP_FRAME_BUF ioctl which CK added somewhere in 0.3. When using this to DMA to the OSD framebuffer, the timings are not affected by whether the decoder has been fired up this session, and I can reliably transfer frames at faster to realtime, other than the occasional frame being slightly delayed presumably due to some quirk of the kernel's scheduler.
Unfortunately, in 0.3.2[ijk], this no longer works - after having been writing some mpeg to /dev/video16, trying to write to the OSD using IVTVFB_IOCTL_PREP_FRAME_BUF transfers at ~80% of the speed it did before (and with more fluctuation in the timings).
Using PREP_FRAME_BUF did solve this behaviour with 0.3.2b, other than after a few days "ivtv: DEC 1st DMA Xfer Info failed=0xfffffff0 336827317" style errors would surface on the first few writes to the OSD after having been playing MPEG (or vice versa). After a bit longer, DMAs to the OSD became unstable altogether, which is why I'm trying to upgrade to a 0.3.2 with cleaner DMA code.
To demonstrate the problem with 0.3.2k:
# modprobe ivtv # modprobe ivtv-fb # ./ivtvfbctl /dev/fb0 -prepdma -nosleep ... frameloop: userspace buffer 0xb7cfe000 of 1658880 bytes: Warning, you must change CPU_HZ to be accurate, currently 2793423000: mlock rc = 0 iter 0: time = 33.058521 fps iter 1: time = 32.919242 fps iter 2: time = 32.929567 fps iter 3: time = 32.971597 fps iter 4: time = 32.975228 fps iter 5: time = 32.957011 fps iter 6: time = 32.931189 fps iter 7: time = 32.912909 fps iter 8: time = 32.951270 fps iter 9: time = 32.959177 fps iter 10: time = 32.971320 fps iter 11: time = 32.879614 fps iter 12: time = 32.961221 fps iter 13: time = 32.964796 fps etc.
# cat test.mpeg > /dev/video16
# ./ivtvfbctl /dev/fb0 -prepdma -nosleep ... frameloop: userspace buffer 0xb7cfe000 of 1658880 bytes: Warning, you must change CPU_HZ to be accurate, currently 2793423000: mlock rc = 0 iter 0: time = 24.887542 fps iter 1: time = 25.405616 fps iter 2: time = 25.393173 fps iter 3: time = 24.822726 fps iter 4: time = 25.403095 fps iter 5: time = 25.428180 fps iter 6: time = 24.811362 fps iter 7: time = 25.425392 fps iter 8: time = 25.419839 fps iter 9: time = 25.420931 fps iter 10: time = 25.448121 fps iter 11: time = 25.393103 fps iter 12: time = 25.404537 fps etc.
Can anyone else reproduce this simple test case?
Does anyone have any idea why it happens, and/or how to stop it?
thanks;
Matthew.
--
______________________________________________________________
Matthew Hodgson [EMAIL PROTECTED] Tel: +44 845 6667778
Systems Analyst, MX Telecom Ltd.
------------------------------------------------------- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click _______________________________________________ ivtv-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ivtv-devel
