diff options
| author | gabucino <gabucino@b3059339-0415-0410-9bf9-f77b7e298cf2> | 2001-08-24 18:48:13 +0000 |
|---|---|---|
| committer | gabucino <gabucino@b3059339-0415-0410-9bf9-f77b7e298cf2> | 2001-08-24 18:48:13 +0000 |
| commit | 8fae9da08683f88f7ad1ec2649830b6d0b2da483 (patch) | |
| tree | 58e06ab8fa7cc62f246d4fd5c6e10a06215880ef /DOCS/video.html | |
| parent | 5a363c0e8498572594026612099227c3a1b68479 (diff) | |
| download | mpv-8fae9da08683f88f7ad1ec2649830b6d0b2da483.tar.bz2 mpv-8fae9da08683f88f7ad1ec2649830b6d0b2da483.tar.xz | |
*** empty log message ***
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@1683 b3059339-0415-0410-9bf9-f77b7e298cf2
Diffstat (limited to 'DOCS/video.html')
| -rw-r--r-- | DOCS/video.html | 969 |
1 files changed, 476 insertions, 493 deletions
diff --git a/DOCS/video.html b/DOCS/video.html index ffabe1f1e6..3c10cbd72a 100644 --- a/DOCS/video.html +++ b/DOCS/video.html @@ -1,115 +1,113 @@ <HTML> - <BODY> -<PRE> - - <A NAME=2.2.1>2.2.1. Video output devices</A> - - General: - - x11: X11 with optional SHM extension - - xv: X11 using overlays with the Xvideo extension (hardware YUV & scaling) - - gl: OpenGL renderer, so far works only with : - - all cards with Utah-GLX - - Matrox cards with X/DRI >=4.0.3 - - Radeon with X/DRI CVS - - dga: X11 DGA extension - - fbdev:Output to general framebuffers - - svga: Output to SVGAlib - - sdl: 1.1.7 : supports software scaling - 1.1.8 : supports Xvideo (hardware scaling/fullscreen) - 1.2.0 : supports AAlib (-vo aa is very recommended, see below!) - - ggi: similar to SDL - - aa: textmode rendering with AAlib - - Card specific: - - mga: Matrox G200/G400 hardware YUV overlay via the mga_vid device - - xmga: Matrox G200/G400 overlay (mga_vid) in X11 window - (Xv emulation on X 3.3.x !) - - syncfb: Matrox G400 YUV support on framebuffer (obsoleted, use mga/xmga) - - 3dfx: Voodoo2/3 hardware YUV (/dev/3dfx) support (not yet tested, maybe - broken) - - Special: - - png: PNG files output (use -z switch to set compression) - - pgm: PGM files output (for testing purposes or ffmpeg encoding) - - md5: MD5sum output (for MPEG conformance tests) - - odivx:OpenDivX AVI File writer (use -br to set encoding bitrate) - - null: Null output (for speed tests/benchmarking) - - NOTE: check the following subsections for details and requirements! - - - <A NAME=2.2.1.1>2.2.1.1. MTRR</A> +<P><B><A NAME=2.2.1>2.2.1. Video output devices</A></B></P> - It is VERY recommended to set MTRR registers up properly, because they can - give a big performance boost. First you have to find the base address. - You have 3 ways to find it: +<TABLE BORDER=0> - - from X11 startup messages, for example: +<TD COLSPAN=4><P><B>General:</B></P></TD><TR> - (--) SVGA: PCI: Matrox MGA G400 AGP rev 4, Memory @ 0xd8000000, 0xd4000000 - (--) SVGA: Linear framebuffer at 0xD8000000 +<TD> </TD><TD VALIGN=top>x11</TD><TD> </TD><TD>X11 with optional SHM extension</TD><TR> +<TD></TD><TD VALIGN=top>xv</TD><TD></TD><TD>X11 using overlays with the Xvideo extension (hardware YUV & scaling)</TD><TR> +<TD></TD><TD VALIGN=top>gl</TD><TD></TD><TD>OpenGL renderer, so far works only with: +<UL><LI>all cards with Utah-GLX +<LI>Matrox cards with X/DRI >=4.0.3 +<LI>Radeon with X/DRI CVS</UL></TD><TR> +<TD></TD><TD VALIGN=top>dga</TD><TD></TD><TD>X11 DGA extension</TD><TR> +<TD></TD><TD VALIGN=top>fbdev</TD><TD></TD><TD>Output to general framebuffers</TD><TR> +<TD></TD><TD VALIGN=top>svga</TD><TD></TD><TD>Output to SVGAlib</TD><TR> +<TD></TD><TD VALIGN=top>sdl</TD><TD></TD><TD> + <CODE>1.1.7:</CODE> supports software scaling<BR> + <CODE>1.1.8:</CODE> supports Xvideo (hardware scaling/fullscreen)<BR> + <CODE>1.2.0:</CODE> supports AAlib (-vo aa is very recommended, see below!)</TD><TR> +<TD></TD><TD VALIGN=top>ggi</TD><TD></TD><TD>similar to SDL</TD><TR> +<TD></TD><TD VALIGN=top>aa</TD><TD></TD><TD>textmode rendering with AAlib</TD><TR> - - from /proc/pci (use lspci -v command): +<TD COLSPAN=4><P><B>Card specific:</B></P></TD><TR> - 01:00.0 VGA compatible controller: Matrox Graphics, Inc.: Unknown device 0525 - Memory at d8000000 (32-bit, prefetchable) - - - from mga_vid kernel driver messages (use dmesg): +<TD> </TD><TD VALIGN=top>mga</TD><TD> </TD><TD>Matrox G200/G400 hardware YUV overlay via the mga_vid device</TD><TR> +<TD></TD><TD VALIGN=top>xmga</TD><TD></TD><TD>Matrox G200/G400 overlay (mga_vid) in X11 window<BR> +(<I>Xv emulation on X 3.3.x!</I>)</TD><TR> +<TD></TD><TD VALIGN=top>syncfb</TD><TD></TD><TD>Matrox G400 YUV support on framebuffer (obsoleted, use mga/xmga)</TD><TR> +<TD></TD><TD VALIGN=top>3dfx</TD><TD></TD><TD>Voodoo2/3 hardware YUV (/dev/3dfx) support (not yet tested, maybe +broken)</TD><TR> - mga_mem_base = d8000000 +<TD COLSPAN=4><P><B>Special:</B></P></TD><TR> - Then let's find the memory size. This is very easy, just convert video ram - size to hexadecimal, or use this table: +<TD> </TD><TD VALIGN=top>png</TD><TD> </TD><TD>PNG files output (use -z switch to set compression)</TD><TR> +<TD></TD><TD VALIGN=top>pgm</TD><TD></TD><TD>PGM files output (for testing purposes or ffmpeg encoding)</TD><TR> +<TD></TD><TD VALIGN=top>md5</TD><TD></TD><TD>MD5sum output (for MPEG conformance tests)</TD><TR> +<TD></TD><TD VALIGN=top>odivx</TD><TD></TD><TD>OpenDivX AVI File writer (use -br to set encoding bitrate)</TD><TR> +<TD></TD><TD VALIGN=top>null</TD><TD></TD><TD>Null output (for speed tests/benchmarking)</TD><TR> +</TABLE> +<P>NOTE: <I>check the following subsections for details and requirements!</I></P> - 1 MB 0x100000 - 2 MB 0x200000 - 4 MB 0x400000 - 8 MB 0x800000 - 16 MB 0x1000000 - 32 MB 0x2000000 +<P><B><A NAME=2.2.1.1>2.2.1.1. MTRR</A></B></P> - You know base address and memory size, let's setup mtrr registers! - For example, for the Matrox card above (base=0xd8000000) with 32MB - ram (size=0x2000000) just execute: +<P>It is VERY recommended to set MTRR registers up properly, because they can +give a big performance boost. First you have to find the base address. +You have 3 ways to find it:</P> +<P><UL> +<LI>from X11 startup messages, for example: +<P><CODE>(--) SVGA: PCI: Matrox MGA G400 AGP rev 4, Memory @ 0xd8000000, 0xd4000000<BR> +(--) SVGA: Linear framebuffer at 0xD8000000</CODE></P> +<LI>from /proc/pci (use lspci -v command): +<P><TABLE> +<TD VALIGN=top><CODE>01:00.0</CODE></TD><TD><CODE>VGA compatible controller: Matrox Graphics, Inc.: Unknown device 0525</CODE></TD><TR> +<TD></TD><TD><CODE>Memory at d8000000 (32-bit, prefetchable)</CODE></TD><TR> +</TABLE></P></CODE> +<LI>from mga_vid kernel driver messages (use dmesg): +<P><CODE>mga_mem_base = d8000000</CODE></P> +</UL></P> - echo "base=0xd8000000 size=0x2000000 type=write-combining" >| /proc/mtrr +<P>Then let's find the memory size. This is very easy, just convert video ram +size to hexadecimal, or use this table:</P> +<TABLE BORDER=0> +<TD> </TD><TD>1 MB</TD><TD WIDTH=10%></TD><TD>0x100000</TD><TR> +<TD></TD><TD>2 MB</TD><TD></TD><TD>0x200000</TD><TR> +<TD></TD><TD>4 MB</TD><TD></TD><TD>0x400000</TD><TR> +<TD></TD><TD>8 MB</TD><TD></TD><TD>0x800000</TD><TR> +<TD></TD><TD>16 MB</TD><TD></TD><TD>0x1000000</TD><TR> +<TD></TD><TD>32 MB</TD><TD></TD><TD>0x2000000</TD><TR> +</TABLE> - Not all CPUs support MTRRs. For example older K6-2's [around 266Mhz, - stepping 0] doesn't support MTRR, but stepping 12's do ('cat /proc/cpuinfo' - to check it). +<P>You know base address and memory size, let's setup mtrr registers! +For example, for the Matrox card above (base=0xd8000000) with 32MB +ram (size=0x2000000) just execute:</P> - <A NAME=2.2.1.2>2.2.1.2. Xv</A> - Under XFree86 4.0.2 or newer, you can use your card's hardware YUV routines - using the XVideo extension. This is what the option '-vo xv' uses. - In order to make this work, be sure to check the following: - - You have to use XFree86 4.0.2 or newer (former versions don't have XVideo) - - Your card actually supports harware acceleration (modern cards do) - - X loads the XVideo extension, it's something like this: +<P><CODE> echo "base=0xd8000000 size=0x2000000 type=write-combining" >| /proc/mtrr</CODE></P> - (II) Loading extension XVideo +<P>Not all CPUs support MTRRs. For example older K6-2's [around 266Mhz, +stepping 0] doesn't support MTRR, but stepping 12's do ('<CODE>cat /proc/cpuinfo</CODE>' +to check it).</P> +<P><B><A NAME=2.2.1.2>2.2.1.2. Xv</A></B></P> - in /var/log/XFree86.0.log - - - NOTE : this loads only the XFree86's extension. In a good install, this is - always loaded, and doesn't mean that the _card's_ XVideo support is - loaded! - - - Your card has Xv support under Linux. To check, try 'xvinfo', it is the - part of the XFree86 distribution. It should display a long text, similar - to this: +<P>Under XFree86 4.0.2 or newer, you can use your card's hardware YUV routines +using the XVideo extension. This is what the option '-vo xv' uses. +In order to make this work, be sure to check the following:</P> +<P><UL> +<LI>You have to use XFree86 4.0.2 or newer (former versions don't have XVideo) +<LI>Your card actually supports harware acceleration (modern cards do) +<LI>X loads the XVideo extension, it's something like this: +<P><CODE> (II) Loading extension XVideo</CODE></P> +<P>in /var/log/XFree86.0.log</P> +<P>NOTE: this loads only the XFree86's extension. In a good install, this is +always loaded, and doesn't mean that the _card's_ XVideo support is loaded!</P> + +<LI>Your card has Xv support under Linux. To check, try 'xvinfo', it is the +part of the XFree86 distribution. It should display a long text, similar +to this: +<PRE> X-Video Extension version 2.2 screen #0 Adaptor #0: "Savage Streams Engine" @@ -133,239 +131,234 @@ number of planes: 3 type: YUV (planar) (...etc...) +</PRE> +<P>It must support YUY2 packed, and YV12 planar pixel formats to be +usable with <B>MPlayer</B>.</P> - It must support YUY2 packed, and YV12 planar pixel formats to be - usable with <B>MPlayer</B>. - - - And finally, check if <B>MPlayer</B> was compiled with 'xv' support. - ./configure prints this. - - - <A NAME=2.2.1.2.1>2.2.1.2.1. 3dfx cards</A> - - Older 3dfx drivers were known to have problems with XVideo acceleration, - it didn't support either YUY2 or YV12, and so. Verify that you have - XFree86 version 4.1.0 or greater, it works ok. Alternatively, you can use - <A HREF="http://dri.sourceforge.net">DRI</A> cvs. - If you experience strange effects using -vo xv, try SDL (it has XVideo too) - and see if it helps. Check the <A HREF="#2.2.1.4">SDL section</A> for details. - - - <A NAME=2.2.1.2.2>2.2.1.2.2. S3 cards</A> - - S3 Savage3D's should work fine, but for Savage4, use XFree86 version 4.0.3 - or greater. As for S3 Virge.. sell it. - - - <A NAME=2.2.1.2.3>2.2.1.2.3. nVidia cards</A> +<LI>And finally, check if <B>MPlayer</B> was compiled with 'xv' support. +./configure prints this. - nVidia isn't a very good choice under Linux.. You'll have to use the - binary nVidia driver, available at nVidia's website. The standard X - driver doesn't support XVideo for these cards, due to nVidia's closed - sources/specifications. +</UL></P> - - Riva128 cards don't have XVideo support even with the nvidia driver :( - Complain to NVidia. +<P><B><A NAME=2.2.1.2.1>2.2.1.2.1. 3dfx cards</A></B></P> +<P>Older 3dfx drivers were known to have problems with XVideo acceleration, +it didn't support either YUY2 or YV12, and so. Verify that you have +XFree86 version 4.1.0 or greater, it works ok. Alternatively, you can use +<A HREF="http://dri.sourceforge.net">DRI</A> cvs. +If you experience strange effects using -vo xv, try SDL (it has XVideo too) +and see if it helps. Check the <A HREF="#2.2.1.4">SDL section</A> for details.</P> - <A NAME=2.2.1.2.4>2.2.1.2.4. ATI cards</A> - The GATOS driver has VSYNC enabled by default. It means that decoding speed - (!) is synced to the monitor's refresh rate. If playing seems to be slow, try - disabling VSYNC somehow, or set refresh rate to n*(fps of the movie) Hz. +<P><B><A NAME=2.2.1.2.2>2.2.1.2.2. S3 cards</A></B></P> +<P>S3 Savage3D's should work fine, but for Savage4, use XFree86 version 4.0.3 +or greater. As for S3 Virge.. sell it.</P> - <A NAME=2.2.1.3>2.2.1.3. DGA</A> +<P><B><A NAME=2.2.1.2.3>2.2.1.2.3. nVidia cards</A></B></P> - <A NAME=2.2.1.3.1>2.2.1.3.1. Summary</A> +<P>nVidia isn't a very good choice under Linux.. You'll have to use the +binary nVidia driver, available at nVidia's website. The standard X +driver doesn't support XVideo for these cards, due to nVidia's closed +sources/specifications.</P> - This document tries to explain in some words what DGA is in general and - what the DGA video output driver for mplayer can do (and what it can't). +<P><UL><LI>Riva128 cards don't have XVideo support even with the nvidia driver :( +Complain to NVidia.</UL></P> - <A NAME=2.2.1.3.2>2.2.1.3.2. What is DGA</A> +<P><B><A NAME=2.2.1.2.4>2.2.1.2.4. ATI cards</A></B></P> - DGA is short for Direct Graphics Access and is a means for a program to - bypass the X-Server and directly modifying the framebuffer memory. - Technically spoken this happens by mapping the framebuffer memory into - the memory range of your process. This is allowed by the kernel only - if you have superuser privileges. You can get these either by logging in - as root or by setting the suid bit on the mplayer excecutable (NOT - recommended!). +<P>The GATOS driver has VSYNC enabled by default. It means that decoding speed +(!) is synced to the monitor's refresh rate. If playing seems to be slow, try +disabling VSYNC somehow, or set refresh rate to n*(fps of the movie) Hz.</P> - There are two versions of DGA: DGA1 is used by XFree 3.x.x and DGA2 was - introduced with XFree 4.0.1. - DGA1 provides only direct framebuffer access as described above. For - switching the resolution of the video signal you have to rely on the - XVidMode extension. +<P><B><A NAME=2.2.1.3>2.2.1.3. DGA</A></B></P> - DGA2 incorporates the features of XVidMode extension and also allows - switching the depth of the display. So you may, although basically - running a 32 bit depth XServer, switch to a depth of 15 bits and vice - versa. +<P><B><A NAME=2.2.1.3.1>2.2.1.3.1. Summary</A></B></P> - However DGA has some drawbacks. It seems it is somewhat dependent on the - graphics chip you use and on the implementation of the XServer's video - driver that controls this chip. So it does not work on every system ... +<P>This document tries to explain in some words what DGA is in general and +what the DGA video output driver for mplayer can do (and what it can't).</P> -<A NAME=2.2.1.3.3>2.2.1.3.3. Installing DGA support for <B>MPlayer</B></A> +<P><B><A NAME=2.2.1.3.2>2.2.1.3.2. What is DGA</A></B></P> - First make sure X loads the DGA extension, see in /var/log/XFree86.0.log : +<P>DGA is short for Direct Graphics Access and is a means for a program to +bypass the X-Server and directly modifying the framebuffer memory. +Technically spoken this happens by mapping the framebuffer memory into +the memory range of your process. This is allowed by the kernel only +if you have superuser privileges. You can get these either by logging in +as root or by setting the suid bit on the mplayer excecutable (NOT +recommended!).</P> +<P>There are two versions of DGA: DGA1 is used by XFree 3.x.x and DGA2 was +introduced with XFree 4.0.1.</P> - (II) Loading extension XFree86-DGA +<P>DGA1 provides only direct framebuffer access as described above. For +switching the resolution of the video signal you have to rely on the +XVidMode extension.</P> +<P>DGA2 incorporates the features of XVidMode extension and also allows +switching the depth of the display. So you may, although basically +running a 32 bit depth XServer, switch to a depth of 15 bits and vice +versa. </P> - See, XFree86 4.0.x or greater is VERY RECOMMENDED! - <B>MPlayer</B>'s DGA driver is autodetected on ./configure, or you can force it - with --enable-dga. +<P>However DGA has some drawbacks. It seems it is somewhat dependent on the +graphics chip you use and on the implementation of the XServer's video +driver that controls this chip. So it does not work on every system ...</P> - If the driver couldn't switch to a smaller resolution, experiment with - switches -vm (only with X 3.3.x), -fs, -bpp, -zoom to find a video mode that - the movie fits in. There is no converter right now.. :( - Become ROOT. DGA needs root access to be able to write directly video memory. - If you want to run it as user, then install <B>MPlayer</B> SUID root: +<P><B><A NAME=2.2.1.3.3>2.2.1.3.3. Installing DGA support for MPlayer</A></B></P> +<P>First make sure X loads the DGA extension, see in /var/log/XFree86.0.log:</P> - chown root /usr/local/bin/mplayer - chmod 750 /usr/local/bin/mplayer - chmod +s /usr/local/bin/mplayer +<P> <CODE>(II) Loading extension XFree86-DGA</CODE></P> +<P>See, XFree86 4.0.x or greater is VERY RECOMMENDED! +<B>MPlayer</B>'s DGA driver is autodetected on ./configure, or you can force it +with --enable-dga.</P> - Now it works as a simple user, too. +<P>If the driver couldn't switch to a smaller resolution, experiment with +switches -vm (only with X 3.3.x), -fs, -bpp, -zoom to find a video mode that +the movie fits in. There is no converter right now.. :(</P> +<P>Become ROOT. DGA needs root access to be able to write directly video memory. +If you want to run it as user, then install <B>MPlayer</B> SUID root:</P> - !!!! BUT STAY TUNED !!!! - This is a BIG security risk! Never do this on a server or on a computer - can be accessed by more people than only you because they can gain root - privilegies through suid root mplayer. - !!!! SO YOU HAVE BEEN WARNED ... !!!! +<P><CODE> + <CODE>chown root /usr/local/bin/mplayer<BR> + <CODE>chmod 750 /usr/local/bin/mplayer<BR> + <CODE>chmod +s /usr/local/bin/mplayer<BR></CODE></P> - Now use '-vo dga' option, and there you go! (hope so:) - You should also try if the '-vo sdl:dga' option works for you! It's much - faster!!! +<P>Now it works as a simple user, too.</P> - <A NAME=2.2.1.3.4>2.2.1.3.4. Resolution switching</A> +<P><B>!!!! BUT STAY TUNED !!!!</B><BR> +This is a <B>BIG</B> security risk! Never do this on a server or on a computer +can be accessed by more people than only you because they can gain root +privilegies through suid root mplayer.<BR> +<B>!!!! SO YOU HAVE BEEN WARNED ... !!!!</B></P> - The DGA driver allows for switching the resolution of the output signal. - This avoids the need for doing (slow) software scaling and at the same - time provides a fullscreen image. Ideally it would switch to the exact - resolution (except for honouring aspect ratio) of the video data, but the - XServer only allows switching to resolutions predefined in - /etc/X11/XF86Config (/etc/X11/XF86Config-4 for XFree 4.0.X respectively). - Those are defined by so-called modelines and depend on the capabilites - of your video hardware. The XServer scans this config file on startup and - disables the modelines not suitable for your hardware. You can find - out which modes survive with the X11 log file. It can be found at: - /var/log/XFree86.0.log - See appendix A for some sample modeline definitions. +<P>Now use '-vo dga' option, and there you go! (hope so:) +You should also try if the '-vo sdl:dga' option works for you! It's much +faster!!!</P> +<P><B><A NAME=2.2.1.3.4>2.2.1.3.4. Resolution switching</A></B></P> - <A NAME=2.2.1.3.5>2.2.1.3.5. DGA & <B>MPlayer</B></A> +<P>The DGA driver allows for switching the resolution of the output signal. +This avoids the need for doing (slow) software scaling and at the same +time provides a fullscreen image. Ideally it would switch to the exact +resolution (except for honouring aspect ratio) of the video data, but the +XServer only allows switching to resolutions predefined in +<CODE>/etc/X11/XF86Config</CODE> (<CODE>/etc/X11/XF86Config-4</CODE> for XFree 4.0.X respectively). +Those are defined by so-called modelines and depend on the capabilites +of your video hardware. The XServer scans this config file on startup and +disables the modelines not suitable for your hardware. You can find +out which modes survive with the X11 log file. It can be found at: +<CODE>/var/log/XFree86.0.log</CODE>.</P> +<P>See appendix A for some sample modeline definitions.</P> - DGA is used in two places with <B>MPlayer</B>: The SDL driver can be made to make - use of it (-vo sdl:dga) and within the DGA driver (-vo dga). - The above said is true for both; in the following sections I'll explain - how the DGA driver for <B>MPlayer</B> works. +<P><B><A NAME=2.2.1.3.5>2.2.1.3.5. DGA & MPlayer</A></B></P> +<P>DGA is used in two places with <B>MPlayer</B>: The SDL driver can be made to make +use of it (-vo sdl:dga) and within the DGA driver (-vo dga). +The above said is true for both; in the following sections I'll explain +how the DGA driver for <B>MPlayer</B> works.</P> - <A NAME=2.2.1.3.6>2.2.1.3.6. Features of the DGA driver</A> +<P><B><A NAME=2.2.1.3.6>2.2.1.3.6. Features of the DGA driver</A></B></P> - The DGA driver is invoked by specifying -vo dga at the command line. - The default behaviour is to switch to a resolution matching the original - resolution of the video as close as possible. It deliberately ignores the - -vm and -fs switches (enabling of video mode switching and fullscreen) - - it always tries to cover as much area of your screen as possible by switching - the video mode, thus refraining to use a single additional cycle of your CPU - to scale the image. - If you don't like the mode it chooses you may force it to choose the mode - matching closest the resolution you specify by -x and -y. - By providing the -v option, the DGA driver will print, among a lot of other - things, a list of all resolutions supported by your current XF86-Config - file. - Having DGA2 you may also force it to use a certain depth by using the -bpp - option. Valid depths are 15, 16, 24 and 32. It depends on your hardware - whether these depths are natively supported or if a (possibly slow) - conversion has to be done. +<P>The DGA driver is invoked by specifying -vo dga at the command line. +The default behaviour is to switch to a resolution matching the original +resolution of the video as close as possible. It deliberately ignores the +-vm and -fs switches (enabling of video mode switching and fullscreen) - +it always tries to cover as much area of your screen as possible by switching +the video mode, thus refraining to use a single additional cycle of your CPU +to scale the image. +If you don't like the mode it chooses you may force it to choose the mode +matching closest the resolution you specify by -x and -y. +By providing the -v option, the DGA driver will print, among a lot of other +things, a list of all resolutions supported by your current XF86-Config +file. +Having DGA2 you may also force it to use a certain depth by using the -bpp +option. Valid depths are 15, 16, 24 and 32. It depends on your hardware +whether these depths are natively supported or if a (possibly slow) +conversion has to be done.</P> - If you should be lucky enough to have enough offscreen memory left to - put a whole image there, the DGA driver will use doublebuffering, which - results in much smoother movie replaying. It will tell you whether double- - buffering is enabled or not. - - Doublebuffering means that the next frame of your video is being drawn in - some offscreen memory while the current frame is being displayed. When the - next frame is ready, the graphics chip is just told the location in memory - of the new frame and simply fetches the data to be displayed from there. - In the meantime the other buffer in memory will be filled again with new - video data. - - Doublebuffering may be switched on by using the option -double and may be - disabled with -nodouble. Current default option is to disable - doublebuffering. When using the DGA driver, onscreen display (OSD) only - works with doublebuffering enabled. However, enabling doublebuffering may - result in a big speed penalty (on my K6-II+ 525 it used an additional 20% of - CPU time!) depending on the implementation of DGA for your hardware. +<P>If you should be lucky enough to have enough offscreen memory left to +put a whole image there, the DGA driver will use doublebuffering, which +results in much smoother movie replaying. It will tell you whether double- +buffering is enabled or not.</P> + +<P>Doublebuffering means that the next frame of your video is being drawn in +some offscreen memory while the current frame is being displayed. When the +next frame is ready, the graphics chip is just told the location in memory +of the new frame and simply fetches the data to be displayed from there. +In the meantime the other buffer in memory will be filled again with new +video data.</P> + +Doublebuffering may be switched on by using the option -double and may be +disabled with -nodouble. Current default option is to disable +doublebuffering. When using the DGA driver, onscreen display (OSD) only +works with doublebuffering enabled. However, enabling doublebuffering may +result in a big speed penalty (on my K6-II+ 525 it used an additional 20% of +CPU time!) depending on the implementation of DGA for your hardware.</P> - <A NAME=2.2.1.3.7>2.2.1.3.7. Speed issues</A> +<P><B><A NAME=2.2.1.3.7>2.2.1.3.7. Speed issues</A></B></P> - Generally spoken, DGA framebuffer access should be at least as fast as using - the X11 driver with the additional benefit of getting a fullscreen image. - The percentage speed values printed by mplayer have to be interpreted with - some care, as for example, with the X11 driver they do not include the time - used by the X-Server needed for the actual drawing. Hook a terminal to a - serial line of your box and start top to see what is really going on in your - box ... +<P>Generally spoken, DGA framebuffer access should be at least as fast as using +the X11 driver with the additional benefit of getting a fullscreen image. +The percentage speed values printed by mplayer have to be interpreted with +some care, as for example, with the X11 driver they do not include the time +used by the X-Server needed for the actual drawing. Hook a terminal to a +serial line of your box and start top to see what is really going on in your +box ...</P> - Generally spoken, the speedup done by using DGA against 'normal' use of X11 - highly depends on your graphics card and how well the X-Server module for it - is optimized. +<P>Generally spoken, the speedup done by using DGA against 'normal' use of X11 +highly depends on your graphics card and how well the X-Server module for it +is optimized.</P> - If you have a slow system, better use 15 or 16bit depth since they require - only half the memory bandwidth of a 32 bit display. - - Using a depth of 24bit is even a good idea if your card natively just supports - 32 bit depth since it transfers 25% less data compared to the 32/32 mode. - - I've seen some avi files already be replayed on a Pentium MMX 266. AMD K6-2 - CPUs might work at 400 MHZ and above. +<P>If you have a slow system, better use 15 or 16bit depth since they require +only half the memory bandwidth of a 32 bit display.</P> +<P>Using a depth of 24bit is even a good idea if your card natively just supports +32 bit depth since it transfers 25% less data compared to the 32/32 mode.</P> + +<P>I've seen some avi files already be replayed on a Pentium MMX 266. AMD K6-2 +CPUs might work at 400 MHZ and above.</P> - <A NAME=2.2.1.3.8>2.2.1.3.8. Known bugs</A> - - Well, according to some developpers of XFree, DGA is quite a beast. They - tell you better not to use it. Its implementation is not always flawless - with every chipset driver for XFree out there. +<P><B><A NAME=2.2.1.3.8>2.2.1.3.8. Known bugs</A></B></P> - o with XFree 4.0.3 and nv.o there is a bug resulting in strange colors - o ATI driver requires to switch mode back more than once after finishing - using of DGA - o some drivers simply fail to switch back to normal resolution (use - Ctrl-Alt-Keypad +, - to switch back manually) - o some drivers simply display strange colors - o some drivers lie about the amount of memory they map into the process's - address space, thus vo_dga won't use doublebuffering (SIS?) - o some drivers seem to fail to report even a single valid mode. In this - case the DGA driver will crash telling you about a nonsense mode of - 100000x100000 or the like ... - o OSD only works with doublebuffering enabled +<P>Well, according to some developpers of XFree, DGA is quite a beast. They +tell you better not to use it. Its implementation is not always flawless +with every chipset driver for XFree out there.</P> +<P><UL> +<LI>with XFree 4.0.3 and nv.o there is a bug resulting in strange colors +<LI>ATI driver requires to switch mode back more than once after finishing +using of DGA +<LI>some drivers simply fail to switch back to normal resolution (use +Ctrl-Alt-Keypad +, - to switch back manually) +<LI>some drivers simply display strange colors +<LI>some drivers lie about the amount of memory they map into the process's +address space, thus vo_dga won't use doublebuffering (SIS?) +<LI>some drivers seem to fail to report even a single valid mode. In this +case the DGA driver will crash telling you about a nonsense mode of +100000x100000 or the like ... +<LI>OSD only works with doublebuffering enabled +</UL></P> - <A NAME=2.2.1.3.9>2.2.1.3.9. Future work</A> +<P><B><A NAME=2.2.1.3.9>2.2.1.3.9. Future work</A></B></P> - o use of the new X11 render interface for OSD - o where is my TODO list ???? :-((( +<P><UL><LI>use of the new X11 render interface for OSD +<LI>where is my TODO list ???? :-(((</UL></P> - <A NAME=2.2.1.3.A>2.2.1.3.A. Some modelines</A> +<P><B><A NAME=2.2.1.3.A>2.2.1.3.A. Some modelines</A></B></P> +<PRE> Section "Modes" Identifier "Modes[0]" Modeline "800x600" 40 800 840 968 1056 600 601 605 628 @@ -376,301 +369,291 @@ Modeline "352x240" 15.750 352 368 416 432 240 244 246 262 Doublescan Modeline "320x240" 12.588 320 336 384 400 240 245 246 262 Doublescan EndSection +</PRE> - - These entries work fine with my Riva128 chip, using nv.o XServer driver - module. +<P>These entries work fine with my Riva128 chip, using nv.o XServer driver +module.</P> - <A NAME=2.2.1.3.B>2.2.1.3.B. Bug Reports</A> +<P><B><A NAME=2.2.1.3.B>2.2.1.3.B. Bug Reports</A></B></P> - If you experience troubles with the DGA driver please feel free to file - a bug report to me (e-mail address below). Please start mplayer with the - -v option and include all lines in the bug report that start with vo_dga: +<P>If you experience troubles with the DGA driver please feel free to file +a bug report to me (e-mail address below). Please start mplayer with the +-v option and include all lines in the bug report that start with vo_dga:</P> - Please do also include the version of X11 you are using, the graphics card - and your CPU type. The X11 driver module (defined in XF86-Config) might - also help. Thanks! +<P>Please do also include the version of X11 you are using, the graphics card +and your CPU type. The X11 driver module (defined in XF86-Config) might +also help. Thanks!</P> - Acki (acki@acki-netz.de, www.acki-netz.de) - +<P><I>Acki (acki@acki-netz.de, www.acki-netz.de)</I></P> - <A NAME=2.2.1.4>2.2.1.4. SDL</A> - Here are some notes about SDL out in <B>MPlayer</B>. +<P><B><A NAME=2.2.1.4>2.2.1.4. SDL</A></B></P> - There are several commandline switches for SDL: +<P>Here are some notes about SDL out in <B>MPlayer</B>.</P> - -vo sdl:name specifies sdl video driver to use (ie. aalib, - dga, x11) - -ao sdl:name specifies sdl audio driver to use (ie. dsp, - esd, arts) - -noxv disables Xvideo hardware acceleration - -forcexv tries to force Xvideo acceleration - SDL Keys: - F toggles fullscreen/windowed mode - C cycles available fullscreen modes - W/S mappings for * and / (mixer control) +<P><TABLE BORDER=0> +<TD COLSPAN=4><P><B>There are several commandline switches for SDL:</B></P></TD><TR> +<TD> </TD><TD>-vo sdl:name</TD><TD> </TD><TD> +specifies sdl video driver to use (ie. aalib, dga, x11)</TD><TR> +<TD></TD><TD>-ao sdl:name</TD><TD></TD><TD>specifies sdl audio driver to use (ie. dsp, +esd, arts)</TD><TR> +<TD></TD><TD>-noxv</TD><TD></TD><TD>disables Xvideo hardware acceleration</TD><TR> +<TD></TD><TD>-forcexv</TD><TD></TD><TD>tries to force Xvideo acceleration</TD><TR> - KNOWN BUGS: - - Keys pressed under sdl:aalib console driver repeat forever. (use -vo aa !) - It's bug in SDL, I can't change it (tested with SDL 1.2.1). +<TD COLSPAN=4><P><B>SDL Keys:</B></P></TD><TR> +<TD></TD><TD>F</TD><TD></TD><TD>toggles fullscreen/windowed mode</TD><TR> +<TD></TD><TD>C</TD><TD></TD><TD>cycles available fullscreen modes</TD><TR> +<TD></TD><TD>W/S</TD><TD></TD><TD>mappings for * and / (mixer control)</TD><TR> - <A NAME=2.2.1.5>2.2.1.5. SVGAlib</A> +</TABLE></P> - If you don't have X, you can use the SVGAlib target! Be sure not to use the - -fs switch, since it toggles the usage of the software scaler, and it's - SLOOOW now, unless you have a real fast CPU (and/or MTRR?). :( +<P><B>KNOWN BUGS:</B></P> +<P><UL><LI>Keys pressed under sdl:aalib console driver repeat forever. (use -vo aa !) +It's bug in SDL, I can't change it (tested with SDL 1.2.1). +</UL></P> - Of course you'll have to install svgalib and its development package in - order for <B>MPlayer</B> build its SVGAlib driver (autodetected, but can be - forced), and don't forget to edit /etc/vga/libvga.config to suit your - card & monitor. +<P><B><A NAME=2.2.1.5>2.2.1.5. SVGAlib</A></B></P> +<P>If you don't have X, you can use the SVGAlib target! Be sure not to use the +-fs switch, since it toggles the usage of the software scaler, and it's +SLOOOW now, unless you have a real fast CPU (and/or MTRR?). :(</P> - <A NAME=2.2.1.6>2.2.1.6. Framebuffer output (FBdev)</A> +<P>Of course you'll have to install svgalib and its development package in +order for <B>MPlayer</B> build its SVGAlib driver (autodetected, but can be +forced), and don't forget to edit /etc/vga/libvga.config to suit your +card & monitor.</P> - Whether to build the FBdev target is autodetected during ./configure . - Read the framebuffer documentation in the kernel sources - (Documentation/fb/*) for info on how to enable it, etc.. ! +<P><B><A NAME=2.2.1.6>2.2.1.6. Framebuffer output (FBdev)</A></B></P> - If your card doesn't support VBE 2.0 standard (older ISA/PCI - cards, such as S3 Trio64), only VBE 1.2 (or older?) : - Well, VESAfb is still available, but you'll have to load SciTech Display - Doctor (formerly UniVBE) before booting Linux. Use a DOS boot disk or - whatever. And don't forget to register your UniVBE ;)) +<P>Whether to build the FBdev target is autodetected during ./configure . +Read the framebuffer documentation in the kernel sources +(Documentation/fb/*) for info on how to enable it, etc.. !</P> - The FBdev output takes some additional parameters above the others: +<P>If your card doesn't support VBE 2.0 standard (older ISA/PCI +cards, such as S3 Trio64), only VBE 1.2 (or older?) : +Well, VESAfb is still available, but you'll have to load SciTech Display +Doctor |