From: Bastien N. <ha...@ha...> - 2003-03-14 14:24:46
|
Hi Michael, On Fri, 2003-03-14 at 14:00, Michael Roitzsch wrote: > Hi James, > > > > so the end-user can adapt it to his/her machine > > > (quality/performance trade-off). not sure about the default - on > > > the one hand better quality is desireable, on the other hand the > > > default setting shouldn't hurt performance too much, even on > > > low-end machines - so even a slow 800mhz...1ghz machine should be > > > able to still decode mpeg-4 without dropping frames. > > > > The default is trickier, though I find max quality with the default > > post processing only gives ~20% (according to top) cpu usage on a > > duron 1.2Ghz for a 576x304 divx. One quite nice solution would be to > > reduce the quality automatically if we are having to drop frames. > > Increasing the quality if we have free time seems like it would be a > > more difficult problem to solve though... > > An adaptive solution would be most welcome. What about an integer that > gets updated by the number of dropped frames returned by frame->draw() > in the following way: > > * starting value is 50, starting post proc quality could be some value > in the middle > * when 0 frames to drop are returned: increase by 1 > * when >0 frames to drop are returned: decrease by 5*frames_to_drop > * whenever the accumulated integer reaches 0 or below, we decrease > quality by one level and start with 50 again > * whenever the accumulated integer reaches 100, we increase quality > by one level and start with 50 again You would then get the engine doing yo-yo between two qualities, if the machine isn't fast enough to get to the top quality without skipping. That doesn't sound like a very good idea to me. Cheers -- /Bastien Nocera http://hadess.net #2 0x4205a2cc in printf ("Oh my %s\n", preferred_deity) from /lib/i686/libc.so.6 printf ("Oh my %s\n", preferred_deity); Segmentation fault |