summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* options: change option macros and all option declarationswm42020-03-1878-1634/+1641
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change all OPT_* macros such that they don't define the entire m_option initializer, and instead expand only to a part of it, which sets certain fields. This requires changing almost every option declaration, because they all use these macros. A declaration now always starts with {"name", ... followed by designated initializers only (possibly wrapped in macros). The OPT_* macros now initialize the .offset and .type fields only, sometimes also .priv and others. I think this change makes the option macros less tricky. The old code had to stuff everything into macro arguments (and attempted to allow setting arbitrary fields by letting the user pass designated initializers in the vararg parts). Some of this was made messy due to C99 and C11 not allowing 0-sized varargs with ',' removal. It's also possible that this change is pointless, other than cosmetic preferences. Not too happy about some things. For example, the OPT_CHOICE() indentation I applied looks a bit ugly. Much of this change was done with regex search&replace, but some places required manual editing. In particular, code in "obscure" areas (which I didn't include in compilation) might be broken now. In wayland_common.c the author of some option declarations confused the flags parameter with the default value (though the default value was also properly set below). I fixed this with this change.
* wayland: notify vo if an output changesDudemanguy2020-03-151-0/+2
| | | | | | | | Previously, the vo wasn't always informed if something about the output changed during playback. For instance, changing a display's refresh rate during playback would not update mpv's display fps. Fix this by simply using VO_EVENT_WIN_STATE in output_handle_done which executes whenever something about the output is changed.
* m_option: remove debug codewm42020-03-141-3/+0
| | | | | | | Forgot to remove this. Here you see my confusion and realization how casting INT64_MAX to double becomes INT64_MAX+1 (due to mantissa precision and rounding), so some things seemed not to make sense at first.
* vo_gpu: warn if correct-downscaling is ignoredAvi Halachmi (:avih)2020-03-142-0/+13
| | | | And document that it's ignored with bilinear scaler.
* osc: fix updating message when pausedwm42020-03-141-5/+12
| | | | | | | | | | | | | | The message_timeout field was basically polled. But ever since the OSC was changed to work more event based, this didn't quite work. It was quite visible when switching subtitle or audio tracks while paused (and with caching disabled, since the cache update triggered some extra redrawing). Fix by using a proper timer. I noticed that changing tracks with the message call commented didn't redraw properly either, but, uh, I guess the message is always triggered anyway, and happens to take care of this.
* github: additionally ask for log files on build problems and questionsder richter2020-03-142-0/+14
|
* ao_pcm: fix double free on exitwm42020-03-141-6/+8
| | | | | | | | This seems to be an older bug. It set priv->outputfilename to a new talloc-allocated string, but the field is also managed as string option, so talloc will free it first, then m_option_free() is called on the dangling pointer. Possibly this is caused by the earlier ta destruction order change.
* cocoa-cb: support maximize/minimize on startupder richter2020-03-141-1/+9
| | | | | | | Allow the --window-maximized and --window-minimized flags to actually work when the player is started. since macOS doesn't like using both at the same time the minimized state takes precedence over the maximized state.
* options: introduce bool option type, use it for --fullscreenwm42020-03-146-11/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The option code is very old and was added to MPlayer in the early 2000s, when C99 was still new. MPlayer did not use the "bool" type anywhere,l and the logical option equivalent to bool, the "flag" option type, used int, with the convention that only the values 0 and 1 are allowed. mpv may have hammered many, many additional tentacles to the option code, but some of the basics never changed, and m_option_type_flag still uses int. This seems a bit weird, since mpv uses bool for booleans. So finally introduce an m_option_type_bool. To avoid duplicating too much code, change the flag code to bool, and "reimplement" m_option_type_flag on top of m_option_type_bool. As a "demonstration", change the --fullscreen option to this new type. Ideally, all options would be changed too bool, and m_option_type_flag would be removed. But that is a lot of monotonous thankless work, so I'm not doing it, and making it a painful years long transition. At the same time, I'm introducing a new concept for option declarations. Instead of OPT_BOOL(), which define the full m_option struct contents, there's OPTF_BOOL(), which only takes the option field name itself. The name is provided via a normal struct field initializer. Other fields (such as flags) can be provided via designated initializers. The advantage of this is that we don't need tons of nested vararg macros. We also don't need to deal with 0-sized varargs being a pain (and in fact they are not a thing in standard C99 and probably C11). There is no need to provide a mandatory flags argument either, which is the reason why so many OPT_ macros are used with a "0" argument. (The flag argument seems to confuse other developers; they either don't immediately recognize what it is, and sometimes it's supposed to be the option's default value.) Not having to mess with the flag argument in such option macros is also a reason for the removal of M_OPT_RANGE etc., for the better or worse. The only place that special-cased the _flag option type was in command.c; change it to use something effectively very similar that automatically includes the new _bool option type. Everything else should be transparent to the change. The fullscreen option change should be transparent too, as C99 bool is basically an integer type that is clamped to 0/1 (except in Swift, Swift sucks).
* DOCS/interface-changes.rst: add note about property notification changeswm42020-03-141-0/+7
| | | | | | | | | Commits ba70b150fbe8 and 8a4f812b76be should have mentioned this. These things should be quite useful for client API users, and thus should be mentioned in a prominent place. Although I'm not sure if anyone will understand from this gibberish what this really means.
* command: disable edition switching if there are no editionswm42020-03-142-1/+4
| | | | | | | | | | | | | | | | | | | | | | Commit 8d965a1bfb3 changed option/property min/max handling. As a consequence, ranges that contain only 1 or 0 elements are not possible anymore. Normally that's fine, because it makes no sense to have an option that has only one or none allowed value (statically). But edition switching used some sort of mechanism where the property can return a different, dynamically decided range at runtime. That meant that if there were <2 editions, edition switching with the "cycle" command would always pick the same value. But with the recent commit, this changed to having "no range set" and would cycle through all integer values. Work this around with a simple change. Now, edition switching on a file without editions shows "edition: auto" instead of "edition: 0", which may appear odd. But the former is the --edition default value, and previous mpv versions rendered the edition property like this when not using switching. (Who the fuck uses editions?)
* options: change how option range min/max is handledwm42020-03-1316-119/+142
| | | | | | | | | | | | | | | | | Before this commit, option declarations used M_OPT_MIN/M_OPT_MAX (and some other identifiers based on these) to signal whether an option had min/max values. Remove these flags, and make it use a range implicitly on the condition if min<max is true. This requires care in all cases when only M_OPT_MIN or M_OPT_MAX were set (instead of both). Generally, the commit replaces all these instances with using DBL_MAX/DBL_MIN for the "unset" part of the range. This also happens to fix some cases where you could pass over-large values to integer options, which were silently truncated, but now cause an error. This commit has some higher potential for regressions.
* ao_lavc: don't spam underrun warningswm42020-03-131-0/+1
| | | | | Like ao_pcm, this is (conceptually) in perpetual underrun, as long as dumping is fast enough.
* options: more pushing code aroundwm42020-03-134-151/+245
| | | | | | | Try to remove m_config implementation details from m_config_frontend. Not sure if I like it. Seems to be ~100 lines of awkward code more, and not much is gained from it. Also it took way too long to do it, and there might be bugs.
* options: split m_config.c/hwm42020-03-1313-1238/+1336
| | | | | | | | | | | | | | | | | Move the "old" mostly command line parsing and option management related code to m_config_frontend.c/h. Move the the code that enables other part of the player to access options to m_config_core.c/h. "frontend" is out of lack of creativity for a better name. Unfortunately, the separation isn't quite clean yet. m_config_frontend.c still references some m_config_core.c implementation details, and m_config_new() is even left in m_config_core.c for now. There some odd functions that should be removed as well (marked as "Bad functions"). Fixing these things requires more changes and will be done separately. struct m_config is left with the current name to reduce diff noise. Also, since there are a _lot_ source files that include m_config.h, add a replacement m_config.h that "redirects" to m_config_core.h.
* options: remove intpair option typewm42020-03-134-61/+5
| | | | | | | | | | | This was mostly unused, and has certain problems. Just get rid of it. It was still used in CDDA (--cdda-span) and a debug option for OpenGL (--opengl-check-pattern). Replace both of these with 2 options, where each sets the start/end values of the former span. Both were undocumented somehow (normally we require all options to be documented), so I'm not caring about compatibility, and not bothering to add it to the API changelog.
* options: remove min/max support from strings and string listswm42020-03-133-33/+6
| | | | | We don't really use this anymore. Only --playlist and vf_lavfi filter names did (to error on empty parameters), but it doesn't really matter.
* build: make C11 atomics mandatorywm42020-03-131-14/+5
| | | | | | | | | | The emulation is pretty bad, and C11 compilers are everywhere now. It's time to retire the emulation, which was always meant as temporary hack for transition. In theory, a user can still use --disable-stdatomic to enable the emulation code, but that's sort of hidden. Actual support will be removed after the next release or so.
* video/out/android_common: use jni helpersAman Gupta2020-03-121-10/+11
| | | | Signed-off-by: Aman Gupta <aman@tmm1.net>
* vo_gpu: generally allow non-storable FBOsNiklas Haas2020-03-082-3/+12
| | | | | | | | | | | | | We have this cap now thanks to e2976e662, but we don't actually make sure our FBOs are storable before we blindly attempt using them with compute shaders. There's no more need to unconditionally set `storage_dst = true` as long as we make sure to include an extra condition on the `fbo_format` selection to prevent users from accidentally enabling compute-shader-only features with non-storable FBOs, alongside some other miscellaneous adjustments to eliminate instances of "assumed storability" from vo_gpu.
* vo_gpu: avoid error spam when ra_fbo fmt is non-storableNiklas Haas2020-03-081-0/+2
| | | | | | | | | | | This simply makes the "is the destination FBO format bad?" check a tiny bit less awful, by making sure we prefer storable FBO formats over non-storable FBO formats. I'd love to make this also conditional on whether or not we actually *need* a storable FBO format, but that logic is decided later, in `pass_draw_to_screen`, and I don't want to replicate the logic. Fixes #7017.
* filter: minor cosmetic naming issuewm42020-03-086-41/+47
| | | | | Just putting some more lipstick on the pig, maybe it looks a bit nicer now.
* command: add libass-version propertywm42020-03-082-0/+20
| | | | A bit of a mess with that ifdeffery, but fuck it.
* sub: log libass versionwm42020-03-081-0/+2
| | | | | Sometimes helpful. Would be even nicer if libass logged it themselves, including git hash, I guess.
* player: rearrange libav* library checkwm42020-03-083-21/+12
| | | | No need to be nice. Also hopefully breaks idiotic distro patches.
* stream_file: mark fd protocols as "unsafe"wm42020-03-082-2/+11
| | | | | Whatever good or bad that might do. In any case, they can easily trigger UB-like behavior.
* wayland: always use the fs-screen id for fsDudemanguy2020-03-081-33/+31
| | | | | | | | | Previously if the --fs-screen option was set, it would only use the screen if mpv was launched with --fs and only on startup. During runtime, the toggle would ignore it. Rework the logic here so that mpv's fullscreen always uses --fs-screen if it is set. Additionally, cleanup some unneeded cruft in vo_wayland_reconfig and make find_output more useful.
* stream_lavf: use smb:// for ffmpeg libsmbclient supportwm42020-03-072-2/+2
| | | | If you really want that, you can get it through FFmpeg, I guess.
* ci: remove libsmblientwm42020-03-071-1/+0
| | | | This was forgotten.
* player: move on_unload hook after frame step pausingwm42020-03-071-2/+2
| | | | | | | Really minor detail that doesn't really matter. If frame stepping pauses playback on end (why does this special case even exist), it should probably be done after on_unload, because all works is supposed to be finished at that point.
* client API: always reset new_property_events fieldswm42020-03-071-1/+2
| | | | | | This was not reset in the num_properties==0 case. This didn't really matter, but for debugging it's slightly nicer to see new_property_events reset once the client thread is done with it.
* manpage: explicitly mention "tick" event as deprecatedwm42020-03-071-1/+1
| | | | Just. Don't. Use. It.
* demux: bump --cache-secs default valuewm42020-03-071-1/+1
| | | | | | Change to it 1000 hours, which is "infinite" enough. (Hesitant to use INFINITY, as that is not in the option's range. The option parser rejects it because it causes only problems in API users and so on.)
* demux: mark recently added debug option as deprecatedwm42020-03-071-1/+2
| | | | | It was the intention to remove it again after a release or two; mark it was deprecated so nobody thinks it gets to stay.
* js: osd-overlay update: return the command result (match 7a76b577)Avi Halachmi (:avih)2020-03-071-2/+1
| | | | Currently only useful for the new 'compute_bounds' command key.
* js: osd-overlay update: support arbitrary key namesAvi Halachmi (:avih)2020-03-071-9/+11
| | | | | | | | | | | | | | | | | | | | Until now the 'update' method used mp.command_native with a hardcoded list of key names. Change it to use whatever keys the user set to this object, so that we can remain oblivious to new keys which 'osd-overlay' may support. This is how the lua code did it from the begining. We didn't, and now we pay the price. Note: could be implemented either as we have now (clone `this` excluding the methods) or by moving the methods up the prototype chain (i.e. class methods) so they don't get enumerated and use `this` as the command object itself. However, in the latter approach we'll have to save the values which we change (name, res_x, res_y) and restore them after the command, so it's simpler to just clone `this`.
* client API: provide ways to finish property changes on file changeswm42020-03-074-5/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the current file changes (or rather, when starting/finishing playback of a playlist entry), clients tend to have the problem that it's hard to tell whether a property change notification (via mpv_observe_property() and mechanisms layered on top of it) is from the previous or new playlist entry. The previous commit probably helps, but all the asynchronity is still a bit unhelpful. Try to make this better by adding new hooks, that are run before/after playback init/deinit. This is similar to the existing hooks, except they're outside of "initialized" playback, which excludes that you might accidentally get an overlap between the current and the previous/next playlist entry. That still doesn't seem quite enough, since normally, property change notifications come after the hook event. So basically a client would have to explicitly "drain" the event queue within the hook, and make the hook continue only after that is done. Knowing when property notifications are done is another asynchronous nightmare (how exactly it works keeps changing within client.c, and an API user probably can't tell anymore when all pending properties are truly done). So introduce another guarantee: properties that were changed before the hook happens will be returned before the hook event is returned. That means the client will have received all pending property notifications from the previous playlist entry (or whatever) before the hook is entered. As another minor complication, we shouldn't just keep the hook pending until _all_ property notifications are done, since the client's hook could produce new ones. (Or just consider things like the demuxer thread hammering the client with cache update events, while the "on_preloaded" hook is run.) So there is some extra untested, fragile logic in client.c to handle this (the waiting_for_hook flag). This probably works, but was barely tested. Not sure if this helps anyone, but I think it's fine for my own purposes. (I really hated this aspect of the API whenever I used it myself.)
* client API: avoid returning stale value on property notificationswm42020-03-061-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | This could happen if a property was flagged as changed, then updated, then flagged again, but gen_property_change_event() was called before the value was updated a second time. Then the function simply returned the old value, and would later trigger a new change event again. This was considered acceptable before, since property notifications are asynchronous anyway (so they may always be "outdated", it just mattered whether the most recent value was eventually delivered). But consider ordering with events. It seems desirable that specific important events (e.g. MPV_EVENT_START_FILE) should not be followed by property updates that happened before it, because that would make application logic really a mess, and property notification near-useless in certain cases. Avoid this by never returning a value if it was marked changed, but not updated yet. Unfortunately, this could lead to clients never receiving a value (or receiving it with a high random delay), if they're too slow to read it (or the property simply updates too often). Note that this is done for _all_ property notifications, not just returned events. Hopefully not a problem in practice. If it turns out to be one, this mechanism could be restricted to actually returned events, for which this really matters.
* client API: remove deprecated qthelper.hpp headerwm42020-03-063-387/+11
| | | | | | | | | | | | No replacement. Qt or C++ code has no business in this repository, and new code (even if it uses Qt) should not use it. Get rid of it. We consider the libmpv API itself as stable. Symbols can be deprecated, but not be removed. However, qthelper.hpp was never considered part of the libmpv API. There no ABI implications either, since it's a header- only implementation that uses C API symbols only. It's just a header provided for convenience for Qt/C++ programs (i.e. extremely limited usefulness).
* command: remove legacy hook APIwm42020-03-065-104/+13
| | | | | Hopefully nothing uses this. (I know one exception, but, well, what can I do.)
* command: extend osd-overlay command with bounds reportingwm42020-03-0610-8/+161
| | | | | | | | | | | | | | | | | | | | This is more or less a minimal hack to make _some_ text measurement functionality available to scripts. Since libass does not support such a thing, this simply uses the bounding box of the rendered text. This is far from ideal. Problems include: - using a bitmap bounding box - additional memory waste and/or flushing caches - dependency on window size - odd small deviations with different window sizes (run osd-test.lua and resize the window after each timer update; the bounding boxes aren't adjusted in an overly useful way) - inability to query the size _after_ actual rendering But I guess it's a start. Since I'm aware that it's crap, add a threat to the manpage that this may be changed/removed again. For now, I'm interested whether anyone will have use for it in its current form, as it's an often requested feature.
* manpage: fix typoswm42020-03-061-2/+2
|
* player: force update of cache properties even on inactive demuxer cachewm42020-03-052-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | When the demuxer cache read until the end of the stream, and was finished and completely inactive, the cache properties were not updated anymore via MP_EVENT_CACHE_UPDATE. Unfortunately, many cache properties depend on the current playback position, such as cache-duration or fw-bytes. This is especially visible on the OSC. If everything was cached, seeking around didn't update the displayed forward cache duration. That means checking demuxer_reader_state.idle is not enough. You also need to check whether the current playback position changed. Fix this by explicitly using the current playback position, and update the properties if it changed "enough". "Enough" is 1 second of media time in this example, which may or may not be appropriate. In general, this could probably be done better. There are many other triggers that change the cache state and that are not covered. For now I'm content with getting rid of the obvious problems. I think the OSC problem in particular was caused by changing it from polling to using property change notifications.
* build: disable RPI vendor blob auto-detectionwm42020-03-051-0/+1
| | | | | | | Apparently this bit-rotted a lot, and now causes more problems that it helps. In particular picking up broadcom EGL instead of Mesa EGL will break things. With RPI getting proper Mesa/DRM/V4L support, this problem should solve itself as well.
* demux: deprecate --cache-secswm42020-03-053-3/+17
| | | | | Because it's confusing and useless. If nobody complains, we'll have one weird cache configuration option less.
* player: reduce impact of blocking filterswm42020-03-051-0/+1
| | | | | | | | | | | | | | | | | | | | Some filters may block the playloop for a longer time. For example, if a decoder fails to decode anything and somehow just discards packets, the filter graph would run (in a blocking manner) until all packets are read, which could take a longer time if the demuxer thread is fast enough. Make it exit every 100ms. That should at least give the user a chance to stop playback. Filtering could run on a different thread, but I don't see much value in doing that in the general case. It would just waste a thread. Although being able to use mp_filter_graph_interrupt() would be slightly nicer than such a timeout mechanism. Decoding in particular can actually use a separate thread (--vd-queue-enable), but again, this is not enabled by default, because it just wastes a thread. Like the previous f_decoder_wrapper commit, this is probably a sin.
* manpage: make suggestion for --vd-queue dynamic configwm42020-03-051-1/+3
|
* f_decoder_wrapper: make decoder thread responsive while filling queuewm42020-03-052-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | The mp_filter_run() invocation blocks as long as the demuxer provides packets and the queue can be filled. That means it may block quite a long time of the decoder queue size is large (since we use libavcodec in a blocking manner; it regrettably does not have an async. API). This made the main thread freeze in certain situations, because it has to wait on the decoder thread. Other than I suspected (I wrote that code, but that doesn't mean I know how the hell it works), this did not freeze during seeking: seek resets flushed the queue, which also prevented the decoder thread from adding more frames to it, thus stopping decoding and responding to the main thread in time. But it does fix the issue that exiting the player waited for the decoder to finish filling the queue when stopping playback. (This happened because it called mp_decoder_wrapper_set_play_dir() before any resets. Related to the somewhat messy way play_dir is generally set. But it affects all "synchronous" decoder wrapper API calls.) This uses pretty weird mechanisms in filter.h and dispatch.h. The resulting durr hurr interactions are probably hard to follow, and this whole thing is a sin. On the other hand, this is a _very_ user visible issue, and I'm happy that it can be fixed in such an unintrusive way.