summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* DOCS/contribute.md: license clarificationswm42019-09-212-0/+6
| | | | | | | | | Basically, both the license of the file and the preferred license of the project (LGPLv2.1+) counts. I'm doing that so that files with more liberal licenses don't get infected by LGPL, but allow copy & pasting to LGPL source files without jumping through lawyer bullshit hoops. Mention this in Copyright too.
* github: remove LGPL relicensing boilerplatewm42019-09-211-3/+2
| | | | | | Most files are LGPL anyway by now. contribute.md still requires contributors to provide changes under LGPL, which should cover changes to files that are LGPL, as well as GPL files.
* vo_sdl: Only create the SDL window onceCameron Cawley2019-09-211-54/+23
|
* ao_pulse: add --pulse-allow-suspendedTérence Clastres2019-09-212-1/+7
| | | | | | | | | | This flag makes mpv continue using the PulseAudio driver even if the sink is suspended. This can be useful if JACK is running with PulseAudio in bridge mode and the sink-input assigned to mpv is the one JACK controls, thus being suspended. By forcing mpv to still use PulseAudio in this case, the user can now adjust the sink to an unsuspended one.
* stream_libarchive: Always use LC_CTYPE_MASK for libarchiveJames Hilliard2019-09-212-2/+1
| | | | | | Using LC_ALL_MASK is unnecessary and unreliable on some systems. Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
* command: drop removed cache properties from cache update eventswm42019-09-201-2/+2
| | | | These did nothing anymore, maybe made it slightly slower.
* player: update status line cache displaywm42019-09-202-7/+5
| | | | | | | | | | | Replace the "+" with "/". The "+" was supposed to imply that the cache is the sum of the time (demuxer cache) and the size in bytes (stream cache). We could not provide something nicer, because we had no idea how many seconds of media was buffered in the stream cache. Now the stream cache is done, and both the duration and byte size show the amount buffered in the demuxer cache. Hopefully "/" is better to imply this properly. Update the manpage explanations too.
* context_drm_egl: Use eglGetPlatformDisplayEXT if availablememeka2019-09-201-1/+20
| | | | | | | | Check if eglGetPlatformDisplayEXT is available and try to use it to obtain the display connection. Fall back to eglGetDisplay if eglGetPlatformDisplayEXT is not available or failing. From PR #5992
* client API: fix missing property change events after property updatesGunnar Marten2019-09-201-24/+28
| | | | | | | | | | | | | | | | | | | | | | | | | When update_prop() successfully fetched a changed property value, it set prop->changed to true to indicate the success. mark_property_changed() also always set prop->changed to true and additionally prop->need_new_value to true This is the case since 6ac0ef78 If the observed property changes every frame and then due to timing the next mark_property_changed() is called before gen_property_change_event() and therefore directly after update_prop(), prop->need_new_value was again true and indicated that a new value has to be retrieved with update_prop(). As a result the event for the last successful update_prop() was never triggered. This meant that a property change event were never generated for frame-based properties only for properties that were observed with MPV_FORMAT_NONE or when the timing was different and gen_property_change_event() was called after update_prop(). To fix this, mark_property_change() and update_prop() should not use the same flag to indicate different things and therefore a new flag for successfully update a property is introduced. But with the now decoupled property changed and updated the need_new_value flag is redundant and removed completely. Fixes #4195
* loadfile: restore playlist prefetchingwm42019-09-201-4/+11
| | | | | | | | | | | | | | | | | | | | | | | With the stream cache gone, this function had almost no use anymore (other than opening the stream). Improve this by triggering demuxer cache readahead. This enables all streams. At this point we can't know yet what streams the user's options would select (at least not without great additional effort). Generally this is what you want, and the stream cache would have read the same amount of data. In addition, this will work much better for files that e.g. need to seek to the end when opening (typically mp4, and mkv files produced by newer mkvmerge versions). Remove the deselection call from add_stream_track(). This should be fine, as streams normally start out as deselected anyway. In the prefetch case, some code in play_current_file() actually deselects it. Streams that appear during demuxing are disabled by default, so this doesn't break this logic either. Fixes: #6753
* demux: propagate streaming flag through demux_timelinewm42019-09-203-3/+10
| | | | | | | | | | | | | | Before this commit, EDL or CUE files did not properly enable the cache if they were on "slow" media (stream->streaming==true). This happened because the stream is unset for demux_timeline, so the streaming flag could not be queried anymore. Fix this by adding this flag to struct demuxer, and propagate it exactly like the is_network flag. is_network is not used for checking the cache options anymore, and its main function seems to be something else. Normal http streams set the streaming flag already. This should fix #6958.
* client API, vo_libmpv: document random deadlock problemswm42019-09-202-0/+20
| | | | | | | I guess trying to make DR work on libmpv was a mistake. I never observed such a deadlock, but it's looks like it's theoretically possible.
* vo_libmpv: fix some more uninit issueswm42019-09-201-24/+35
| | | | | | | | | | | | | | | | | | | | | | This is mostly for the case when mpv_render_context_free() is called while video is going on. This is supposed to gracefully stop video and deinitialize everything properly. (I feel like it would put too much on the API user to require that video is stopped before calling this function. Whether video is running or not is a fairly highlevel thing, and the API user could not do it in a race-free way.) One problem was that unit() accessed ctx after ctx->in_use was set to false. The update(ctx) call was basically a racy use-after-free. It needed that call to wake up the mpv_render_context_free() loop that waited for VO uninit. Fix this by triggering the wakeup inside the lock, and then doing "barrier" locking in mpv_render_context_free(). Another problem was that the wait loop didn't really wait properly. IT seems the had_kill_update field was a botched attempt to do that. It's indeed quite hairy to do that with update(). Instead make use of the dispatch queue (infinite timeout, using mp_dispatch_interrupt()), which handles the problem of having to wait both for dispatch queue updates and VO uninit at the same time.
* client API: document unfortunate render API threading requirementwm42019-09-201-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is because dr_helper.c calls pthread_self(). It's used to avoid deadlocks. This was not a problem internal to mpv (dr_helper.c was first created for vo_gpu.c), but it accidentally leaked as an unintended consequence of an implementation detail to libmpv. This problem existed for MPV_RENDER_PARAM_ADVANCED_CONTROL users, ever since it was introduced. Maybe this could be done differently, but it's certainly very tricky. the pthread_t is used to avoid deadlocks when the caller is on the same thread as the one which needs to handle the calls. The critical code is in free_dr_buffer_on_dr_thread(). It's called when a DR image is free'd. Freeing a DR image requires access to the GL context, i.e. it just has to run on the "GL" thread. In libmpv's case, this is done by calling the API user's wakeup call, and the user will eventually call mpv_render_context_update() on the "GL" thread, which in turn calls mp_dispatch_queue_process() on the dispatch queue that was passed to dr_helper_create(), which then calls av_buffer_unref(), which calls gl_video_dr_free_buffer(). (God who came up with this rube goldberg shit.) The above case will typically happen when e.g. vd_lavc.c (internal mpv thread) frees images. Allocation works similarly; deallocation is just trickier because calls to free images are everywhere. Now consider if mpv_render_context_render() releases a DR image. This function is always called on the "GL" thread. Going through the dispatch queue would obviously deadlock, because according to the render API rules, the user's wakeup callback must not mpv_render_context_update(), instead it has to signal the "GL" thread, which must wait until mpv_render_context_render() returns. To avoid this deadlock, dr_helper.c checks whether the calling thread is the "GL" thread, and if so, allows a reentrant call (basically gl_video_dr_free_buffer() is called directly). While with GL, you usually will stay on the same thread, API users were in theory allowed to e.g. move the GL context to a different thread. But this dr_helper issue means this is not possible. Moreover, other APIs will not have the same thread-locality problems as GL. FUCK THIS SHIT In theory, libmpv could provide an API to "move" the context to a separate thread, but let's not start with even more broken crap like this. I'm not sure yet whether there is an easy solution. Maybe all mpv_render() function could be guarded by entry/exit functions, which set/unset a flag that dr_helper.c should use reentrant calls. libmpv users which do not set MPV_RENDER_PARAM_ADVANCED_CONTROL were never affected.
* vo_libmpv: always create ctx->dispatchwm42019-09-201-19/+12
| | | | | | | | Preparation for the next commit. Until now, it was only needed if DR was involved. One reason for not always creating it was that you normally must not use it if advanced_control is not enabled. This is why e.g. VOCTRL_SCREENSHOT now checks for that variable; it still can't use ctx->dispatch if the render API user did not enable it.
* render api: fix use-after-freewnoun2019-09-203-33/+6
| | | | | | | | render api needs to wait for vo to be destroyed before frees the context. The purpose of kill_cb is to wake up render api after vo is destroyed, but uninit did that before kill_cb, so kill_cb tries using the freed memory. Remove kill_cb to fix the issue as uninit is able to do the work.
* rpi: Update for modern systemsCameron Cawley2019-09-205-25/+14
|
* Coypright: update list of fileswm42019-09-201-13/+1
|
* vo: remove unused equalizer control remainswm42019-09-201-14/+1
| | | | | | | | | | Equalizer control was redone in 03cf150ff3516789d5812 (over 2 years ago). Ever since, the equalizer control structs and the GET voctrl have been unused. Only the SET voctrl is still used as notification mechanism (actually a bad hack to avoid some further option change handling complexity). Remove the unused parts.
* oml_sync: fix typo in commentwm42019-09-201-2/+2
| | | | I think... Also reword another part of the text.
* vf_fingerprint: use aligned_alloc instead of posix_memalignwm42019-09-192-2/+8
| | | | | | | | | | | I was assuming posix_memalign was the most portable function to use, but MinGW does not provide it for some reason. Switch to C11 aligned_alloc() which someone suggested was provided by MinGW (but actually isn't, someone probably confused it with the incompatible _aligned_malloc), and add a configure check. Even though it turned out that MinGW doesn't provide it, the function is slightly more elegant than posix_memalign(), so stay with it.
* demux_lavf: document intentional FFmpeg API violationwm42019-09-191-0/+4
| | | | | | | | | | | | | | | This field is documented as internal, so an API user should not access it. However, this is the only way to get some read statistics without replacing FFmpeg's entire HLS demuxer. (Using custom I/O as workaround doesn't work: the HLS code uses some weird internal APIs that cannot be provided by FFmpeg API users; I even made the author of the relevant patch to provide a public API, but which was shot down by another FFmpeg developer. So I take this as my right to access this field.) Mention this explicitly, as it affects ABI and API compatibility, and I don't want that anyone claims this was a "mistake". Add some explanations.
* packet: fix theoretical UB if called on "empty" packetswm42019-09-191-2/+4
| | | | | | | | | | In theory, a 0 size allocation could have made it memset() on a NULL pointer (with a non-0 size, which makes it crash in addition to theoretical UB). This should never happen, since even packets with size 0 should have an associated allocation, as FFmpeg currently does. But avoiding this makes the API slightly more orthogonal and less tricky, I guess.
* Revert "demux/packet: fix demux_packet_shorten"wm42019-09-191-2/+2
| | | | | | | | | | | This reverts commit 95636c65e73c1d0d8cba43d8c230291d99962e88. This change shouldn't be needed, and in fact it's wrong. The FFmpeg API function could do anything it wants with the packet, including changing the packet data pointer. Likewise, it's not guaranteed that the referenced packet's fields mirror the current state of the mpv packet struct (the AVPacket is only kept for the AVBuffer and the side data stuff).
* client API: fix some commentswm42019-09-191-4/+4
|
* sd_lavc: support scaling for bitmap subtitleswm42019-09-191-0/+16
|
* demux: fix another incorrect BOF cache flag issuewm42019-09-191-2/+5
|
* f_swscale: fix a typowm42019-09-191-1/+1
|
* manpage: input.rst: fix a typowm42019-09-191-1/+1
|
* video: add vf_fingerprint and a skip-logo scriptwm42019-09-197-0/+618
| | | | | | | | | | | | | | | | | | | | | | | | | skip-logo.lua is just what I wanted to have. Explanations are on the top of that file. As usual, all documentation threatens to remove this stuff all the time, since this stuff is just for me, and unlike a normal user I can afford the luxuary of hacking the shit directly into the player. vf_fingerprint is needed to support this script. It needs to scale down video frames as part of its operation. For that, it uses zimg. zimg is much faster than libswscale and generates more correct output. (The filter includes a runtime fallback, but it doesn't even work because libswscale fucks up and can't do YUV->Gray with range adjustment.) Note on the algorithm: seems almost too simple, but was suggested to me. It seems to be pretty effective, although long time experience with false positives is missing. At first I wanted to use dHash [1][2], which is also pretty simple and effective, but might actually be worse than the implemented mechanism. dHash has the advantage that the fingerprint is smaller. But exact matching is too unreliable, and you'd still need to determine the number of different bits for fuzzier comparison. So there wasn't really a reason to use it. [1] https://pypi.org/project/dhash/ [2] http://www.hackerfactor.com/blog/index.php?/archives/529-Kind-of-Like-That.html
* command: make vf-metadata/af-metadata somewhat observablewm42019-09-191-1/+1
| | | | | | | | | | | Until now they weren't observable and never reported any updates. Apply a shitty hack to make them mostly-observable. It relies on the "idle" event, which is basically triggered on every frame displayed, or similar. This can lead to property change notifications not being sent quickly enough. The cleaner solution would be adding a notification mechanisms from filters, but I'm too lazy for that.
* command: make vf-metadata/af-metadata not query metadata twicewm42019-09-191-7/+13
| | | | | | | | | | | For simplicity, these properties usually query the metadata from the filter twice, even if it's not technically needed at all. The reason for this is mostly the horrible (and legacy) sub-path access (which is why tag_property() is so complex). But for simple cases, we can easily avoid double querying, so do that. The benefit is performance (well, won't matter), and supporting filters that reset information on query (for later).
* video: generally try to align image data on 64 byteswm42019-09-195-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Generally, using x86 SIMD efficiently (or crash-free) requires aligning all data on boundaries of 16, 32, or 64 (depending on instruction set used). 64 bytes is needed or AVX-512, 32 for old AVX, 16 for SSE. Both FFmpeg and zimg usually require aligned data for this reason. FFmpeg is very unclear about alignment. Yes, it requires you to align data pointers and strides. No, it doesn't tell you how much, except sometimes (libavcodec has a legacy-looking avcodec_align_dimensions2() API function, that requires a heavy-weight AVCodecContext as argument). Sometimes, FFmpeg will take a shit on YOUR and ITS OWN alignment. For example, vf_crop will randomly reduce alignment of data pointers, depending on the crop parameters. On the other hand, some libavfilter filters or libavcodec encoders may randomly crash if they get the wrong alignment. I have no idea how this thing works at all. FFmpeg usually doesn't seem to signal alignment internal anywhere, and usually leaves it to av_malloc() etc. to allocate with proper alignment. libavutil/mem.c currently has a ALIGN define, which is set to 64 if FFmpeg is built with AVX-512 support, or as low as 16 if built without any AVX support. The really funny thing is that a normal FFmpeg build will e.g. align tiny string allocations to 64 bytes, even if the machine does not support AVX at all. For zimg use (in a later commit), we also want guaranteed alignment. Modern x86 should actually not be much slower at unaligned accesses, but that doesn't help. zimg's dumb intrinsic code apparently randomly chooses between aligned or unaligned accesses (depending on compiler, I guess), and on some CPUs these can even cause crashes. So just treat the requirement to align as a fact of life. All this means that we should probably make sure our own allocations are 64 bit aligned. This still doesn't guarantee alignment in all cases, but it's slightly better than before. This also makes me wonder whether we should always override libavcodec's buffer pool, just so we have a guaranteed alignment. Currently, we only do that if --vd-lavc-dr is used (and if that actually works). On the other hand, it always uses DR on my machine, so who cares.
* ta: destroy/free children in reverse orderwm42019-09-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | This matters when talloc allocations set destructors. Before this commit, destructors were called in the same order as they were added to the parent allocations. Now it happens in reverse order. I think this makes more sense. It's reasonable to assume that an allocation that was added later may depend on any of the previous allocations, so later additions should be destroyed first. (Of course other orders are entirely possible too.) Hopefully this doesn't fix or break anything, but I can't be sure (about either of those). It's risky. (Then why do it?) The destructor of a parent allocation is called before its children. It makes sense and must stay this way, because in most cases, the destructor wants to access the children. This is a reason why I don't really like talloc (it wasn't my idea to use talloc, is my excuse). Quite possible that destructors should be removed from talloc entirely. Actually, this project should probably be rewritten in Rust (or a better language), but that would be even more of a pain; also, I think this is just the right level of suffering and punishment.
* m_config: add assertion to a specific casewm42019-09-191-2/+4
| | | | | | | | It seems using multiple prefixes for an option isn't supported out of laziness (and shouldn't, because what the fuck). So assert() on this. (Unfortunately this prefix nonsense is still needed. Especially AO and VO options use this through the options_prefix field.)
* command: don't add deprecated CLI aliases to property listwm42019-09-191-0/+12
| | | | | | | A dumb thing that the cursed property-option bridge accidentally did. Normal deprecated options on the other hand are fine in the property list, because they're wanted for compatibility.
* options: deprecate --stream-recordwm42019-09-194-21/+38
| | | | It's inadequate for most uses. There are better mechanisms.
* builtin.conf: add clarificationswm42019-09-191-0/+7
| | | | | Just in case a confused user or developer finds this file and wonders why it's "incomplete".
* m_config: remove m_config_create_shadowwm42019-09-193-13/+1
| | | | | | | A previous commit changed m_config so that it always creates the shadow thing, and the function's only remaining purpose was to initialize mpv_global. It makes much more sense to do that at the caller, and it's only 1 line of code too.
* m_config: further minor simplificationswm42019-09-191-35/+26
| | | | | Now m_config_shadow is fully independent from m_config (except for the fact that m_config is still involved in its creation).
* m_config: simplify some minor crapwm42019-09-191-24/+20
| | | | | | | | | | | | m_config has a m_config_option array, that is used for all option access. The code maintaining shadow copies also tried to make use of it, and did so by "cleverly" assigning each m_sub_options run a slice of that array. But actually it's much simpler to, you know, directly access the damn options. This helps separation m_config and the general option code slightly. Still seems to work after a superficial test, good enough.
* m_config: move group list to internal contextwm42019-09-192-42/+53
| | | | | | | | | | This is good because a private thing is not so public anymore, and it's also preparation for further changes. Some tricky memory management issues: m_config_data (i.e. config->data) now depends on m_config_shadow, instead of m_config. In particular, free_option_data() accesses the m_config_shadow.groups array. Obviously it must be freed before m_config_shadow.
* io: remove Windows tmpfile() emulationwm42019-09-192-37/+0
| | | | | | | | | | | | Unused now. The old stream cache used it, but it was removed. On a side note, the demuxer cache uses mp_mkostemps(). It looks like our Windows open() emulation handles this correctly by using CREATE_NEW, so no functionality gets lost by the "new" approach. On the other hand, the demuxer cache does not set FILE_FLAG_DELETE_ON_CLOSE, but instead tries to delete the file after opening (POSIX style), which probably won't work on Windows. But I'm not sure how to make it use the DELETE_ON_CLOSE flag, so whatever.
* m_config: add/move some commentswm42019-09-192-21/+33
| | | | | | | Move the comments documenting exported functions to the header. It looks like the header is the preferred place for that (although I don't really appreciate headers where you lose the overview because of all the documentation comments). Add comments to some undocumented prototypes.
* m_config: remove an unused functionwm42019-09-192-7/+0
| | | | | | | | | This was one of those "shouldn't exist" type of functions that could access internals that were supposed to be isolated away, but some code needed to access it anyway. It looks like the last use of it went away in 2016, shortly after it was introduced.
* vo: fix missed option updates under rare circumstanceswm42019-09-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Dear diary, today I fixed a shitty bug that was all my fault because I made a horrible mess. (Except it was a horrible mess before I even touched this shit, but let's not blame others.) Sometimes, updates to VO option that control video sizing (like panscan) didn't update the screen correctly. They were delayed until the next option change or so. It turns out that if the option update happens at the "same" time as a VOCTRL, update_opts() doesn't actually notify the vo_driver of the change. This in turn happened because run_control() called m_config_cache_update(). The latter function returns true if the options changed since the last call, and update_opts() also calls it (on the same config cache) for the same purpose. The update_opts() call, which is triggered by a third mechanism, comes later, but the cache update call will return false (as it should). Basically, given the config API, you can't act differently on multiple update calls and expect it to work. The skipped handling in update_opts() meant that the notification required to apply t