[MPlayer-dev-eng] MplayerXP vs Mplayer. Hall of truth.

[Arpi]

Hi,

> > so even if you think (say) it's 5000% faster, it won't allow playback on
> 300% please didn't distort digits
these numbers doesn't matter here - they measure things but not performance

> > cpus where old mplayer (==avg benchmark) can't play without drop.
> > 
> > your patch does no more than smoother playback on fast enough (avg<100%) b
> ut
> > not too fast (max>100%) systems.
> > 
> Yes! you are right!
sure ;)

> > also note, taht your max bench code reporetd ~480% cpu usage whan playing
> > I-frames only vcd-sized mpeg1 on p4-1.8ghz with mga_vid...
> > 
> That's ok for 0.0.0 version - I should clean that, sorry!

it was in mplayer cvs (near to 0.70 or even 1.0) for a month

> Any independed cpu meter shows that xp loads cpu much less of mplayer.

they are all confused by threads and usleep
test my '3pm' mp3 player. it is reported as using 0% cpu by top, ps etc...

> > don't tell me that i need p4-8ghz to be abel to playback vcd :)
> > the whole decoding+libvo process was under 12% total...
> > 
> > > My idea is have them predecoded in pauses (when main process sleeps).
> > > So there is a big speedup. - Monotonous cpu loading against of peaked lo
> adin
> > > g.
> > ideas are nice things. but if you check mplayer code, there are no pauses
> > when decoding frame tooks longer than 1/fps seconds, it will delay next
> > frame a bit. it is called 'drifted delay' by kabi...
> > yes, it isn't so smooth as your but works and not slower.
> But what about 250% per B-frame and 50% per other frames?
> It doesn't matter what causes these 250% - media reading delays or other
> (concurent tasks)
if yo uhave 250% b frames, the movie is unplayable...
92% of frames are P or B frames (you lie whan say B eats more than P - both
ues MC, only I frames are fast) so it means you have ~200% avg bench...

> > rtfm docs/tech/dr-methods.txt
> > 
> DR is already works and there is nothing to do except writting of new driver
> s :(

DR wiht single buffer really helps on slow systems where video bandwith is
the bottleneck, so on p1 and slow celerons. m2dr+dga really achieves dixiv
playback on tehse without framedrops!
your decoding ahead won't work wiht single buffer so you lose the biggest
advantage of direct rendering - updating avg 30% of framebuffer instead of
memcpy the whole

> > or my oldmail heer about DR (the file contains it a bit extended by
> > implementation details used in libmpcodecs)
> > 
> > Nick:
> > "* Cleaning program to be GPL'ed.
> >   (You can redistribute it in binary form if you want)"
> > - you should remove libmp1e, it is not used at all, just left in main cvs
> o'k
> > - you should at least ask us, at least my code is not GPL yet.
> Arpi, it seems that you already several years violate GPL, isn't?
no.

> Did you remeber that noise which was around MS licence on etu
> where MS called GPL'ed licence like a virus.
> Please look at this licence 2.b:
please look at mplayer license

> This means that any program which contain GPL'ed code MUST BE whole GPL!
mplayer is not a program!
it is a collection of various sources, gpl and non-gpl ones
this is why distributing it in compiled form is forbidden...

the good old trick used by ml3labe and some other projects to solve fuckin'
gpl restrictions

YOU will break gpl by allowing users to distribute it in compiled form :)

> FYI: It's viral nature of GPL.
> (Note: mplayer contains GPL'ed code - my code at least (vidix,fastmemcpy)!!!
yes


A'rpi / Astral & ESP-team

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