summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* video: actually wait for last frame being rendered on EOFwm42018-05-031-1/+5
| | | | | | | | | | | | | | | | | | | The video timing code could just decide that EOF was reached before it was displayed. This is not really a problem for normal playback (if you use something like --keep-open it'd show the last frame anyway, otherwise it'd at best flash it on screen before destroying the window). But in encode mode, it really matters, and makes the difference between having one frame more or less in the output file. Fix this by waiting for the VO before starting the real EOF. vo_is_ready_for_frame() is normally used to determine when the VO frame queue has enough space to send a new frame. Since the VO frame queue is currently at most 1 frame, it being signaled means the remaining frame was consumed and thus sent to the VO driver. If it returns false, it will wake up the playloop as soon as the state changes. I also considered using vo_still_displaying(), but it's not reliable, because it checks the realtime of the frame end display time.
* encode: remove old timestamp handlingwm42018-05-037-291/+57
| | | | | This effectively makes --ocopyts the default. The --ocopyts option itself is also removed, because it's redundant.
* encode: restore 2-pass modewm42018-05-031-2/+7
| | | | | | | | | | While I'm not sure whether it really works, at least it writes the pass1 log correctly now. How 2-pass stat output is supposed to interact with the new decode API is rather fishy. ffmpeg.c does the same, and before this change, the log was not written on EOF (when at least libvpx actually outputs its stats).
* manpage: -pre, -del etc. does not work on some options anymorewm42018-05-031-25/+4
| | | | | | With the internal change from stringlist to keyvaluelist, these sub-options stop working. I don't really care enough to bring them back. (Order doesn't matter, -del always seemed annoying.)
* docs/vo: fixup some minor typos a la "planed" instead of "plane"Jan Ekström2018-05-011-3/+3
|
* 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-018-55/+103
| | | | | | | | 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-016-4/+38
| | | | | | | | | | 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-018-35/+113
| | | | | | | | | | | | | | | | | 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.
* manpage: remove 4 previously removed optionswm42018-05-011-24/+0
| | | | The manpage parts were forgotten when removing the options.
* manpage: --demuxer-seekable-cache is not experimental anymorewm42018-05-011-2/+1
| | | | | This seems to work surprisingly well, and it's enabled by default (unlike the old text claims).
* common: add missing %f time formatwm42018-05-011-0/+1
| | | | | | | | It was documented for --screenshot-template, but apparently never implemented. This value is not explicitly rounded, other than for printf() %f default formatting (which rounds to 6 digits).
* common: round all integer times to millisecondswm42018-05-011-2/+6
| | | | | | | | | This means that a time of 4.5678 is displayed as "00:00:04.568" when the format string is "%H:%M:%S.%T". Likewise, 59.99999 will be displayed as "00:01:00.000". Before this change, the sub-ms times were just truncated. Requested by TheAMM.
* cocoa: change deprecation warning from opengl-cb to libmpvAkemi2018-04-292-3/+3
|
* build: bump wayland-protocols requirement to 1.12+Jan Ekström2018-04-291-1/+1
| | | | The stable xdg-shell protocol is only available from this version.
* wayland_common: update to stable xdg-shellEmmanuel Gil Peyrot2018-04-293-52/+52
| | | | | 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.
* command: change cycle-value command behaviorwm42018-04-294-87/+97
| | | | | | | | | | | | | | | | | | | | Instead of using an internal counter to keep track of the value that was set last, attempt to find the current value of the property/option in the value list, and then set the next value in the list. There are some potential problems. If a property refuses to accept a specific value, the cycle-values command will fail, and start from the same position again. It can't know that it's supposed to skip the next value. The same can happen to properties which behave "strangely", such as the "aspect" property, which will return the current aspect if you write "-1" to it. As a consequence, cycle-values can appear to get "stuck". I still think the new behavior is what users expect more, and which is generally more useful. We won't restore the ability to get the old behavior, unless we decide to revert this commit entirely. Fixes #5772, and hopefully other complaints.
* command: make track properties cycle through no/auto if uninitializedwm42018-04-291-9/+18
| | | | | | | | | | | | | If playback has not been initialized yet (decoders not initialized etc.), or if in idle mode, let the track properties cycle through "no" and "auto". This should be slightly more helpful than making it simply exit. Depending on the stage of loading, more could be done. For example, if youtube-dl loads additional subtitle files, it can happen that these get added before the main file, and this could be cycled through to an extent. This is probably too clever, and also sort of dangerous (unintended interactions with messy in-loading state), so don't do it.
* command: fix coding stylewm42018-04-291-5/+6
| | | | Add {...}, change if(!a) to if(a) and swap its if/else body.
* vd_lavc: enable dr by defaultwm42018-04-292-7/+5
| | | | | 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.
* f_lavfi: support setting common filter options like "threads"wm42018-04-293-3/+12
| | | | | | | | | AVFilterContext instances support some additional AVOptions over the actual filter. This includes useful options like "threads". We didn't support setting those for the "direct" wrapper (--vf=yadif:threads=1 failed). Change this. It requires setting options on the AVFilterContext directly, except the code for positional parameters still needs to access the actual filter's AVOptions.
* client API: some doxygen clarificationswm42018-04-291-0/+11
| | | | | | | Strictly speaking redundant, but probably helpful. In particular I want to push MPV_RENDER_PARAM_ADVANCED_CONTROL. Not enabling this parameter is actually not very sane.
* 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.
* player: don't wait for last video frame in encode modewm42018-04-291-0/+3
| | | | | This code makes the player wait using real time, which makes sense for normal playback, but not encode mode.
* TOOLS/matroska.py: ignore some unused elementswm42018-04-291-1/+3
| | | | So that demux_mkv doesn't log them as unknown.
* f_decoder_wrapper: fix a typo in log messagewm42018-04-291-1/+1
|
* input: raise log level of some noisy messageswm42018-04-291-7/+7
| | | | Same as the commit before this.
* demux_mkv: adjust log verbosity levelswm42018-04-292-40/+41
| | | | | | | | | With -v -v ("debug" level), which is the default for --log-file, this would log every damn Matroska EBML element and some other uninteresting things, which was very noisy. Adjust the log levels to make them less noisy. Also, change some log calls to MP_ERR for things which are actually errors.
* filter: hide warning when disconnecting pins drops frameswm42018-04-291-2/+2
| | | | | | | | | | Sometimes this hints that there's a bug, but sometimes it's normal. Since the code for --end/--frames puts frames that should not be shown anymore back into the pin, using those options will show this warning when playback ends. This is a minor annoyance. We could change how it's done (e.g. set an explicit flag somewhere), but that seems bothersome, so just change the message from warning to verbose.
* encode: rewrite half of itwm42018-04-2911-1114/+754
| | | | | | | | | | | | | 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-293-4/+27
| | | | | | 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.
* encode: get rid of AVDictionary setter helperwm42018-04-293-73/+19
| | | | | | | | | | | | Removes a good hunk of weird code. This loses qscale "emulation", some logging, and the fact that duplicate keys for values starting with +/- were added with AV_DICT_APPEND. I don't assign those any importance, even if they are user-visible changes. The new M_OPT_ flag is just so that nothing weird happens for other key-value options, which do not interpret a "help" key specially.
* encode: some more cleanupswm42018-04-294-32/+6
|
* f_output_chain: remove a redundant variablewm42018-04-291-4/+2
|
* options: remove broken --video-stereo-mode optionwm42018-04-293-4/+4
| | | | | See changelog for minor explanation. Basically, 3D is unused crap and nobody cares.
* video: remove internal stereo_out flagwm42018-04-296-24/+12
| | | | | | 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?)
* demux_lavf: discard "und" language tagwm42018-04-291-1/+1
| | | | | | | | | Going by ISO 639.2, "und" means "Undetermined". Whatever it's supposed to mean, in practice it's user for "unset". We prefer if the language tag remains simply unset in this case. This removes an ugliness with mp4 in partricular, because libavformat will export unset languages as such, which affects most mp4 files.
* f_output_chain: log status of auto filterswm42018-04-294-0/+48
| | | | | Just so users don't think the filters do anything when they don't insert any filters.
* f_output_chain: log input instead of output formatwm42018-04-291-44/+38
| | | | | | | I think this is more intuitive. This requires a dedicated "out" dummy filter. But keep the "in" dummy filter for symmetry, like in the old filter code. (We could remove the "in" dummy filter, because the first actual filter would still show the real input format.)
* client API: add some render API extensions for timingwm42018-04-294-29/+219
| | | | | | | | | | | | 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-298-30/+269
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-295-91/+184
| | | | | 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