Mercurial > mplayer.hg
changeset 1500:526047bdda07
*** empty log message ***
author | gabucino |
---|---|
date | Mon, 13 Aug 2001 10:38:01 +0000 |
parents | c3517acc0497 |
children | d40f2b686846 |
files | DOCS/documentation.html DOCS/mplayer.1 DOCS/tech/general.txt |
diffstat | 3 files changed, 122 insertions(+), 47 deletions(-) [+] |
line wrap: on
line diff
--- a/DOCS/documentation.html Sun Aug 12 22:36:05 2001 +0000 +++ b/DOCS/documentation.html Mon Aug 13 10:38:01 2001 +0000 @@ -201,6 +201,9 @@ _before_ compiling <B>MPlayer</B>, otherwise no Matrox-specific support will be built. + If you plan to use the ProjectMayo's <B>OpenDivX</B> codec, check the + <A HREF="#2.1.2.1">2.1.2.1</A> section before compiling. + Then build <B>MPlayer</B>: @@ -260,7 +263,7 @@ The most important video codecs: - MPEG1 (VCD) and MPEG2 (DVD) video - - DivX, OpenDivX and other MPEG4 variants + - DivX, FFmpeg, OpenDivX and other MPEG4 variants - Windows Media Video 7 (WMV1) used in .wmv files - Intel Indeo codecs (3.1,3.2,4.1,5.0) - MJPEG, ASV2 and other hardware formats @@ -307,7 +310,8 @@ <B>MPlayer</B> autodetects if OpenDivX is (properly) installed, just compile - as usual. + as usual. If it doesn't detect it, you didn't install it exactly as above, + and/or has fucked up config (see last question of 6.1 section). Using it is a bit tricky. As it conflicts with the old OpenDivX (it's API is very similar to OpenDivX's), OpenDivX code is disabled, and the OpenDivX @@ -345,16 +349,36 @@ which is compatible with the traditional DivX. <B>MPlayer</B> contains this codec, and this makes it possible to <B>watch DivX movies on non-x86 platforms!</B> To get it compile, you'll need nasm, bison, and flex, above the other - devel tools. No manual hacking is needed to build it, ./configure detects - if it can be built. At the moment it doesn't support postprocessing, and - is under optimization (it's generally a bit faster than the DirectShow - DivX codec, now). + devel tools. It was removed from <B>MPlayer</B>'s cvs tree, you have + to download it manually directly from <B>FFmpeg</B>'s tree : + + + cvs -d:pserver:anonymous@cvs.ffmpeg.sourceforge.net:/cvsroot/ffmpeg login + cvs -d:pserver:anonymous@cvs.ffmpeg.sourceforge.net:/cvsroot/ffmpeg co ffmpeg + + + Note: if you copy with CVS subdirs, next time it's enough to do + 'cvs update'. + + Now, move the newly downloaded ffmpeg source's <B>libavcodec</B> directory, + (with all it's subdirectories) to <B>MPlayer</B>'s tree, so it will look + like this : + + + main/libavcodec + + + Symlinking is NOT enough, you have to copy it. + + ./configure detects if it can be built. At the moment it doesn't support + postprocessing, and is under optimization (it's faster than the DS/VfW DivX + codec). In order to use it, refresh your codecs.conf file, and do as the manpage, or the example.conf says (the -vfm option). Note: libavcodec contains other codecs as well, but at the moment we mostly - focus on ffdivx. + focus on ffdivx, and it's unlikely that this will change. <A NAME=2.1.3>2.1.4. Codec importing howto @@ -388,7 +412,7 @@ This is the MP3 codec. So, now we have all the info needed (fourcc, codec file, sample AVI), submit your codec support request in mail, and upload these files to the FTP: - ftp://mplayerhq.hu/MPlayer/incoming/<codecname>/ + ftp://mplayerhq.hu/MPlayer/incoming/[codecname]/ <A NAME=2.1.4.2>2.1.4.2. DirectShow codecs @@ -421,7 +445,7 @@ So, now we have all the info needed (fourcc, GUID, codec file, sample AVI), submit your codec support request in mail, and upload these files to the FTP: - ftp://mplayerhq.hu/MPlayer/incoming/<codecname>/ + ftp://mplayerhq.hu/MPlayer/incoming/[codecname]/ <A NAME=2.2>2.2. Video & Audio output devices @@ -782,7 +806,7 @@ -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) + esd, arts) -noxv disables Xvideo hardware acceleration -forcexv tries to force Xvideo acceleration @@ -821,6 +845,26 @@ Doctor (formerly UniVBE) before booting Linux. Use a DOS boot disk or whatever. And don't forget to register your UniVBE ;)) + The FBdev output takes some additional parameters above the others: + + -fb specify the framebuffer device to use (/dev/fd0) + -fbmode mode name to use (according to /etc/fb.modes) + -fbmodeconfig config file of modes (default /etc/fb.modes) + monitor_hfreq + monitor_vfreq IMPORTANT values, see example.conf + monitor_dotclock + + If you want to change to a specific mode, then use + + mplayer -vm -fbmode (NameOfMode) filename + + -vm alone will choose the most suitable mode from /etc/fb.modes . Can be + used together with -x and -y options too. The -flip option is supported only + if the movie's pixel format matches the video mode's pixel format. + Pay attention to the bpp value, fbdev driver tries to use the current, + or if you specify the -bpp option, then that. + -zoom option isn't supported (software scaling is slow). -fs option + isn't supported. You can't use 8bpp (or less) modes. NOTE: FBdev video mode changing _does not work_ with the VESA framebuffer, and don't ask for it, since it's not an <B>MPlayer</B> limitation. @@ -1057,7 +1101,7 @@ end If you don't like the standard location for the lirc-config file (~/.lircrc) - use the -lircconf <filename> switch to specify another file. + use the -lircconf [filename] switch to specify another file. <A NAME=3.3>3.3. Streaming from network or pipes @@ -1184,7 +1228,7 @@ It's recommended that you tuneup your CDROM drive also with hdparm : - hdparm -d1 -a8 -u1 <cdrom device> + hdparm -d1 -a8 -u1 (cdrom device) to enable using DMA access, readahead, and IRQ unmasking. @@ -1351,11 +1395,19 @@ <B>Q: What's the problem with gcc 2.96 ? </B>A: gcc 2.96 is RedHat's UNOFFICIAL (it can be found only on RedHat sites, or RedHat distributions) and BUGGY gcc release. gcc 2.96 is TOTALLY - unsupported by <B>MPlayer</B>, because it simply SKIPS MMX codes, it just does not - compile it. Important: this is NOT an <B>MPlayer</B>-specific problem, numerous - other projects (DRI, avifile, etc..) have problems with this shit too. + unsupported by <B>MPlayer</B>, because it simply SKIPS MMX codes, it just does + not compile it. Important: this is NOT an <B>MPlayer</B>-specific problem, + numerous other projects (DRI, avifile, etc..) have problems with this shit + too. ** DO NOT USE gcc 2.96 !!! ** + <B>Q: Great, I have gcc 3.0.1 from RedHat/Mandrake, then I'm fine--! + </B>A: No :) Their gcc 3.0.1 was compiled with gcc 2.96, so they are + buggy shit too. + + <B>Q: Now then. What should I use? + </B>A: Any of gcc 2.95 series. + <B>Q: SDL output doesn't work or compile. Problem is .... </B>A: It is tested with newest SDL (probably runs on 1.1.7+). It does NOT work with 1.1.6, 1.1.5 1.1.4 1.1.3 1.0.4 etc, don't ask. @@ -1404,14 +1456,16 @@ <B>Q: I can't compile SVGAlib.. I'm using 2.3/2.4 kernel. </B>A: You have to edit SVGAlib's Makefile.cfg and comment "BACKGROUND = y" out. - <B>Q: I compiled <B>MPlayer</B> with libcss support, but when I try to start - it, it says : + <B>Q: I compiled <B>MPlayer</B> with libcss/libdivxdecore support, but when + I try to start it, it says : > error while loading shared libraries: libcss.so.0: cannot load > shared object file: No such file or directory I checked up on the file and it IS there in /usr/local/lib. </B>A: What are you doing on Linux? Can't you install a library? Why do we get these questions? It's not <B>MPlayer</B> specific at all! Add /usr/local/lib to <B>/etc/ld.so.conf</B> and run <B>ldconfig</B> . + Or install it to /usr/lib , because if you can't solve the /usr/local + problem, you are careless enough to do such things. <A NAME=6.2>6.2. General questions @@ -1714,7 +1768,7 @@ "options USER_LDT" (unless you are running -CURRENT, where this is default). If <B>MPlayer</B> complains about "CD-ROM Device '/dev/cdrom' not found!" make a - symbolic link : ln -s /dev/<your_cdrom_device> /dev/cdrom + symbolic link : ln -s /dev/(your_cdrom_device) /dev/cdrom There's no DVD support for FreeBSD yet. Feel free to add it :-) @@ -1770,8 +1824,8 @@ gcc -c -Iloader -Ilibvo -O4 -march=i686 -mcpu=i686 -pipe -ffast-math -fomit-frame-pointer -I/usr/local/include -o mplayer.o mplayer.c Assembler: mplayer.c - "<stdin>", line 3567 : Illegal mnemonic - "<stdin>", line 3567 : Syntax error + "(stdin)", line 3567 : Illegal mnemonic + "(stdin)", line 3567 : Syntax error ... more "Illegal mnemonic" and "Syntax error" errors ...
--- a/DOCS/mplayer.1 Sun Aug 12 22:36:05 2001 +0000 +++ b/DOCS/mplayer.1 Mon Aug 13 10:38:01 2001 +0000 @@ -60,6 +60,9 @@ .RB [ \-afm\ audio\ codec\ family ] .RB [ \-frames\ number ] .RB [ \-autoq\ quality ] +.RB [ \-fb\ device ] +.RB [ \-fbmode\ modename ] +.RB [ \-fbmodeconfig filename ] .I - or file .PP .SH DESCRIPTION @@ -326,6 +329,7 @@ This option workarounds some problems when using specific windowmanagers and fullscreen mode. If you experience fullscreen problems, try changing this value between 0 and 7. + -fsmode 0 new method (since 0.18pre3) -fsmode 1 ICCCWM patch (for KDE2/icewm) -fsmode 2 old method (0.17a) @@ -333,6 +337,21 @@ .TP .B \-frames\ number MPlayer plays <number> frames, then quits. +.TP +.B \-fb\ device +Specifies the framebuffer device to use. By default it uses /dev/fb0 . +Only valid for the fbdev driver. +.TP +.B \-fbmode\ modename +Change videomode to the one that is labelled as <modename> in /etc/fb.modes . +Only valid for the fbdev driver. +.TP +.I NOTE +VESA framebuffer doesn't support mode changing. +.TP +.B \-fbmodeconfig\ filename +Use this config file instead of the default /etc/fb.modes . +Only valid for the fbdev driver. .IP .SH "ALPHA/BETA CODE" .TP
--- a/DOCS/tech/general.txt Sun Aug 12 22:36:05 2001 +0000 +++ b/DOCS/tech/general.txt Mon Aug 13 10:38:01 2001 +0000 @@ -73,11 +73,11 @@ Now, go on: 3. mplayer.c - ooh, he's the boss :) - The timing is solved odd, since it has/recommended to be done differently - for each of the formats, and sometimes can be done in many ways. + It's main purpose is connecting the other modules, and maintaining A/V + sync. - There are float variables called a_frame and v_frame, they store - the just played A/V position in seconds. + The given stream's actual position is in the corresponding stream header + timer field (sh_audio / sh_video). The structure of the playing loop : while(not EOF) { @@ -129,19 +129,28 @@ Life didn't get simpler with AVI. There's the "official" timing method, the BPS-based, so the header contains how many compressed - audio bytes belong to one second of frames. - Of course this doesn't always work... why it should :) - So I emulate the MPEG's PTS/sector method on AVI, that is the - AVI parser calculates a fake PTS for every read chunk, decided by - the type of the frames. This is how my timing is done. And sometimes - this works better. + audio bytes or chunks belong to one second of frames. + In the AVI stream header there are 2 important fields, the + dwSampleSize, and dwRate/dwScale pairs: + - If the dwSampleSize is 0, then it's VBR stream, so its bitrate + isn't constant. It means that 1 chunk stores 1 sample, and + dwRate/dwScale gives the chunks/sec value. + - If the dwSampleSize is >0, then it's constant bitrate, and the + time can be measured this way: time = (bytepos/dwSampleSize) / + (dwRate/dwScale) (so the sample's number is divided with the + samplerate). Now the audio can be handled as a stream, which can + be cut to chunks, but can be one chunk also. - In AVI, usually there is a bigger piece of audio stored first, then - comes the video. This needs to be calculated into the delay, this is - called "Initial PTS delay". - Of course there are 2 of them, one is stored in the header and not - really used :) the other isn't stored anywhere, this can only be - measured... + The other method can be used only for interleaved files: from + the order of the chunks, a timestamp (PTS) value can be calculated. + The PTS of the video chunks are simple: chunk number * fps + The audio is the same as the previous video chunk was. + We have to pay attention to the so called "audio preload", that is, + there is a delay between the audio and video streams. This is + usually 0.5-1.0 sec, but can be totally different. + The exact value was measured until now, but now the demux_avi.c + handles it: at the audio chunk after the first video, it calculates + the A/V difference, and take this as a measure for audio preload. 3.a. audio playback: Some words on audio playback: @@ -166,17 +175,10 @@ 4. Codecs. They are separate libs. For example libac3, libmpeg2, xa/*, alaw.c, opendivx/*, loader, mp3lib. - mplayer.c calls them if a piece of audio or video needs to be played. - (see the beginning of 3.) - And they call the appropriate demuxer, to get the compressed data. - (see 2.) - We have to pass the appropriate stream header as parameter (sh_audio/ - sh_video), this should contain all the needed info for decoding - (the demuxer too: sh->ds). - The codecs' seprating is underway, the audio is already done, the video is - work-in-progress. The aim is that mplayer.c won't have to know - which are the codecs and how to use 'em, instead it should call - an init/decode audio/video function. + + mplayer.c doesn't call the directly, but through the dec_audio.c and + dec_video.c files, so the mplayer.c doesn't have to know anything about + the codec. 5. libvo: this displays the frame. The constants for different pixelformats are defined in img_format.h,