> The framedrop functionality can be improved, and I've tested enhanced > versions of it. However consistent "drop every second frame" is not > doable for all sources because of the way frames depend on each other; > you can't skip decoding of odd frames and only them if motion > compensation in even frames refers to the odd ones. > Ok that is understandable > > If you're using an svn version of MPlayer, then the better VDPAU support > in git can give improved performance. However the difference is unlikely > to be big enough to improve from 48 to 60. But there is another > alternative, using (possibly threaded) software decoding. Is there a > reason why you'd need to specifically use the hardware decoding in > VDPAU? > Yes I am using SVN from 3 days ago >> Intel(R) Core(TM) i7 CPU ? ? ? Q 720 ?@ 1.60GHz > > I think this should be plenty fast enough to do software decoding of 60 > Hz 1920x1080 video with 4 threads. > > If you haven't looked into threaded decoding before, > git clone git://repo.or.cz/mplayer-build.git > and see the README for some thread-related information. Depending on > your Linux distribution there may also be suitable binary packages. > I will look into that. Luckily it will be awhile till it is needed since I am just working with a sample from the internet, just to do research in the thought of maybe buying a Camcorder that does that. Plus it may not need a full 4 threads since when I did tests of retail Blu-ray 1080/24p quality (I have a BD drive) it can just about do it with just a little random slowness on what I a pretty sure is a single thread xv output.
