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

Nick Kurshev nickols_k at mail.ru
Mon Feb 25 12:49:02 CET 2002


Hello, Arpi!

On Mon, 25 Feb 2002 12:47:25 +0100 you wrote:

> Hi,
> 
> > Anyway - implementing of such changes requires losing of CVS stability (prob
> > ably).
> for very long time...
Not 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
> and probably never will work with X drivers, as X doesn't like calling from
> 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 problems!
And it on glibc level - not on X11 one. So don't mix please linux-kernel
and X11 as application.
> 
> > 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!

> 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 slow
> 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?
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)
Currently we can solve that and make it by perfect player even on slow
machines but you are against of this idea.

Do you have also any reasonable arguments (except - this brings problems
and similar)?
> 
> 
> A'rpi / Astral & ESP-team
> 
> 

Best regards! Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20020225/653738bb/attachment.pgp>


More information about the MPlayer-dev-eng mailing list