[MPlayer-dev-eng] DECODING AHEAD - (Initialy Michael's idea)

[Arpi]

Hi,

> > for very long time...
> Not sure!
So sure

> > > So Arpi should decide which way he preferes for mplayer in the future.
> > > Maybe after release? Or maybe in the forked branch?
> > fork. it is not a question.
> > as you said, it needs big rewrite of a-v sync, libvo, decoding and so on.
> libvo doesn't require rewritting in this case
why?

> > and probably never will work with X drivers, as X doesn't like calling fro
> m
> > interrupts.
> Arpi, I have working stuff with timer callback even under WinNT, so X11
> is not a problem a long ago. It works already 2 year without even hints on p
> roblems!
> And it on glibc level - not on X11 one. So don't mix please linux-kernel
> and X11 as application.

X11 is not threadsafe. if an X call is interrupted and from the interrupt
(signal handler) you call another X11 functon, you'll get async i/o reply and
X11 hangup. it happened also in mplayer GUI before i moved update function
from timer interrupt (sigalarm handler) to mainloop.

i don't know about Win NT, but hey, we 're under linux, so who cares???

> > > Anyway, it should be mplayer2, imho.
> > aviplay2 :)
> > 
> > just a note: fps is not constant. rtfs libmpdemux/video.c
> > there are lots of problems come with "your" idea.
> > 
> But other developers have successfuly solved them!
Yes. But they have different core design. They have threaded players.

> > anyway, i'll continue with current mplayer, implementing direct render for
> > all codecs and libvo. i don't believe your idea could help so lot. for slo
> w
> > systems direct render is faster, fast ones are fast enough.
> In this case - what you can suggest me for realtime playback of that movie
> if I have 30% average cpu loading and 150% for B-frame decoding?
rm -f that movie.
or fix your max benchmark calc code. it seems to be broken.
b frames aren't harder to decode than P frames. only I frames are faster but
they are rare (2/sec for mpeg and 0.1/sec for avg divx)

> mplayer has interruptible playback in many cases and it's bad.
> We spend a lot of our time to speedup it but it loses frames as before
> unlike MS-MediaPlayer8. (Which provides SMOOTH playback of MPEG4 movies
> on Cel1-266 where mplayer provides the same interruptible playback)
because of it does direct rendering.

> Currently we can solve that and make it by perfect player even on slow
> machines but you are against of this idea.
yes

> Do you have also any reasonable arguments (except - this brings problems
> and similar)?
a-v sync won't work as now, it have to be redesigned to ger rid of variable
fps and its delay
X11 reentrancy should be solved (threaded player? argh)
direct rendering?

if you say it's easy, do it, but do not commit. send a patch, so it can be
tested and if it's clean enough, it may be commited. anyway i doubt it will
ever work without big ugly hacks (like your direct rendering) or rewrites.


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu