summaryrefslogtreecommitdiffstats
path: root/options
Commit message (Collapse)AuthorAgeFilesLines
* Implement backwards playbackwm42019-09-192-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See manpage additions. This is a huge hack. You can bet there are shit tons of bugs. It's literally forcing square pegs into round holes. Hopefully, the manpage wall of text makes it clear enough that the whole shit can easily crash and burn. (Although it shouldn't literally crash. That would be a bug. It possibly _could_ start a fire by entering some sort of endless loop, not a literal one, just something where it tries to do work without making progress.) (Some obvious bugs I simply ignored for this initial version, but there's a number of potential bugs I can't even imagine. Normal playback should remain completely unaffected, though.) How this works is also described in the manpage. Basically, we demux in reverse, then we decode in reverse, then we render in reverse. The decoding part is the simplest: just reorder the decoder output. This weirdly integrates with the timeline/ordered chapter code, which also has special requirements on feeding the packets to the decoder in a non-straightforward way (it doesn't conflict, although a bugmessmass breaks correct slicing of segments, so EDL/ordered chapter playback is broken in backward direction). Backward demuxing is pretty involved. In theory, it could be much easier: simply iterating the usual demuxer output backward. But this just doesn't fit into our code, so there's a cthulhu nightmare of shit. To be specific, each stream (audio, video) is reversed separately. At least this means we can do backward playback within cached content (for example, you could play backwards in a live stream; on that note, it disables prefetching, which would lead to losing new live video, but this could be avoided). The fuckmess also meant that I didn't bother trying to support subtitles. Subtitles are a problem because they're "sparse" streams. They need to be "passively" demuxed: you don't try to read a subtitle packet, you demux audio and video, and then look whether there was a subtitle packet. This means to get subtitles for a time range, you need to know that you demuxed video and audio over this range, which becomes pretty messy when you demux audio and video backwards separately. Backward display is the most weird (and potentially buggy) part. To avoid that we need to touch a LOT of timing code, we negate all timestamps. The basic idea is that due to the navigation, all comparisons and subtractions of timestamps keep working, and you don't need to touch every single of them to "reverse" them. E.g.: bool before = pts_a < pts_b; would need to be: bool before = forward ? pts_a < pts_b : pts_a > pts_b; or: bool before = pts_a * dir < pts_b * dir; or if you, as it's implemented now, just do this after decoding: pts_a *= dir; pts_b *= dir; and then in the normal timing/renderer code: bool before = pts_a < pts_b; Consequently, we don't need many changes in the latter code. But some assumptions inhererently true for forward playback may have been broken anyway. What is mainly needed is fixing places where values are passed between positive and negative "domains". For example, seeking and timestamp user display always uses positive timestamps. The main mess is that it's not obvious which domain a given variable should or does use. Well, in my tests with a single file, it suddenly started to work when I did this. I'm honestly surprised that it did, and that I didn't have to change a single line in the timing code past decoder (just something minor to make external/cached text subtitles display). I committed it immediately while avoiding thinking about it. But there really likely are subtle problems of all sorts. As far as I'm aware, gstreamer also supports backward playback. When I looked at this years ago, I couldn't find a way to actually try this, and I didn't revisit it now. Back then I also read talk slides from the person who implemented it, and I'm not sure if and which ideas I might have taken from it. It's possible that the timestamp reversal is inspired by it, but I didn't check. (I think it claimed that it could avoid large changes by changing a sign?) VapourSynth has some sort of reverse function, which provides a backward view on a video. The function itself is trivial to implement, as VapourSynth aims to provide random access to video by frame numbers (so you just request decreasing frame numbers). From what I remember, it wasn't exactly fluid, but it worked. It's implemented by creating an index, and seeking to the target on demand, and a bunch of caching. mpv could use it, but it would either require using VapourSynth as demuxer and decoder for everything, or replacing the current file every time something is supposed to be played backwards. FFmpeg's libavfilter has reversal filters for audio and video. These require buffering the entire media data of the file, and don't really fit into mpv's architecture. It could be used by playing a libavfilter graph that also demuxes, but that's like VapourSynth but worse.
* player: add --demuxer-cache-wait optionwm42019-09-192-0/+2
|
* DOCS: remove references to --video-stereo-modeNiklas Haas2019-09-141-0/+1
| | | | | | | This option was removed by a5610b2a but the documentation persisted. Also adds an OPT_REMOVED. Closes #6938.
* Remove classic Linux analog TV support, and DVB runtime controlswm42019-09-132-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | Linux analog TV support (via tv://) was excessively complex, and whenever I attempted to use it (cameras or loopback devices), it didn't work well, or would have required some major work to update it. It's very much stuck in the analog past (my favorite are the frequency tables in frequencies.c for analog TV channels which don't exist anymore). Especially cameras and such work fine with libavdevice and better than tv://, for example: mpv av://v4l2:/dev/video0 (adding --profile=low-latency --untimed even makes it mostly realtime) Adding a new input layer that targets such "modern" uses would be acceptable, if anyone is interested in it. The old TV code is just too focused on actual analog TV. DVB is rather obscure, but has an active maintainer, so don't remove it. However, the demux/stream ctrl layer must go, so remove controls for channel switching. Most of these could be reimplemented by using the normal method for option runtime changes.
* Remove optical disc fancification layerswm42019-09-131-35/+0
| | | | | | | | | | | | | | | | | This removes anything related to DVD/BD/CD that negatively affected the core code. It includes trying to rewrite timestamps (since DVDs and Blurays do not set packet stream timestamps to playback time, and can even have resets mid-stream), export of chapters, stream languages, export of title/track lists, and all that. Only basic seeking is supported. It is very much possible that seeking completely fails on some discs (on some parts of the timeline), because timestamp rewriting was removed. Note that I don't give a shit about optical media. If you want to watch them, rip them. Keeping some bare support for DVD/BD is the most I'm going to do to appease the type of lazy, obnoxious users who will care. There are other players which are better at optical discs.
* Remove libdvdread support in favor of libdvdnavwm42019-09-131-2/+2
| | | | | | | | | | | stream_dvd.c contained large amounts of ancient, unmaintained code, which has been historically moved to libdvdnav. Basically, it's full of low level parsing of DVD on-disc structures. Kill it for good. Users can use the remaining dvdnav support (which basically operates in non-menu mode). Users have reported that libdvdread sometimes works better, but this is just libdvdnav's problem and not ours.
* options/path: fix url detection per RFC3986john2019-04-051-3/+7
|
* Merge commit '559a400ac36e75a8d73ba263fd7fa6736df1c2da' into ↵Anton Kindestam2018-12-059-382/+394
|\ | | | | | | | | | | wm4-commits--merge-edition This bumps libmpv version to 1.103
| * demux, stream: rip out the classic stream cachewm42018-08-312-15/+0
| | | | | | | | | | | | The demuxer cache is the only cache now. Might need another change to combat seeking failures in mp4 etc. The only bad thing is the loss of cache-speed, which was sort of nice to have.
| * m_config: remove a redundant conditionwm42018-05-241-3/+1
| | | | | | | | Always true, because a few lines above it checks for the same thing.
| * m_config: fix build with emulated stdatomicwm42018-05-241-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | C11 can access atomic variables normally (in which case they use the strictest memory access semantics). But the mpv stdatomic wrapper for C99 compilers does not allow it, because it couldn't give any guarantees. This means we always need to access them with atomic macros. While we're at, use relaxed semantics for the m_config_cache field, since because it's accessed from a single thread only (essentially used in a non-atomic way). Switch the comparison arguments to make the formatting look slightly less weird.
| * m_config: make m_config_cache_update() return more fine grainedwm42018-05-241-3/+7
| | | | | | | | | | | | | | | | | | Although the new code actually fires update notifications only when needed, m_config_cache_update() itself returned a rather coarse change value, which could indicate change even if none of the cached options were changed. On top of that, some code (like vo_gpu) calls the update function on every frame, which would reconfigure the renderer even on unrelated option changes.
| * player: get rid of mpv_global.optswm42018-05-242-5/+3
| | | | | | | | | | | | | | | | This was always a legacy thing. Remove it by applying an orgy of mp_get_config_group() calls, and sometimes m_config_cache_alloc() or mp_read_option_raw(). win32 changes untested.
| * vd_lavc: move hwdec opts to local config, don't use global MPOptswm42018-05-242-16/+1
| | | | | | | | | | | | | | The --hwdec* options are a good fit for the vd_lavc local option struct. This annoyingly requires manual prefixing of most of these options with --vd-lavc (could be avoided by using more sub-struct craziness, but let's not).
| * path: don't access global option structwm42018-05-242-7/+18
| | | | | | | | | | | | | | The path functions need to access the option that forces non-default config directories. Just add it as a field to mpv_global - it seems justified. The accessed options were always enforced as immutable after init, so there's not much of a change.
| * m_config: add a special define to access main configwm42018-05-241-4/+6
| | | | | | | | | | | | | | | | Passing NULL to mp_get_config_group() returns the main option struct. This is just a dumb hack to deal with inconsistencies caused by legacy things (as I'll claim), and will probably be changed in the future. So before littering the whole code base with hard to find NULL parameters, require using callers an easy to find separate define.
| * ao: use a local option structwm42018-05-242-14/+4
| | | | | | | | Instead of accessing MPOpts.
| * m_config: optimize initialization of each optionwm42018-05-241-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Options with dynamic memory allocations (such as strings) require some care. They need to be fully copied on initialization, and if a static default value was declared, we must not free that value either. Instead of going through the entire thing even for simple types like integers, really run it only for options with dynamic allocations. To distinguish types which use dynamic allocations, we can use the fact that they require a free callback (otherwise they would leak). As a result initialization of simple types becomes chaper, and the init function does nothing at all if src==dst for a simple type. (It's funny how mplayer had M_OPT_TYPE_DYNAMIC since 2002, until we replaced it by the same heuristic as used here in commit 3bb134969eb6. It's also funny how the new check was used only for some asserts, and finally removed in commit 7539928c1c. I guess at this time I felt like having uniform code was more important than pointless micro-optimizations.) The src==NULL case is removed because it can't happen.
| * m_config: remove extra default_data fieldwm42018-05-242-17/+25
| | | | | | | | Just wastes memory (a few KB, because there are so many options).
| * m_config: remove unused fieldswm42018-05-242-8/+2
| |
| * m_config: reduce redundant option change notificationswm42018-05-241-1/+1
| |
| * m_config: remove an old temporary hackwm42018-05-242-308/+336
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Actually rewrite most of the option management code. This affects how options are allocated, and how thread-safe access to them is done. One thing that is nicer is that creating m_config_cache does not need to ridiculously recreate and store the entire option list again. Instead, option metadata and option storage are now separated. m_config contains the metadata, and m_config_data all or parts of the actual option values. (m_config_cache simply uses the metadata part of m_config, which is immutable after creation.) The mentioned hack was introduced in commit 1a2319f3e4cc4, and is the global state around g_group_mutex. Although it was "benign" global state, it's good that it's finally removed.
| * m_config: remove outdated commentwm42018-05-241-1/+0
| |
| * m_config: check for int16_t offset overflowwm42018-05-241-1/+3
| | | | | | | | | | | | | | | | For some reason shadow_offset is a int16_t variable (to save some space or something), which means the static part of the entire option list must be below 32KB. This is fine, but still add a check against overflows. (Currently it's 3.6KB. This does not include dynamic allocations like strings.)
| * m_config: remove an unused functionwm42018-05-242-15/+0
| |
| * m_option: remove an unused fieldwm42018-05-242-13/+0
| |
| * m_config: cosmetics: fix 2 typoswm42018-05-241-2/+2
| |
| * player: make playback termination asynchronouswm42018-05-242-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, stopping playback aborted the demuxer and I/O layer violently by signaling mp_cancel (bound to libavformat's AVIOInterruptCB mechanism). Change it to try closing them gracefully. The main purpose is to silence those libavformat errors that happen when you request termination. Most of libavformat barely cares about the termination mechanism (AVIOInterruptCB), and essentially it's like the network connection is abruptly severed, or file I/O suddenly returns I/O errors. There were issues with dumb TLS warnings, parsers complaining about incomplete data, and some special protocols that require server communication to gracefully disconnect. We still want to abort it forcefully if it refuses to terminate on its own, so a timeout is required. Users can set the timeout to 0, which should give them the old behavior. This also removes the old mechanism that treats certain commands (like "quit") specially, and tries to terminate the demuxers even if the core is currently frozen. This is for situations where the core synchronized to the demuxer or stream layer while network is unresponsive. This in turn can only happen due to the "program" or "cache-size" properties in the current code (see one of the previous commits). Also, the old mechanism doesn't fit particularly well with the new one. We wouldn't want to abort playback immediately on a "quit" command - the new code is all about giving it a chance to end it gracefully. We'd need some sort of watchdog thread or something equally complicated to handle this. So just remove it. The change in osd.c is to prevent that it clears the status line while waiting for termination. The normal status line code doesn't output anything useful at this point, and the code path taken clears it, both of which is an annoying behavior change, so just let it show the old one.
| * command: make loadlist command async and abortablewm42018-05-241-1/+1
| | | | | | | | | | | | | | | | | | | | Don't allow it to freeze everything when loading a playlist from network (although you definitely shouldn't do that, but whatever). This also affects the really obscure --ordered-chapters-files option. The --playlist option on the other hand has no choice but to freeze the shit, because there's no concept of aborting the player during command line parsing.
| * command: add a subprocess commandwm42018-05-241-0/+1
| | | | | | | | | | | | | | This supports named arguments. It benefits from the infrastructure of async commands. The plan is to reimplement Lua's utils.subprocess() on top of it.
* | wscript: split egl-android from androidTom Yan2018-08-201-1/+1
| |
* | options.c: display additional metadata tags during video playbackStephen Hutchinson2018-06-111-2/+3
| | | | | | | | | | | | | | | | The currently-displayed tags make sense for music files, but similar information for video is more commonly - or at least should be - put under other tags, while the audio-related tags are often used for other information on video files (particularly with youtube-dl's output).
* | m_config: remove outdated commentwm42018-05-311-1/+0
| |
* | m_config: check for int16_t offset overflowwm42018-05-311-1/+3
| | | | | | | | | | | | | | | | For some reason shadow_offset is a int16_t variable (to save some space or something), which means the static part of the entire option list must be below 32KB. This is fine, but still add a check against overflows. (Currently it's 3.6KB. This does not include dynamic allocations like strings.)
* | m_config: remove an unused functionwm42018-05-312-15/+0
| |
* | m_option: remove an unused fieldwm42018-05-312-13/+0
| |
* | m_config: cosmetics: fix 2 typoswm42018-05-311-2/+2
|/
* m_option: fix duplicate flag valuePhilip Sequeira2018-05-131-2/+2
|
* build: make encoding mode non-optionalwm42018-05-031-2/+0
| | | | Makes it easier to not break the build by confusing the ifdeffery.
* encode: get rid of AVDictionary setter helperwm42018-04-292-0/+6
| | | | | | | | | | | | Removes a good hunk of weird code. This loses qscale "emulation", some logging, and the fact that duplicate keys for values starting with +/- were added with AV_DICT_APPEND. I don't assign those any importance, even if they are user-visible changes. The new M_OPT_ flag is just so that nothing weird happens for other key-value options, which do not interpret a "help" key specially.
* options: remove broken --video-stereo-mode optionwm42018-04-292-4/+0
| | | | | See changelog for minor explanation. Basically, 3D is unused crap and nobody cares.
* vaapi: add option to select a non-default device pathRostislav Pehlivanov2018-03-302-0/+6
| | | | | | | | | | | On machines with multiple GPUs, /dev/dri/renderD128 isn't guaranteed to point to a valid vaapi device. This just adds the option to specify what path to use. The old fallback /dev/dri/card0 is gone but that's not a loss as its a legacy interface no longer accepted as valid by libva. Fixes #4320
* command: move property multiply code to m_property.cwm42018-03-262-0/+33
| | | | | | | I think this will help with reducing code duplication (see following commit). The error messages loses the multiplication factor, but the error message will be replaced by a generic one in the following commit anyway.
* vo: move display-fps internal option value to VO optswm42018-03-152-3/+2
| | | | | | Removes the awkward notification through VO_EVENT_WIN_STATE. Unfortunately, some awkwardness remains in mp_property_display_fps(), because the property has conflicting semantics with the option.
* video: add an option to tune waiting for video timingwm42018-03-153-0/+7
| | | | Probably mostly useful for the libmpv render API.
* video: add option to reduce latency by 1 or 2 frameswm42018-03-032-0/+2
| | | | | | | | | | | | | | | | | | | | The playback start logic explicitly waits until the first frame has been displayed. Usually this will introduce a wait of 1 vsync. For normal playback this doesn't matter, but with respect to low latency needs, this only leads to additional data getting queued up in the demuxer or network buffers. Another thing is that the timing logic decodes 1 frame ahead (= 1 frame extra latency) to determine the exact duration of a frame. To be fair, there doesn't really seem to be a hard reason why this is needed. With the current code, enabling the option does lead to A/V desync sometimes (if the demuxer FPS is too inaccurate), and also frame drops at playback start in some situations. But this all seems to be avoidable, if the timing logic were to be rewritten completely, which should probably happen in the future. Thus the new option comes with the warning that it can be removed any time. This is also why the option has "hack" in the name.
* m_option: remove unneded compatibility featureswm42018-02-282-9/+2
| | | |