April 2006 - MPlayer-dev-eng - lists.mplayerhq.hu

[PATCH] Remove assumptions about kernel HZ=100 from timing
by Uoti Urpala 02 Apr '06

02 Apr '06

The non-rtc timing code was written assuming that kernel HZ is always 100, and biases the timing to compensate for the average 5 ms ("randomly" 0-10 ms) extra delay when sleeping. With the current Linux kernels this assumption is no longer true. The kernel config has choices for HZ 100, 250 and 1000, and most distributions use the higher values (Debian uses 1000). The patch removes the bias and some unnecessary complexity from the timing (at least I believe special-casing "usec_sleep(0)" was useless unless someone can demonstrate otherwise). The code still assumes HZ=100 if softsleep is being used. Timing error relative to desired time with and without the patch: HZ 100 without patch: -5 to +5 ms HZ 100 with patch: 0 to +10 ms HZ 250 without patch: -5 to -1 ms HZ 250 with patch: 0 to +4 ms HZ 1000 without patch: -5 to -4 ms HZ 1000 with patch: 0 to +1 ms With normal a/v sync options the effect of the systematic bias in either direction is small as it will get compensated for in the sync code, so in most cases this patch will not result is significantly changed behaviour. The documentation should also be updated to mention that both rtc and softsleep are useless on HZ 1000 boxes (and maybe HZ 250 too). With kernel HZ 1000, non-rtc has timing accuracy similar to rtc, but is better in the sense that the code does not need to wake up every 1/1024 s while sleeping to check the time.

1 0

[PATCH] 'configure' & lasattr improvement
by Derek E. Lewis 02 Apr '06

02 Apr '06

The output of 'lsattr -E -l proc0' has changed in AIX 5.3 (an additional line detailing information about simultaneous multithreading -- SMT). This patch uses the preferred interface for determining the processor type in AIX. Thanks, Derek E. Lewis dlewis(a)solnetworks.net http://riemann.solnetworks.net/~dlewis

2 1

Need help with interlaced images and strides
by Walter Belhaven 01 Apr '06

01 Apr '06

Hi, I'm attempting to implement a slight variation of the 'tinterlace=0' filter, and it's clear that I just don't "get" the stride implementation in mplayer, or just how interlaced images are stored. Can someone point me to some info on this? I've read everything I can find, including all of the technical documentation. I even think I understand the entire filter interface and most of what's going on in vf_tinterlace.c, but there's a disconnect somewhere. Here are the details. To convert 720p/60Fps HD "video" to 480i/60fps SD "video" for burning to DVD-Video (capital F's mean Frames, little f's mean fields), I'd like to take, say, the even lines from Frame 'j', and, say, the odd lines from Frame 'j+1'. At a high level this is what the tinterlace=0 filter does, but not quite. In order to test the concept and to get things working, I'm making my changes "in place" to tinterlace=0. The changes I've made are as follows: vf_tinterlace.c::config() 1. passed 'height' and 'd_height" to next filter, rather than height*2 and d_height*2 vf_tinterlace.c::put_image() 1. requested an image of 'mpi->height' instead of 2x that in vf_get_image 2. set 'dmpi->fields' to MP_IMGFIELD_INTERLACED. Also tried setting MP_IMGFIELD_TOP_FIRST. 3. changed all occurrences of dmpi->stride[n] to twice that value, in all calls to memcpy_pic. 4. changed all height's to height/2 in calls to memcpy_pic. I get core dumps if I don't, and it makes sense to me to make this change. 5. Used a single stride offset when copying the 2nd field I'm clearly missing something, because the resulting output doesn't look interlaced, especially with two carefully crafted JPG images I'm using for testing. Any help would be appreciated. Thanks, WB __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: Need help with interlaced images and strides
by Walter Belhaven 01 Apr '06

01 Apr '06

I wrote: > > Can someone point me to some info on this? I've read > everything I can find, including all of the technical > documentation. I even think I understand the entire > filter interface and most of what's going on in > vf_tinterlace.c, but there's a disconnect somewhere. > > [..snip..] > 4. changed all height's to height/2 in calls to > memcpy_pic. I get core dumps if I don't, and it makes > sense to me to make this change. Nevermind. I was being bitten by the "special case" of dstStride == srcStride in which the whole image is copied in a single memcpy. I need the stride-by-stride copy of, e.g., my_memcpy_pic, that several folks have implemented in their various filters. Problem solved for the moment. Sorry for the interruption. At some point I hope to have a patch ready for review by you folks. WB __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0