summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* f_decoder_wrapper: use proper log prefix for all involved filterswm42020-03-051-1/+1
| | | | | | p->log has a prefix set that gives some context and distinguishes audio and video decoders. The "public" wrapper filter didn't use it, which is a regression since commit a3823ce0e03.
* filter: add functions to suspend filtering temporarilywm42020-03-052-1/+66
| | | | | | | | | | | | | | Filtering is integrated into an event loop, which is something the filter API user provides. To make interacting with the event loop easier, and in particular to avoid filtering to block event handling, add functions the event loop code can suspend filtering. While we cannot actually suspend a single filter, it's pretty easy to suspend the filter graph run loop itself, which is responsible for selecting which filter to run next. This commit shouldn't change behavior at all, but the functions will be used in later commits.
* atomic: add atomic_exchange_explicit() fallbackwm42020-03-051-2/+7
| | | | | Apparently I want to use this in a later commit. Untested, because this is a pre-C11 fallback, and I only test with real <stdatomic.h>.
* dispatch: add strange mechanism for making worker threads responsivewm42020-03-052-2/+26
| | | | | This is probably a sin for the sake of user experience. See a following commit that wires up f_decoder_wrapper with it.
* f_decoder_wrapper: enable DR and hwdec with --vd-queue-enablewm42020-03-051-0/+10
| | | | | | | | | | | | | | This was forgotten. Hardware decoding typically breaks immediately, because many hw decoding APIs require allocating all surfaces in advance (and/or libavcodec was not made flexible enough to add new surfaces later). If the queue is large enough, it will run out of surfaces, fail decoding, and fall back to software decoding. We consider this the user's fault. --hwdec-extra-frames can be used to avoid this, if you have enough GPU memory, and the needed number of frames is lower than the arbitrary mpv-set maximum limit of that option.
* manpage: document how final queue size is determinedwm42020-03-051-0/+5
| | | | Believe it or not, users were confused about this.
* manpage: clarify writes to playlist-poswm42020-03-051-2/+8
| | | | | | | | | | | | | | I don't know what should happen when the same value is written to the property. It seems that it would be more natural if it were ignored (since that's also what is done with options now), but you could argue the other way around as well. In any case, changing it silently could leads to user scripts etc. breaking, so don't change it now. Instead, add blabla to the manpage to put the responsibility on the user, so when we suddenly change it one day, we can blame any breakages on someone else. See: #7501
* stream_smb: remove thiswm42020-03-055-168/+0
| | | | | | | | | | | This required libsmbclient, which is a heavy dependency, and as a library, has all kinds of problems. For one, the API requires completely unacceptable global state (in particular, leaks auth state), and is not thread-safe (meaning concurrent reads to multiple files block each other). There are better replacements: you can use the Linux kernel's builtin CIFS support, fusesmb, or contribute supoport for libdsm.
* drm_prime: double free bugSven Kroeger2020-03-053-15/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit fixes a bug where handle for a framebuffer gets double freed. It seems to happen that the same prime fd gets two framebuffers. As the prime fd is the same the resulting prime handle is also the same. This means one handle but 2 framebuffers and can lead to the following chain: 1. The first framebuffer gets deleted the handle gets also freed via the ioctl. 2. In startup phase not all 4 dumb buffers for overlay drawing are set up. It can happen that the last dumb buffer gets the handle we freed above. 3. The second framebuffer gets freed and the handle will be freed again resulting that the 4's dumb buffer handle is not backed by a buffer. 4. Drm prime continues to assign handles to its prime fds an will lead to have this handle which was just freed to reassign again but to an prime buffer. 5.Now the overlay should be drawn into dumb buffer 4 which still has the same handle but is backed by the wrong buffer. This leads to two different behaviors: - MPV crashes as the drm prime buffers size als calculated by the decoder output format. The overlay output format differs and it takes more space. SO the size check in kernel fails. - MPV is continuing play. This happens when the decoders allocates a bigger buffer than needed for the overlay. For example overlay is Full HD and decoder output is 4k. This leads to the behavior das the overlay wil be drawn into the wrong buffer as its a drm prime buffer and results in a flicker every fourth step.
* drm_prime: forward modifiers from FFMPEG to drm APISven Kroeger2020-03-031-2/+9
| | | | | | * Change drmModeAddFB2 to drmModeAddFB2WithModifiers * Set modifiers flag in API call * fetch and set modifiers according to kernel constraints
* demuxer-lavf: udp_multicast rtsp-transport optionmg2020-03-032-2/+5
|
* manpage: suggest using the decoding queue with backward playbackwm42020-03-011-0/+3
|
* f_decoder_wrapper: make most queue options runtime changeablewm42020-03-012-13/+25
| | | | Why not.
* options: make decoder options local to decoder wrapperwm42020-03-016-82/+96
| | | | | | | | | | | | | | | Instead of having f_decoder_wrapper create its own copy of the entire mpv option tree, create a struct local to that file and move all used options to there. movie_aspect is used by the "video-aspect" deprecated property code. I think it's probably better not to remove the property yet, but fortunately it's easy to work around without needing special handling for this option or so. correct_pts is used to prevent use of hr-seek in playloop.c. Ignore that, if you use --no-correct-pts you're asking for trouble anyway. This is the only behavior change.
* demux: another hack to deal with track switching refreshwm42020-02-291-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The demuxer cache employs a strange method to make track switching instant with caching enabled. Normally this would mean you have to wait until the cache has played out (and you get new packets, including packets from the newly selected track), or you have to perform a slow high level seek (decoding video again etc.). The strange method is that it performs a demuxer-level seek without a high level seek so it looks like a continuous stream to the decoder, and the newly select stream gets packets at the current playback position. This is called a refresh seek. This works only if some weird heuristics work. It needs a packet "unique ID", for which it uses either dts or pts. The value must be strictly monotonic increasing. If this doesn't work, the referesh seek can't be executed, and the user has to wait until the end of the cache. Sometimes there are files that simply do not work. In the present case, there's actually a hack that we can extend. Packets with unset position are likely generated by the parser, and the hack which this commit touches simply attempts to make up a new (hopefully unique) position value, even if the value itself makes no sense. It only ha to be deterministic. It turns out libavcodec sometimes output packets with repeating position values. This commit tries to handle this case too with the same hack. Fixes: #7498
* ad_lavc: disable decoder downmix by defaultwm42020-02-292-2/+2
| | | | | | | | Let's see how much everyone hates this. Leaving it enabled seems problematic, because libavcodec returns an unspecific error if it doesn't like it. Fixes: #6300
* player: add optional separate video decoding threadwm42020-02-295-55/+383
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See manpage additions. This has been a topic in MPlayer/mplayer2/mpv since forever. But since libavcodec multi-threaded decoding was added, I've always considered this pointless. libavcodec requires you to "preload" it with packets, and then you can pretty much avoid blocking on it, if decoding is fast enough. But in some cases, a decoupled decoder thread _might_ help. Users have for example come up with cases where decoding video in a separate process and piping it as raw video to mpv helped. (Or my memory is false, and it was about vapoursynth filtering, who knows.) So let's just see whether this helps with anything. Note that this would have been _much_ easier if libavcodec had an asynchronous (or rather, non-blocking) API. It could probably have easily gained that with a small change to its multi-threading code and a small extension to its API, but I guess not. Unfortunately, this uglifies f_decoder_wrapper quite a lot. Part of this is due to annoying corner cases like legacy frame dropping and hardware decoder state. These could probably be prettified later on. There is also a change in playloop.c: this is because there is a need to coordinate playback resets between demuxer thread, decoder thread, and playback logic. I think this SEEK_BLOCK idea worked out reasonably well. There are still a number of problems. For example, if the demuxer cache is full, the decoder thread will simply block hard until the output queue is full, which interferes with seeking. Could also be improved later. Hardware decoding will probably die in a fire, because it will run out of surfaces quickly. We could reduce the queue to size 1... maybe later. We could update the queue options at runtime easily, but currently I'm not going to bother. I could only have put the lavc wrapper itself on a separate thread. But there is some annoying interaction with EDL and backward playback shit, and also you would have had to loop demuxer packets through the playloop, so this sounded less annoying. The food my mother made for us today was delicious. Because audio uses the same code, also for audio (even if completely pointless). Fixes: #6926
* filter: add async queue filterwm42020-02-294-1/+393
| | | | | | | | | | | | | | | | | | | | | | | | | | This is supposed to enable communication between filter graphs on separate threads. Having multiple threads makes only sense if they can run concurrently with each other, which requires such an asynchronous queue as a building block. (Probably.) The basic idea is that you have two independent filters, which can be each part of separate filter graphs, but which communicate into one direction with an explicit queue. This is rather similar to unix pipes. Just like unix pipes, the queue is limited in size, so that still some data flow control enforced, and runaway memory usage is avoided. This implementation is pretty dumb. In theory, you could avoid avoid waking up the filter graphs in quite a lot of situations. For example, you don't need to wake up the consumer filter if there are already frames queued. Also, you could add "watermarks" that set a threshold at which producer or consumer should be woken up to produce/consume more frames (this would generally serve to "batch" multiple frames at once, instead of performing high-frequency wakeups). But this is hard, so the code is dumb. (I just deleted all related code when I still got situations where wakeups were lost.) This is actually salvaged and modified from a much older branch I had lying around. It will be used in the next commit.
* filter: decide how multi-threading is supposed to workwm42020-02-292-8/+24
| | | | | | | | | | Instead of vague ideas about making different filter graphs on different threads interact directly, this have no direct support. Instead, helpers are required (such as added with the next commit). Document it. Different root filters (i.e. separate filter graphs) are now considered to be part of separate threads, so assert() if they're found to accidentally interact.
* skip-logo.lua: remove lua 5.2 warning messagewm42020-02-291-1/+0
| | | | (OK, I tested it.)
* build: pick up Lua 5.2 by defaultwm42020-02-291