« June 2007 | Main | October 2007 »
September 26, 2007
framerate decimation hell (or: deflickering revisited)
i'm encoding the ocarina of time 100% run for the third time right now (second time was due to a bad statid).
F1: ||||||
F2: | | |
F3: | |
in the above picture each | represents one frame. this drawing depicts one complete cycle and only one complete cycle, so the first frame not shown is the first frame of the next cycle. it would be solid blue like the first frame of this cycle.
oot is d4 f3. from the f1 original i was going to f2 first, then to f3 to avoid odd (deflickered) frames (shown above with a bar through them). otherwise i have to use retard bob which does a marginal job of undoing the deflickering and takes exponentially more cpu. more on deflickering in these two blog entries (incidentally this is the same reason i put up this topic).
the frame marked with blue is fine. the problem as i understand it is that sometimes instead of the motion happening in the green frame it happens in the purple or red frame (and gets lost as you can see on the f3 line). in these cases the pattern of motion in f1 is:
K D D K D D or
K D D D K D respectively, instead of
K D K D D D
where K is a motion frame and D is a duplicate (no motion). when i was testing this i saw only sequences of the last type which are ok. but there are often sequences of the first or second type. and once this starts it apparently continues for some time, thus the long, painful stretches of f6 people are seeing.
so basically the game isn't dropping frames at regular intervals. sometimes it will be ok to go -> f2 -> f3 but usually not.
the good news is that i think i've worked out a solution with the help of donald graft's decimate():
changefps(f1/2)
decimate(cycle=3)
this seems to be picking the correct frame (either green or red) from the f2 constellation, probably because it's checking to see that each frame is unique. this means i probably won't have to go back to the horrid retard bob.
Posted by njahnke at 12:28 AM | Comments (0)
September 16, 2007
mac mini
so i bought a "top of the line" mac mini.
it's a core 2 duo 2.0 ghz with 2 gigs of ram (it isn't "apple" ram, of course).
total cost was $1,017.28. cost to sda was $339.09. 1/3 of the machine was paid for with sda funds for the following reasons:
1) the recent increase in the number of d1 f1 runs i need to encode for the site meant less and less idle time for my macbook. i was concerned that i would run out of cpu power to meet demand, especially after the warm reception of metroid prime 3 coupled with its length: the current estimate for an optimal any percent run is around three and half hours - not counting cutscenes. for reference, it takes about a week to encode 5 hours of d1 f1 video (deinterlacing to nmf and encoding all seven qualities) using four processor cores (assuming full speed from them all). i had been counting on most runs being d4, but this appears to be coming to an end.
2) related to 1), i had no quick way to take 10-20 gig of content in to campus to upload while the macbook is locked down encoding.
only 1/3 of the cost was covered by sda because i could have gotten a better machine for the money had it not been a mac (i wanted a desktop mac because using the macbook as one was suboptimal). granted, this will help me do non-encoding work for sda more efficiently, but i feel that is a rather weak reason to take more money from our reserves in this crazy time. also, regarding 2), the other half of the reason i have to have the macbook on campus is school, which has yet to demonstrate decisively that it is beneficial to m2k2sda (though it has been making gains of late: some work on anri-chan was actually done as part of my on-campus job!).
i backed down from saving up for the next beast machine (codenamed V6) because it no longer made sense economically. there are many factors involved, but to summarize:
3) i need more power right now (see 1) and 2)). an eight-core machine costs about $4,000. i wouldn't be able to afford that until may at the earliest.
4) there has been no solution found for multithreaded deinterlacing. therefore i will have to write my own (already discussed as a feature for a future version of anri-chan). once i do this, it will no longer matter how many physical computers are performing the deinterlacing - the load will be divided evenly between the available number of cores.
5) following from 4), continuing to pretend otherwise would mean that the macbook and V5 would be considered useless after the purchase of V6. together they have just under 50% of the theoretical power of V6, so this would be a great waste. by buying a weaker machine now and writing software to tie it together with my existing two, i can have 75% of the power of V6 right now for 1/4 of the price.
therefore, i now think of V5, the macbook and the new mac mini together as V6.
obligatory birth sequence documentation:
Posted by njahnke at 4:08 PM | Comments (0)