summaryrefslogtreecommitdiffstats
path: root/video/out/vo.c
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most contributors have agreed. vo.c requires a "driver" entry for each video output - we assume that if someone who didn't agree to LGPL added a line, it's fine for vo.c to be LGPL anyway. If the affected video output is not disabled at compilation time, the resulting binary will be GPL anyway. One problem are the changes by Nick Kurshev (usually using "nick" as SVN username). He could not be reached. I believe all changes to his files are actually gone, but here is a detailed listing: fa1d5742bc: nick introduces a new VO API. It was removed in 64bedd9683. Some of this was replaced by VOCTRLs are introduced in 7c51652a1b, obviously replacing at least some functionality by his API. b587a3d642: nick adds a vo_tune_info_t struct. Removed in 64bedd9683 too. 9caad2c29a: nick adds some VOCTRLs, which were silently removed in 8cc5ba5ab8 (they became unused probably with the VIDIX removal). 340183b0e9: nick adds VO-based screenshots, which got removed in 2f4b840f62. Strangely the same name was introduced in 01cf896a2f again, but this is a coincidence and worked differently (also it was removed yet again in 2858232220). 104c125e6d: nick adds an option for "direct rendering". It was renamed in 6403904ae9 and fully removed in e48b21dd87. 5ddd8e92a1: nick adds code to check the VO driver preinit arg to every single VO driver. The argument itself and any possibly remaining code associated with it was removed in 1f5ffe7d30. f6878753fb: nick adds header inclusion guards. We assume this is not relevant for copyright. Some of nick's code was merely moved to other files, such as the equalizer stuff added in 555c676683 and moved in 4db72f6a80 and 12579136ff, and don't affect copyright of these files anymore. Other notes: fef7b17c34: a patch by someone who wasn't asked for relicensing added a symbol that was removed again in 1b09f4633. 4a8a46fafd: author probably didn't agree to LGPL, but the function signature was changed later on anyway, and nothing of this is left. 7b25afd742: the same author adds a symbol to what is vo.h today, which this relicensing commit removes, as it was unused. (It's not clear whether the mere symbol is copyrightable, but no need to take a risk.) 3a406e94d7, 9dd8f241ac: slave mode things by someone who couldn't be reached. This aspect of the old slave mode was completely removed. bbeb54d80a: patch by someone who was not asked, but the added code was completely removed again.
* vo: fix subtleties in the redrawing logicwm42017-02-211-6/+11
| | | | | | | | | | | | | | | | | This fixes a race condition created by the previous commit, and possibly others. Sometimes interpolated frames weren't redrawn as uninterpolated ones. The problem is that redrawing/drawing a frame can't reset the VO want_redraw flags, because logically these have to happen after the core acknowledged and explicitly reissued a redraw. The core needs to be involved because the OSD text and drawings could depend on the playback or window state. Change it such that it always goes through the core. Also, VOs inconsistently called vo_wakeup() when setting want_redraw, which is also taken care of by this commit.
* player: reduce blocking on VO when switching pausewm42017-02-211-1/+8
| | | | | | | | | | | | | | | | | | | When pausing, we sent BOCTRL_PAUSE and VOCTRL_RESTORE_SCREENSAVER. These essentially wait until the video frame has been rendered. This is a problem with the opengl-cb, if GL rendering is done in the same thread as libmpv uses. Unfortunately, it's allowed to use opengl-cb this way. Logically speaking, it's a deadlock situation, which is resolved with a timeout. This can lead to quite ugly effects, like the on-pause frame not being rendered until the timeout has passed. It has been interpreted as video continuing to play. Resolve this by simply not blocking on pause. Make the screensaver controls async, and handle sending VOCTRL_PAUSE in the VO thread. (All this could be avoided by redoing the internal VO API.) Also see #4152.
* vo: log timings around flipping/waitingwm42017-01-181-3/+6
| | | | Found those useful.
* vo_rpi: partially undeprecatewm42016-12-081-3/+3
| | | | Using vo_opengl + MMAL overlay didn't quite work out.
* options: remove deprecated sub-option handling for --vo and --aowm42016-11-251-9/+7
| | | | | | | | Long planned. Leads to some sanity. There still are some rather gross things. Especially g_groups is ugly, and a hack that can hopefully be removed. (There is a plan for it, but whether it's implemented depends on how much energy is left.)
* win32: fix some Clang warningsJames Ross-Gowan2016-11-171-1/+1
| | | | | | | | - win32-console-wrapper.c was inconsistently using the explicit Unicode versions of some Windows API functions and structures. - vo.c should use llabs for int64_t, since long is 32-bit on Windows. - vo_direct3d.c had a potential use of an uninitialized variable if it took the first goto error_exit.
* vo: clear frame repeat flag when redrawingwm42016-11-011-0/+1
| | | | | | This makes no sense, as the flag is supposed to be used for vsync purposes only (when literally outputting the screen again with no changes at all), and redrawing is often used for OSD updates.
* vo_tct: optional custom size, support non-posix with 80x25 defaultAvi Halachmi (:avih)2016-10-251-2/+0
| | | | Also, replace the UTF8 half block char at the source code with C escape.
* vo: vo_tct is now available on non-POSIXwm42016-10-201-0/+2
| | | | Fixes Windows build.
* vo_tct: introduce modern caca alternativerr-2016-10-201-0/+2
|
* vo: log framedropswm42016-09-231-1/+3
| | | | Seems useful. (This was possibly added ages ago and then removed.)
* vo: add a unique frame_id to vo_framewm42016-09-221-0/+3
| | | | | We think that this allows simpler logic than using the redraw and repeat fields. Not used yet.
* player, ao, vo: don't call mp_input_wakeup() directlywm42016-09-161-6/+14
| | | | | | | | | | | | | Currently, calling mp_input_wakeup() will wake up the core thread (also called the playloop). This seems odd, but currently the core indeed calls mp_input_wait() when it has nothing more to do. It's done this way because MPlayer used input_ctx as central "mainloop". This is probably going to change. Remove direct calls to this function, and replace it with mp_wakeup_core() calls. ao and vo are changed to use opaque callbacks and not use input_ctx for this purpose. Other code already uses opaque callbacks, or has legitimate reasons to use input_ctx directly (such as sending actual user input).
* vo_rpi: deprecate this VOwm4