Re: [Mplayerxp-general] Frame dropping again...
Brought to you by:
olov
From: <mr...@us...> - 2003-01-29 12:13:01
|
Nick Kurshev <nic...@ya...> writes: > I did some changes in framedropping code! > It works more or less acceptable for me (with my movies on slow systems= ) > But really I need to have more reports about visible changes with > frame dropping on other systems! For me, it runs mostly smoothly with short, 0.1-0.2 second, freezes at somewhat regular intervals (when there's a need to drop frames at all). Some of the freezes are long enough to slightly annoying. What's worse, sometimes video gets ahead of audio by ~0.5 seconds, which is really disturbing. After ~15 minutes audio stopped with a "Too many audio packets" message. The source was a DVD, and it used to play fine, so it's not the file's fault. > The problem with multithreaded decoding is that it's hardly to predict > how many frames we need to drop to restore A-V sync. In many cases > mplayerxp will drop unnecessary frames (which could be displayed). > But it seems that latest changes produce more or less smooth frame > dropping for relatively fast machines for me! > What about relatively slow systems - smoothness is unreachable there > so probably it was bad idea to optimize frame dropping for such systems= ! I'm not sure what you mean by fast or slow machines. What would 80-100% CPU load playing DVD count as? > I have an idea to move computing of number of frame to be dropped into > video thread but it will not solve main problem - thread is decoding > frame in non real-time (i.e. part of them is being decoded faster > but some of them - slower than main thread displays them). And as resul= t > - it's hardly to predict when we should initiate frame dropping and whe= re > we should stop it to keep maximal number of decoded frames. (Also not > every frame can be dropped by codec). Only B-frames can be dropped, right? > Still one flaw of framedropping ahead is stalling of main thread > when breakup of PTS in frame queue (due dropped frames) reaches > place to be displayed. In this case main thread will stall > althrough currently decoded frames are not required any > framedropping. (Btw - it's auto regulation of busmastering activity > ;) >=20 > Thus - it would be much better don't use -framedrop key if it's > possible and grow number of buffers for decoding ahead to avoid > local A-V resync instead! I'm already using 1024 buffers, which is enough for most things, except a few particularly nasty DVDs. Using more buffers would mean modifying mplayerxp and shopping for more ram. --=20 M=E5ns Rullg=E5rd mr...@us... |