summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* encode: remove old timestamp handlingwm42018-05-031-193/+35
| | | | | This effectively makes --ocopyts the default. The --ocopyts option itself is also removed, because it's redundant.
* drm_atomic: Disallow selecting cursor planes using the optionsAnton Kindestam2018-05-011-0/+3
|
* drm_common: Be smarter when deciding on which CRTC and Encoder to useAnton Kindestam2018-05-011-1/+27
| | | | | | | | | | | | | | | | | Inspired by kmscube, first try to pick the Encoder and CRTC already associated with the selected Connector, if any. Otherwise try to find the first matching encoder & CRTC like before. The previous behavior had problems when using atomic modesetting (crtc_setup_atomic) when we picked an Encoder & CRTC that was currently being used by the fbcon together with another Encoder. drmModeSetCrtc was able to "steal" the CRTC in this case, but using atomic modesetting we do not seem to get this behavior automatically. This should also improve behavior somewhat when run on a multi screen setup with regards to deinit and VT switching (still sometimes you end up with a blank screen where you previously had a cloned display of your fbcon)
* context_drm_egl: fix some comments and log messages that had not been ↵Anton Kindestam2018-05-011-6/+5
| | | | updated since the plane rename commit
* drm/atomic: Fix crtc_setup_atomic and crtc_release_atomicAnton Kindestam2018-05-011-25/+33
| | | | | | | | | | | Add some properties which where forgotten in crtc_setup_atomic. In both change to not use DRM_MODE_PAGE_FLIP_EVENT | DRM_MODE_ATOMIC_NONBLOCK flags. This should make it more similar to the drmSetCrtc which it aims to replace (take effect directly, and blocking call). This also saves us the trouble of having to set up a poll to wait for pageflip, which would've been neccesary with DRM_MODE_PAGE_FLIP_EVENT, in both crtc_setup_atomic and crtc_release_atomic.
* drm/atomic: disable video plane when unused.LongChair2018-05-011-0/+28
| | | | | | | | | | This patch will make sure that the video plane is hidden when unused. When using high resolution modes, typically UHD, and embedding mpv, having the video plane sitting in the back when you don't play any video is eating a lot of memory bandwidth for compositing. That patch makes sure that the video layer is just disabled before and after playback.
* drm/atomic: add atomic modesetting.LongChair2018-05-011-11/+104
| | | | | | | This commit allows to add atomic modesetting when using the atomic renderer. This is actually needed when using and osd with a smaller size than screen resolution. It will also make the drm atomic path more consistent
* drm/atomic: refactor planes namesLongChair2018-05-017-55/+89
| | | | | | | | We are currently using primary / overlay planes drm objects, assuming that primary plane is osd and overlay plane is video. This commit is doing two things : - replace the primary / overlay planes members with osd and video planes member without the assumption - Add two more options to determine which one of the primary / overlay is associated to osd / video. - It will default osd to overlay and video to primary if unspecified
* drm/atomic: add connector to atomic contextLongChair2018-05-015-4/+35
| | | | | | | | | | This patch adds - DRM connector object to atomic context. - fd property to the drm atomic object as well as a method to read blob type properties. This allows to ensure that the proper connector is picked up, especially when specifying it from the commandline, and also allows to make sure we're using the right one when embedding with interop into an application.
* drm/atomic: refactor hwdec_drmprime_drm with native resourcesLongChair2018-05-015-30/+63
| | | | | | | | | | | | | | | | | That new API was introduced and allows to have several native resources. Thisuses that mechanisma for drm resources rather than the deprecated opengl-cb structs. This patch therefore add two structs that can be used with the drm atomic interop. - mpv_opengl_drm_params : which will hold all the drm handles - mpv_opengl_drm_osd_size : which will hold osd layer size This commit adds a drm-osd-size=WxH parameter to commandline which allows to define the OSD plane dimension. OSD can be upscaled to screen resolution when having OSD at video resolution is too heavy. This is especially useful for UHD modes on embedded devices where the GPU cannot handle UHD modes at a decent framerate.
* vo_gpu/video: disable compute shaders if an FBO format was not availableJan Ekström2018-05-011-0/+5
| | | | | This is actually more generic and better than just lazily plastering peak calculation together with dumb mode.
* vo_gpu/video: add improved logging when a user-specified FBO failsJan Ekström2018-05-011-2/+13
| | | | | I don't know if we can just return from this function, so for now just adding this piece of logging.
* cocoa: change deprecation warning from opengl-cb to libmpvAkemi2018-04-291-1/+1
|
* wayland_common: update to stable xdg-shellEmmanuel Gil Peyrot2018-04-292-47/+47
| | | | | This removes support for older compositors using the unstable version, but those will still use Xwayland by default, so not a big loss.
* gpu/video: make HDR peak computing work without work group countNiklas Haas2018-04-291-4/+5
| | | | | | | | | | Define a hard-coded value for gl_NumWorkGroups if it is not available. This adds an additional requirement of needing a shader recompile for all window size changes. This was considered a worthwhile compromise as currently f.ex. d3d11 completely lacked any peak computation - this is a major quality of life upgrade.
* gpu/video: improve HDR peak computation feature check loggingJan Ekström2018-04-291-1/+4
| | | | | Now that the feature depends on multiple features, log all of their states in the message.
* vd_lavc: enable dr by defaultwm42018-04-291-0/+1
| | | | | I had this enabled for quite a while and experienced no issues. I'm not aware of other issues either.
* vf_vapoursynth: correctly signal error on script init failurewm42018-04-291-0/+1
| | | | Otherwise it will do nothing, waiting on nothing forever.
* egl_helpers: change minimum framebuffer size to 8 bit per componentwm42018-04-291-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | This is for working around bugs in certain Android devices. At least one device fails to sort EGLConfigs by size, so eglChooseConfig() ends up choosing a config with 5/6/5 bits per r/g/b component. The other attributes in the affected EGLConfigs did not look like they should affect the sorting process as specified by the EGL 1.4 standard. The device was reported as: Sony Xperia Z3 Tablet Compact Firmware 6.0.1 build number 23.5.A.1.291 GL_VERSION='OpenGL ES 3.0 V@140.0 AU@ (GIT@I741a3d36ca)' GL_VENDOR='Qualcomm' GL_RENDERER='Adreno (TM) 330' Other Qualcom/Adreno devices have been reported as unaffected by this (including some with same GL_RENDERER string). "Fix" this by always requiring at least 8 bit. This means it would fail on devices which cannot provide this. We're fine with this. mpv-android/mpv-android#112
* encode: do not clear video PTS on VOCTRL_RESETwm42018-04-291-8/+0
| | | | | | | | | | | | | | This was supposed to be a replacement for encode_lavc_discontinuity() (so we don't need to store last_video_in_pts in a way which requires synchronization). Unfortunately, VOCTRL_RESET is also called before termination, and even though it shouldn't matter as far as the VO API is concerned, it does. It's because vo_lavc.c buffers a frame to compute the frame duration. Drop this code. The consequence is that it appears to encode 2 frames with the same PTS if multiple files are encoded into one. Before this, it merely dropped a frame (maybe the first of every subsequent file, not sure).
* egl_helpers: log certain EGL attributeswm42018-04-291-0/+38
| | | | Might be helpful with broken EGL implementations.
* encode: rewrite half of itwm42018-04-291-198/+114
| | | | | | | | | | | | | The main change is that we wait with opening the muxer ("writing headers") until we have data from all streams. This fixes race conditions at init due to broken assumptions in the old code. This also changes a lot of other stuff. I found and fixed a few API violations (often things for which better mechanisms were invented, and the old ones are not valid anymore). I try to get away from the public mutex and shared fields in encode_lavc_context. For now it's still needed for some timestamp-related fields, but most are gone. It also removes some bad code duplication between audio and video paths.
* vo: add vo_reconfig2()wm42018-04-292-3/+26
| | | | | | 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.
* video: remove internal stereo_out flagwm42018-04-294-19/+10
| | | | | | Also rename stereo3d to stereo_in. The only real change is that the vo_gpu OSD code now uses the actual stereo 3D mode, instead of the --video-steroe-mode value. (Why does this vo_gpu code even exist?)
* client API: add some render API extensions for timingwm42018-04-291-24/+68
| | | | | | | | | | | | Attempts to enable the following things: - let a render API user do "proper" audio-sync video timing itself - make it possible to not re-render repeated frames if the API user has better mechanisms available (e.g. waiting for a DisplayLink cycle instead) - allow the user to delay or skip redraws if it makes sense Basically this information will be needed by API users who want to be "clever" about optimizing timing and rendering.
* vo_libmpv: support GPU rendered screenshotswm42018-04-293-0/+45
| | | | | Like DR, this needed a lot of preparation, and here's the boring glue code that finally implements it.
* vo_libmpv: adjust redraw handling to new API semanticswm42018-04-291-12/+4
| | | | | | | | | | | | | | | | | In MPV_RENDER_PARAM_ADVANCED_CONTROL mode, a simple update callback does not necessarily make the API user redraw. So handle it differently. For one, setting vo->want_redraw already uses the "normal" redraw path, which will call draw_frame() and set next_frame. Then there are redraws trigered by mpv_render_context_set_parameter(), which are on the render thread, and would require a separate mechanism. I decided this is not really a good idea, since it's not even clear that setting an arbitrary parameter should redraw. Also this could trigger an unbounded number of redraws. The user can trigger redraws manually if really needed, depending on the parameter that's being set. If we really wanted vo_libmpv to do this, we could add a new flag like need_redraw, which would be 4 lines of code or so.
* vo_libmpv: remove annoying indirectionswm42018-04-291-71/+80
| | | | I think this is a bit more readable this way.
* vo_libmpv: move some update() callbacks out of context lockwm42018-04-291-3/+3
| | | | | | | | update() used to require the lock, but now it doesn't matter. It's slightly better to do it outside of the lock now, in case the update callback reschedules before returning, and the user render thread tries to acquire the still held lock (which would require 2 more context switches).
* vo_libmpv: move up update() functionwm42018-04-291-14/+12
| | | | Avoids a forward declaration.
* vo_libmpv: add support for DRwm42018-04-293-0/+38
| | | | | With all the preparation work done, this only has to do the annoying dance of passing it through all the damn layers.
* client API: preparations for allowing render API to use DR etc.wm42018-04-292-22/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | DR (letting the decoder allocate texture memory) requires running the allocation on the render thread. This is rather hard with the render API, because the user controls this thread and when it's entered. It was not possible until now. This commit adds a bunch of infrastructure to make this possible. We add a new optional mode (MPV_RENDER_PARAM_ADVANCED_CONTROL) which basically lets the user's render thread and libmpv agree how this should be done. Misuse would lead to deadlocks. To make this less likely, strictly document thread safety/locking issues. In particular, document which libmpv functions can be called without issues. (The rest has to be assumed unsafe.) The worst issue is destruction of the render context while video is still active. To avoid certain unintended recursive locks (i.e. deadlocks, unless we'd make the locks recursive), make the update callback lock separate. Make "killing" the video chain asynchronous, so we can do extra work while video is being destroyed. Because losing wakeups is a big deal, setting the update callback now triggers a wakeup. (It would have been better if the wakeup callback were a parameter to mpv_render_context_create(), but too late.) This commit does not add DR yet; the following commit does this.
* vo: move DR helper code to a separate source filewm42018-04-294-91/+183
| | | | | So it can be reused by vo_libmpv.c, which needs to use it in a slightly different way.
* mp_image: fixup a simple 10L in ref_bufferJan Ekström2018-04-211-1/+1
| | | | | We didn't want to set the pointer to zero, but the value that the pointer was pointing towards.
* vo_gpu: move some extra code for screenshot to video.cwm42018-04-202-13/+15
| | | | | This also happens to fix some UB on the error path (target being declared after the first "goto done;").
* encode: simplify colorspace settingwm42018-04-201-3/+2
| | | | | This was also refactored at some point, and is now unnecessarily roundabout.
* encode: cosmeticswm42018-04-201-35/+30
| | | | Mostly whitespace changes; some semantic preserving transformations.
* vo_lavc: remove pointless uint32_t type for int valueswm42018-04-201-7/+2
| | | | | params->w/h are int, and the further use of these variables are int. The uint32_t is probably some refactoring artifact.
* video: pass through container fps to filterswm42018-04-193-6/+7
| | | | | | | | | | | | This means vf_vapoursynth doesn't need a hack to work around the filter code, and libavfilter filters now actually get the frame_rate field on input pads set. The libavfilter doxygen says the frame_rate field is only to be set if the frame rate is known to be constant, and uses the word "must" (which probably means they really mean it?) - but ffmpeg.c sets the field to mere guesses anyway, and it looks like this normally won't lead to problems.
* w32_common: avoid recursive dispatch queue callswm42018-04-181-1/+6
| | | | | | | | I suppose this doesn't matter in practice, i.e. even if calls relayed over the dispatch queue will cause WndProc to be invoked, WndProc will never run for a longer time. Preparation for removing recursion support from the dispatch queue code.
* hwdec_ios: fix crash after mapper_init failureAman Gupta2018-04-171-2/+4
|
* client API: clarify that Display pointers etc. need to stay validwm42018-04-161-6/+21
| | | | | | | | | | | | Normally, MPV_RENDER_PARAM* arguments are copied, unless documented otherwise. Of course we can't copy X11 Display or Wayland wl_display types, but for arguments that are "summarized" in a struct (like MPV_RENDER_PARAM_OPENGL_FBO), a copy is expected. Also add some unused infrastructure to make this explicit, and to make it easier to add parameter types that require a copy. Untested.
* vo_gpu: hwdec: Use ffnvcodec to load CUDA symbolsPhilip Langdale2018-04-153-244/+45
| | | | | | The CUDA dynamic loader was broken out of ffmpeg into its own repo and package. This gives us an opportunity to re-use it in mpv and remove our custom loader logic.
* opengl: include details in EGL context errorsAman Gupta2018-04-121-3/+3
|
* video: remove libavutil PSEUDOPAL stuffwm42018-04-032-5/+2
| | | | Not needed anymore with newest libavutil.
* vaapi: add option to select a non-default device pathRostislav Pehlivanov2018-03-301-27/+46
| | | | | | | | | | | On machines with multiple GPUs, /dev/dri/renderD128 isn't guaranteed to point to a valid vaapi device. This just adds the option to specify what path to use. The old fallback /dev/dri/card0 is gone but that's not a loss as its a legacy interface no longer accepted as valid by libva. Fixes #4320
* client API: add a new way to pass X11 Display etc. to render APIwm42018-03-2618-86/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hardware decoding things often need access to additional handles from the windowing system, such as the X11 or Wayland display when using vaapi. The opengl-cb had nothing dedicated for this, and used the weird GL_MP_MPGetNativeDisplay GL extension (which was mpv specific and not officially registered with OpenGL). This was awkward, and a pain due to having to emulate GL context behavior (like needing a TLS variable to store context for the pseudo GL extension function). In addition (and not inherently due to this), we could pass only one resource from mpv builtin context backends to hwdecs. It was also all GL specific. Replace this with a newer mechanism. It works for all RA backends, not just GL. the API user can explicitly pass the objects at init time via mpv_render_context_create(). Multiple resources are naturally possible. The API uses MPV_RENDER_PARAM_* defines, but internally we use strings. This is done for 2 reasons: 1. trying to leave libmpv and internal mechanisms decoupled, 2. not having to add public API for some of the internal resource types (especially D3D/GL interop stuff). To remain sane, drop support for obscure half-working opengl-cb things, like the DRM interop (was missing necessary things), the RPI window thing (nobody used it), and obscure D3D interop things (not needed with ANGLE, others were undocumented). In order not to break ABI and the C API, we don't remove the associated structs from opengl_cb.h. The parts which are still needed (in particular DRM interop) needs to be ported to the render API.
* cocoa-cb: render on a dedicated dispatch queueAkemi2018-03-253-28/+36
| | | | | | | | | | | we rendered on the displaylink thread which wasn't the best idea. if rendering took too long or was blocking it also blocked the displaylink callback. when that happened new vsyncs were reported delayed or not at all. consequently the mpv_render_context_report_swap function wasn't called consistently and that could cause bad video playback. so the rendering is moved to a dedicated dispatch queue. furthermore the update callback starts a layer update directly instead of the displaylink callback, making the rendering a bit more consistent.
* drm/atomic: ensure request is available until uninitLongChair2018-03-231-3/+14
| | | | | | | | | | Right now the atomic request is alive during the renderloop. We want it to be alive until the drm egl context is destroyed because some properties might still be set upon interop close This patch make the request to be kept created even outside the renderloop. The context uninit will commit the last request.
* cocoa-cb: fix shutdown when fullscreen animation is runningAkemi2018-03-182-7/+17
| | | | | | | | commit 2edf00f changed the MPV_EVENT_SHUTDOWN behaviour slightly, such that it will only be sent once. cocoa-cb relied on it being sent continuously till all mpv_handles are destroyed. now it manually shuts down and destroys the mpv_handle after the animation instead of relying on this removed behaviour.
* vo_gpu: fix anamorphic video screenshots (second try)wm42018-03-161-3/+4
| | | | | | | | | | | | | | This passed the display size as source size to the renderer, which is of course nonsense. I don't know what I was doing in 569383bc54. Yet another fix for those damn anamorphic videos. As a somewhat redundant/cosmetic change, use image_params instead of real_image_params in the code above. They should have the same, dimensions (but possibly different formats when doing hw decdoing), and mixing them is confusing. p->image_params wins because it's shorter. Actually fixes #5619.
* img_format.h: cosmetics: fix whitespacewm42018-03-151-1/+1
|
* vo: pass through framedrop flag differentlywm42018-03-152-5/+3
| | | | | | | | 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
|
* vo_gpu: fix anamorphic screenshotswm42018-03-151-2/+2
| | | | | | | | | | | We took the storage size instead of the display size for "unscaled" screenshots. Even if it's called "unscaled", it's still supposed to scale to compensate for aspect ratio. (How many commits fixing anamorphic screenshots in various situations are there?) Fixes #5619.
* mp_image: fix UB with certain callers like vf_vdpauppwm42018-03-151-0/+4
| | | | | | | | | | | | | | | | | | | vf_vdpaupp crashed on certain files (with --hwdec=vdpau --deinterlace). This happened for example with mpeg2 files, which for some reason typically contain some AVFrame side data. It turns out the last change in 55c88fdb8f1a9269 was not quite clean, and forgot the special cases in mp_image_new_dummy_ref(). This function is supposed to copy all metadata from the argument passed, except buffer refs. But there were new buffer refs, that were not cleared properly. Also, the ff_side_data pointer must be cleared, or the new mp_image would try to free it on destruction. The bottom line is that mp_image_new_dummy_ref() is a pretty bad idea, and I suppose all callers with non-NULL arguments should be changed to create a blank mp_image, and copy frame properties as needed (this includes callers of mp_image