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

[Nick Kurshev]

Hello, Arpi!

On Sun, 17 Mar 2002 20:04:34 +0100 you wrote:

> Hi,
> 
> > > such slow systems (like p1 or old celerons) usually has no xv-capable card
> > s
> >                                               ^^^^^^^
> > > but dga or vidix or xmga (1 buffers) could work there fine
> > Middle size divx4 can be fitted into 2MB of video upto 7 times.
> 
> please rtfm dr-methods.txt
> 
> you still don't understand...
> if you have a single (1) buffer, you don't have to update the whole buffer
> at each frames, just the chanegd macroblocks.
> at average (<=1000kbit) divx only ~30% of MBs chanegs between 2 frames.
> so it means 300% speedup of video blitting
> and it really matters on slow pci bus / video ram old systems have
> 
> if you have more than 1 buffers (even if they are in video ram) you have to
> refresh all MBs so you lose this advantage of DRm2, and only get one less
> memcpy (maybe) nothing more.
> 
> of course having 1 buffers decreases quality but on p1 mmx who cares...
> 
> and on faster systems it has no sense nor your stuff
> 
> so if we see the things:
> 
>                  1       2         3             4
>             |--------|--------|---------|-----------------------------|
> cpu speed:  slow  ~200mhz   ~400mhz   ~800mhz                       fast
> avg bench:   >100%     >100%    <100%       <100%
> max bench:   >100      >100     >100        <100
> method:     framedrop| dr m2  |dec.ahead| old single-process mplayer
> playback:   jerky      smooth   smoother  smoother
> 
> your threading mess is only usefull at range '3', to make playback smoother
> ( != make playabck possible - it makes no extra performance - just a bit
> better quality)
> 
> it won't help at 1,2 and 4, only at 3
> 
When frame cares only part of scene it's easy frame.
Hard frames cares a full new scene and this method will not help you.

> > > > Every commercial product communicates with GPL'ed kernel.
> > > > So it seems just as stupid limitation.
> > > there are no shared objects nor LGPL
> > > 
> > > ans we'll remove this stupid license as soon as we get rid of things keepe
> > ng
> > > us away from binary packages. but you'd better RTFMing
> > > 
> > Anyway - I can redistribute your sources under GPL as you said.
> > Second - you should make it as soon as possible simply because mplayer has
> > many parts which are GPL'ed - GPL is applicable to PROGRAM which doesn't exi
> > st.
> > (vidix is not a program)
> > It something strange.
> > Anyway you should call something by PROGRAM to which is applied GPL of parts
> > !
> 
> heh?
> 
> you should actually program instead of thinking about what is program :)
> 
I would be glad to program a program.
> 
> A'rpi / Astral & ESP-team
> 
> --
> Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> 


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/20020317/c7d4c36a/attachment.pgp>