Re: [Mplayer-matrox] Problems with mplayer1.0-pre1

[<sy...@sc...>]

On Mon, Sep 08, 2003 at 03:48:43AM +0200, kv...@st... wrote:
> Unfortunately the mainboard stopped working after experimenting with a
> faulty CPU. So now im stuck on a p3 450Mhz untill i get a positive
> cash-flow and can buy a new mainboard im stuck with a computer that is
> too slow to show movies on the tv without skips. Im still hoping there
> will be a fbdev/directfb/dfbmga-update or general update of mplayer1 so
> that tv-output will be possible using my
> low-efficiency-brand-equipment.

I think P3 450 should be sufficient. -vsync option will cause a lot of
dropped frames. To get smooth playback without -vsync you need triple
buffering suppport. For triple buffering you need DirectFB >=3D 0.9.18 an=
d
mplayer from main cvs branch. AFAIK 1.0-pre stuff should be based on the
main branch.

> Im also using the mga_vid-module cause
> this gives me flawless, skipless video output on my lcd with most types
> divx and alterations.=20

You can use DirectFB for this too so you don't necessarily need mga_vid.
-vo directfb or -vo dfbmga:nocrtc2:bes should provide the same
functionality. The triple buffering stuff applies here too. mga_vid uses
triple buffering.

> What will happen to Ville Syrj=E4l=E4's patches in upcoming kernels? Im
> really eager to try out features in the 2.5 and 2.6 brand of the
> linux-kernel. I can't find any updated patchsets for those kernels.

To clear things up those patches aren't originally by me. I have added
second head stuff and other stuff to them though.

Anyway 2.4.22 should include vsync support out of the box. The full-memor=
y
patch has some issues regarding console acceleration and hw cursor so it
won't go in.

> and i think that support for a close to
> obsolete brand of cards (g200/400/550andallthose) lay mainly in
> video-output
> (since the weak support of opengl in the current drivers
> (and in the cards themselves))

FWIW I've fixed a lot of bugs and added new features to the mga DRI
drivers lately. But still the cards are slow and since Matrox don't want
to release full specs or produce better WARP microcode there's very
little anyone can do to add some missing features. The cards could
probably do quite a bit more with more flexible microcode.

--=20
Ville Syrj=E4l=E4
sy...@sc...
http://www.sci.fi/~syrjala/