pax_global_header00006660000000000000000000000064122727635440014526gustar00rootroot0000000000000052 comment=844e8f2b5167785f241f65164d910a14768bd744 mpv-0.3.4/000077500000000000000000000000001227276354400123345ustar00rootroot00000000000000mpv-0.3.4/.gitignore000066400000000000000000000006501227276354400143250ustar00rootroot00000000000000*.o *.a *.d *.exe *.pyc .depend /config.h /config.mak /config.log /mpv /mpv.app /version.h /input/input_conf.h /tags /TAGS /video/out/gl_video_shaders.h /video/out/x11_icon.inc /demux/ebml_defs.c /demux/ebml_types.h /sub/osd_font.h /player/lua/*.inc /DOCS/man/*/mpv.1 /DOCS/man/*/mpv.aux /DOCS/man/*/mpv.log /DOCS/man/*/mpv.out /DOCS/man/*/mpv.pdf /DOCS/man/*/mpv.toc /waf /build /.waf* /.lock-waf_* /old_build /Makefile mpv-0.3.4/.travis.yml000066400000000000000000000007541227276354400144530ustar00rootroot00000000000000language: c env: - LIBAV=libav-stable - LIBAV=libav-git - LIBAV=ffmpeg-stable - LIBAV=ffmpeg-git compiler: - clang branches: only: - master - ci before_install: ./travis-deps libass-stable $LIBAV script: - ./bootstrap.py - ./waf configure - ./waf build notifications-policy: ¬ifications-policy on_success: change on_failure: always notifications: email: false irc: channels: - "irc.freenode.org#mpv-player-dev" <<: *notifications-policy mpv-0.3.4/Copyright000066400000000000000000000020151227276354400142250ustar00rootroot00000000000000mpv is a fork of mplayer2, which is a fork of MPlayer. mpv as a whole is licensed as GPL version 2 or later (see LICENSE). Most source files are GPLv2+, but some files are available under a more liberal license, such as LGPLv2+, BSD, MIT, ISC, and possibly others. Look at the copyright header of each source file, and grep the sources for "Copyright" if you need to know details. Files without Copyright notice are licensed as LGPLv2+. For information about authors and contributors, consult the git log, which contains the complete SVN and CVS history as well. Note that mplayer2 as a whole is licensed under GPLv3+. This is because it uses a copy of talloc (part of Samba), which is LGPLv3+, and the next compatible license for this mix is GPLv3+. MPlayer as a whole is licensed under GPLv2 (incompatible to GPLv3!), because some files are licensed to GPLv2 (and _not_ any later version of the license). In particular, this affects the file libmpdemux/demux_ty_osd.c. It is disabled under mplayer2, and has been removed from mpv. mpv-0.3.4/DOCS/000077500000000000000000000000001227276354400130645ustar00rootroot00000000000000mpv-0.3.4/DOCS/OUTDATED-tech/000077500000000000000000000000001227276354400152165ustar00rootroot00000000000000mpv-0.3.4/DOCS/OUTDATED-tech/formats.txt000066400000000000000000000213171227276354400174360ustar00rootroot000000000000001. Input layer, supported devices, methods: - plain file, with seeking - STDIN, without seeking backward - network streaming (currently plain wget-like HTTP and MMS (.asx)) - VCD (Video CD) track, by direct CDROM device access (not requires mounting disc) - DVD titles using .IFO structure, by direct DVD device access (not requires mounting disc) - DVD titles using menu navigation (experimental/alpha, not yet finished!!!) - CDDA - raw audio from audio CD-ROM discs (using cdparanoia libs) - RTP streaming (mpeg-ps over multicast only) - LIVE555 streaming - support SDP/RTSP (using the LIVE555 libs) - SMB - file access over samba (experimental) 2. Demuxer/parser layer, supported file/media formats: - MPEG streams (ES,PES,PS. no TS support yet) note: mpeg demuxer silently ignore non-mpeg content, and find mpeg packets in arbitrary streams. it means you can play directly VCD images (for example CDRwin's .BIN files) without extracting mpeg files first (with tools like vcdgear) It accepts all PES variants, including files created by VDR. Note: VOB (video object) is simple mpeg stream, but it usually has 01BD packets which may contain subtitles and non-mpeg audio. Usually found on DVD discs. Headers: mpeg streams has no global header. each frame sequence (also called GOP, group of pictures) contains an sequence header, it describes that block. In normal mpeg 1/2 content there are groups of 12-15 frames (24/30 fps). It means you can freely seek in mpeg streams, and even can cut it to small parts with standard file tools (dd, cut) without destroying it. Codecs: video is always mpeg video (mpeg1, mpeg2 or mpeg4). audio is usually mpeg audio (any layer allowed, but it's layer 2 in most files) but 01BD packets may contain AC3, DTS or LPCM too. FPS: mpeg2 content allows variable framerate, in form of delayed frames. It's mostly used for playback 24fps content at 29.97/30 fps (NTSC) rate. (so called Telecine or 3:2 pulldown effect) It means you see 30 frames per second, but there are only 24 different pictures and some of them are shown longer to fill 30 frame time. If you encode such files with mencoder, using -ofps 24 or -ofps 23.976 is recommended. - AVI streams. Two kind of RIFF AVI files exists: 1. interleaved: audio and video content is interleaved. it's faster and requires only 1 reading thread, so it's recommended (and mostly used). 2. non-interleaved: audio and video aren't interleaved, i mean first come whole video followed by whole audio. it requires 2 reading process or 1 reading with lots of seeking. very bad for network or cdrom. 3. badly interleaved streams: mplayer detects interleaving at startup and enables -ni option if it finds non-interleaved content. but sometimes the stream seems to be interleaved, but with bad sync so it should be played as non-interleaved otherwise you get a-v desync or buffer overflow. MPlayer supports 2 kind of timing for AVI files: - bps-based: it is based on bitrate/samplerate of video/audio stream. this method is used by most players, including avifile and wmp. files with broken headers, and files created with VBR audio but not vbr-compliant encoder will result a-v desync with this method. (mostly at seeking). - interleaving-based: note: it can't be used togethwer with -ni it doesn't use bitrate stuff of header, it uses the relative position of interleaved audio and video chunks. makes some badly encoded file with vbr audio playable. Headers: AVI files has a mandatory header at the begin of the file, describing video parameters (resolution, fps) and codecs. Optionally they have an INDEX block at the end of the file. It's optional, but most files has such block, because it's REQUIRED for seeking. Btw usually it can be rebuilt from file content, mplayer does it with the -idx switch. MPlayer can recreate broken index blocks using -forceidx. As AVI files needs index for random access, broken files with no index are usually unplayable. Of course, cutting/joining AVI files needs special programs. Codecs: any audio and video codecs allowed, but I note that VBR audio is not well supported by most players. The file format makes it possible to use VBR audio, but most players expect CBR audio and fails with VBR, as VBR is unusual, and Microsoft's AVI specs only describe CBR audio. I also note, that most AVI encoders/multiplexers create bad files if using VBR audio. only 2 exception (known by me): NaNDub and MEncoder. FPS: only constant framerate allowed, but it's possible to skip frames. - ASF streams: ASF (active streaming format) comes from Microsoft. they developed two variant of ASF, v1.0 and v2.0. v1.0 is used by their media tools (wmp and wme) and v2.0 is published and patented :). of course, they differ, no compatibility at all. (it's just a legality game) MPlayer supports only v1.0, as nobody ever seen v2.0 files :) Note, that .ASF files are nowdays come with extension .WMA or .WMV. UPDATE: MS recently released the ASF v1.0 specs too, but it has some restrictions making it illegal to read by us :) Headers: Stream headers (codecs parameters) can be everywhere (in theory), but all files i've seen had it at the beginning of the file. Asf uses fixed packet size, so it is seekable without any INDEX block, and broken files are playable well. Codecs: video is mostly microsoft's mpeg4 variants: MP42, MP43 (aka DivX), WMV1 and WMV2. but any codecs allowed. audio is usually wma or voxware, sometimes mp3, but any codecs allowed. FPS: no fixed fps, every video frame has an exact timestamp instead. I've got stream with up to 3 sec frame display times. - QuickTime / MOV files: They come from Mac users, usually with .mov or .qt extension, but as MPEG Group chose quicktime as recommended file format for MPEG4, sometimes you meet quicktime files with .mpg or .mp4 extension. At first look, it's a mixture of ASF and AVI. It requires INDEX block for random access and seeking, and even for playback, like AVI, but uses timestamps instead of constant framerate and has more flexible stream options (including network stuff) like ASF. Headers: header can be placed at the beginning or at the end of file. About half of my files have it at the beginning, others have it at the end. Broken files are only playable if they have header at the beginning! Codecs: any codecs allowed, both CBR and VBR. Note: most new mov files use Sorenson video and QDesign Music audio, they are patented, closed, secret, (TM)-ed etc formats, only Apple's quicktime player is able to playback these files (on win/mac only). - VIVO files: They are funny streams. They have a human-readable ascii header at the beginning, followed by interleaved audio and video chunks. It has no index block, has no fixed packetsize or sync bytes, and most files even has no keyframes, so forget seeking! Video is standard h.263 (in vivo/2.0 files it's modified, non-standard h.263), audio is either standard g.723 or Vivo Siren codec. Note, that microsoft licensed vivo stuff, and included in their netshow v2.0 program, so there are VfW/ACM codecs for vivo video and audio. - RealMedia files: A mixture of AVI and ASF features. It has mandatory headers at the beginning and an optional INDEX (missing in most files). The file is constructed of variable size chunks, with small header telling the stream ID, timestamp, flags (keyframe...) and size. But it has some features found in ASF files: The video is actually double-muxed, the video chunks are really appended fragments of the video frame. RV30+ supports B frames, so you have to parse some bits of the first fragment to get the real PTS. The audio frames are fixed size (CBR) but using the same scrambling (out-of-order interleaving) as in the ASF files. Codecs: Audio is either COOK(er), SIPR(o), ATRAC3 or DNET. The DNET is actually a byte-swapped low-bitrate Dolby AC3 variant :) Video is RV10 (h263 variant), RV20 (rp G2), RV30 (rp v8) or RV40 (rp v9). FPS: variable, just like in ASF. Note, that similarity of real and asf has some background - they worked together on the (never finished/used) ASF v2 spec for some time. - GIF files: The GIF format is a common format for web graphics that supports animation. These are read through libungif or compatible library. Variable frame delays are supported, but seeking is not supported. Seeking will be supported once an index of gif frames can be built. mpv-0.3.4/DOCS/OUTDATED-tech/general.txt000066400000000000000000000272541227276354400174060ustar00rootroot00000000000000So, I'll describe how this stuff works. The main modules: 1. stream.c: this is the input layer, this reads the input media (file, stdin, vcd, dvd, network etc). what it has to know: appropriate buffering by sector, seek, skip functions, reading by bytes, or blocks with any size. The stream_t (stream.h) structure describes the input stream, file/device. There is a stream cache layer (cache2.c), it's a wrapper for the stream API. It does fork(), then emulates stream driver in the parent process, and stream user in the child process, while proxying between them using preallocated big memory chunk for FIFO buffer. 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. 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. 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) 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: 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 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. 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 single video frame, and it's duration in seconds (float). The implementation is splitted to 2 big parts - reading from mpeg-like streams and reading from one-frame-per-chunk files (avi, asf, mov). Then it calculates duration, either from fixed FPS value, or from the PTS difference between and after reading the frame. 2.e. other utility functions: there are some useful code there, like AVI muxer, or mp3 header parser, but leave them for now. So everything is ok 'till now. It can be found in libmpdemux/ library. It should compile outside of mplayer tree, you just have to implement few simple functions, like mp_msg() to print messages, etc. See libmpdemux/test.c for example. See also formats.txt, for description of common media file formats and their implementation details in libmpdemux. Now, go on: 3. mplayer.c - ooh, he's the boss :) Its main purpose is connecting the other modules, and maintaining A/V sync. 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 : while(not EOF) { fill audio buffer (read & decode audio) + increase a_frame read & decode a single video frame + increase v_frame sleep (wait until a_frame>=v_frame) display the frame apply A-V PTS correction to a_frame 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. 3.a. audio playback: Some words on audio playback: Not the playing is hard, but: 1. knowing when to write into the buffer, without blocking 2. knowing how much was played of what we wrote into The first is needed for audio decoding, and to keep the buffer full (so the audio will never skip). And the second is needed for correct timing, because some soundcards delay even 3-7 seconds, which can't be forgotten about. To solve this, the OSS gives several possibilities: - ioctl(SNDCTL_DSP_GETODELAY): tells how many unplayed bytes are in the soundcard's buffer -> perfect for timing, but not all drivers support it :( - ioctl(SNDCTL_DSP_GETOSPACE): tells how much can we write into the soundcard's buffer, without blocking. If the driver doesn't support GETODELAY, we can use this to know how much the delay is. - select(): should tell if we can write into the buffer without blocking. Unfortunately it doesn't say how much we could :(( Also, doesn't/badly works with some drivers. Only used if none of the above works. 4. Codecs. Consists of libmpcodecs/* and separate files or libs, for example libmpeg2, loader, mp3lib. mplayer.c doesn't call them directly, but through the dec_audio.c and dec_video.c files, so the mplayer.c doesn't have to know anything about the codecs. libmpcodecs contains wrapper for every codecs, some of them include the codec function implementation, some calls functions from other files included with mplayer, some calls optional external libraries. file naming convention in libmpcodecs: ad_*.c - audio decoder (called through dec_audio.c) vd_*.c - video decoder (called through dec_video.c) ve_*.c - video encoder (used by mencoder) vf_*.c - video filter (see option -vf) On this topic, see also: libmpcodecs.txt - The structure of the codec-filter path, with explanation dr-methods.txt - Direct rendering, MPI buffer management for video codecs codecs.conf.txt - How to write/edit codec configuration file (codecs.conf) codec-devel.txt - Mike's hints about codec development - a bit OUTDATED hwac3.txt - about SP/DIF audio passthrough 5. libvo: this displays the frame. for details on this, read libvo.txt 6. libao2: this control audio playing 6.a audio plugins for details on this, read libao2.txt mpv-0.3.4/DOCS/OUTDATED-tech/hwac3.txt000066400000000000000000000151721227276354400167720ustar00rootroot00000000000000mails by A'rpi and Marcus Blomenkamp describing how this ac3-passtrough hack work under linux and mplayer... ----------------------------------------------------------------------- Hi, > I received the following patch from Steven Brookes . > He is working on fixing the digital audio output of the dxr3 driver and > told me he fixed some bugs in mplayer along the way. I don't know shit > about hwac3 output so all I did was to make sure the patch applied > against latest cvs. > This is from his e-mail to me: > > "Secondly there is a patch to dec_audio.c and > ac3-iec958 to fix the -ac hwac3 codec stuff and to use liba52 to sync it. > Seems to work for everything I've thrown at and maintains sync for all audio > types through the DXR3." patch applied (with some comments added and an unwanted change (in software a52 decoder) removed) now i understand how this whole hwac3 mess work. it's very very tricky. it virtually decodes ac3 to LPCM packets, but really it keeps the original compressed data padded by zeros. this way it's constant bitrate, and sync is calculated just like for stereo PCM. (so it bypass LPCM-capable media converters...) so, every ac3 frame is translated to 6144 byte long tricky LPCM packet. 6144 = 4*(6*256) = 4 * samples_per_ac3_frame = LPCM size of uncompressed ac3 frame. i wanna know if it works for sblive and other ac3-capable cards too? (i can't test it, lack of ac3 decoder) A'rpi / Astral & ESP-team ----------------------------------------------------------------------- Hi folks. I spend some time fiddling with ac3 passthrough in mplayer. The traditional way of setting the output format to AFMT_AC3 was no ideal solution since not all digital io cards/drivers supported this format or honoured it to set the spdif non-audio bit. To make it short, it only worked with oss sblive driver IIRC. Inspired by alsa's ac3dec program I found an alternative way by inspecting to which format the alsa device had been set. Suprise: it was simple 16bit_le 2_channel pcm. So setting the non-audio bit doesn't necessarily mean the point. The only important thing seems to be bit-identical output at the correct samplerate. Modern AV-Receivers seem to be quite tolerant/compatible. So I changed the output format of hwac3 from AFMT_AC3 channels=1 to AFMT_S16_LE channels=2 and corrected the absolute time calculation. That was all to get it running for me. ----------------------------------------------------------------------- Hi there. Perhaps I can clear up some mystification about AC3 passthrough in general and mplayer in special: To get the external decoder solution working, it must be fed with data which is bitidentical to the chunks in the source ac3 file (compressed data is very picky about bit errors). Additionally - or better to say 'historically' - the non-audio bit should be set in the spdif status fields to prevent old spdif hardware from reproducing ugly scratchy noise. Note: for current decoders (probably those with DTS capability) this safety bit isn't needed anymore. At least I can state that for my Sherwood RVD-6095RDS. I think it is due to DTS because DTS sound can reside on a ordinary AudioCD and an ordinary AudioCD-Player will always have it's audio-bit set. The sample format of the data must be 2channel 16bit (little endian IIRC). Samplerates are 48kHz - although my receiver also accepts 44100Hz. I do not know if this is due to an over-compatability of my receiver or if 44100 is also possible in the ac3 specs. For safety's sake lets keep this at 48000Hz. AC3 data chunks are inserted into the stream every 0x1600 bytes (don't bite me on that, look into 'ac3-iec958.c': 'ac3_iec958_build_burst'). To come back to the problem: data must be played bit-identically through the soundcard at the correct samplerate and should optionally have it's non-audio bit set. There are two ways to accomplish this: 1) Some OSS guy invented the format AFMT_AC3. Soundcard drivers implementing this format should therefore adjust it's mixers and switches to produce the desired output. Unfortunately some soundcard drivers do not support this format correctly and most do not even support it at all (including ALSA). 2) The alternative approach currently in mplayer CVS is to simply set the output format to 48kHz16bitLE and rely on the user to have the soundcard mixers adjusted properly. I do have two soundcards with digital IO facilities (CMI8738 and Trident4DWaveNX based) plus the mentioned decoder. I'm currently running Linux-2.4.17. Following configurations are happily running here: 1. Trident with ALSA drivers (OSS does not support Hoontech's dig. IO) 2. CMI with ALSA drivers 3. CMI with OSS drivers For Linux I'd suggest using ALSA because of it's cleaner architecture and more consitent user interface. Not to mention that it'll be the standard sound support in Linux soon. For those who want to stick to OSS drivers: The CMI8738 drivers works out-of-the-box, if the PCM/Wave mixer is set to 100%. For ALSA I'd suggest using its OSS emulation. More on that later. ALSA-0.9 invented the idea of cards, devices and dubdevices. You can reach the digital interface of all supported cards consitently by using the device 'hw:x,2' (x counting from 0 is the number of your soundcard). So most people would end up at 'hw:0,2'. This device can only be opened in sample formats and rates which are directly supported in hardware hence no samplerate conversion is done keeping the stream as-is. However most consumer soundcards do not support 44kHz so it would definitively be a bad idea to use this as your standard device if you wanted to listen to some mp3s (most of them are 44kHz due to CD source). Here the OSS comes to play again. You can configure which OSS device (/dev/dsp and /dev/adsp) uses which ALSA device. So I'd suggest pointing the standard '/dev/dsp' to standard 'hw:0,0' which suports mixing and samplerate conversion. No further reconfiguration would be needed for your sound apps. For movies I'd point '/dev/adsp' to 'hw:0,2' and configure mplayer to use adsp instead of dsp. The samplerate constrain is no big deal here since movies usually are in 48Khz anyway. The configuration in '/etc/modules.conf' is no big deal also: alias snd-card-0 snd-card-cmipci # insert your card here alias snd-card-1 snd-pcm-oss # load OSS emulation options snd-pcm-oss snd_dsp_map=0 snd_adsp_map=2 # do the mapping This works flawlessly in combination with alsa's native SysVrc-init-script 'alsasound'. Be sure to disable any distribution dependent script (e.g. Mandrake-8.1 has an 'alsa' script which depends on ALSA-0.5). Sorry for you *BSD'lers out there. I have no grasp on sound support there. HTH Marcus mpv-0.3.4/DOCS/OUTDATED-tech/libao2.txt000066400000000000000000000047661227276354400171440ustar00rootroot000000000000006. libao2: this control audio playing As in libvo (see 5.) also here are some drivers, based on the same API: static int control(int cmd, int arg); This is for reading/setting driver-specific and other special parameters. Not really used for now. static int init(int rate,int channels,int format,int flags); The init of driver, opens device, sets sample rate, channels, sample format parameters. Sample format: usually AFMT_S16_LE or AFMT_U8, for more definitions see dec_audio.c and linux/soundcards.h files! static void uninit(void); Guess what. Ok I help: closes the device, not (yet) called when exit. static void reset(void); Resets device. To be exact, it's for deleting buffers' contents, so after reset() the previously received stuff won't be output. (called if pause or seek) static int get_space(void); Returns how many bytes can be written into the audio buffer without blocking (making caller process wait). MPlayer occasionally checks the remaining space and tries to fill the buffer with play() if there's free space. The buffer size used should be sane; a buffer that is too small could run empty before MPlayer tries filling it again (normally once per video frame), a buffer that is too big would force MPlayer decode the file far ahead trying to find enough audio data to fill it. static int play(void* data,int len,int flags); Plays a bit of audio, which is received throught the "data" memory area, with a size of "len". It has to copy the data, because they can be overwritten after the call is made. Doesn't have to use all the bytes; it has to return the number of bytes used used (copied to buffer). If flags|AOPLAY_FINAL_CHUNK is true then this is the last audio in the file. The purpose of this flag is to tell aos that round down the audio played from "len" to a multiple of some chunksize that this "len" should not be rounded down to 0 or the data will never be played (as MPlayer will never call play() with a larger len). static float get_delay(void); Returns how long time it will take to play the data currently in the output buffer. Be exact, if possible, since the whole timing depends on this! In the worst case, return the maximum delay. !!! Because the video is synchronized to the audio (card), it's very important !!! that the get_delay function is correctly implemented! static void audio_pause(void); Pause playing but do not delete buffered data if possible. static void audio_resume(void); Continue playing after audio_pause(). mpv-0.3.4/DOCS/OUTDATED-tech/libvo.txt000066400000000000000000000214631227276354400171000ustar00rootroot00000000000000libvo --- the library to handle video output by A'rpi, 2002.04 ============================================ Note: before start on this, read colorspaces.txt ! The constants for different pixelformats are defined in img_format.h, their usage is mandatory. WARNING: Please keep in mind that some of this information may be out-dated, so if you are working on a new vo, consider submitting preliminary patches very early on. Currently vo_gl is one of the more up-to-date VOs to use as reference if you are unsure about something and do not want to ask on the list. vo_vdpau and vo_direct3d may be a good choice, too, they use different approaches closer to the sometimes convoluted way DirectX works. Each vo driver _has_ to implement these: preinit(): init the video system (to support querying for supported formats) uninit(): Uninit the whole system, this is on the same "level" as preinit. control(): Current controls (VOCTRL_QUERY_FORMAT must be implemented, VOCTRL_DRAW_IMAGE, VOCTRL_FULLSCREEN, VOCTRL_UPDATE_SCREENINFO should be implemented): VOCTRL_QUERY_FORMAT - queries if a given pixelformat is supported. It also returns various flags decsirbing the capabilities of the driver with teh given mode. for the flags, see file vfcaps.h ! the most important flags, every driver must properly report these: 0x1 - supported (with or without conversion) 0x2 - supported without conversion (define 0x1 too!) 0x100 - driver/hardware handles timing (blocking) also SET sw/hw scaling and osd support flags, and flip, and accept_stride if you implement VOCTRL_DRAW_IMAGE (see bellow) NOTE: VOCTRL_QUERY_FORMAT may be called _before_ first config() but is always called between preinit() and uninit() VOCTRL_GET_IMAGE libmpcodecs Direct Rendering interface You need to update mpi (mp_image.h) structure, for example, look at vo_x11, vo_sdl, vo_xv or mga_common. VOCTRL_DRAW_IMAGE replacement for the current draw_slice/draw_frame way of passing video frames. by implementing SET_IMAGE, you'll get image in mp_image struct instead of by calling draw_*. unless you return VO_TRUE for VOCTRL_DRAW_IMAGE call, the old-style draw_* functils will be called! Note: draw_slice is still mandatory, for per-slice rendering! VOCTRL_RESET - reset the video device This is sent on seeking and similar and is useful if you are using a device which prebuffers frames that need to flush them before refilling audio/video buffers. VOCTRL_PAUSE VOCTRL_RESUME VOCTRL_GUISUPPORT return true only if driver supports co-operation with MPlayer's GUI (not yet used by GUI) VOCTRL_SET_EQUALIZER set the video equalizer to the given values two arguments are provided: item and value item is a string, the possible values are (currently): brightness, contrast, saturation, hue VOCTRL_GET_EQUALIZER get the current video equalizer values two arguments are provided: item and value item is a string, the possible values are (currently): brightness, contrast, saturation, hue VOCTRL_ONTOP Makes the player window stay-on-top. Only supported (currently) by drivers which use X11, except SDL, as well as directx and gl2 under Windows. VOCTRL_BORDER Makes the player window borderless. VOCTRL_FULLSCREEN Switch from and to fullscreen mode VOCTRL_GET_PANSCAN VOCTRL_SET_PANSCAN Needed to implement pan-scan support ('w' and 'e' keys during playback in fullscreen mode) VOCTRL_START_SLICE Called before the first draw_slice of each frame, useful if you need to do some set-up work. VOCTRL_DRAW_EOSD Required for EOSD (ASS subtitle) support. Provides all information necessary to draw the EOSD for the current video frame. VOCTRL_GET_EOSD_RES Required for EOSD (ASS subtitle) support. Informs the ASS renderer about the properties of the drawing area (size, borders). VOCTRL_SET_DEINTERLACE VOCTRL_GET_DEINTERLACE Get or set deinterlacing status for VOs that support some kind of deinterlacing. VOCTRL_UPDATE_SCREENINFO Should set the xinerama_x, xinerama_y, vo_screenwidth and vo_screenheight appropriately for the currently used monitor and -xineramascreen option. Usually should simply call the w32_update_xinerama_info or update_xinerama_info function. By supporting this, the VO also requests the newer API that sets vo_dx, vo_dy etc. appropriately before config() is called. config(): Set up the video system. You get the dimensions and flags. width, height: size of the source image d_width, d_height: wanted scaled/display size (it's a hint) Flags: 0x01 - force fullscreen (-fs) 0x02 - allow mode switching (-vm) 0x04 - allow software scaling (-zoom) 0x08 - flipping (-flip) They're defined as VOFLAG_* (see libvo/video_out.h) IMPORTANT NOTE: config() may be called 0 (zero), 1 or more (2,3...) times between preinit() and uninit() calls. You MUST handle it, and you shouldn't crash at second config() call or at uninit() without any config() call! To make your life easier, vo_config_count is set to the number of previous config() call, counted from preinit(). It's set by the caller (vf_vo.c), you don't have to increase it! So, you can check for vo_config_count>0 in uninit() when freeing resources allocated in config() to avoid crash! You should implement VOCTRL_UPDATE_SCREENINFO so that vo_dx, vo_dy, vo_dwidth and vo_dheight are already pre-set to values that take aspect and -geometry into account. It is also necessary to properly support multi-monitor setups (if based on x11_common, w32_common). draw_slice(): this displays YV12 pictures (3 planes, one full sized that contains brightness (Y), and 2 quarter-sized which the colour-info (U,V). MPEG codecs (libmpeg2, opendivx) use this. This doesn't have to display the whole frame, only update small parts of it. If this is not supported, it must be signaled in QUERY_FORMAT with VOCAP_NOSLICES. draw_frame(): this is the older interface, this displays only complete frames, and can do only packed format (YUY2, RGB/BGR). Win32 codecs use this (DivX, Indeo, etc). If you implement VOCTRL_DRAW_IMAGE, you do not need to implement draw_frame. draw_osd(): this displays subtitles and OSD. It's a bit tricky to use it, since it's a callback-style stuff. It should call vo_draw_text() with screen dimension and your draw_alpha implementation for the pixelformat (function pointer). The vo_draw_text() checks the characters to draw, and calls draw_alpha() for each. As a help, osd.c contains draw_alpha for each pixelformats, use this if possible! Note that if you do not draw directly onto the video you should use vo_draw_text_ext() which allows you to specify the border values etc. needed to draw DVD menu highlights at the correct place. If you do not want to implement this, you can still use -vf expand=osd=1 to draw the OSD, or even implement code to insert this filter automatically. Make sure you set VFCAP_OSD depending on whether you implemented it or not. NOTE: This one will be obsolete soon! But it's still useful when you want to do tricks, like rendering osd _after_ hardware scaling (tdfxfb) or render subtitles under of the image (vo_mpegpes, sdl) NOTE2: above NOTE is probably wrong, there are currently no plans to obsolete draw_osd, though there is the more advanced EOSD support for ASS subtitles. flip_page(): this is called after each frame, this displays the buffer for real. This is 'swapbuffers' when doublebuffering. Try to do as little work here as possible, since that affect jitter/ A-V sync. mpv-0.3.4/DOCS/OUTDATED-tech/mpsub.sub000066400000000000000000000033421227276354400170610ustar00rootroot00000000000000TITLE=Weird Al Yankovic - The Saga Begins (clip) # just to be informative (maybe future # use?) FILE=14233792,7972c637f619e01854ecb453b7339e3f # size,md5 AUTHOR=Gabucino TYPE=VIDEO # maybe AUDIO in future (for displaying # mp3 lyrics while playing or whatever) FORMAT=TIME # this file contains measures based on # TIME, not frames. # if FORMAT is a number, then it's frame based, i.e.: # FORMAT=25 NOTE=MPlayerSub test file v0.1 # first number : wait this much after previous subtitle disappeared # second number : display the current subtitle for this many seconds 15 3 A long, long time ago... 0 3 in a galaxy far away... 0 3 Naboo was under an attack. 1 2.5 And I thought me and Qui-Gon Jinn could 0 2.5 talk the Federation into 0 4 ...maybe cutting them a little slack. 2 3 But their response, it didn't thrill us, 0 3 They locked the doors, and tried to kill us. 0 2.5 We escaped from that gas, 0 3.5 then met Jar-jar and Boss-Nass. 1 6 We took a bongo from the scene and we went to Theed to see the Queen. 0 5 We all wound' up on Tatooine. 0 6 That's where, we've found this boy. 0 4 Oh my, my this here Anakin guy, 0 5 maybe Vader someday later now he's just a small fry. 0 4 And he left his home and kissed his mommy goodbye, 0 5 singing "Soon I'm gonna be a Jedi!" 6 6 Did you know this junkyard slave isn't even old enough to shave, 0 3 but he can use the Force, they say. 1 6 Ahh, do you see him hitting on the queen though he's just nine and she's fourteen 0 6 yeah, he's probably gonna marry her, someday! mpv-0.3.4/DOCS/OUTDATED-tech/swscaler_filters.txt000066400000000000000000000012371227276354400213350ustar00rootroot00000000000000software scaler filter docs -ssf cgb= chrominance gaussian blur useful for videos with some chroma (color) noise (TV captures, VHS, ...) -ssf lgb= -> luminance gaussian blur hmm, mostly special effect, could be used as lame noise reducer though -ssf chs= -> shift chrominance horizontally -ssf cvs= -> shift chrominance vertically useful if the luma & chroma are not aligned exactly -ssf cs= -> chrominance sharpen -ssf ls= -> luminance sharpen simple sharpening filter note: these will only work if the swscaler is used at all (use -vf scale) example: mplayer foobar.avi -vf scale -ssf lgb=3.0 mpv-0.3.4/DOCS/OUTDATED-tech/swscaler_methods.txt000066400000000000000000000045171227276354400213340ustar00rootroot00000000000000 artifact types: --------------------------------------------------------------------- ringing wave or noise like patterns around sharp edges bad: sinc, lanczos (with high filter length) acceptable: lanczos (with low filter length), cubic, spline ok: area, (fast)blinear, gauss, point blur loss of detail / high frequency bad: gauss with high variance acceptable: (fast)bilinear, area ok: others aliasing (only downscale) straight lines look like staircases areas of high detail look worse regular patterns turn into a funny looking mess (moire patterns) bad: fast bilinear, point, gauss with low variance acceptable: area ok: others blocky (upscale only) looks like the image is made of rectangular blocks like a mosaic bad: point ok: others recommendations: (based upon my personal opinion many ppl might disagree ...) --------------------------------------------------------------------- the recommended scalers for upscaling: fast_bilinear, point if speed is important cubic, spline, lanczos if quality is important the recommended scalers for downscaling: fast_bilinear, point if speed is important gauss, bilinear if quality is important cubic, spline, lanczos if a sharper picture is important note: when encoding at a limited amount of bits (not constant quantizer) then a slightly blurred input might look better after decoding than a slightly sharpened one, especially for lower bitrates sws numbers / names / artifact types ------------------------------------------------------------------------- r ringing b blurry a aliasing (downscale only) m mosaic (blocky) (upscale only) -sws 0 fast bilinear bA -sws 1 bilinear b -sws 2 bicubic high sharpness r low sharpness b -sws 3 experimental ???? -sws 4 nearest neighbour AM -sws 5 area ba -sws 6 luma bicubic / chroma bilinear r -sws 7 gauss low sharpness B high sharpness AM -sws 8 sinc R -sws 9 lanczos long filter R short filter b -sws 10 bicubic spline r Notes: area upscale is identical to bilinear mpv-0.3.4/DOCS/crosscompile-mingw.txt000066400000000000000000000032541227276354400174520ustar00rootroot00000000000000Cross compiling mpv to Windows is supported with MinGW-w64. This can be used to produce both 32 bit and 64 bit executables. MinGW-w64 is available from http://mingw-w64.sourceforge.net. You have to run mpv's configure with these arguments: DEST_OS=win32 TARGET=i686-w64-mingw32 ./waf configure Using mingw-w64-cmake to setup a MinGW-w64 environment is recommended (this will also build mpv and its dependencies): https://github.com/lachs0r/mingw-w64-cmake Alternatively, use MXE: http://mxe.cc Warning: the original MinGW (http://www.mingw.org) is unsupported. Note that MinGW environments included in Linux distributions are often broken, outdated and useless, and usually don't use MinGW-w64. Example with MXE ================ # Download MXE. Note that compiling the required packages requires about 1 GB # or more! cd /opt git clone https://github.com/mxe/mxe mingw cd mingw # Edit the MXE target, so that MinGW-w64 for 32 bit targets is built. echo "MXE_TARGETS := i686-w64-mingw32" > settings.mk # Build required packages. The following provide a minimum required to build # mpv. (Not all of the following packages are strictly required.) make gcc make ffmpeg make libass make jpeg make pthreads # Build mpv. The target will be used to automatically select the name of the # build tools involved (e.g. it will use i686-w64-mingw32-gcc). git clone https://github.com/mpv-player/mpv.git cd mpv export PATH=/opt/mingw/usr/bin/:$PATH DEST_OS=win32 TARGET=i686-w64-mingw32 ./waf configure ./waf build # This should work. Note however that MXE’s ffmpeg package might be very old # in order to avoid breaking e.g. xine-lib, so you might want to update that # or build it manually as well. mpv-0.3.4/DOCS/edl-mpv.rst000066400000000000000000000077671227276354400152030ustar00rootroot00000000000000EDL files ========= EDL files basically concatenate ranges of video/audio from multiple source files into a single continuous virtual file. Each such range is called a segment, and consists of source file, source offset, and segment length. For example:: # mpv EDL v0 f1.mkv,10,20 f2.mkv f1.mkv,40,10 This would skip the first 10 seconds of the file f1.mkv, then play the next 20 seconds, then switch to the file f2.mkv and play all of it, then switch back to f1.mkv, skip to the 40 second mark, and play 10 seconds, and then stop playback. The difference to specifying the files directly on command line (and using ``--{ --start=10 --length=20 f1.mkv --}`` etc.) is that the virtual EDL file appears as a virtual timeline (like a single file), instead as a playlist. The general simplified syntax is:: # mpv EDL v0 ,, If the start time is omitted, 0 is used. If the length is omitted, the estimated duration of the source file is used. Note:: mpv can't use ordered chapter files or libquvi-resolved URLs in EDL entries. Usage of relative or absolute paths as well as any protocol prefixes is prevented for security reasons. Syntax of mpv EDL files ======================= Generally, the format is relatively strict. No superfluous whitespace (except empty lines and commented lines) are allowed. You must use UNIX line breaks. The first line in the file must be ``# mpv EDL v0``. This designates that the file uses format version 0, which is not frozen yet and may change any time. (If you need a stable EDL file format, make a feature request. Likewise, if you have suggestions for improvements, it's not too late yet.) The rest of the lines belong to one of these classes: 1) An empty or commented line. A comment starts with ``#``, which must be the first character in the line. The rest of the line (up until the next line break) is ignored. An empty line has 0 bytes between two line feed bytes. 2) A segment entry in all other cases. Each segment entry consists of a list of named or unnamed parameters. Parameters are separated with ``,``. Named parameters consist of a name, followed by ``=``, followed by the value. Unnamed parameters have only a value, and the name is implicit from the parameter position. Syntax:: segment_entry ::= ( ',' )* param ::= [ '=' ] ( | '%' '%' ) The ``name`` string can consist of any characters, except ``=%,;\n``. The ``value`` string can consist of any characters except of ``,;\n``. The construct starting with ``%`` allows defining any value with arbitrary contents inline, where ``number`` is an integer giving the number of bytes in ``valuebytes``. If a parameter value contains disallowed characters, it has to be guarded by a length specifier using this syntax. The parameter name defines the meaning of the parameter: 1) ``file``, the source file to use for this segment. 2) ``start``, a time value that specifies the start offset into the source file. 3) ``length``, a time value that specifies the length of the segment. (Currently, time values are floating point values in seconds.) Unnamed parameters carry implicit names. The parameter position determines which of the parameters listed above is set. For example, the second parameter implicitly uses the name ``start``. Example:: # mpv EDL v0 %18%filename,with,.mkv,10,length=20,param3=%13%value,escaped,param4=value2 this sets ``file`` to ``filename,with,.mkv``, ``start`` to ``10``, ``length`` to ``20``, ``param3`` to ``value,escaped``, ``param4`` to ``value2``. Instead of line breaks, the character ``;`` can be used. Line feed bytes and ``;`` are treated equally. Syntax of EDL URIs ================== mpv accepts inline EDL data in form of ``edl://`` URIs. Other than the header, the syntax is exactly the same. It's far more convenient to use ``;`` instead of line breaks, but that is orthogonal. Example: ``edl://f1.mkv,length=5,start=10;f2.mkv,30,20;f3.mkv`` mpv-0.3.4/DOCS/encoding.rst000066400000000000000000000117641227276354400154150ustar00rootroot00000000000000General usage ============= :: mpv infile -o outfile [-of outfileformat] [-ofopts formatoptions] \ [-ofps outfps | -oautofps] [-oharddup] [-ocopyts | -orawts] [-oneverdrop] \ [(any other mpv options)] \ -ovc outvideocodec [-ovcopts outvideocodecoptions] \ -oac outaudiocodec [-oacopts outaudiocodecoptions] Help for these options is provided if giving help as parameter, as in:: mpv -ovc help The suboptions of these generally are identical to ffmpeg's (as option parsing is simply delegated to ffmpeg). The option -ocopyts enables copying timestamps from the source as-is, instead of fixing them to match audio playback time (note: this doesn't work with all output container formats); -orawts even turns off discontinuity fixing. Note that if neither -ofps nor -oautofps is specified, VFR encoding is assumed and the time base is 24000fps. -oautofps sets -ofps to a guessed fps number from the input video. Note that not all codecs and not all formats support VFR encoding, and some which do have bugs when a target bitrate is specified - use -ofps or -oautofps to force CFR encoding in these cases. Of course, the options can be stored in a profile, like this .mpv/config section:: [myencprofile] vf-add = scale=480:-2 ovc = libx264 ovcopts-add = preset=medium,tune=fastdecode ovcopts-add = crf=23 ovcopts-add = maxrate=1500k,bufsize=1000k,rc_init_occupancy=900k,refs=2 ovcopts-add = profile=baseline oac = aac oacopts-add = b=96k One can then encode using this profile using the command:: mpv infile -o outfile.mp4 -profile myencprofile Some example profiles are provided in a file etc/encoding-profiles.conf; as for this, see below. Encoding examples ================= These are some examples of encoding targets this code has been used and tested for. Typical MPEG-4 Part 2 ("ASP", "DivX") encoding, AVI container:: mpv infile -o outfile.avi \ -ofps 25 \ -ovc mpeg4 -ovcopts qscale=4 \ -oac libmp3lame -oacopts ab=128k Note: AVI does not support variable frame rate, so -ofps must be used. The frame rate should ideally match the input (25 for PAL, 24000/1001 or 30000/1001 for NTSC) Typical MPEG-4 Part 10 ("AVC", "H.264") encoding, Matroska (MKV) container:: mpv infile -o outfile.mkv \ -ovc libx264 -ovcopts preset=medium,crf=23,profile=baseline \ -oac libvorbis -oacopts qscale=3 Typical MPEG-4 Part 10 ("AVC", "H.264") encoding, MPEG-4 (MP4) container:: mpv infile -o outfile.mp4 \ -ovc libx264 -ovcopts preset=medium,crf=23,profile=baseline \ -oac aac -oacopts ab=128k Typical VP8 encoding, WebM (restricted Matroska) container:: mpv infile -o outfile.mkv \ -of webm \ -ovc libvpx -ovcopts qmin=6,b=1000000k \ -oac libvorbis -oacopts qscale=3 Device targets ============== As the options for various devices can get complex, profiles can be used. An example profile file for encoding is provided in etc/encoding-profiles.conf in the source tree. This file is installed and loaded by default (if libavfilter is enabled at compilation). If you want to modify it, you can replace and it with your own copy by doing:: mkdir -p ~/.mpv cp /etc/mpv/encoding-profiles.conf ~/.mpv/encoding-profiles.conf Refer to the top of that file for more comments - in a nutshell, the following options are added by it:: -profile enc-to-dvdpal DVD-Video PAL, use dvdauthor -v pal+4:3 -a ac3+en -profile enc-to-dvdntsc DVD-Video NTSC, use dvdauthor -v ntsc+4:3 -a ac3+en -profile enc-to-bb-9000 MP4 for Blackberry Bold 9000 -profile enc-to-nok-6300 3GP for Nokia 6300 -profile enc-to-psp MP4 for PlayStation Portable -profile enc-to-iphone MP4 for iPhone -profile enc-to-iphone-4 MP4 for iPhone 4 (double res) -profile enc-to-iphone-5 MP4 for iPhone 5 (even larger res) You can encode using these with a command line like:: mpv infile -o outfile.mp4 -profile enc-to-bb-9000 Of course, you are free to override options set by these profiles by specifying them after the -profile option. What works ========== * Encoding at variable frame rate (default) * Encoding at constant frame rate using -ofps framerate -oharddup * 2-pass encoding (specify flags=+pass1 in the first pass's -ovcopts, specify flags=+pass2 in the second pass) * Hardcoding subtitles using vobsub, ass or srt subtitle rendering (just configure mpv for the subtitles as usual) * Hardcoding any other mpv OSD (e.g. time codes, using -osdlevel 3 and -vf expand=::::1) * Encoding directly from a DVD, network stream, webcam, or any other source mpv supports * Using x264 presets/tunings/profiles (by using profile=, tune=, preset= in the -ovcopts) * Deinterlacing/Inverse Telecine with any of mpv's filters for that * Audio file converting: mpv -o outfile.mp3 infile.flac -no-video -oac libmp3lame -oacopts ab=320k * inverse telecine filters (confirmed working: detc, pullup, filmdint) What does not work yet * 3-pass encoding (ensuring constant total size and bitrate constraints while having VBR audio; mencoder calls this "frameno") * Direct stream copy mpv-0.3.4/DOCS/man/000077500000000000000000000000001227276354400136375ustar00rootroot00000000000000mpv-0.3.4/DOCS/man/docutils.conf000066400000000000000000000011721227276354400163350ustar00rootroot00000000000000[latex2e writer] use-latex-docinfo: yes use-latex-toc: yes hyperlink-color: Blue!30!RoyalPurple!70!Black latex-preamble: \usepackage[usenames,dvipsnames]{xcolor} \usepackage{fullpage} \usepackage{graphicx} \renewcommand{\familydefault}{\sfdefault} \makeatletter \renewcommand{\maketitle}{ \begin{center} \vspace*{-1.5em} \begin{Huge} \@title \end{Huge} \end{center} } \makeatother mpv-0.3.4/DOCS/man/en/000077500000000000000000000000001227276354400142415ustar00rootroot00000000000000mpv-0.3.4/DOCS/man/en/af.rst000066400000000000000000000570701227276354400153720ustar00rootroot00000000000000AUDIO FILTERS ============= Audio filters allow you to modify the audio stream and its properties. The syntax is: ``--af=`` Setup a chain of audio filters. .. note:: To get a full list of available audio filters, see ``--af=help``. You can also set defaults for each filter. The defaults are applied before the normal filter parameters. ``--af-defaults=`` Set defaults for each filter. Audio filters are managed in lists. There are a few commands to manage the filter list: ``--af-add=`` Appends the filters given as arguments to the filter list. ``--af-pre=`` Prepends the filters given as arguments to the filter list. ``--af-del=`` Deletes the filters at the given indexes. Index numbers start at 0, negative numbers address the end of the list (-1 is the last). ``--af-clr`` Completely empties the filter list. Available filters are: ``lavrresample[=option1:option2:...]`` This filter uses libavresample (or libswresample, depending on the build) to change sample rate, sample format, or channel layout of the audio stream. This filter is automatically enabled if the audio output does not support the audio configuration of the file being played. It supports only the following sample formats: u8, s16, s32, float. ``filter-size=`` Length of the filter with respect to the lower sampling rate. (default: 16) ``phase-shift=`` Log2 of the number of polyphase entries. (..., 10->1024, 11->2048, 12->4096, ...) (default: 10->1024) ``cutoff=`` Cutoff frequency (0.0-1.0), default set depending upon filter length. ``linear`` If set then filters will be linearly interpolated between polyphase entries. (default: no) ``no-detach`` Do not detach if input and output audio format/rate/channels match. (If you just want to set defaults for this filter that will be used even by automatically inserted lavrresample instances, you should prefer setting them with ``--af-defaults=lavrresample:...``.) ``o=`` Set AVOptions on the SwrContext or AVAudioResampleContext. These should be documented by FFmpeg or Libav. ``lavcac3enc[=tospdif[:bitrate[:minchn]]]`` Encode multi-channel audio to AC-3 at runtime using libavcodec. Supports 16-bit native-endian input format, maximum 6 channels. The output is big-endian when outputting a raw AC-3 stream, native-endian when outputting to S/PDIF. If the input sample rate is not 48 kHz, 44.1 kHz or 32 kHz, it will be resampled to 48 kHz. ``tospdif=`` Output raw AC-3 stream if ``no``, output to S/PDIF for passthrough if ``yes`` (default). ``bitrate=`` The bitrate use for the AC-3 stream. Set it to 384 to get 384 kbps. Valid values: 32, 40, 48, 56, 64, 80, 96, 112, 128, 160, 192, 224, 256, 320, 384, 448, 512, 576, 640. The special value ``default`` selects a default bitrate based on the input channel number: :1ch: 96 :2ch: 192 :3ch: 224 :4ch: 384 :5ch: 448 :6ch: 448 ``minchn=`` If the input channel number is less than ````, the filter will detach itself (default: 5). ``sweep[=speed]`` Produces a sine sweep. ``<0.0-1.0>`` Sine function delta, use very low values to hear the sweep. ``sinesuppress[=freq:decay]`` Remove a sine at the specified frequency. Useful to get rid of the 50/60Hz noise on low quality audio equipment. It only works on mono input. ```` The frequency of the sine which should be removed (in Hz) (default: 50) ```` Controls the adaptivity (a larger value will make the filter adapt to amplitude and phase changes quicker, a smaller value will make the adaptation slower) (default: 0.0001). Reasonable values are around 0.001. ``bs2b[=option1:option2:...]`` Bauer stereophonic to binaural transformation using libbs2b. Improves the headphone listening experience by making the sound similar to that from loudspeakers, allowing each ear to hear both channels and taking into account the distance difference and the head shadowing effect. It is applicable only to 2-channel audio. ``fcut=<300-1000>`` Set cut frequency in Hz. ``feed=<10-150>`` Set feed level for low frequencies in 0.1*dB. ``profile=`` Several profiles are available for convenience: :default: will be used if nothing else was specified (fcut=700, feed=45) :cmoy: Chu Moy circuit implementation (fcut=700, feed=60) :jmeier: Jan Meier circuit implementation (fcut=650, feed=95) If ``fcut`` or ``feed`` options are specified together with a profile, they will be applied on top of the selected profile. ``hrtf[=flag]`` Head-related transfer function: Converts multichannel audio to 2-channel output for headphones, preserving the spatiality of the sound. ==== =================================== Flag Meaning ==== =================================== m matrix decoding of the rear channel s 2-channel matrix decoding 0 no matrix decoding (default) ==== =================================== ``equalizer=g1:g2:g3:...:g10`` 10 octave band graphic equalizer, implemented using 10 IIR band-pass filters. This means that it works regardless of what type of audio is being played back. The center frequencies for the 10 bands are: === ========== No. frequency === ========== 0 31.25 Hz 1 62.50 Hz 2 125.00 Hz 3 250.00 Hz 4 500.00 Hz 5 1.00 kHz 6 2.00 kHz 7 4.00 kHz 8 8.00 kHz 9 16.00 kHz === ========== If the sample rate of the sound being played is lower than the center frequency for a frequency band, then that band will be disabled. A known bug with this filter is that the characteristics for the uppermost band are not completely symmetric if the sample rate is close to the center frequency of that band. This problem can be worked around by upsampling the sound using a resampling filter before it reaches this filter. ``:::...:`` floating point numbers representing the gain in dB for each frequency band (-12-12) .. admonition:: Example ``mpv --af=equalizer=11:11:10:5:0:-12:0:5:12:12 media.avi`` Would amplify the sound in the upper and lower frequency region while canceling it almost completely around 1kHz. ``channels=nch[:routes]`` Can be used for adding, removing, routing and copying audio channels. If only ```` is given, the default routing is used. It works as follows: If the number of output channels is greater than the number of input channels, empty channels are inserted (except when mixing from mono to stereo; then the mono channel is duplicated). If the number of output channels is less than the number of input channels, the exceeding channels are truncated. ```` number of output channels (1-8) ```` List of ``,`` separated routes, in the form ``from1-to1,from2-to2,...``. Each pair defines where to route each channel. There can be at most 8 routes. Without this argument, the default routing is used. Since ``,`` is also used to separate filters, you must quote this argument with ``[...]`` or similar. .. admonition:: Examples ``mpv --af=channels=4:[0-1,1-0,0-2,1-3] media.avi`` Would change the number of channels to 4 and set up 4 routes that swap channel 0 and channel 1 and leave channel 2 and 3 intact. Observe that if media containing two channels were played back, channels 2 and 3 would contain silence but 0 and 1 would still be swapped. ``mpv --af=channels=6:[0-0,0-1,0-2,0-3] media.avi`` Would change the number of channels to 6 and set up 4 routes that copy channel 0 to channels 0 to 3. Channel 4 and 5 will contain silence. .. note:: You should probably not use this filter. If you want to change the output channel layout, try the ``format`` filter, which can make mpv automatically up- and downmix standard channel layouts. ``format=format:srate:channels:out-format:out-srate:out-channels`` Force a specific audio format/configuration without actually changing the audio data. Keep in mind that the filter system might auto-insert actual conversion filters before or after this filter if needed. All parameters are optional. The first 3 parameters restrict what the filter accepts as input. The ``out-`` parameters change the audio format, without actually doing a conversion. The data will be 'reinterpreted' by the filters or audio outputs following this filter. ```` Force conversion to this format. Use ``--af=format=format=help`` to get a list of valid formats. ```` Force conversion to a specific sample rate. The rate is an integer, 48000 for example. ```` Force mixing to a specific channel layout. See ``--channels`` option for possible values. ```` ```` ```` See also ``--format``, ``--srate``, and ``--channels`` for related options. Keep in mind that ``--channels`` does not actually force the number of channels in most cases, while this filter can do this. *NOTE*: this filter used to be named ``force``. Also, unlike the old ``format`` filter, this does not do any actual conversion anymore. Conversion is done by other, automatically inserted filters. ``convert24`` Filter for internal use only. Converts between 24-bit and 32-bit sample formats. ``convertsignendian`` Filter for internal use only. Converts between signed/unsigned formats and formats with different endian. ``volume[=volumedb[:softclip[:s16]]]`` Implements software volume control. Use this filter with caution since it can reduce the signal to noise ratio of the sound. In most cases it is best to use the *Master* volume control of your sound card or the volume knob on your amplifier. *NOTE*: This filter is not reentrant and can therefore only be enabled once for every audio stream. ```` Sets the desired gain in dB for all channels in the stream from -200dB to +60dB, where -200dB mutes the sound completely and +60dB equals a gain of 1000 (default: 0). ```` Turns soft clipping on. Soft-clipping can make the sound more smooth if very high volume levels are used. Enable this option if the dynamic range of the loudspeakers is very low. *WARNING*: This feature creates distortion and should be considered a last resort. ```` Force S16 sample format if set. Lower quality, but might be faster in some situations. .. admonition:: Example ``mpv --af=volume=10.1 media.avi`` Would amplify the sound by 10.1dB and hard-clip if the sound level is too high. ``pan=n[:]`` Mixes channels arbitrarily. Basically a combination of the volume and the channels filter that can be used to down-mix many channels to only a few, e.g. stereo to mono, or vary the "width" of the center speaker in a surround sound system. This filter is hard to use, and will require some tinkering before the desired result is obtained. The number of options for this filter depends on the number of output channels. An example how to downmix a six-channel file to two channels with this filter can be found in the examples section near the end. ```` Number of output channels (1-8). ```` A list of values ``[L00,L01,L02,...,L10,L11,L12,...,Ln0,Ln1,Ln2,...]``, where each element ``Lij`` means how much of input channel i is mixed into output channel j (range 0-1). So in principle you first have n numbers saying what to do with the first input channel, then n numbers that act on the second input channel etc. If you do not specify any numbers for some input channels, 0 is assumed. Note that the values are separated by ``,``, which is already used by the option parser to separate filters. This is why you must quote the value list with ``[...]`` or similar. .. admonition:: Examples ``mpv --af=pan=1:[0.5,0.5] media.avi`` Would downmix from stereo to mono. ``mpv --af=pan=3:[1,0,0.5,0,1,0.5] media.avi`` Would give 3 channel output leaving channels 0 and 1 intact, and mix channels 0 and 1 into output channel 2 (which could be sent to a subwoofer for example). .. note:: If you just want to force remixing to a certain output channel layout, it is easier to use the ``format`` filter. For example, ``mpv '--af=format=channels=5.1' '--channels=5.1'`` would always force remixing audio to 5.1 and output it like this. ``sub[=fc:ch]`` Adds a subwoofer channel to the audio stream. The audio data used for creating the subwoofer channel is an average of the sound in channel 0 and channel 1. The resulting sound is then low-pass filtered by a 4th order Butterworth filter with a default cutoff frequency of 60Hz and added to a separate channel in the audio stream. .. warning:: Disable this filter when you are playing media with an LFE channel (e.g. 5.1 surround sound), otherwise this filter will disrupt the sound to the subwoofer. ```` cutoff frequency in Hz for the low-pass filter (20Hz to 300Hz) (default: 60Hz) For the best result try setting the cutoff frequency as low as possible. This will improve the stereo or surround sound experience. ```` Determines the channel number in which to insert the sub-channel audio. Channel number can be between 0 and 7 (default: 5). Observe that the number of channels will automatically be increased to if necessary. .. admonition:: Example ``mpv --af=sub=100:4 --channels=5 media.avi`` Would add a subwoofer channel with a cutoff frequency of 100Hz to output channel 4. ``center`` Creates a center channel from the front channels. May currently be low quality as it does not implement a high-pass filter for proper extraction yet, but averages and halves the channels instead. ```` Determines the channel number in which to insert the center channel. Channel number can be between 0 and 7 (default: 5). Observe that the number of channels will automatically be increased to ```` if necessary. ``surround[=delay]`` Decoder for matrix encoded surround sound like Dolby Surround. Some files with 2-channel audio actually contain matrix encoded surround sound. ```` delay time in ms for the rear speakers (0 to 1000) (default: 20) This delay should be set as follows: If d1 is the distance from the listening position to the front speakers and d2 is the distance from the listening position to the rear speakers, then the delay should be set to 15ms if d1 <= d2 and to 15 + 5*(d1-d2) if d1 > d2. .. admonition:: Example ``mpv --af=surround=15 --channels=4 media.avi`` Would add surround sound decoding with 15ms delay for the sound to the rear speakers. ``delay[=[ch1,ch2,...]]`` Delays the sound to the loudspeakers such that the sound from the different channels arrives at the listening position simultaneously. It is only useful if you have more than 2 loudspeakers. ``[ch1,ch2,...]`` The delay in ms that should be imposed on each channel (floating point number between 0 and 1000). To calculate the required delay for the different channels, do as follows: 1. Measure the distance to the loudspeakers in meters in relation to your listening position, giving you the distances s1 to s5 (for a 5.1 system). There is no point in compensating for the subwoofer (you will not hear the difference anyway). 2. Subtract the distances s1 to s5 from the maximum distance, i.e. ``s[i] = max(s) - s[i]; i = 1...5``. 3. Calculate the required delays in ms as ``d[i] = 1000*s[i]/342; i = 1...5``. .. admonition:: Example ``mpv --af=delay=[10.5,10.5,0,0,7,0] media.avi`` Would delay front left and right by 10.5ms, the two rear channels and the subwoofer by 0ms and the center channel by 7ms. ``export=mmapped_file:nsamples]`` Exports the incoming signal to other processes using memory mapping (``mmap()``). Memory mapped areas contain a header:: int nch /* number of channels */ int size /* buffer size */ unsigned long long counter /* Used to keep sync, updated every time new data is exported. */ The rest is payload (non-interleaved) 16-bit data. ```` File to map data to (required) ```` number of samples per channel (default: 512). .. admonition:: Example ``mpv --af=export=/tmp/mpv-af_export:1024 media.avi`` Would export 1024 samples per channel to ``/tmp/mpv-af_export``. ``extrastereo[=mul]`` (Linearly) increases the difference between left and right channels which adds some sort of "live" effect to playback. ```` Sets the difference coefficient (default: 2.5). 0.0 means mono sound (average of both channels), with 1.0 sound will be unchanged, with -1.0 left and right channels will be swapped. ``drc[=method:target]`` Applies dynamic range compression. This maximizes the volume by compressing the audio signal's dynamic range. (Formerly called ``volnorm``.) ```` Sets the used method. 1 Use a single sample to smooth the variations via the standard weighted mean over past samples (default). 2 Use several samples to smooth the variations via the standard weighted mean over past samples. ```` Sets the target amplitude as a fraction of the maximum for the sample type (default: 0.25). .. note:: This filter can cause distortion with audio signals that have a very large dynamic range. ``ladspa=file:label:[,,...]`` Load a LADSPA (Linux Audio Developer's Simple Plugin API) plugin. This filter is reentrant, so multiple LADSPA plugins can be used at once. ```` Specifies the LADSPA plugin library file. .. note:: See also the note about the ``LADSPA_PATH`` variable in the `ENVIRONMENT VARIABLES`_ section. ``