summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--AUTHORS3
-rw-r--r--DOCS/default.css8
-rw-r--r--DOCS/man/de/mplayer.12
-rw-r--r--DOCS/man/en/mplayer.12
-rw-r--r--DOCS/man/fr/mplayer.16
-rw-r--r--DOCS/tech/codec-devel.txt2
-rw-r--r--DOCS/tech/colorspaces.txt6
-rw-r--r--DOCS/tech/general.txt252
-rw-r--r--DOCS/tech/hwac3.txt6
-rw-r--r--DOCS/tech/libvo.txt232
-rw-r--r--DOCS/tech/mirrors/mirror_howto.txt4
-rw-r--r--DOCS/tech/mpdsf.txt26
-rw-r--r--DOCS/tech/mpsub.sub14
-rw-r--r--DOCS/tech/osd.txt54
-rw-r--r--DOCS/tech/realcodecs/audio-codecs.txt28
-rw-r--r--DOCS/tech/realcodecs/streaming.txt4
-rw-r--r--DOCS/tech/realcodecs/video-codecs.txt96
-rw-r--r--DOCS/tech/slave.txt15
-rw-r--r--DOCS/tech/subcp.txt14
-rw-r--r--DOCS/tech/swscaler_filters.txt8
-rw-r--r--DOCS/tech/swscaler_methods.txt64
-rw-r--r--DOCS/tech/vidix.txt78
-rw-r--r--DOCS/xml/README21
-rw-r--r--DOCS/xml/README.maintainers6
-rwxr-xr-xDOCS/xml/configure10
-rw-r--r--DOCS/xml/cs/video.xml2
-rw-r--r--DOCS/xml/de/cd-dvd.xml4
-rw-r--r--DOCS/xml/de/encoding-guide.xml2
-rw-r--r--DOCS/xml/de/faq.xml2
-rw-r--r--DOCS/xml/de/tvinput.xml4
-rw-r--r--DOCS/xml/de/usage.xml1910
-rw-r--r--DOCS/xml/de/video.xml8
-rw-r--r--DOCS/xml/default.css66
-rw-r--r--DOCS/xml/en/ports.xml2
-rw-r--r--DOCS/xml/en/video.xml2
-rw-r--r--DOCS/xml/es/video.xml4
-rw-r--r--DOCS/xml/fr/encoding-guide.xml314
-rw-r--r--DOCS/xml/fr/install.xml16
-rw-r--r--DOCS/xml/fr/mencoder.xml16
-rw-r--r--DOCS/xml/fr/ports.xml23
-rw-r--r--DOCS/xml/fr/usage.xml2
-rw-r--r--DOCS/xml/fr/video.xml46
-rw-r--r--DOCS/xml/hu/encoding-guide.xml14
-rw-r--r--DOCS/xml/hu/mencoder.xml34
-rw-r--r--DOCS/xml/hu/video.xml2
-rw-r--r--DOCS/xml/it/usage.xml2
-rw-r--r--DOCS/xml/it/video.xml2
-rw-r--r--DOCS/xml/ldp.dsl6
-rw-r--r--DOCS/xml/pl/bugreports.xml2
-rw-r--r--DOCS/xml/pl/faq.xml2
-rw-r--r--DOCS/xml/pl/ports.xml231
-rw-r--r--DOCS/xml/pl/skin.xml98
-rw-r--r--DOCS/xml/ru/usage.xml2
-rw-r--r--DOCS/xml/xsl/ldp-html-common.xsl3
-rw-r--r--Makefile16
-rw-r--r--command.c48
-rwxr-xr-xconfigure4
-rw-r--r--drivers/3dfx.h288
-rw-r--r--drivers/README.Ati8
-rw-r--r--drivers/README.Matrox34
-rw-r--r--drivers/generic_math.h2
-rw-r--r--drivers/hacking.ati240
-rw-r--r--drivers/mga_vid.c2324
-rw-r--r--drivers/mga_vid_test.c326
-rw-r--r--drivers/radeon.h3660
-rw-r--r--etc/input.conf1
-rw-r--r--input/input.c7
-rw-r--r--input/input.h8
-rw-r--r--libmpcodecs/vf_geq.c7
-rw-r--r--libmpcodecs/vf_gradfun.c4
-rw-r--r--libmpcodecs/vf_qp.c2
-rw-r--r--libvo/gl_common.h9
-rw-r--r--mp3lib/dct36.c28
-rw-r--r--mp3lib/dct36_3dnow.c902
-rw-r--r--mp3lib/dct64_3dnow.c1666
-rw-r--r--mp3lib/dct64_k7.c1404
-rw-r--r--mp3lib/dct64_mmx.c1892
-rw-r--r--mp3lib/decod386.c10
-rw-r--r--mp3lib/decode_i586.c6
-rw-r--r--mp3lib/decode_mmx.c382
-rw-r--r--mp3lib/equalizer.c119
-rw-r--r--mp3lib/l2tables.h258
-rw-r--r--mp3lib/layer1.c2
-rw-r--r--mp3lib/layer2.c6
-rw-r--r--mp3lib/layer3.c28
-rw-r--r--mp3lib/mpg123.h4
-rw-r--r--mp3lib/sr1.c36
-rw-r--r--stream/cookies.c2
-rw-r--r--stream/stream_vcd.c2
-rw-r--r--stream/vcd_read.h5
-rw-r--r--stream/vcd_read_darwin.h5
-rw-r--r--stream/vcd_read_fbsd.h5
-rw-r--r--stream/vcd_read_os2.h5
-rw-r--r--stream/vcd_read_win32.h5
94 files changed, 8823 insertions, 8719 deletions
diff --git a/AUTHORS b/AUTHORS
index ed2c0bfdaa..0bca9f4ab9 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -385,6 +385,9 @@ Hůrka, Tomáš <tom@hukatronic.cz>
* Darwin DVD support (mpdvdkit2)
* various fixes
+Hysseo, Jehan <hysseo@zemarmot.net>
+ * af_add, af_switch, af_del, af_clr commands.
+
Isani, Sidik <lksi@cfht.hawaii.edu>
* get_delay() smoothing code (-autosync)
* RTC initialization fixes
diff --git a/DOCS/default.css b/DOCS/default.css
index 557be9623a..dde261b174 100644
--- a/DOCS/default.css
+++ b/DOCS/default.css
@@ -1,5 +1,5 @@
-body,table {
- font-family : Arial, Helvetica, sans-serif;
- font-size : 14px;
- background : white;
+body,table {
+ font-family : Arial, Helvetica, sans-serif;
+ font-size : 14px;
+ background : white;
}
diff --git a/DOCS/man/de/mplayer.1 b/DOCS/man/de/mplayer.1
index 635fcdb959..f5123b1481 100644
--- a/DOCS/man/de/mplayer.1
+++ b/DOCS/man/de/mplayer.1
@@ -297,6 +297,8 @@ Mache einen Schnappschuss.
Beginne/beende die Aufnahme von Schnappschüssen.
.IPs "I\ \ \ \ "
Zeige den Dateinamen im OSD.
+.IPs "P\ \ \ \ "
+Zeige den Fortschrittsbalken, die abgelaufene Zeit und die Gesamtzeit im OSD.
.IPs "! und @"
Spult zum Anfang des vorigen/nächsten Kapitels.
.IPs "D (nur bei \-vo xvmc, \-vf yadif, \-vf kerndeint)"
diff --git a/DOCS/man/en/mplayer.1 b/DOCS/man/en/mplayer.1
index 5b102868d7..ab1a551abe 100644
--- a/DOCS/man/en/mplayer.1
+++ b/DOCS/man/en/mplayer.1
@@ -278,6 +278,8 @@ Take a screenshot.
Start/stop taking screenshots.
.IPs "I\ \ \ \ "
Show filename on the OSD.
+.IPs "P\ \ \ \ "
+Show progression bar, elapsed time and total duration on the OSD.
.IPs "! and @"
Seek to the beginning of the previous/next chapter.
.IPs "D (\-vo xvmc, \-vo vdpau, \-vf yadif, \-vf kerndeint only)"
diff --git a/DOCS/man/fr/mplayer.1 b/DOCS/man/fr/mplayer.1
index cf33b922c8..3fee7fe302 100644
--- a/DOCS/man/fr/mplayer.1
+++ b/DOCS/man/fr/mplayer.1
@@ -303,6 +303,8 @@ Réalise une capture d'écran.
Amorce/arrête la capture d'écran.
.IPs "I\ \ \ \ "
Affiche le nom de fichier dans l'OSD.
+.IPs "P\ \ \ \ "
+Affiche la barre d'avancement, le temps écoulé et la durée totale sur l'OSD.
.IPs "! and @"
Saute au début du chapitre précédent/suivant.
.IPs "D (\-vo xvmc, \-vo vdpau, \-vf yadif et \-vf kerndeint uniquement)"
@@ -5782,8 +5784,8 @@ Les aires de mémoire mappées contiennent une entête:
int nch /*nombre de canaux*/
int size /*taille du tampon*/
unsigned long long counter /*Utilisé pour garder la synchro, mis à jour
- chaque fois que de nouvelles données son
- exportées.*/
+ chaque fois que de nouvelles données son
+ exportées.*/
.fi
.sp 1
Le reste est charge utile, constitué de données 16bit (non-entrelacées).
diff --git a/DOCS/tech/codec-devel.txt b/DOCS/tech/codec-devel.txt
index 765bf1c281..bc968c9499 100644
--- a/DOCS/tech/codec-devel.txt
+++ b/DOCS/tech/codec-devel.txt
@@ -43,7 +43,7 @@ understand, then you will either need to somehow convert the format to a
media file format that the program does understand, or write your own
MPlayer file demuxer that can handle the data. Writing a file demuxer
is beyond the scope of this document.
- Try to obtain media that stresses all possible modes of a
+ Try to obtain media that stresses all possible modes of a
decoder. If an audio codec is known to work with both mono and stereo
data, search for sample media of both types. If a video codec is known to
work at 7 different bit depths, then, as painful as it may be, do what you
diff --git a/DOCS/tech/colorspaces.txt b/DOCS/tech/colorspaces.txt
index 291a435f30..eaf9d221e4 100644
--- a/DOCS/tech/colorspaces.txt
+++ b/DOCS/tech/colorspaces.txt
@@ -66,9 +66,9 @@ The most misunderstood thingie...
In MPlayer, we usually have 3 pointers to the Y, U and V planes, so it
doesn't matter what the order of the planes in the memory is:
for mp_image_t and libvo's draw_slice():
- planes[0] = Y = luminance
- planes[1] = U = Cb = blue
- planes[2] = V = Cr = red
+ planes[0] = Y = luminance
+ planes[1] = U = Cb = blue
+ planes[2] = V = Cr = red
Note: planes[1] is ALWAYS U, and planes[2] is V, the FOURCC
(YV12 vs. I420) doesn't matter here! So, every codec using 3 pointers
(not only the first one) normally supports YV12 and I420 (=IYUV), too!
diff --git a/DOCS/tech/general.txt b/DOCS/tech/general.txt
index 631ee3f9de..4ca3671cf3 100644
--- a/DOCS/tech/general.txt
+++ b/DOCS/tech/general.txt
@@ -14,64 +14,64 @@ The main modules:
2. demuxer.c: this does the demultiplexing (separating) of the input to
audio, video or dvdsub channels, and their reading by buffered packages.
- The demuxer.c is basically a framework, which is the same for all the
- input formats, and there are parsers for each of them (mpeg-es,
- mpeg-ps, avi, avi-ni, asf), these are in the demux_*.c files.
- The structure is the demuxer_t. There is only one demuxer.
+ The demuxer.c is basically a framework, which is the same for all the
+ input formats, and there are parsers for each of them (mpeg-es,
+ mpeg-ps, avi, avi-ni, asf), these are in the demux_*.c files.
+ The structure is the demuxer_t. There is only one demuxer.
2.a. demux_packet_t, that is DP.
Contains one chunk (avi) or packet (asf,mpg). They are stored in memory as
- in linked list, cause of their different size.
+ in linked list, cause of their different size.
2.b. demuxer stream, that is DS.
Struct: demux_stream_t
Every channel (a/v/s) has one. This contains the packets for the stream
(see 2.a). For now, there can be 3 for each demuxer :
- - audio (d_audio)
- - video (d_video)
- - DVD subtitle (d_dvdsub)
+ - audio (d_audio)
+ - video (d_video)
+ - DVD subtitle (d_dvdsub)
2.c. stream header. There are 2 types (for now): sh_audio_t and sh_video_t
This contains every parameter essential for decoding, such as input/output
- buffers, chosen codec, fps, etc. There are each for every stream in
- the file. At least one for video, if sound is present then another,
- but if there are more, then there'll be one structure for each.
- These are filled according to the header (avi/asf), or demux_mpg.c
- does it (mpg) if it founds a new stream. If a new stream is found,
- the ====> Found audio/video stream: <id> messages is displayed.
-
- The chosen stream header and its demuxer are connected together
- (ds->sh and sh->ds) to simplify the usage. So it's enough to pass the
- ds or the sh, depending on the function.
-
- For example: we have an asf file, 6 streams inside it, 1 audio, 5
- video. During the reading of the header, 6 sh structs are created, 1
- audio and 5 video. When it starts reading the packet, it chooses the
- stream for the first found audio & video packet, and sets the sh
- pointers of d_audio and d_video according to them. So later it reads
- only these streams. Of course the user can force choosing a specific
- stream with
- -vid and -aid switches.
- A good example for this is the DVD, where the english stream is not
- always the first, so every VOB has different language :)
- That's when we have to use for example the -aid 128 switch.
+ buffers, chosen codec, fps, etc. There are each for every stream in
+ the file. At least one for video, if sound is present then another,
+ but if there are more, then there'll be one structure for each.
+ These are filled according to the header (avi/asf), or demux_mpg.c
+ does it (mpg) if it founds a new stream. If a new stream is found,
+ the ====> Found audio/video stream: <id> messages is displayed.
+
+ The chosen stream header and its demuxer are connected together
+ (ds->sh and sh->ds) to simplify the usage. So it's enough to pass the
+ ds or the sh, depending on the function.
+
+ For example: we have an asf file, 6 streams inside it, 1 audio, 5
+ video. During the reading of the header, 6 sh structs are created, 1
+ audio and 5 video. When it starts reading the packet, it chooses the
+ stream for the first found audio & video packet, and sets the sh
+ pointers of d_audio and d_video according to them. So later it reads
+ only these streams. Of course the user can force choosing a specific
+ stream with
+ -vid and -aid switches.
+ A good example for this is the DVD, where the english stream is not
+ always the first, so every VOB has different language :)
+ That's when we have to use for example the -aid 128 switch.
Now, how this reading works?
- - demuxer.c/demux_read_data() is called, it gets how many bytes,
- and where (memory address), would we like to read, and from which
+ - demuxer.c/demux_read_data() is called, it gets how many bytes,
+ and where (memory address), would we like to read, and from which
DS. The codecs call this.
- - this checks if the given DS's buffer contains something, if so, it
- reads from there as much as needed. If there isn't enough, it calls
- ds_fill_buffer(), which:
- - checks if the given DS has buffered packages (DP's), if so, it moves
- the oldest to the buffer, and reads on. If the list is empty, it
- calls demux_fill_buffer() :
- - this calls the parser for the input format, which reads the file
- onward, and moves the found packages to their buffers.
- Well it we'd like an audio package, but only a bunch of video
- packages are available, then sooner or later the:
- DEMUXER: Too many (%d in %d bytes) audio packets in the buffer
- error shows up.
+ - this checks if the given DS's buffer contains something, if so, it
+ reads from there as much as needed. If there isn't enough, it calls
+ ds_fill_buffer(), which:
+ - checks if the given DS has buffered packages (DP's), if so, it moves
+ the oldest to the buffer, and reads on. If the list is empty, it
+ calls demux_fill_buffer() :
+ - this calls the parser for the input format, which reads the file
+ onward, and moves the found packages to their buffers.
+ Well it we'd like an audio package, but only a bunch of video
+ packages are available, then sooner or later the:
+ DEMUXER: Too many (%d in %d bytes) audio packets in the buffer
+ error shows up.
2.d. video.c: this file/function handle the reading and assembling of the
video frames. each call to video_read_frame() should read and return a
@@ -101,7 +101,7 @@ Now, go on:
The given stream's actual position is in the 'timer' field of the
corresponding stream header (sh_audio / sh_video).
- The structure of the playing loop :
+ The structure of the playing loop :
while(not EOF) {
fill audio buffer (read & decode audio) + increase a_frame
read & decode a single video frame + increase v_frame
@@ -111,89 +111,89 @@ Now, go on:
handle events (keys,lirc etc) -> pause,seek,...
}
- When playing (a/v), it increases the variables by the duration of the
- played a/v.
- - with audio this is played bytes / sh_audio->o_bps
- Note: i_bps = number of compressed bytes for one second of audio
- o_bps = number of uncompressed bytes for one second of audio
- (this is = bps*samplerate*channels)
- - with video this is usually == 1.0/fps, but I have to note that
- fps doesn't really matters at video, for example asf doesn't have that,
- instead there is "duration" and it can change per frame.
- MPEG2 has "repeat_count" which delays the frame by 1-2.5 ...
- Maybe only AVI and MPEG1 has fixed fps.
-
- So everything works right until the audio and video are in perfect
- synchronity, since the audio goes, it gives the timing, and if the
- time of a frame passed, the next frame is displayed.
- But what if these two aren't synchronized in the input file?
- PTS correction kicks in. The input demuxers read the PTS (presentation
- timestamp) of the packages, and with it we can see if the streams
- are synchronized. Then MPlayer can correct the a_frame, within
- a given maximal bounder (see -mc option). The summary of the
- corrections can be found in c_total .
-
- Of course this is not everything, several things suck.
- For example the soundcards delay, which has to be corrected by
- MPlayer! The audio delay is the sum of all these:
- - bytes read since the last timestamp:
- t1 = d_audio->pts_bytes/sh_audio->i_bps
- - if Win32/ACM then the bytes stored in audio input buffer
- t2 = a_in_buffer_len/sh_audio->i_bps
- - uncompressed bytes in audio out buffer
- t3 = a_buffer_len/sh_audio->o_bps
- - not yet played bytes stored in the soundcard's (or DMA's) buffer
- t4 = get_audio_delay()/sh_audio->o_bps
-
- From this we can calculate what PTS we need for the just played
- audio, then after we compare this with the video's PTS, we have
- the difference!
-
- 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 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.
-
- 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.