Re: [Mplayerxp-general] [ANNOUNCE] XP mode with -vo X11, -vo dga

[Nick K. <nic...@ma...>]

Hello, Arpi!

On Sat, 27 Apr 2002 13:48:02 +0200 you wrote:

> Hi,
> 
> > >-vo x11 is slow as hell (mplayerxp drops frames on my Duron-700
> > >with DivX-MPEG4 720x480@30 fps)
> > 
> > If it is 'slow as hell', I would suspect there are problems with the
> > implementation.  When designed and implemented correctly, threaded
> > applications should impose very little, if any, overhead at all.  The
> 
> it has nothing with threads - x11 is slow because it sends images through
> socket and us ethe X server process top copy it into video memory.
> while dga. divix, vesa directly renders into video memory -> faster.
> 
Agree
> on my test machine, celeron 366 with et6000 pci vga, x11 needs 60% drop
> while vesa works without any dropped frame and still has 12% idle cpu
> 
> > reason why threads exist in the first place is because a thread context
> > switch is a lot cheaper than a process context switch.  If you are taking
> it is not true on linux - linux threads are implemented by processes.
> this is why apache 2 is not faster than 1.x on linux
> 
threads are lightweight simply because they don't eat additional memory as in
case of fork. In case of thread mplayerxp has 2 entry point into 1 process but
with fork() we have 2 simultaneously working processes (as in case of 
mplayer's cache).
(Btw, I've found out that 128MB of free PHYSICAL memory is not enough for
fast working of decoding ahead -with vo_x11 - it causes disk swapping for me.
But 200MB - is OK).
> > I am not sure how far you will get with threading if you continue to use
> > mplayer as is.  From the code I have read so far, mplayer is simply not
> > designed with threading in mind.  A brute force method of injecting
> > threads into the structure may not be the best approach.  Seems your
> > performance testing is an indication of this.
> 
> fully agree. this was teh reason of being beside forking instead of being
> against it. mplayerxp really needs a big core redesign/rewrite to be
> efficient with threads.
> 
> the original mplayer was designed to be a single process. no threads, no
> processes, just a single process, implementing cooperative multitasking
> inside, by well queing and controlling the jobs.
> 
> why? it was designed for linux. and linux has 100hz context switch, it means
> 10ms time slices. it is simply not enough for such application, where 33/40
> ms is the whole pipeline time slice from reading to displaying decoded frame.
> and imho threads are only usefull for SMP systems, but (imho) desktop
> systems are mostly UP, not SMP. And, when manipulating big data areas (video
The fact that you don't understand why threads speedup decoding on UP under
Linux caused the forking of mplayerxp. Else xp patch could be applied into mplayer
without any barriers from your side. As you might found - I'm UP user!
But this question was discussed a lot in mplayer-dev-eng.
It was proved by me on multiple benchmarks and I don't want to flame that
again and again.
> data), the bottleneck is usually the system RAM and video memory.
> and, at least on PC, ram cannot be used by more than one CPU at the same
> time, so adding more cpu won't really speed up such things.
It's truth for SIMM, but not for DIMM.
> smp only helps with math calcs where lots of operations are done on small
> amount of data (fits in cpu cache) and the process can be separated to
> independent tasks (to avoid big data interchange between cpus).
> 
> the second thing is stability, and simplicity. as you wrote above, threads
> introduce lots of new problems, like locking, forking/killing threads,
> queueing etc. i wanted to avoid these.
> 
and without any reasons simply because single thread process is main
bottleneck for real-time decoding. What about problems - multithreaded core
of mplayerxp works fine with non-reent demuxer and many other parts of mplayer.
I would say - I try to keep development in the way of compatibility MT core
with non-reent libs.
> anyway, we should keep codecs, demuxers and other thread-independent parts
> compatible, to reduce development/merging time spent on these.
> 
Agree - but I've found that demuxer required to be rewritten in the libmpcodec way.
And ever more - it should be splitted on 2 libraries - libstream and libdemux.
They are independed tasks.
> 
> A'rpi / Astral & ESP-team
> 
> --
> Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
> 
> _______________________________________________
> Mplayerxp-general mailing list
> Mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mplayerxp-general
> 


Best regards! Nick