summaryrefslogtreecommitdiffstats
path: root/DOCS
Commit message (Collapse)AuthorAgeFilesLines
* core: redo how codecs are mapped, remove codecs.confwm42013-02-105-256/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use codec names instead of FourCCs to identify codecs. Rewrite how codecs are selected and initialized. Now each decoder exports a list of decoders (and the codec it supports) via add_decoders(). The order matters, and the first decoder for a given decoder is preferred over the other decoders. E.g. all ad_mpg123 decoders are preferred over ad_lavc, because it comes first in the mpcodecs_ad_drivers array. Likewise, decoders within ad_lavc that are enumerated first by libavcodec (using av_codec_next()) are preferred. (This is actually critical to select h264 software decoding by default instead of vdpau. libavcodec and ffmpeg/avconv use the same method to select decoders by default, so we hope this is sane.) The codec names follow libavcodec's codec names as defined by AVCodecDescriptor.name (see libavcodec/codec_desc.c). Some decoders have names different from the canonical codec name. The AVCodecDescriptor API is relatively new, so we need a compatibility layer for older libavcodec versions for codec names that are referenced internally, and which are different from the decoder name. (Add a configure check for that, because checking versions is getting way too messy.) demux/codec_tags.c is generated from the former codecs.conf (minus "special" decoders like vdpau, and excluding the mappings that are the same as the mappings libavformat's exported RIFF tables). It contains all the mappings from FourCCs to codec name. This is needed for demux_mkv, demux_mpg, demux_avi and demux_asf. demux_lavf will set the codec as determined by libavformat, while the other demuxers have to do this on their own, using the mp_set_audio/video_codec_from_tag() functions. Note that the sh_audio/video->format members don't uniquely identify the codec anymore, and sh->codec takes over this role. Replace the --ac/--vc/--afm/--vfm with new --vd/--ad options, which provide cover the functionality of the removed switched. Note: there's no CODECS_FLAG_FLIP flag anymore. This means some obscure container/video combinations (e.g. the sample Film_200_zygo_pro.mov) are played flipped. ffplay/avplay doesn't handle this properly either, so we don't care and blame ffmeg/libav instead.
* options: change --no-config option, make it apply to input.conf as wellwm42013-02-091-11/+9
| | | | | | | | | | | | | Simplify --no-config and make it a normal flag option, and doesn't take an argument anymore. You can get the same behavior by using --no-config and then --include to explicitly load a certain config file. Make --no-config work for input.conf as well. Make it so that --input:conf=file still works in this case. As a technically unrelated change, the file argument now works as one would expect, instead of making it relatively to "~/.mpv/". This makes for simpler code and easier to understand option semantics. We can also print better error messages.
* options: unify single dash and double dash optionswm42013-02-091-23/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There were two option syntax variations: "old": -opt value "new": --opt=value "-opt=value" was invalid, and "--opt value" meant "--opt=" followed by a separate option "value" (i.e. interpreted as filename). There isn't really any reason to do this. The "old" syntax used to be ambiguous (you had to call the option parser to know whether the following argument is an option value or a new option), but that has been removed. Further, using "=" in the option string is always unambiguous. Since the distinction between the two option variants is confusing, just remove the difference and allow "--opt value" and "-opt=value". To make this easier, do some other cleanups as well (e.g. avoid having to do a manual lookup of the option just to check for M_OPT_PRE_PARSE, which somehow ended up with finally getting rid of the m_config.mode member). Error reporting is still a mess, and we opt for reporting too many rather than too few errors to the user. There shouldn't be many user-visible changes. The --framedrop and --term-osd options now always require parameters. The --mute option is intentionally made ambiguous: it works like a flag option, but a value can be passed to it explicitly ("--mute=auto"). If the interpretation of the option is ambiguous (like "--mute auto"), the second string is interpreted as separate option or filename. (Normal flag options are actually ambiguous in this way too.)
* Remove BSD legacy TV/radio support (BT848 stuff)wm42013-02-061-13/+3
| | | | | FreeBSD actually supports V4L2, and V4L2 supports this chip. Also, this chip is from 1997. Farewell.
* core: remove --edlout functionalitywm42013-02-062-10/+1
| | | | | | | | | | | | | | | | This could write .edl files in MPlayer's format. Support for playing these files has been removed from mplayer2 quite a while ago. (mplayer2 can play its own, "new" .edl format, but does not support writing it.) Since this is a rather obscure functionality, and it's not really clear how it should behave (e.g. what should it do if a new file is played), and wasn't all that great to begin with (what if you made a mistake? the "edl_mark" command sucks for editing), get rid of it. Suggestions how to reimplement this in a nicer way are welcome. If it's just about retrieving timecodes, this in input.conf will do: KEY print_text "position: ${=time-pos}"
* manpage: document option syntax variations betterwm42013-02-032-4/+29
|
* DOCS: remove files documenting removed/rewritten functionalitywm42013-02-0312-3267/+0
| | | | | | | Most of these are a waste of time. Some (like slave.txt) have been rewritten in rst. The remaining files aren't that useful, but probably do no harm.
* DOCS: update encoding profiles installation instructionsStefano Pigozzi2013-02-011-2/+4
| | | | | | Simply removed the assumption that the user is using `mpv-build`. Now provide 3 lines of shell that can be copy-pasted by the user for instant gratification (and independent from $PWD).
* manpage: fixeswm42013-01-312-3/+11
| | | | | | | Add missing documentation for --quvi-format switch. Fix description how hw decoding is enabled. The old way currently still works, but is deprecated.
* screenshot: minor simplification, prefer VF over VOwm42013-01-303-17/+10
| | | | | | | | | | | | | Remove screenshot_force and associated logic. Always try to use the screenshot video filter before trying taking screenshots with the VO, which means that --vf=screenshot now takes the role of --vf=screenshot_force. (To make this clear, not adding a video filter is still the recommended way to take screenshots; we just change how VF screenshots are forced.) Preferring VO over VF and having --vf=screenshot_force used to make sense when not all VOs supported screenshots, and some VOs had somewhat broken screenshots (like vo_xv taking screenshots with OSD in it). But all these issues are fixed now, so just get rid of the cruft.
* vo_opengl: always ditherWessel Dankers2013-01-271-5/+0
| | | | | | | | | | | | Dithering was disabled if the input bit depth was not larger than the output bit depth of the screen framebuffer. But since scaling, RGB conversion, and other filters change the number of significant bits anyway, dithering could still benefit image quality even in these cases. Always do dithering, unless dithering is completely disabled. The original intention of this mechanism was not to change the image needlessly when playing video that matches the native bit depth of the screen.
* stream: implement some HTTP specific options for stream_lavfwm42013-01-241-10/+0
| | | | | | | | | | | | | | | | | | The "http:" protocol has been switched to use ffmpeg's HTTP implementation some time ago. One problem with this was that many HTTP specific options stopped working, because they were obviously implemented for the internal HTTP implementation only. Add the missing things. Note that many options will work for ffmpeg only, as Libav's HTTP implementation is missing these. They will silently be ignored on Libav. Some options we can't fix: --ipv4-only-proxy, --prefer-ipv4, --prefer-ipv6 As far as I can see, not even libavformat internals distinguish between ipv4 and ipv6. --user, --passwd ffmpeg probably supports specifying these in the URL directly.
* video: remove -x/-y/-xy optionswm42013-01-232-14/+2
| | | | | | | | | | | | | | | -x/-y were rather useless and obscure. The only use I can see is forcing a specific aspect ratio without having to calculate the aspect ratio float value (although --aspect takes values of the form w:h). This can be also done with --geometry and --no-keepaspect. There was also a comment that -x/-y is useful for -vm, although I don't see how this is useful as it still messes up aspect ratio. -xy is mostly obsolete. It does two things: a) set the window width to a pixel value, b) scale the window size by a factor. a) is already done by --autofit (--autofit=num does exactly the same thing as --xy=num, if num >= 8). b) is not all that useful, so we just drop that functionality.
* video: add --autofit and --autofit-larger optionswm42013-01-231-0/+48
| | | | | | | | | --autofit=WxH sets the window size to a maximum width and/or height, without changing the window's aspect ratio. --autofit-larger=WxH does the same, but only if the video size is actually larger than the window size that would result when using the --autofit=WxH option with the same arguments.
* options: allow using % for width and height in --geometrywm42013-01-231-13/+23
| | | | | | | | | | | | | | | | | | | | Now all numbers in the --geometry specification can take percentages. Rewrite the parsing of --geometry, because adjusting the sscanf() mess would require adding all the combinations of using and not using %. As a side effect, using % and pixel values can be freely mixed. Keep the aspect if only one of width or height is set. This is more useful in general. Note: there is one semantic change: --geometry=num used to mean setting the window X position, but now it means setting the window width. Apparently this was a mplayer-specific feature (not part of standard X geometry specifications), and it doesn't look like an overly useful feature, so we are fine with breaking it. In general, the new parsing should still adhere to standard X geometry specification (as used by XParseGeometry()).
* manpage: fix places that still treat FourCCs and pixel formats equalwm42013-01-172-13/+12
| | | | | | | | | | | | | | | The video filter chain traditionally used FourCCs for pixel formats. This was recently changed, but some parts of the manpage were not updated properly. Now there are two rypes of options: some which take a FourCC (as used with raw video formats), and some which take a symbolic format identifier (as used in the video filter chain). I realize that it's harder to specify FourCC for RGB formats now (TV stuff may need RGB). They use non-printable characters as part of the FourCC, and have to be specified as hexadecimal numbers (instead of a symbolic identifier). Because I can't be bothered to find out what these numbers are for the respective formats, just remove the old pseudo-FourCCs from the documentation.
* vd_lavc: remove -lavdopts vstats suboptionwm42013-01-131-2/+0
| | | | | | This printed per-frame statistics into a file, like bitrate or frame type. Not very useful and accesses obscure AVCodecContext fields (danger of deprecation/breakage), so get rid of it.
* vd_lavc: remove lowres decodingwm42013-01-131-13/+0
| | | | | | | | | | This was a "broken misfeature" according to Libav developers. It wasn't implemented for modern codecs (like h264), and has been removed from Libav a while ago (the AVCodecContext field has been marked as deprecated and its value is ignored). FFmpeg still supports it, but isn't much useful due to aforementioned reasons. Remove the code to enable it.
* sub: add experimental --force-rgba-osd-rendering switchwm42013-01-131-0/+8
|
* vo_direct3d: remove 2ch hack for 10 bit playbackwm42013-01-131-9/+0
| | | | | | | | | | | This was an awkward hack that attempted to avoid the use of 16 bit textures, while still allowing rendering 10-16 bit YUV formats. The idea was that even if the hardware doesn't support 16 bit textures, an A8L8 textures could be used to convert 10 bit (etc.) to 8 bit in the shader, instead of doing this on the CPU. This was an experiment, disabled by default, and was (probably) rarely used. I've never heard of this being used successfully. Remove it.
* video: decouple internal pixel formats from FourCCswm42013-01-131-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mplayer's video chain traditionally used FourCCs for pixel formats. For example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the string 'YV12' interpreted as unsigned int. Additionally, it used to encode information into the numeric values of some formats. The RGB formats had their bit depth and endian encoded into the least significant byte. Extended planar formats (420P10 etc.) had chroma shift, endian, and component bit depth encoded. (This has been removed in recent commits.) Replace the FourCC mess with a simple enum. Remove all the redundant formats like YV12/I420/IYUV. Replace some image format names by something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P. Add img_fourcc.h, which contains the old IDs for code that actually uses FourCCs. Change the way demuxers, that output raw video, identify the video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to request the rawvideo decoder, and sh_video->imgfmt specifies the pixel format. Like the previous hack, this is supposed to avoid the need for a complete codecs.cfg entry per format, or other lookup tables. (Note that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT raw video, but this is still considered better than adding a raw video decoder - even if trivial, it would be full of annoying lookup tables.) The TV code has not been tested. Some corrective changes regarding endian and other image format flags creep in.
* video: different way to enable hardware decoding, add software fallbackwm42013-01-132-0/+13
| | | | | | | | | | | | | | Deprecate the hardware specific video codec entries (like ffh264vdpau). Replace them with the --hwdec switch, which requests that a specific hardware decoding API should be used. The codecs.conf entries will be removed at a later time, but for now they are useful for testing and compatibility. Instead of --vc=ffh264vdpau, --hwdec=vdpau should be used. Add a fallback if hardware decoding fails. Most hardware decoders (including vdpau) support only a subset of h264, and having such a fallback is supposed to enable a better user experience.
* video: remove slice based filtering and video outputwm42013-01-131-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Slices allowed filtering or drawing video in horizontal bands or blocks. This allowed working on the video in smaller units. In theory, this could bring a performance win by lowering cache pressure, as you didn't have to keep the whole video frame in cache while filtering, only the slice. In practice, the slice code path was barely used for the following reasons: - Multithreaded decoding with ffmpeg didn't use slices. The ffmpeg slice callback was disabled, because it can be called from another thread, and the mplayer video chain is not thread-safe. - There was nothing that would turn "full" images into appropriate slices, so slices were rarely used. - Most filters didn't actually support slices. On the other hand, supporting slices lead to code duplication and more complex code in general. I made some experiments and didn't find any actual measurable performance improvements when using slices. Even ffmpeg removed slices based filtering from libavfilter in favor of simpler code. The most broken thing about the slices code path is that slices can't be queued, like it is done for images in vo.c.
* vo_sdl: add a "sw" flag like in openglRudolf Polzer2013-01-101-0/+3
| | | | | | Also, rework the renderer creation for the flag being generally effective even if the "SW renderer" is detected only after creating a context.
* mplayer: make --loop loop the playlist instead of each playlist entrywm42013-01-091-1/+2
| | | | | | | | | | This is simpler and more useful. We could add a new switch for the old functionality, but that would probably be more confusing than helpful. When passing only a single file to the command line, this commit shouldn't change behavior. (Classic mplayer provided both features by duplicating the loop functionality in the "playtree".)
* DOCS: add some basic MinGW cross compilation instructionswm42013-01-081-0/+59
|
* manpage: document the dangers of some subtitle optionswm42013-01-051-7/+20
| | | | | | | | | | | | | Setting some subtitle options may lead to incorrect rendering of complex ASS subtitle scripts, such as displaced signs or visual artifacts. The user should be made aware that this can happen. In theory, libass could make using some of these options relatively safe, but it doesn't. Note that there are potentially much more options that could in theory break subtitle rendering, but add a warning only to the most fragile ones.
* sub: add --sub-text-* options to unstyled text subtitles fontwm42013-01-052-31/+34
| | | | | | | Before this commit, the --osd-* options (like --osd-font-size etc.) configured both the OSD and subtitle font. Make them separate, and add --sub-text-* options (like --sub-text-size etc.). Now --osd-* affects the OSD font only, and --sub-text-* unstyled text subtitles only.
* manpage: sort --osd-* optionswm42013-01-041-36/+36
| | | | | | They were more or less grouped by usefulness, but since everything else in the manpage is sorted alphabetically, it's better to be consistent and sort these options as well.
* manpage: minor improvementswm42012-12-281-9/+14
|
* DOCS: document EDL formatwm42012-12-281-0/+139
| | | | | This is taken from the commit message of 968154ba77f8, with some fixes to make it valid RST.
* vo_opengl: use more precise gamma for BT.709 with color managementnand2012-12-281-2/+2
| | | | | | | | | | Change from gamma 2.2 to the slightly more precise 1/0.45 as per BT.709. https://www.itu.int/rec/R-REC-BT.709-5-200204-I/en mentions a value of γ=0.45 for the conceptual non-linear precorrection of video signals. This is approximately the inverse of 2.22, and not 2.20 as the code had been using until now.
* vo/ao: SDL 1.2+ audio driver, SDL 2.0+ accelerated video driverRudolf Polzer2012-12-282-0/+20
| | | | | | | | | | | This mainly serves as a fallback for platforms where nothing better is available; also as a debugging help. Both the audio and video driver are not first class - the audio driver lacks delay detection, and the video driver only supports a single YUV color space. Configure options: --disable-sdl2 to disable SDL 2.0+ detection, --disable-sdl to disable SDL 1.2+ detection. Both options need to be specified to turn off SDL support entirely.
* options: move -ass-bottom-margin/-ass-top-margin options to vf_subwm42012-12-123-9/+10
| | | | | These options might be useful sometimes, but they are not that important, and work with vf_sub only. Make them vf_sub sub-options.
* manpage: mark HTTP related options as deprecated/brokenwm42012-12-112-1/+21
| | | | | | | | | | Commit c02f25 switched the "http://" protocol to use ffmpeg's HTTP implementation (stream_lavf.c), instead of the mplayer internal one (http.c). Unfortunately, it turns out that there are some network related options that are not respected by stream_lavf.c, and consequently do not work anymore for "http://" URLs. This might be fixed later. Mark them as deprecated for now, as it might take arbitrarily long until this is taken care of.
* core: allow disabling display of "album art" in audio fileswm42012-12-111-0/+10
| | | | | | | | | | | | | | | | | | ffmpeg pretends that image attachments (such as contained in ID3v2 metadata) are video streams. It injects the attached pictures as packets into the packet stream received with av_read_frame(). Add the --audio-display option to allow configuring whether attached pictures should be displayed. The default behavior doesn't change (images are displayed). Identify video streams, that are actually image attachments, with "[P]" in the terminal output. Modify the default stream selection such that real video streams are preferred over attached pictures. (This is just for robustness; I do not know of any samples where images are added before actual video streams and could lead to bad default stream selection with the old code.)
* audio: remove support for native alaw/mulaw/adpcm outputwm42012-12-111-1/+1
| | | | | | This is considered a worthless feature. Note that alaw/mulaw/adpcm input is unaffected: such data is handed to libavcodec and "decoded" to linear PCM.
* demux_lavf: make minimum probe score customizable, remove lavf_preferredwm42012-12-111-0/+6
| | | | | | | | | | | | | | | | | | | | | libavformat wants to read a full ~400KB of data to determine whether it's really AAC. This causes slow startup with AAC web radio streams [1] (possible due to a broken initial packet). There are similar issues with other file formats. Make the probe "score" (libavformat's mechanism for testing file formats) configurable with the -lavfdtops:probescore option. This allows lowering the amount of data read on probing. If the probe score is below the probescore option value, demux_lavf will try to get a higher score by feeding more data to libavformat, until the required score or the max. probe size is reached. Remove the lavf_preferred demuxer entry. This had a purpose in mplayer-svn, but now there doesn't seem to be any good reason for it to exist. Make sure that our native "good" demuxers are above demux_lavf in demuxer_list[] instead (so that they are preferred). [1] http://lr2mp0.latvijasradio.lv:8000
* sub: remove vobsub reader in favor of ffmpeg vobsub demuxerwm42012-12-112-13/+7
| | | | | | | | ffmpeg recently added a demuxer that can read vobsubs (pairs of .sub and .idx files). Get rid of the internal vobsub reader, and use the ffmpeg demuxer instead. Sneak in an unrelated manpage change (autosub default).
* subs: remove --utf8, simplify codeUoti Urpala2012-12-031-4/+0
| | | | | | | | | | | | | | | | | | | Remove the options --utf8 and --unicode which had no effect any more (what they once did should be doable with --subcp). The only use of corresponding variables left in code was subreader.c code using sub_utf8 as a flag indicating whether iconv conversion was active. Change the code to test the existence of iconv context instead. Conflicts: DOCS/man/en/options.rst core/cfg-mplayer.h sub/sub.c sub/sub.h sub/subreader.c Merged from mplayer2 commit ea7311. Note: --unicode was already removed
* core: automatically pause on low cachewm42012-12-031-1/+10
| | | | | | | | | | | | | | | When the cache fill status goes below a certain threshold, automatically pause the player. When the cache is filled again, unpause again. This is intended to help with streaming from http. It's better to pause a while, rather than exposing extremely crappy behavior when packet reads during decoding block the entire player. In theory, we should try to increase the cache if underruns happen too often. Unfortunately, changing the cache implementation would be very hard, because it's insane code (forks, uses shared memory and "volatile" etc.). So for now, this just reduces the frequency of the stuttering if the network is absolutely too slow to play the stream in realtime.
* demux_lavf: add support for libavdevicewm42012-12-031-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | libavdevice supports various "special" video and audio inputs, such as screen-capture or libavfilter filter graphs. libavdevice inputs are implemented as demuxers. They don't use the custom stream callbacks (in AVFormatContext.pb). Instead, input parameters are passed as filename. This means the mpv stream layer has to be disabled. Do this by adding the pseudo stream handler avdevice://, whose only purpose is passing the filename to demux_lavf, without actually doing anything. Change the logic how the filename is passed to libavformat. Remove handling of the filename from demux_open_lavf() and move it to lavf_check_file(). (This also fixes a possible bug when skipping the "lavf://" prefix.) libavdevice now can be invoked by specifying demuxer and args as in: mpv avdevice://demuxer:args The args are passed as filename to libavformat. When using libavdevice demuxers, their actual meaning is highly implementation specific. They don't refer to actual filenames. Note: libavdevice is disabled by default. There is one problem: libavdevice pulls in libavfilter, which in turn causes symbol clashes with mpv internals. The problem is that libavfilter includes a mplayer filter bridge, which is used to interface with a set of nearly unmodified mplayer filters copied into libavfilter. This filter bridge uses the same symbol names as mplayer/mpv's filter chain, which results in symbol clashes at link-time. This can be prevented by building ffmpeg with --disable-filter=mp, but unfortunately this is not the default. This means linking to libavdevice (which in turn forces linking with libavfilter by default) must be disabled. We try doing this by compiling a test file that defines one of the clashing symbols (vf_mpi_clear). To enable libavdevice input, ffmpeg should be built with the options: --disable-filter=mp and mpv with: --enable-libavdevice Originally, I tried to auto-detect it. But the resulting complications in configure did't seem worth the trouble.
*