[MPlayer-dev-eng] [patch] vo_directfb.c and cz language file

[Jiri Svoboda]

> > I've seen NAS uses simple pthread primitives (mutex join).  So, I 
> > guess it's OK to do pthread stuff within a ao/vo module ?  
> Won't it be 
> > problematic if NAS+directfb are used at the same time?
> 
> I never tried NAS, but i'm sure pthread will cause trouble. 
> mplayer optionally runs in 1, 2 or 3 processes using fork() 
> (one extra for gui and one extra for -cache). besides it, the 
> win32 stuff allow using pthread, if the codec uses the 
> windows thread functions (it's a wrapper to pthread). i don't 
> know which codecs use it, but it needs pthread to be linked. 
> and, afaik, sdl internally uses pthread for its buffering stuff.
> 
> so, some pthread experts should explain what conditions are 
> required to safe usage of fork() and multiple pthread() stuff.
> 

Let me explain what the patch does:
The pthread stuff:
If there is a -flip_thread oprion to set other than zero it creates
new thread for performing flip operation. Otherwise there is not
new thread. This is because flipping takes some processor time which 
can be used for decoding - did somebody any benchmark?
I guess some kind of benchmark which will tell us how much time is spend
in each part of video decoding/displaying - decoding in codec,
draw_frame/draw_slice and flip (blitting) could point some bottlenecks
and recommendation for libvo2.

Another part of patch is adding of definition of YUV format, which was
introduced
in new DirectFB version just for compatibility reasons.

And the last part (here I need Your recommendation) was changing
from memcpy to fast_memcpy. Is this good or should not be dome?

			JS