summaryrefslogtreecommitdiffstats
path: root/video/out/vo.c
Commit message (Collapse)AuthorAgeFilesLines
* vo_wlshm: use memfd_create() instead of shm_open()Emmanuel Gil Peyrot2019-10-171-1/+1
| | | | | | | | | | | This syscall avoids the need to guess an unused filename in /dev/shm and allows seals to be placed on it. We immediately return if no fd got returned, as there isn’t anything we can do otherwise. Seals especially allow the compositor to drop the SIGBUS protections, since the kernel promises the fd won’t ever shrink. This removes support for any platform but Linux from this vo.
* Reintroduce vo_wayland as vo_wlshmMichael Forney2019-10-171-0/+4
| | | | | | | | vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
* Revert "vo: add support for externally driven renderloop and make wayland ↵dudemanguy2019-10-101-51/+3
| | | | | | | | | | use it" The externally driven renderloop was originally added for the wayland context (to make display sync somewhat work), but it has a lot of issues with mpv's internal structure. A different approach should be used. This reverts commit a743fef837bcab206b1e576db7e7a64b02890449.
* client API: fix potential deadlock problems by throwing more shit at itwm42019-09-261-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The render API (vo_libmpv) had potential deadlock problems with MPV_RENDER_PARAM_ADVANCED_CONTROL. This required vd-lavc-dr to be enabled (the default). I never observed these deadlocks in the wild (doesn't mean they didn't happen), although I could specifically provoke them with some code changes. The problem was mostly about DR (direct rendering, letting the video decoder write to OpenGL buffer memory). Allocating/freeing a DR image needs to be done on the OpenGL thread, even though _lots_ of threads are involved with handling images. Freeing a DR image is a special case that can happen any time. dr_helper.c does most of the evil magic of achieving this. Unfortunately, there was a (sort of) circular lock dependency: freeing an image while certain internal locks are held would trigger the user's context update callback, which in turn would call mpv_render_context_update(), which processed all pending free requests, and then acquire an internal lock - which the caller might not release until a further DR image could be freed. "Solve" this by making freeing DR images asynchronous. This is slightly risky, but actually not much. The DR images will be free'd eventually. The biggest disadvantage is probably that debugging might get trickier. Any solution to this problem will probably add images to free to some sort of queue, and then process it later. I considered making this more explicit (so there'd be a point where the caller forcibly waits for all queued items to be free'd), but discarded these ideas as this probably would only increase complexity. Another consequence is that freeing DR images on the GL thread is not synchronous anymore. Instead, it mpv_render_context_update() will do it with a delay. This seems roundabout, but doesn't actually change anything, and avoids additional code. This also fixes that the render API required the render API user to remain on the same thread, even though this wasn't documented. As such, it was a bug. OpenGL essentially forces you to do all GL usage on a single thread, but in theory the API user could for example move the GL context to another thread. The API bump is because I think you can't make enough noise about this. Since we don't backport fixes to old versions, I'm specifically stating that old versions are broken, and I'm supplying workarounds. Internally, dr_helper_create() does not use pthread_self() anymore, thus the vo.c change. I think it's better to make binding to the current thread as explicit as possible. Of course it's not sure that this fixes all deadlocks (probably not).
* rpi: Update for modern systemsCameron Cawley2019-09-201-3/+3
|
* 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 the changed option wasn't run. Fix this by simply calling update_opts() directly instead. Now there's only 1 m_config_cache_update() call on this specific instance. Fix the call in run_reconfig() too, so the previous sentence isn't a lie (but it probably doesn't make a difference in practice due to certain details). I'm not sure how I even ran into this sort-of race condition. The VOCTRL that messed up the option update was VOCTRL_UPDATE_PLAYBACK_STATE, which happens semi-regularly. Why this config cache shit and all the other shit? Rediscovering this crap wasn't pleasant. It's a bunch of hacks that became necessary when the ancient MPlayer architecture made it hard to move the VO to a separate thread. All the VO code typically accesses vo->opts (whose fields all used to be global variables in MPlayer). The frontend changes these on user input. Putting locking around all the options would be a nightmare, and keeping a copy of the options in the thread was much simpler. You need a way to propagate option changes, notify the thread, and update the local copy too. And the result of these thoughts was the config cache mechanism. In this specific case, the relevant cache update call in update_opts() triggers a VOCTRL_SET_PANSCAN to the VO driver, which isn't related to its former function anymore. Instead, it causes the VO driver to update the video sizing/placing options, which the generic VO code can't do. (Mostly because the VO driver includes the windowing stuff and is responsible for resizing etc. itself.) VOCTRLs sent by the frontend are even worse. MPlayer had no real runtime option change mechanism. Some options were vaguely duplicated by properties, so you could effectively change those options at runtime. Each of these options had its own VOCTRL, which still exist today, e.g. VOCTRL_FULLSCREEN, or VOCTRL_ONTOP. I tried to make all options runtime changeable, and to unify properties with options. But I couldn't be bothered with updating all VO drivers to listen to option changes directly, because that would be pretty tedious. So the property code is still all there and sends the old VOCTRLs. But of course you need to sync up the options, which is why the run_control() code did that. (Unrelated: VO_EVENT_FULLSCREEN_STATE is the worst shithack of them all. Currently, only the frontend can actually write to options (for awful reasons), so if the fullscreen state changes due to outside interaction, the VO driver can't update the corresponding option fields. So the VO notifies the frontend with said VO_EVENT_, and the frontend then sends VOCTRL_GET_FULLSCREEN, and updates the global copy of the option with the value returned by that. I still like to think the situation is not that bad considering the monstrous effort of converting single-threaded code that had hundreds of options in global variables to multi-threaded code with no global variables at all.)
* vo, vo_gpu, glx: correct GLX_OML_sync_control usagewm42018-12-061-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | I misunderstood how this extension works. If I understand it correctly now, it's worse than I thought. They key thing is that the (ust, msc, sbc) tripple is not for a single swap event. Instead, (ust, msc) run independently from sbc. Assuming a CFR display/compositor, this means you can at best know the vsync phase and frequency, but not the exact time a sbc changed value. There is GLX_INTEL_swap_event, which might work as expected, but it has no EGL equivalent (while GLX_OML_sync_control does, in theory). Redo the context_glx sync code. Now it's either more correct or less correct. I wanted to add proper skip detection (if a vsync gets skipped due to rendering taking too long and other problems), but it turned out to be too complex, so only some unused fields in vo.h are left of it. The "generic" skip detection has to do. The vsync_duration field is also unused by vo.c. Actually this seems to be an improvement. In cases where the flip call timing is off, but the real driver-level timing apparently still works, this will not report vsync skips or higher vsync jitter anymore. I could observe this with screenshots and fullscreen switching. On the other hand, maybe it just introduces an A/V offset or so. Why the fuck can't there be a proper API for retrieving these statistics? I'm not even asking for much.
* vo: use a struct for vsync feedback stuffwm42018-12-061-15/+17
| | | | So new useless stuff can be easily added.
* vo_gpu: glx: use GLX_OML_sync_control for better vsync reportingwm42018-12-061-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the extension to compute the (hopefully correct) video delay and vsync phase. This is very fuzzy, because the latency will suddenly be applied after some frames have already been shown. This means there _will_ be "jumps" in the time accounting, which can lead to strange effects at start of playback (such as making initial "dropped" etc. frames worse). The only reasonable way to fix this would be running a few dummy frame swaps at start of playback until the latency is known. The same happens when unpausing. This only affects display-sync mode. Correct function was not confirmed. It only "looks right". I don't have the equipment to make scientifically correct measurements. A potentially bad thing is that we trust the timestamps we're receiving. Out of bounds timestamps could wreak havoc. On the other hand, this will probably cause the higher level code to panic and just disable DS. As a further caveat, this makes a bunch of assumptions about UST timestamps. If there are delayed frames (i.e. we skipped one or more vsyncs), the latency logic is mostly reset. There is no attempt to make the vo.c skipped vsync logic to use this. Also, the latency computation determines a vsync duration, and there's no effort to reconcile or share the vo.c logic for determining vsync duration.
* vo: remove bogus #ifwm42018-05-241-2/+0
| | | | | | | | | | | | If anyone happened to build with GL disabled, this could lead to option changes not always refreshing the screen. Since vo_gpu is always enabled now (just not necessarily any backend for it), we can drop the #if completely. (The way this works is a bit idiotic - the option cache exists only to grab the change notification, which will trigger a redraw and make vo_gpu update its own second copy of them. But at least it avoids some layering issues for now.)
* player: get rid of mpv_global.optswm42018-05-241-7/+11
| | | | | | | | This was always a legacy thing. Remove it by applying an orgy of mp_get_config_group() calls, and sometimes m_config_cache_alloc() or mp_read_option_raw(). win32 changes untested.
* build: make encoding mode non-optionalwm42018-05-031-2/+0
| | | | Makes it easier to not break the build by confusing the ifdeffery.
* encode: get rid of the output packet queuewm42018-05-031-1/+3
| | | | | | | | | | | | Until recently, ao_lavc and vo_lavc started encoding whenever the core happened to send them data. Since audio and video are not initialized at the same time, and the muxer was not necessarily opened when the first encoder started to produce data, the resulting packets were put into a queue. As soon as the muxer was opened, the queue was flushed. Change this to make the core wait with sending data until all encoders are initialized. This has the advantage that we don't need to queue up the packets.
* vo: add vo_reconfig2()wm42018-04-291-3/+19
| | | | | | 1. I want to get away from mp_image_params (maybe). 2. For encoding mode, it's convenient to get the nominal_fps, which is a mp_image field, and not in mp_image_params.
* vo: move DR helper code to a separate source filewm42018-04-291-91/+25
| | | | | So it can be reused by vo_libmpv.c, which needs to use it in a slightly different way.
* vo: pass through framedrop flag differentlywm42018-03-151-5/+1
| | | | | | | | There is some sort-of awkwardness here, because option access needs to happen in a synchronized manner, and the framedrop flag is not in the VO option struct. Remove the mp_read_option_raw() call and the awkward change notification via VO_EVENT_WIN_STATE from command.c, and pass it through as new vo_frame flag.
* vo: move display-fps internal option value to VO optswm42018-03-151-14/+18
| | | | | | Removes the awkward notification through VO_EVENT_WIN_STATE. Unfortunately, some awkwardness remains in mp_property_display_fps(), because the property has conflicting semantics with the option.
* video: add an option to tune waiting for video timingwm42018-03-151-2/+17
| | | | Probably mostly useful for the libmpv render API.
* vo: cosmetics: fix a case of bad whitespacewm42018-03-151-2/+1
|
* client API: deprecate opengl-cb API and introduce a replacement APIwm42018-02-281-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | The purpose of the new API is to make it useable with other APIs than OpenGL, especially D3D11 and vulkan. In theory it's now possible to support other vo_gpu backends, as well as backends that don't use the vo_gpu code at all. This also aims to get rid of the dumb mpv_get_sub_api() function. The life cycle of the new mpv_render_context is a bit different from mpv_opengl_cb_context, and you explicitly create/destroy the new context, instead of calling init/uninit on an object returned by mpv_get_sub_api(). In other to make the render API generic, it's annoyingly EGL style, and requires you to pass in API-specific objects to generic functions. This is to avoid explicit objects like the internal ra API has, because that sounds more complicated and annoying for an API that's supposed to never change. The opengl_cb API will continue to exist for a bit longer, but internally there are already a few tradeoffs, like reduced thread-safety. Mostly untested. Seems to work fine with mpc-qt.
* video: rename VO_CAP_NOREDRAW to VO_CAP_NORETAINAman Gupta2018-02-171-2/+2
|
* vo: make opengl-cb first in the autoprobing orderwm42018-02-131-3/+3
| | | | | | | This should be helpful for the new OSX Cocoa backend, which uses opengl-cb internally. Since it comes with a behavior change that could possibly interfere with libmpv/opengl_cb users, we mark it as explicit API change.
* vo_gpu: make screenshots use the GL rendererwm42018-02-111-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | Using the GL renderer for color conversion will make sure screenshots will use the same conversion as normal video rendering. It can do this for all types of screenshots. The logic when to write 16 bit PNGs changes. To approximate the old behavior, we decide by looking whether the source video format has more than 8 bits per component. We apply this logic even for window screenshots. Also, 16 bit PNGs now always include an unused alpha channel. The reason is that FFmpeg has RGB48 and RGBA64 formats, but no RGB064. RGB48 is 3 bytes and usually not supported by GPUs for rendering, so we have to use RGBA64, which forces an alpha channel. Will break for users who use --target-trc and similar options. I considered creating a new gl_video context, but it could double GPU memory use, so I didn't. This uses FBOs instead of glGetTexImage(), because that increases the chance it could work on GLES (e.g. ANGLE). Untested. No support for the Vulkan and D3D11 backends yet. Fixes #5498. Also fixes #5240, because the code for reading back is not used with the new code path.
* video: change some remaining vo_opengl mentions to vo_gpuAkemi2018-01-201-1/+1
|
* ta: introduce talloc_dup() and use it in some placeswm42018-01-181-2/+2
| | | | | | | It was actually already implemented as ta_dup_ptrtype(), but that seems like a clunky name. Also we still use the talloc_ names throughout the source, and I'd rather use an old name instead of a mixing inconsistent naming conventions.
* vo: log reconfig callswm42018-01-181-0/+2
| | | | Helpful for debugging, sometimes.
* vo: fix a compiler warning by properly printing a 64bit integerJan Ekström2017-12-111-1/+1
|
* vo: add support for externally driven renderloop and make wayland use itRostislav Pehlivanov2017-12-051-3/+51
| | | | | | | | | | | Fixes display-sync (though if you change virtual desktops you'll need to seek to re-enable display-sync) partially under wayland. As an advantage, rendering is completely disabled if you change desktops or alt+tab so you lose no performance if you leave mpv running elsewhere as long as it isn't visible. This could also be ported to other VOs which supports it.
* vo: fix reference to mediacodec_embedAman Gupta2017-10-091-2/+2
|
* vo_gpu: simplify opengl aliaswm42017-10-091-3/+2
| | | | | This makes the replacement warning message worse, but I don't think I care enough.
* vo: add mediacodec_embed output driverAman Gupta2017-10-091-0/+4
| | | | | Allows rendering IMGFMT_MEDIACODEC frames directly onto an android.view.Surface
* vo: add VO_CAP_NOREDRAW for upcoming vo_mediacodec_embedAman Gupta2017-10-091-1/+6
| | | | | | | | | | | MediaCodec uses a fixed number of output buffers to hold frames, and expects that output buffers will be released as soon as possible. Once rendered, the underlying frame is automatically released and cannot be reused or rerendered. The new VO_CAP_NOREDRAW forces mpv to release frames immediately after they are rendered or dropped, to ensure that MediaCodec decoder does not run out of buffers and stall out.
* vo_wayland: removeRostislav Pehlivanov2017-10-031-4/+0
| | | | | This VO was buggy and never worked correctly. Like with wayland_common, it needs to be rewritten from scratch.
* vaapi: change license to LGPLwm42017-09-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | Originally mpv vaapi support was based on the MPlayer-vaapi patches. These were never merged in upstream MPlayer. The license headers indicated they were GPL-only. Although the actual author agreed to relicensing, the company employing him to write this code did not, so the original code is unusable to us. Fortunately, vaapi support was refactored and rewritten several times, meaning little code is actually left. The previous commits removed or moved that to GPL-only code. Namely, vo_vaapi.c remains GPL-only. The other code went away or became unnecessary mainly because libavcodec itself gained the ability to manage the hw decoder, and libavutil provides code to manage vaapi surfaces. We also changed to mainly using EGL interop, making any of the old rendering code unnecessary. hwdec_vaglx.c is still GPL. It's possibly relicensable, because much of it was changed, but I'm not too sure and further investigation would be required. Also, this has been disabled by default for a while now, so bothering with this is a waste of time. This commit simply disables it at compile time as well in LGPL mode.
* build: make vo_gpu + infrastructure non-optionalwm42017-09-221-2/+0
| | | | | Also readd the the error message for when no GL backends are found (why was this removed?).
* vo_opengl: refactor into vo_gpuNiklas Haas2017-09-211-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is done in several steps: 1. refactor MPGLContext -> struct ra_ctx 2. move GL-specific stuff in vo_opengl into opengl/context.c 3. generalize context creation to support other APIs, and add --gpu-api 4. rename all of the --opengl- options that are no longer opengl-specific 5. move all of the stuff from opengl/* that isn't GL-specific into gpu/ (note: opengl/gl_utils.h became opengl/utils.h) 6. rename vo_opengl to vo_gpu 7. to handle window screenshots, the short-term approach was to just add it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to ra itself (and vo_gpu altered to compensate), but this was a stop-gap measure to prevent this commit from getting too big 8. move ra->fns->flush to ra_gl_ctx instead 9. some other minor changes that I've probably already forgotten Note: This is one half of a major refactor, the other half of which is provided by rossy's following commit. This commit enables support for all linux platforms, while his version enables support for all non-linux platforms. Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the --opengl- options like --opengl-early-flush, --opengl-finish etc. Should be a strict superset of the old functionality. Disclaimer: Since I have no way of compiling mpv on all platforms, some of these ports were done blindly. Specifically, the blind ports included context_mali_fbdev.c and context_rpi.c. Since they're both based on egl_helpers, the port should have gone smoothly without any major changes required. But if somebody complains about a compile error on those platforms (assuming anybody actually uses them), you know where to complain.
* video: redo video equalizer option handlingwm42017-08-221-0/+11
| | | | | | | | | | | | | | | | | | | | | | | I really wouldn't care much about this, but some parts of the core code are under HAVE_GPL, so there's some need to get rid of it. Simply turn the video equalizer from its current fine-grained handling with vf/vo fallbacks into global options. This makes updating them much simpler. This removes any possibility of applying video equalizers in filters, which affects vf_scale, and the previously removed vf_eq. Not a big loss, since the preferred VOs have this builtin. Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and vo_xv. I'm not going to waste my time on these legacy VOs. vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which exists _only_ to trigger a redraw. This seems silly, but for now I feel like this is less of a pain. The rest of the equalizer using code is self-updating. See commit 96b906a51d5 for how some video equalizer code was GPL only. Some command line option names and ranges can probably be traced back to a GPL only committer, but we don't consider these copyrightable.
* options: add a thread-safe way to notify option updateswm42017-08-221-1/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So far, we had a thread-safe way to read options, but no option update notification mechanism. Everything was funneled though the main thread's central mp_option_change_callback() function. For example, if the panscan options were changed, the function called vo_control() with VOCTRL_SET_PANSCAN to manually notify the VO thread of updates. This worked, but's pretty inconvenient. Most of these problems come from the fact that MPlayer was written as a single-threaded program. This commit works towards a more flexible mechanism. It adds an update callback to m_config_cache (the thing that is already used for thread-safe access of global options). This alone would still be rather inconvenient, at least in context of VOs. Add another mechanism on top of it that uses mp_dispatch_queue, and takes care of some annoying synchronization issues. We extend mp_dispatch_queue itself to make this easier and slightly more efficient. As a first application, use this to reimplement certain VO scaling and renderer options. The update_opts() function translates these to the "old" VOCTRLs, though. An annoyingly subtle issue is that m_config_cache's destructor now releases pending notifications, and must be released before the associated dispatch queue. Otherwise, it could happen that option updates during e.g. VO destruction queue or run stale entries, which is not expected. Rather untested. The singly-linked list code in dispatch.c is probably buggy, and I bet some aspects about synchronization are not entirely sane.
* vo_opengl: add direct rendering supportwm42017-07-241-0/+91
| | | | | | | | | | | | | | | | | | | | Can be enabled via --vd-lavc-dr=yes. See manpage additions for what it does. This reminds of the MPlayer -dr flag, but the implementation is completely different. It's the same basic concept: letting the decoder render into a GPU buffer to avoid a copy. Unlike MPlayer, this doesn't try to go through filters (libavfilter doesn't support this anyway). Unless a filter can work in-place, DR will be silently disabled. MPlayer had very complex semantics about buffer types and management (which apparently nobody ever understood) and weird restrictions that mostly limited it to mpeg2 style codecs. The mpv code does not do any of this, and just lets the decoder allocate an arbitrary number of untyped images. (No MPlayer code was used.) Parts of the code based on work by atomnuker (starting point for the generic code) and haasn (some GL definitions, some basic PBO code, and correct fencing).
* vo.c, vo.h, vo_null.c: change license to LGPLwm42017-05-101-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |