diff options
Diffstat (limited to 'DOCS')
33 files changed, 7333 insertions, 2338 deletions
diff --git a/DOCS/client-api-changes.rst b/DOCS/client-api-changes.rst index 8cc48b8f66..e48cda4fa0 100644 --- a/DOCS/client-api-changes.rst +++ b/DOCS/client-api-changes.rst @@ -31,6 +31,46 @@ API changes =========== :: + + --- mpv 0.38.0 --- + 2.3 - partially revert the changes from API version 1.27, remove libmpv as + the default VO and move it to the bottom of the auto-probing order. + This restores the prior behavior on all platforms other than macOS, + but still auto selects libmpv/cocoa-cb on macOS if it was built with + support for cocoa-cb. + --- mpv 0.37.0 --- + 2.2 - add mpv_time_ns() + --- mpv 0.36.0 --- + 2.1 - add mpv_del_property() + --- mpv 0.35.0 --- + 2.0 - remove headers/functions of the obsolete opengl_cb API + - remove mpv_opengl_init_params.extra_exts field + - remove deprecated mpv_detach_destroy. Use mpv_destroy instead. + - remove obsolete mpv_suspend and mpv_resume + - remove deprecated SCRIPT_INPUT_DISPATCH, PAUSE and UNPAUSE, TRACKS_CHANGED + TRACK_SWITCHED, METADATA_UPDATE, CHAPTER_CHANGE events + --- mpv 0.33.0 --- + 1.109 - add MPV_RENDER_API_TYPE_SW and related (software rendering API) + - inactivate the opengl_cb API (always fails to initialize now) + The opengl_cb API was deprecated over 2 years ago. Use the render API + instead. + 1.108 - Deprecate MPV_EVENT_IDLE + - add mpv_event_start_file + - add the following fields to mpv_event_end_file: playlist_entry_id, + playlist_insert_id, playlist_insert_num_entries + - add mpv_event_to_node() + - add mpv_client_id() + 1.107 - Remove the deprecated qthelper.hpp. This was obviously not part of the + libmpv API, only an "additionally" provided helper, thus this is not + considered an API change. If you are maintaining a project that relies + on this header, you can simply download this file and adjust the + include statement to use it instead: + + https://raw.githubusercontent.com/mpv-player/mpv/v0.32.0/libmpv/qthelper.hpp + + It is a good idea to write better wrappers for your use, though. + --- mpv 0.31.0 --- + 1.107 - Deprecate MPV_EVENT_TICK --- mpv 0.30.0 --- 1.106 - Add cancel_fn to mpv_stream_cb_info 1.105 - Fix deadlock problems with MPV_RENDER_PARAM_ADVANCED_CONTROL and if @@ -48,7 +88,6 @@ API changes - add mpv_abort_async_command() 1.102 - rename struct mpv_opengl_drm_osd_size to mpv_opengl_drm_draw_surface_size - rename MPV_RENDER_PARAM_DRM_OSD_SIZE to MPV_RENDER_PARAM_DRM_DRAW_SURFACE_SIZE - --- mpv 0.29.0 --- 1.101 - add MPV_RENDER_PARAM_ADVANCED_CONTROL and related API - add MPV_RENDER_PARAM_NEXT_FRAME_INFO and related symbols @@ -240,7 +279,7 @@ API changes - extend the "--start" option; a leading "+", which was previously insignificant is now significant - add "cache-free" and "cache-used" properties - - OSX: the "coreaudio" AO spdif code is split into a separate AO + - macOS: the "coreaudio" AO spdif code is split into a separate AO --- mpv 0.4.0 --- 1.0 - the API is declared stable diff --git a/DOCS/compile-windows.md b/DOCS/compile-windows.md index fcf1be7e70..04bc200f37 100644 --- a/DOCS/compile-windows.md +++ b/DOCS/compile-windows.md @@ -4,28 +4,43 @@ Compiling for Windows Compiling for Windows is supported with MinGW-w64. This can be used to produce both 32-bit and 64-bit executables, and it works for building on Windows and cross-compiling from Linux and Cygwin. MinGW-w64 is available from: -http://mingw-w64.sourceforge.net. +https://www.mingw-w64.org/ While building a complete MinGW-w64 toolchain yourself is possible, there are a few build environments and scripts to help ease the process, such as MSYS2 and MXE. Note that MinGW environments included in Linux distributions are often broken, outdated and useless, and usually don't use MinGW-w64. -**Warning**: the original MinGW (http://www.mingw.org) is unsupported. +**Warning**: the original MinGW (https://osdn.net/projects/mingw/) is unsupported. Cross-compilation ================= -When cross-compiling, you have to run mpv's configure with these arguments: - -```bash -DEST_OS=win32 TARGET=i686-w64-mingw32 ./waf configure +When cross-compiling, it is recommended to use a meson crossfile to setup +the cross compiling environment. A minimal example is included below: + +```ini +[binaries] +c = 'x86_64-w64-mingw32-gcc' +cpp = 'x86_64-w64-mingw32-g++' +ar = 'x86_64-w64-mingw32-ar' +strip = 'x86_64-w64-mingw32-strip' +exe_wrapper = 'wine64' + +[host_machine] +system = 'windows' +cpu_family = 'x86_64' +cpu = 'x86_64' +endian = 'little' ``` -[MXE](http://mxe.cc) makes it very easy to bootstrap a complete MingGW-w64 +See [meson's documentation](https://mesonbuild.com/Cross-compilation.html) for +more information. + +[MXE](https://mxe.cc) makes it very easy to bootstrap a complete MingGW-w64 environment from a Linux machine. See a working example below. -Alternatively, you can try [mingw-w64-cmake](https://github.com/lachs0r/mingw-w64-cmake), +Alternatively, you can try [mpv-winbuild-cmake](https://github.com/shinchiro/mpv-winbuild-cmake), which bootstraps a MinGW-w64 environment and builds mpv and dependencies. Example with MXE @@ -38,7 +53,7 @@ Example with MXE # # Refer to # -# http://mxe.cc/#requirements +# https://mxe.cc/#requirements # # Scroll down for disto/OS-specific instructions to install them. @@ -68,7 +83,7 @@ echo "MXE_TARGETS := i686-w64-mingw32.static" >> settings.mk # Build required packages. The following provide a minimum required to build # a reasonable mpv binary (though not an absolute minimum). -make gcc ffmpeg libass jpeg lua +make gcc ffmpeg libass jpeg lua luajit # Add MXE binaries to $PATH export PATH=/opt/mxe/usr/bin/:$PATH @@ -79,11 +94,8 @@ export PATH=/opt/mxe/usr/bin/:$PATH cd .. git clone https://github.com/mpv-player/mpv.git cd mpv -python ./bootstrap.py -DEST_OS=win32 TARGET=i686-w64-mingw32.static ./waf configure -# Or, if 64 bit version, -# DEST_OS=win32 TARGET=x86_64-w64-mingw32.static ./waf configure -./waf build +meson setup build --crossfile crossfile +meson compile -C build ``` Native compilation with MSYS2 @@ -99,7 +111,7 @@ To build 64-bit mpv on Windows: Installing MSYS2 ---------------- -1. Download an installer from https://msys2.github.io/ +1. Download an installer from https://www.msys2.org/ Both the i686 and the x86_64 version of MSYS2 can build 32-bit and 64-bit mpv binaries when running on a 64-bit version of Windows, but the x86_64 @@ -132,54 +144,49 @@ Installing mpv dependencies ```bash # Install MSYS2 build dependencies and a MinGW-w64 compiler -pacman -S git python $MINGW_PACKAGE_PREFIX-{pkg-config,gcc} +pacman -S git $MINGW_PACKAGE_PREFIX-{python,pkgconf,gcc,meson} # Install the most important MinGW-w64 dependencies. libass and lcms2 are also # pulled in as dependencies of ffmpeg. -pacman -S $MINGW_PACKAGE_PREFIX-{ffmpeg,libjpeg-turbo,lua51} +pacman -S $MINGW_PACKAGE_PREFIX-{ffmpeg,libjpeg-turbo,luajit} ``` Building mpv ------------ -Clone the latest mpv from git and install waf. **Note:** ``/usr/bin/python3`` -is invoked directly here, since an MSYS2 version of Python is required. - -```bash -git clone https://github.com/mpv-player/mpv.git && cd mpv -/usr/bin/python3 bootstrap.py -``` - Finally, compile and install mpv. Binaries will be installed to ``/mingw64/bin`` or ``/mingw32/bin``. ```bash -/usr/bin/python3 waf configure CC=gcc.exe --check-c-compiler=gcc --prefix=$MSYSTEM_PREFIX -/usr/bin/python3 waf install +meson setup build --prefix=$MSYSTEM_PREFIX +meson compile -C build ``` Or, compile and install both libmpv and mpv: ```bash -/usr/bin/python3 waf configure CC=gcc.exe --check-c-compiler=gcc --enable-libmpv-shared --prefix=$MSYSTEM_PREFIX -/usr/bin/python3 waf install +meson setup build -Dlibmpv=true --prefix=$MSYSTEM_PREFIX +meson compile -C build +meson install -C build ``` Linking libmpv with MSVC programs --------------------------------- -You can build C++ programs in Visual Studio and link them with libmpv. To do -this, you need a Visual Studio which supports ``stdint.h`` (recent ones do), +mpv/libmpv cannot be built with Visual Studio (Microsoft is too incompetent to +support C99/C11 properly and/or hates open source and Linux too much to +seriously do it). But you can build C++ programs in Visual Studio and link them +with a libmpv built with MinGW. + +To do this, you need a Visual Studio which supports ``stdint.h`` (recent ones do), and you need to create a import library for the mpv DLL: ```bash -lib /def:mpv.def /name:mpv-1.dll /out:mpv.lib /MACHINE:X64 +lib /name:mpv-1.dll /out:mpv.lib /MACHINE:X64 ``` The string in the ``/name:`` parameter must match the filename of the DLL (this -is simply the filename the MSVC linker will use). The ``mpv.def`` can be -retrieved from the mpv build directory, or can be produced by MingGW's -gendef.exe helper from the mpv DLL. +is simply the filename the MSVC linker will use). Static linking is not possible. @@ -204,6 +211,4 @@ Use of the ANGLE OpenGL backend requires a copy of the D3D compiler DLL that matches the version of the D3D SDK that ANGLE was built with (``d3dcompiler_43.dll`` in case of MinGW-built ANGLE) in the path or in the same folder as mpv. It must be of the same architecture (x86_64 / i686) as the -mpv you compiled. You can find copies here: - -https://mpv.srsfckn.biz/d3dcompiler.7z +mpv you compiled. diff --git a/DOCS/contribute.md b/DOCS/contribute.md index d891700cf3..4d2af4ea4e 100644 --- a/DOCS/contribute.md +++ b/DOCS/contribute.md @@ -5,13 +5,13 @@ General ------- The main contact for mpv development is IRC, specifically #mpv -and #mpv-devel on Freenode. Github is used for code review and +and #mpv-devel on Libera.chat. GitHub is used for code review and long term discussions. Sending patches --------------- -- Make a github pull request, or send a link to a plaintext patch created with +- Make a GitHub pull request, or send a link to a plaintext patch created with ``git format-patch``. - Plain diffs posted as pastebins are not acceptable! (Especially if the http link returns HTML.) They only cause extra work for everyone, because they lack @@ -41,7 +41,7 @@ Copyright of contributions behalf of your employer, and the employer owns the copyright, you must mention this. If the license of the code is not LGPLv2.1+, you must mention this. - These license statements are legally binding. -- Don't use fake names (something that looks like an actual names, and may be +- Don't use fake names (something that looks like an actual name, and may be someone else's name, but is not your legal name). Using a pseudonyms is allowed if it can be used to identify or contact you, even if whatever account you used to submit the patch dies. @@ -55,10 +55,10 @@ Write good commit messages - Write informative commit messages. Use present tense to describe the situation with the patch applied, and past tense for the situation before the change. -- The subject line (the first line in a commit message) should contain a +- The subject line (the first line in a commit message) must contain a prefix identifying the sub system, followed by a short description what impact this commit has. This subject line and the commit message body - shouldn't be longer than 72 characters per line, because it messes up the + must not be longer than 72 characters per line, because it messes up the output of many git tools otherwise. For example, you fixed a crash in af_volume.c: @@ -68,7 +68,16 @@ Write good commit messages Having a prefix gives context, and is especially useful when trying to find a specific change by looking at the history, or when running ``git blame``. -- The body of the commit message (everything else after the subject line) should + + Sample prefixes: ``vo_gpu: ...``, ``command: ...``, ``DOCS/input: ...``, + ``TOOLS/osxbundle: ...``, ``osc.lua: ...``, etc. You can always check the git + log for commits which modify specific files to see which prefixes are used. + +- The first word after the ``:`` is lower case. +- Don't end the subject line with a ``.``. +- Put an empty line between the subject line and the commit message. + If this is missing, it will break display in common git tools. +- The body of the commit message (everything else after the subject line) must be as informative as possible and contain everything that isn't obvious. Don't hesitate to dump as much information as you can - it doesn't cost you anything. Put some effort into it. If someone finds a bug months or years @@ -77,13 +86,10 @@ Write good commit messages information to test the original bug. The old bug might be reintroduced while fixing the new bug. - The commit message should be wrapped on 72 characters per line, because git + The commit message must be wrapped on 72 characters per line, because git tools usually do not break text automatically. On the other hand, you do not need to break text that would be unnatural to break (like data for test cases, or long URLs). - - Important: put an empty line between the subject line and the commit message. - If this is missing, it will break display in common git tools. - Another summary of good conventions: https://chris.beams.io/posts/git-commit/ Split changes into multiple commits @@ -95,6 +101,25 @@ Split changes into multiple commits additional cosmetic changes in the same file you're working on. But don't do something like reformatting a whole file, and hiding an actual functional change in the same commit. +- Splitting changes does _not_ mean that you should make them as fine-grained + as possible. Commits should form logical steps in development. The way you + split changes is important for code review and analyzing bugs. + +Always squash fixup commits when making changes to pull requests +---------------------------------------------------------------- + +- If you make fixup commits to your pull request, you should generally squash + them with "git rebase -i". We prefer to have pull requests in a merge + ready state. +- We don't squash-merge (nor do we use GitHub's feature that does this) because + pull requests with multiple commits are perfectly legitimate, and the only + thing that makes sense in non-trivial cases. +- With complex pull requests, it *may* make sense to keep them separate, but + they should be clearly marked as such. Reviewing commits is generally easier + with fixups squashed. +- Reviewers are encouraged to look at individual commits instead of GitHub's + "changes from all commits" view (which just encourages bad git and review + practices). Touching user-visible parts may require updating the mpv docs ------------------------------------------------------------- @@ -106,21 +131,33 @@ Touching user-visible parts may require updating the mpv docs - Changes to command line options (addition/modification/removal) must be documented in options.rst. - Changes to input properties or input commands must be documented in input.rst. -- All incompatible changes to the user interface (options, properties, commands) - must be documented with a small note in interface-changes.rst. (Additions may - be documented there as well, but this isn't required.) - Changes to the libmpv API must be reflected in the libmpv's headers doxygen, and in client-api-changes.rst. +Interface change policy +----------------------- + +- All incompatible changes to the user interface (options, properties, commands) + must be documented by making a new text file with a txt extension containing a + small note in the DOCS/interface-changes directory. +- The name of the file should be brief and related to the commit that makes the + change. +- Grouping multiple related changes in the same file is also OK. Just be sure to + put each separate change on a different line. +- Documenting additions in DOCS/interface-changes is optional but encouraged. +- interface-changes.rst is never directly updated except when making new major + releases. +- See DOCS/interface-changes/example.txt for an example. + Code formatting --------------- -mpv uses C99 with K&R formatting, with some exceptions. +mpv uses C11 with K&R formatting, with some exceptions. - Use the K&R indent style. - Use 4 spaces of indentation, never use tabs (except in Makefiles). - Add a single space between keywords and binary operators. There are some other - cases where spaces should be added. Example: + cases where spaces must be added. Example: ```C if ((a * b) > c) { @@ -128,9 +165,9 @@ mpv uses C99 with K&R formatting, with some exceptions. some_function(a, b, c); } ``` -- Break lines on 80 columns. There is a hard limit of 85 columns. You may ignore +- Break lines on 80 columns. There is a hard limit of 100 columns. You may ignore this limit if there's a strong case that not breaking the line will increase - readability. Going over 85 columns might provoke endless discussions about + readability. Going over 100 columns might provoke endless discussions about whether such a limit is needed or not, so avoid it. - If the body of an if/for/while statement has more than 1 physical lines, then always add braces, even if they're technically redundant. @@ -153,7 +190,7 @@ mpv uses C99 with K&R formatting, with some exceptions. do_something(); } ``` -- If the if has an else branch, both branches should use braces, even if they're +- If the if has an else branch, both branches must use braces, even if they're technically redundant. Example: @@ -185,18 +222,30 @@ mpv uses C99 with K&R formatting, with some exceptions. - Remove any trailing whitespace. - Do not make stray whitespaces changes. +Header #include statement order +------------------------------- + +The order of ``#include`` statements in the source code is not very consistent. +New code must follow the following conventions: + +- Put standard includes (``#include <stdlib.h>`` etc.) on the top, +- then after a blank line, add library includes (``#include <zlib.h>`` etc.) +- then after a blank line, add internal includes (``#include "player/core.h"``) +- sort them alphabetically within these sections + General coding -------------- -- Use C99. Also freely make use of C99 features if it's appropriate, such as - stdbool.h. (Except VLA and complex number types.) +- Use C11. Also freely make use of C11 features if it's appropriate, but do not + use VLA and complex number types. - Don't use non-standard language (such as GNU C-only features). In some cases they may be warranted, if they are optional (such as attributes enabling printf-like format string checks). "#pragma once" is allowed as an exception. - But in general, standard C99 should be used. + But in general, standard C11 must be used. - The same applies to libc functions. We have to be Windows-compatible too. Use - functions guaranteed by C99 or POSIX only, unless your use is guarded by a - configure check. There is some restricted use of C11 (ask on IRC for details). + functions guaranteed by C11 or POSIX only, unless your use is guarded by a + configure check. Be mindful of MinGW-specifics since C11 support is not always + guaranteed. - Prefer fusing declaration and initialization, rather than putting declarations on the top of a block. Obvious data flow is more important than avoiding mixing declarations and statements, which is just a C90 artifact. @@ -207,7 +256,10 @@ General coding Code of Conduct --------------- -We have one, but the document describing it got lost accidentally. +Please note that this project is released with a Contributor Code of Conduct. +By participating in this project you agree to abide by its terms. +The Contributor Code of Conduct can be found here: +https://www.contributor-covenant.org/version/2/0/code_of_conduct/ Rules for git push access ------------------------- diff --git a/DOCS/edl-mpv.rst b/DOCS/edl-mpv.rst index c5771c2bca..0e4d2b410e 100644 --- a/DOCS/edl-mpv.rst +++ b/DOCS/edl-mpv.rst @@ -146,7 +146,8 @@ The current implementation will Another header part of this mechanism is ``no_clip``. This header is similar to ``mp4_dash``, but does not include on-demand opening/closing of segments, and does not support init segments. It also exists solely to support internal -ytdl requirements. +ytdl requirements. Using ``no_clip`` with segments is not recommended and +probably breaks. ``mp4_dash`` already implicitly does a variant of ``no_clip``. The ``mp4_dash`` and ``no_clip`` headers are not part of the core EDL format. They may be changed or removed at any time, depending on mpv's internal @@ -182,6 +183,144 @@ this will use a unified cache for all streams. The ``new_stream`` header is not part of the core EDL format. It may be changed or removed at any time, depending on mpv's internal requirements. +If the first ``!new_stream`` is redundant, it is ignored. This is the same +example as above:: + + # mpv EDL v0 + !new_stream + video.mkv + !new_stream + audio.mkv + +Note that ``!new_stream`` must be the first header. Whether the parser accepts +(i.e. ignores) or rejects other headers before that is implementation specific. + +Track metadata +============== + +The special ``track_meta`` header can set some specific metadata fields of the +current ``!new_stream`` partition. The tags are applied to all tracks within +the partition. It is not possible to set the metadata for individual tracks (the +feature was needed only for single-track media). + +It provides following parameters change track metadata: + +``lang`` + Set the language tag. + +``title`` + Set the title tag. + +``byterate`` + Number of bytes per second this stream uses. (Purely informational.) + +``index`` + The numeric index of the track this should map to (default: -1). This is + the 0-based index of the virtual stream as seen by the player, enumerating + all audio/video/subtitle streams. If nothing matches, this is silently + discarded. The special index -1 (the default) has two meanings: if there + was a previous meta data entry (either ``!track_meta`` or ``!delay_open`` + element since the last ``!new_stream``), then this element manipulates + the previous meta data entry. If there was no previous entry, a new meta + data entry that matches all streams is created. + +Example:: + + # mpv EDL v0 + !track_meta,lang=bla,title=blabla + file.mkv + !new_stream + !track_meta,title=ducks + sub.srt + +If ``file.mkv`` has an audio and a video stream, both will use ``blabla`` as +title. The subtitle stream will use ``ducks`` as title. + +The ``track_meta`` header is not part of the core EDL format. It may be changed +or removed at any time, depending on mpv's internal requirements. + +Global metadata +=============== + +The special ``global_tags`` header can set metadata fields (aka tags) of the EDL +file. This metadata is supposed to be informational, much like for example ID3 +tags in audio files. Due to lack of separation of different kinds of metadata it +is unspecified what names are allowed, how they are interpreted, and whether +some of them affect playback functionally. (Much of this is unfortunately +inherited from FFmpeg. Another consequence of this is that FFmpeg "normalized" +tags are recognized, or stuff like replaygain tags.) + +Example:: + + !global_tags,title=bla,something_arbitrary=even_more_arbitrary + +Any parameter names are allowed. Repeated use of this adds to the tag list. If +``!new_stream`` is used, the location doesn't matter. + +May possibly be ignored in some cases, such as delayed media opening. + +Delayed media opening +===================== + +The special ``delay_open`` header can be used to open the media URL of the +stream only when the track is selected for the first time. This is supposed to +be an optimization to speed up opening of a remote stream if there are many +tracks for whatever reasons. + +This has various tricky restrictions, and also will defer failure to open a +stream to "later". By design, it's supposed to be used for single-track streams. + +Using multiple segments requires you to specify all offsets and durations (also +it was never tested whether it works at all). Interaction with ``mp4_dash`` may +be strange. + +You can describe multiple sub-tracks by using multiple ``delay_open`` headers +before the same source URL. (If there are multiple sub-tracks of the same media +type, then the mapping to the real stream is probably rather arbitrary.) If the +source contains tracks not described, a warning is logged when the delayed +opening happens, and the track is hidden. + +This has the following parameters: + +``media_type`` + Required. Must be set to ``video``, ``audio``, or ``sub``. (Other tracks in + the opened URL are ignored.) + +``codec`` + The mpv codec name that is expected. Although mpv tries to initialize a + decoder with it currently (and will fail track selection if it does not + initialize successfully), it is not used for decoding - decoding still uses + the information retrieved from opening the actual media information, and may + be a different codec (you should try to avoid this, of course). Defaults to + ``null``. + + Above also applies for similar fields such as ``w``. These fields are + mostly to help with user track pre-selection. + +``flags`` + A ``+`` separated list of boolean flags. Currently defined flags: + + ``default`` + Set the default track flag. + + ``forced`` + Set the forced track flag. + + Other values are ignored after triggering a warning. + +``w``, ``h`` + For video codecs: expected video size. See ``codec`` for details. + +``fps`` + For video codecs: expected video framerate, as integer. (The rate is usually + only crudely reported, and it makes no sense to expect exact values.) + +``samplerate`` + For audio codecs: expected sample rate, as integer. + +The ``delay_open`` header is not part of the core EDL format. It may be changed +or removed at any time, depending on mpv's internal requirements. + Timestamp format ================ @@ -189,7 +328,8 @@ Currently, time values are floating point values in seconds. As an extension, you can set the ``timestamps=chapters`` option. If this option is set, timestamps have to be integers, and refer to chapter numbers, starting -with 0. +with 0. The default value for this parameter is ``seconds``, which means the +time is as described in the previous paragraph. Example:: @@ -254,6 +394,3 @@ 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`` - -As a quirks, mpv will accept arbitrary paths in EDLs originating from -``edl://``, while ``.edl`` does not. This makes no sense. diff --git a/DOCS/encoding.rst b/DOCS/encoding.rst index 15e38a4581..9c6c067589 100644 --- a/DOCS/encoding.rst +++ b/DOCS/encoding.rst @@ -3,26 +3,26 @@ General usage :: - mpv infile -o outfile [-of outfileformat] [-ofopts formatoptions] [-orawts] \ + mpv infile --o=outfile [--of=outfileformat] [--ofopts=formatoptions] [--orawts] \ [(any other mpv options)] \ - -ovc outvideocodec [-ovcopts outvideocodecoptions] \ - -oac outaudiocodec [-oacopts outaudiocodecoptions] + --ovc=outvideocodec [--ovcopts=outvideocodecoptions] \ + --oac=outaudiocodec [--oacopts=outaudiocodecoptions] Help for these options is provided if giving help as parameter, as in:: - mpv -ovc help + 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 +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 +(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 +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. +--ofps or --oautofps to force CFR encoding in these cases. Of course, the options can be stored in a profile, like this .config/mpv/mpv.conf section:: @@ -30,9 +30,13 @@ section:: [myencprofile] vf-add = scale=480:-2 ovc = libx264 - ovcopts-add = preset=medium,tune=fastdecode + ovcopts-add = preset=medium + ovcopts-add = tune=fastdecode ovcopts-add = crf=23 - ovcopts-add = maxrate=1500k,bufsize=1000k,rc_init_occupancy=900k,refs=2 + ovcopts-add = maxrate=1500k + ovcopts-add = bufsize=1000k + ovcopts-add = rc_init_occupancy=900k + ovcopts-add = refs=2 ovcopts-add = profile=baseline oac = aac oacopts-add = b=96k @@ -44,7 +48,7 @@ to encoding. This is not the case anymore.) One can then encode using this profile using the command:: - mpv infile -o outfile.mp4 -profile myencprofile + mpv infile --o=outfile.mp4 --profile=myencprofile Some example profiles are provided in a file etc/encoding-profiles.conf; as for this, see below. @@ -58, |