summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* options: rename --video-aspect to --video-aspect-overrideNiklas Haas2019-10-046-22/+45
| | | | | | | | | | | | The justification for this is the fact that the `video-aspect` property doesn't work well with `cycle_values` commands that include the value "-1". The "video-aspect" property has effectively no change in behavior, but we may want to make it read-only in the future. I think it's probably fine to leave as-is, though. Fixes #6068.
* player: "subprocess" command should stop immediately in idle modewm42019-10-042-3/+15
| | | | | | | | | | | | The description of the "playback_only" field in the "subprocess" command says "you can't start it outside of playback". This did not work correctly: if the player was started in idle mode in the first place, the subprocess was allowed to run even with playback_only=yes. This is a bug, and this change fixes it. Add a test for this to command-test.lua. For #7025.
* manpage: clarify some details about async. commands and "subprocess"wm42019-10-043-4/+38
| | | | | | | | | There's potential confusion about how long a process started with the "subprocess" command is allowed to live. Add some more explanations regarding "subprocess" specifics (such as the playback_only field), and things that apply to asynchronous commands in general. Partially for #7025.
* wayland opengl: actually call uninit if init failsdudemanguy2019-10-031-1/+3
| | | | | | | | This is the proper fix to the memory leak @wm4 pointed out. It turns out that when you autoprobe opengl and vo_wayland_init returns false, vo_wayland_uninit is never actually executed. So you have a leftover pointer. The vulkan context does this correctly which was why my old, dumb "fix" broke it.
* Revert "wayland: free wayland_state on a false return"dudemanguy2019-10-031-11/+3
| | | | | | | | Dumb idea. The correct thing to do is to fix the preinit and context creation so that the uninit is correctly executed when probing fails (and then everything gets freed). This reverts commit defc8f359c5e4bb666e8ad1d4a097a8ac66cc1e2.
* wayland: free wayland_state on a false returnDudemanguy9112019-10-021-3/+11
| | | | | | wm4 mentioned that the wayland autoprobe leaked. A simple oversight in the wayland_common code forgot to free the vo_wayland_state if vo_wayland_init returned false.
* vf_fingerprint: fix an obvious memory leakwm42019-10-031-4/+12
| | | | | | Leaks the entire zimg state on filter deinit. Not sure what I was thinking; with some luck, I just didn't give a shit about this case, but most likely I was thinking the same thing as always: nothing.
* vf_vapoursynth: fix crashing memory management mistakewm42019-10-031-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As pointed out by @olifre in #7016, this line of code was wrong. p->opts at this point is a struct allocated and managed by m_config. opts->file is a string, and m_config explicitly frees it on destruction. The line of code in question replaced the opts->file value, and made both the old and new value children of the talloc allocation, so they were _also_ freed on destruction. This crashed due to a double-free. First, talloc auto-freeing freed the string, then m_config explicitly called talloc_free() on the stale pointer again. As @v-fox pointed out, commit 36dd2348a1e1 seems to have triggered the crash. I suspect this code merely worked out of coincidence, since it allowed m_config to free the value first. This removed it from the auto-free list, and thus did not result in a double-free. The change in order of calling alloc destructors changed the order of these calls. There is no strong reason why new behavior (as introduced by commit 36dd2348a1e1) would be wrong (it feels like cleaner behavior). On the other hand, what the vf_vapoursynth code did is clearly unclean and going by the m_config API, you're not at all supposed to do this. m_config manages all memroy referenced by option structs, the end. @olifre's suggested fix also would have been correct (not just hiding the issue), I prefer my fix, as it doesn't mess with the option struct in tricky ways. This wouldn't have happened if mpv were written in Haskell.
* vf_vapoursynth: do not call vsscript_finalize() if init failedwm42019-10-031-1/+5
| | | | | If vsscript_finalize() is not matched by a successful vsscript_init(), an assert in the vsscript library triggers. Makes sense, I guess.
* vf_vapoursynth: remove some Lua backend remainswm42019-10-031-6/+0
| | | | Pretty funny.
* wayland: always create wl_output before renderingDudemanguy9112019-10-021-7/+6
| | | | | | | | | | | I previously skipped creating the wl_output if the --fullscreen flag with no --fsscreen_id was inputted, so the fullscreen video lands on the correct output (where mpv was launched). This has breakage if someone combines the --autofit flag (or other similar options with it). Instead, just actually read xdg_shell spec and realize that you can pass NULL to xdg_toplevel_set_fullscreen and let the compositor choose the output if the user doesn't specify it. If this has issues, get a better compositor.
* demux: restore some of the DVD/BD/CDDA interaction layerswm42019-10-039-32/+751
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This partially reverts commit a9d83eac40c94f44d19fab7b6955331f10efe301 ("Remove optical disc fancification layers"). Mostly due to the timestamp crap, this was never really going to work. The playback layer is sensitive to timestamps, and derives the playback time directly from the low level packet timestamps. DVD/BD works differently, and libdvdnav/libbluray do not make it easy at all to compensate for this. Which is why it never worked well, but not doing it at all is even more awful. demux_disc.c tried this and rewrote packet timestamps from low level TS to playback time. So restore demux_disc.c, which should bring behavior back to the old often non-working but slightly better state. I did not revert anything that affects components above the demuxer layer. For example, the properties for switching DVD angles or listing disc titles are still gone. (Disc titles could be reimplemented as editions. But not by me.) This commit modifies the reverted code a bit; this can't be avoided, because the internal API changed quite a bit. The old seek resync in demux_lavf.c (which was a hack) is replaced with a hack. SEEK_FORCE and demux_params.external_stream are new additions. Some of this could/should be further cleaned up. If you don't want "proper" DVD/BD support to disappear, you should probably volunteer. Now why am I wasting my time for this? Just because some idiot users are too lazy to rip their ever-wearing out shitty physical discs? Then why should I not be lazy and drop support completely? They won't even be thankful for me maintaining this horrible garbage for no compensation.
* f_auto_filters: use f_autoconvert for hw downloadwm42019-10-021-23/+22
| | | | | | | | Instead of using custom code. Now if only f_lavfi knew what formats FFmpeg's vf_yadif accepts, this could look much nicer, and wouldn't require the additional converter filter setup.
* f_autoconvert: provide a function to determine if conversion workswm42019-10-022-41/+75
| | | | | | This adds the function as seen in the f_autoconvert.h part of the patch. It's pretty simple, but goes along with an intrusive code move. I guess the resulting code is slightly nicer anyway.
* f_autoconvert: add hw->sw download pathwm42019-10-022-18/+71
| | | | | For some reason it could do sw->sw and sw->hw (and, in some ways, even do hw->hw in special cases), but not hw->sw. Add this.
* f_auto_filters: use software conversion if hw deint is not possiblewm42019-10-021-7/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | Before this commit, enabling hardware deinterlacing via the "deinterlace" option/property just failed if no hardware deinterlacing was available. An error message was logged, and playback continued without deinterlacing. Change this, and try to copy the hardware surface to memory, and then use yadif. This will have approximately the same effect as --hwdec=auto-copy. Technically it's implemented differently, because changing the hwdec mode is much more convoluted than just inserting a filter for performing the "download". But the low level code for actually performing the download is the same again. Although performance won't be as good as with a hardware deinterlacer (probably), it's more convenient than forcing the user to switch hwdec modes separately. The "deinterlace" property is supposed to be a convenience thing after all. As far as the code architecture goes, it would make sense to auto-insert such a download filter for all software-only filters that need it. However, libavfilter does not tell us what formats a filter supports (isn't that fucking crazy?), so all attempts to work towards this are kind of hopeless. In this case, we merely have hardcoded knowledge that vf_yadif definitely does not support hardware formats. But yes, this sucks ass.
* f_hwtransfer: add a mp_hwdownload filterwm42019-10-022-0/+62
| | | | | | | | | This just wraps the mp_image_hw_download() function as a filter and adds some minor caching/error logging. (Shame that it needs to much boilerplate, I guess.) Will be used by the following commit. Wrapping it as filter seemed more convenient than other choices.
* filters: add another dumb helperwm42019-10-022-0/+22
| | | | | | | Can be used with mp_chain_filters() to combine multiple filters into a single one. This is a bit silly, but whatever. I'm making it an explicit separate filter, because it lets the user access mp_filter.ppins against all conventions.
* mp_image_pool: expose a function for reporting hw download formatwm42019-10-022-11/+22
| | | | | | | | Basically predicts what mp_image_hw_download() will do. It's pretty simple if it gets the full mp_image. (Taking just a imgfmt would make this pretty hard/impossible or inaccurate.) Used in one of the following commits.
* video: remove vf_vavpp from automatic deinterlace propertywm42019-10-022-12/+0
| | | | | | | | | | | | | | This reverts commit 6385a5fd1b8a67c051b82d48c993a6591e8f93c6, and in addition removes the code that automatically inserts the vavpp filter. The reason is the same as the commit that is being reverted: this filter seems to trigger driver bugs. It can cause GPU freezes or just doesn't work. This variant of disabling the filter is better. There was no way to add the "force" parameter to the automatically inserted filter, so the old approach just made manual filter insertion (with the --vf option or "vf" command) more cumbersome.
* DOCS/tech-overview.txt: caching has changedwm42019-10-021-3/+4
|
* README.md: minor cleanupswm42019-10-021-40/+3
| | | | | | | | | I don't think MPlayer/mplayer2 and Libav are well-known enough anymore to warrant such a prominent place in the top-level README file of this project. It's just useless noise to most users. So I've moved these things to the FAQ. Update some other minor things.
* README.md: remove dead homebrew-mpv linkVítor Galvão2019-10-021-1/+0
|
* autoload.lua: Configurable autoload typesMarek Sebera2019-10-021-4/+42
| | | | | | | | | | | Autoload script now suppports loading of not only video, but also image and audio files, in a manner, where one can configure which of the groups (audio, videos, images) is currently enabled. Use file script-opts/autoload.conf with key=value configuration keys disabled,images,videos,audio to configure autoload script. See documentation on top of the script
* DOCS: Document DVB changes in interface-changes.Oliver Freyermuth2019-10-021-0/+9
|
* stream_dvb: Remove now replaced stream-control code for good.Oliver Freyermuth2019-10-022-85/+0
|
* DOCS: Add documentation for dvbin-prog and dvbin-channel-switch-offset.Oliver Freyermuth2019-10-021-0/+16
|
* stream_dvb: Allow actual zapping of channels again.Oliver Freyermuth2019-10-023-0/+9
| | | | | | | | | | | | | | | This is realized by dvbin-channel-switch-offset, which is a numeric offset on the channel initially tuned to. Since the channel list is kept in the stream alone depending on detected hardware and chosen card, and no available backchannel to the player, there's no direct property which could be switched. Using input.conf like: H cycle dvbin-channel-switch-offset up K cycle dvbin-channel-switch-offset down Q set dvbin-prog "ZDF HD" allow fast and reliable channel switching again.
* player: Add mp_property_dvb_channel helper.Oliver Freyermuth2019-10-021-0/+17
| | | | | | | Reinitializes the player as is needed when tuning to a new DVB channel. Currently triggered when dvbin-prog is written to, i.e. when the user explicity switches to a channel by name.
* stream_dvb: Add dvb_update_config to poll config parameters.Oliver Freyermuth2019-10-022-0/+33
| | | | | | | | If any parameters have been updated, reinitiate streaming_start. Throttle checks since we poll from streaming_read. This also requires the player to re-initialize, since all video and audio streams and even the transport format may change. This is added in the next commit.
* stream_dvb: Move stream->is_on initialization to state preparation.Oliver Freyermuth2019-10-022-2/+1
| | | | | | Notably, this allows to call dvb_streaming_start more than once, simplifying e.g. channel switching. Also, get rid of unused timeout variable.
* stream_dvb: Factor out logic to determine program and card.Oliver Freyermuth2019-10-022-47/+75
| | | | | | | | This is now treated in dvb_parse_path consistently instead of logic scattered over various functions. This is a requirement to sensibly re-evaluate config after options have been changed, since we have two ways to configure the stream (decorated URI and config parameters).
* stream_dvb: Use separated out options struct.Oliver Freyermuth2019-10-022-27/+33
| | | | | This also allows the use of m_config_cache_alloc which allows to watch config updates.
* demux_lavf: remove recently added author name from license headerwm42019-10-011-1/+0
| | | | | | | | | | | | | | | | | This was added in 585f9ff42f3195c by @bbarenblat (github handle). We don't do this. This file alone probably has multiple dozen of authors (I didn't count, but it has a history of 15 years). If everyone added their names with each small change, this project would have giant lists of contributing authors on every source file. Neither copyright law nor any of the used licenses require listing authors in the license header. Authorship is recorded in the git log. So don't start with this, and remove this recent case to avoid setting a precedent. Some files still have an author in the header. These cases are grandfathered, and usually are the actual authors of the original code.
* DOCS/contribute.md: split into sections, random changeswm42019-10-011-17/+61
| | | | | | | | Still trying to get people to read it. Even though I wanted to make it less of a wall of text and more readable, it got bigger. Oops. While I'm at it, violate my own rules and mix these mostly cosmetic changes with some actual rule changes and clarifications.
* github: try to get contributors to read contribute.mdwm42019-10-011-5/+4
| | | | | | | | | | | | | | | | | How hard can it be? I know contribute.md is a shitty wall of text, but that doesn't make it less important, and each violation will make it take longer by adding another review round anyway. And we really don't need lazy pull requests. If you can't be assed to follow a few simple rules, your code is probably shit or you wanted to be quick and lazy. Why should we accept it? We're the ones who have to maintain it and fix bugs in it, and if the contributor is lazy, the chance of you maintaining it is probably slim as well. On the other hand, WE the maintainers are not obligated to anything. Don't say that though, the first contact doesn't need to be negative. I don't know if the "lazy pull requests" is still too strong, but I can't tell.
* demux_mkv: better behavior/warnings on partial files/unseekable streamswm42019-10-011-5/+8
| | | | | | | | | | | | | | demux_mkv may seek to the end of the file to read certain headers (which should probably be called "footers", but in theory they are just headers that have been placed at the end of the file unfortunately). This commit changes behavior not to seek if the stream is not marked as seekable. Before this, it only checked whether the stream size was unknown (end negative). In practice it doesn't make much of a difference, since seekable usually equals known stream size. Also improve the wording, and distinguish between actual incomplete files, and unseekable ones.
* vo_gpu/d3d11: add adapter name validation and listing with "help"Jan Ekström2019-09-294-9/+75
| | | | Not the prettiest way to get it done, but seems to work.
* vo_gpu/d3d11: refactor pthread_once d3d11 loading to functionJan Ekström2019-09-291-6/+15
| | | | Lets us reuse this in the future.
* vo_gpu/d3d11: utilize the passed adapter nameJan Ekström2019-09-291-5/+77
| | | | | | Normalize nullptr and an empty string both to nullptr to simplify handling. API users cannot set a value back to nullptr, so both an empty string as well as nullptr should behave the same.
* vo_gpu/d3d11: add an option for the adapter nameJan Ekström2019-09-292-0/+6
| | | | Set it from the adapter name in the d3d11 options.
* video/d3d11: add adapter selection by name into d3d11 optionsJan Ekström2019-09-293-0/+15
| | | | | This lets the user define an adapter name that can then be passed further into the internals.
* vo_gpu/d3d11_helpers: also load up CreateDXGIFactory1Jan Ekström2019-09-291-4/+13
| | | | Just a factory, without a device, is required for listing of devices.
* stream_lavf: add support for gopherLeonardo Taccari2019-09-291-1/+1
|
* vo_drm: fix flickering when setting pan/scanAnton Kindestam2019-09-291-4/+0
| | | | | | | | Turns out clearing all frambuffers in reconfig isn't such a great idea when you also end up here when setting pan/scan. I guess this is just a leftover from a previous iteration of vo_drm where doing this made sense.
* demux: make --record-file/cache dump command work with disabled streamswm42019-09-291-5/+18
| | | | | | | | | | | | | | | | This passed all streams to mp_recorder_create(), even disabled ones. The disabled streams never get packets, so recorder.c eventually errors out with unrelated-looking errors. The reason is that recorder.c waits for packets to appear on other streams, which in turn is because libavformat refuses to mux empty streams anyway. recorder.c could call demux_stream_is_selected(), which would have made the patch much smaller. But this feels like a bad idea, since recorder.c should use sh_stream only for metadata (and not in an "active" way), nor should it care what demux.c is currently doing with it. So make the API user (demux.c) pass only the streams it really wants. Fixes: #6999
* loadfile: make prefetching actually workwm42019-09-291-1/+3
| | | | | | | | | | | | | | | | Looks like this didn't actually work. Prefetching will do nothing if there isn't a thread to "drive" it, and the demuxer thread needs to be explicitly enabled. (I guess I did the worst possible job in verifying whether this actually worked when I implemented it. On the other hand, the user didn't confirm back whether it worked, so who cares.) Like in the previous commit, bad factoring makes everything worse. It duplicates logic and implementation of enable_demux_thread(), since the opener thread cannot access the mpctx->opts field freely. But it's deep night, so fuck it. Fixes: c1f1a0845e03885e Fixes: #6753
* loadfile: don't always accidentally always prefetchingwm42019-09-292-11/+16
| | | | | | | | | | | | | | demux_start_prefetch() was called unconditionally in two cases. This is completely wrong. I'm not sure what part of my brain died off that something this obviously wrong went in. The prefetch case is a bit more complicated. It's a different thread, so you can't access just access mpctx->opts there. So add an explicit field for this, which is the simplest way to get this done. (Even if it's bad factoring.) Fixes: c1f1a0845e03885eebe63 Fixes: 556e204a112ee286972e5
* recorder: don't use a magic index for mp_recorder_get_sink()wm42019-09-294-8/+16
| | | | | | | | | | | | | | | | | | | Although this was sort of elegant, it just seems to complicate things slightly. Originally, the API meant that you cache mp_recorder_sink yourself (which would avoid the mess of passing an index around), but that too seems slightly roundabout. In a later change, I want to change the set of streams passed to mp_recorder_create(), and then I'd have to keep track of the index for each stream, which would suck. With this commit, I can just pass the unambiguous sh_stream to it, and it will be guaranteed to match the correct stream. The disadvantages are barely worth discussing. It's a new linear search per packet, but usually only 2 to 4 streams are active at a time. Also, in theory a user could want to write 2 streams using the same sh_stream (same metadata, just writing different packets or so), but in practice this is never done.
* stream: rearrange open functionswm42019-09-294-56/+96
| | | | | | | | | | | | | | | | Add yet another variant of the stream open function. This time, make it so that it's possible to add new open parameters in an extendable way, which should put an end to having to change this every other year. Effectively get rid of the overly special stream_create_instance() function and use the new one instead, which requires changes in stream_concat.c and stream_memory.c. The function is still in private in stream.c, but I preferred to make the mentioned users go through the new function for orthogonality. The error handling (mostly logging) was adjusted accordingly. This should not have any functional changes. (To preempt any excuses, I didn't actually test stream_concat and stream_memory.)
* demux: sort filenames naturally when playing a directory / archivePhilip Sequeira2019-09-295-2/+95
|
* build: lower version requirement for EGLMarvin Schmidt2019-09-291-1/+1
| | | | | | | | `egl.pc` can be provided either by mesa or libglvnd. The latter doesn't follow the same version scheme as mesa but instead uses the API version that the library exposes, which is 1.5 for EGL[1] [1] https://github.com/NVIDIA/libglvnd/commit/0dfaea2bcb7cdcc785f95e244223bd004a2d7fba#diff-b58a140c00ea99fb9a708e15afaade62R8
* vo_gpu: hwdec_cuda: Synchronise OpenGL InteropPhilip Langdale2019-09-283-0/+8
| | | | | | | | | | | | | | | | | | | | | Previously, there appeared to be implicit synchronisation in the GL interop path, and we never observed any visual glitches. However, recently, I started seeing stuttering in the GL path and on closer examination it looked like read-before-write behaviour where GL would display an old frame again rather than the current one. Aft