summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* vo_drm: 30bpp supportAnton Kindestam2019-09-223-13/+58
|
* manpage: update requirements for vdpau hwdec useNicolas F2019-09-221-1/+2
| | | | | | | | | | We default to EGL instead of GLX now, which means vdpau only works if we explicitly specify that we want a GLX context, as vdpau lacks interop for EGL. Update the hwdec documentation to reflect this. Concerns #6980.
* vo_gpu: d3d11: add support for presentation feedbackJames Ross-Gowan2019-09-221-0/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds vsync reporting to the D3D11 backend using the presentation feedback provided by DXGI, which is pretty similar to what's provided by GLX_OML_sync_control in the GLX backend. In DirectX, PresentCount is the SBC, PresentRefreshCount and SyncRefreshCount are kind of like the MSC and SyncQPCTime is the UST. Unlike GLX, the DXGI API makes it possible for PresentCount and SyncQPCTime to refer to different physical vsyncs, in which case PresentRefreshCount and SyncRefreshCount will be different. The code supports this possibility, even though it's not clear whether it can happen when using flip-model presentation. The docs say for flip-model apps, PresentRefreshCount is equal to SyncRefreshCount "when the app presents on every vsync," but on my hardware, they're always equal, even when mpv misses a vsync. They can definitely be different in exclusive fullscreen bitblt mode, though, which mpv doesn't support now, but might support in future. Another difference to GLX is that, at least on my hardware, PresentRefreshCount and SyncRefreshCount always refer to the last physical vsync on which mpv presented a frame, but glxGetSyncValues can apparently return a MSC and UST from the most recent physical vsync, even if mpv didn't present a new frame on it. This might result in different behaviour between the two backends after dropped frames or brief pauses. Also note, the docs for the DXGI presentation feedback APIs are pretty awful, even by Microsoft standards. In particular the docs for DXGI_FRAME_STATISTICS are misleading (PresentCount really is the number of times Present() has been called for that frame, not "the running total count of times that an image was presented to the monitor since the computer booted.") For good documentation, try these: https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/dxgi-flip-model https://docs.microsoft.com/en-us/windows/win32/direct3d9/d3dpresentstats https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/d3dkmthk/ns-d3dkmthk-_d3dkmt_present_stats (Yeah, the docs for the D3D9Ex and even the kernel-mode version of this structure are better than the DXGI ones. It seems possible that they're all rewordings of the same internal Microsoft docs, but whoever wrote the DXGI one didn't really understand it.)
* command: add expand-path to expand mpv pathsNicolas F2019-09-222-0/+24
| | | | | | | The question came up on how a client would figure out where screenshot-directory saved its screenshots if it contained mpv-specific expansions. This command should remedy the situation by providing a way for the client to ask mpv to do an expansion.
* build: actually detect supported warning optionsAvi Halachmi (:avih)2019-09-221-2/+2
| | | | | | | | | | | | | Previously the options were tested by compiling a test program with the option, and support was "detected" if the compilation didn't fail. However, both gcc and clang only issue a warning on unknown warning option, hence it never failed and all the warn options were detected as supported. Now the tested option is used together with -Werror, which makes it fail if it warns that the warning option is unknown. Fixes clang unknown option warnings -Wno-format-truncation since 4a6b56f .
* command: add sub-start & sub-end propertiesStefano Pigozzi2019-09-228-7/+140
| | | | | These properties contain the current subtitle's start and end times. Can be useful to cut sample audio through the scripting interface.
* wayland: create current_output in wayland_reconfigdudemanguy2019-09-221-5/+6
| | | | | | | | Certain mpv config options require wl->current_output to be created before the video can actually start rendering. Just always create it here if the current_output doesn't exist (the one exception being the --fs option with no --fs-screen flag). Incidentally, this also fixes --fs-screen not working on wayland.
* wscript: Fix test for ffmpeg drmprime supportPhilip Langdale2019-09-221-2/+9
| | | | | | | This test requires libavutil headers but there is no avutil dependency for it to use. So let's add one, and also reorder the ffmpeg tests ahead of the video tests so that the avutil dependency can be used.
* vf_fingerprint: remove extraneous single quote from descriptionJan Ekström2019-09-211-1/+1
| | | | | | This happened to break ZSH completion and seemed to be extraneous. Reported by LaserEyess on IRC.
* test/linked_list: silence nonsense warningswm42019-09-211-6/+12
| | | | | | | | | | ../misc/linked_list.h:71:34: warning: the address of ‘e6’ will always evaluate as ‘true’ [-Waddress] No shit, e6 is on the stack. But the macro argument is also allowed to be NULL. Add some dumb nonsense to shut up the useless warning. (It's probably useful in other contexts though, so don't disable it completely.)
* test: fix cmocka assert_float_equal shadowing warningswm42019-09-213-9/+6
| | | | | | | | | Just use cmocka's function. It takes an epsilon argument, which we now provide directly. There's no assert_double_equal() in cmocka (and the float variant actually forces a conversion to the float type), but fortunately we didn't use it.
* stream_dvb: remove unused variablewm42019-09-211-1/+0
| | | | | | (At first I left this intentionally, because the temporarily disabled stream ctrl code used it, but there's actually no reason to annoy everyone with the warning.)
* waf: fix wayland-scanner deprecation warningdudemanguy2019-09-212-3/+3
| | | | | | Use `private-code` instead of `code` here. Also this bumps up the required wayland-client/wayland-cursor version to 1.15 which is still pretty old anyway.
* audio: fix use-after-free with fuzzed filewm42019-09-211-0/+2
| | | | | | | | | reinit_audio_filters_and_output() can fully shutdown the audio chain on failure. Specifically, it will deallocate mpctx->ao_chain. The value of that field was cached in ao_c. The code after the call did not account that the audio chain can be shutdown, and used the stale ao_c value. Fixes: #6808
* sub/lavc_conv: skip ReadOrder reset when subtitle decoder gets flushedJan Ekström2019-09-211-0/+1
| | | | | | | | | | | During initial testing with US closed captions, ARIB captions, timed text in MP4 or the specific external SRT files I tested with there were no hints that this flag would be needed for seeking to work. Unfortunately, that result seems to have been incorrect. Fixes #6970
* dec_sub: remove unused declarationwm42019-09-211-1/+0
|
* input: add keybind commandDudemanguy9112019-09-214-0/+65
|
* playloop: don't read playback pos from byte streamDudemanguy9112019-09-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a file format supports PTS resets, get_current_pos_ratio calculates the ratio using the stored filepos in the demuxer struct instead of a standard query of the current time in the stream and its total length. This seems like a reasonable way to avoid weird PTS values, but in reality this just causes problems and results in inaccurate ratio values that can affect other parts of the player (most notably the osc seekbar). For libavformat formats, demux->filepos is obtained from the demux_lavf_fill_buffer function which is called on the next packet. The problem is that there is a slight delay between packets and in some cases, this delay can be relatively large. That means the obtained demuxer->filepos value will be very inaccurate since it obtains the pos from the end of the upcoming packet and not its actual current position. This is especially noticeable at the very beginning of playback where get_current_pos_ratio sometimes returns a value of well over 2% despite less than a second passing in the stream. Another telltale sign is to simply watch the osc seekbar as a stream progresses and observe how it loads in staggered steps as every packet is decoded. In contrast, the seekbar progresses smoothly on the playback of a format that does not support PTS resets. The simple solution is to instead use the query of the current time and length of a stream and calculate the ratio that way. get_current_pos_ratio will still fallback on using the byte stream position if the previous queries fail. However, get_current_time will be more accurate in the vast majority of cases and should be the preferred method of calculating the position ratio.
* wayland: avoid handling a 0-value axis eventDudemanguy9112019-09-211-0/+2
| | | | This shouldn't be possible, but an extra check never hurts.
* player: expose pixel aspect ratio, bitrate and rotation value on trackswnoun2019-09-213-0/+21
|
* DOCS/contribute.md: expand on recommended C99 usagewm42019-09-211-1/+1
|
* build: don't add swift object when swift disabledder richter2019-09-211-2/+6
|
* wayland: read xcursor size from XCURSOR_SIZE envemersion2019-09-211-1/+13
| | | | | This allows compositors to set the cursor size from user configuration.
* player: use track title if exists instead of filenamethewisenerd2019-09-211-1/+5
|
* input: ignore empty lines on drag-drop mime datathewisenerd2019-09-211-1/+1
| | | | do not outright err and quit the player for this
* ao_oss: Fallback to stereo when the device does not support >2 channelsLeonardo Taccari2019-09-211-6/+10
| | | | | | | | ioctl(..., SNDCTL_DSP_CHANNELS, &nchannels) for not supported nchannels does not return an error and instead set nchannels to the default value. Instead of failing with no audio, fallback to stereo.
* osd: allow sub-text to work even if sub-visibility is disableddudemanguy2019-09-213-5/+5
|
* x11: fix ICC profiling for multiple monitorsslatchurie2019-09-212-2/+22
| | | | | | | | | To find the correct ICC profile X atom, the screen number was calculated directly from the xrandr order of the screens. But if a primary screen is set, it should be the first Xinerama screen, even if it is not the first xrandr screen. Calculate the the proper atom id for each screen.
* osc: add mouse mid-button as alias to shift+left buttonRicardo Constantino2019-09-211-0/+3
|
* wayland: don't show cursor when fullscreeningdudemanguy2019-09-212-0/+7
|
* wayland: reconfigure cursor on pointer enter eventThomas Weißschuh2019-09-212-1/+4
| | | | | | | | | | | | | | | | | | | | | On wayland the cursor has to be configured each time the pointer enters. Currently if the window (re)gains the focus, the pointer is not hidden, even when configured. After the mouse has been moved the pointer hides correctly. https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_pointer: wl_pointer::enter - enter event ... When a seat's focus enters a surface, the pointer image is undefined and a client should respond to this event by setting an appropriate pointer image with the set_cursor request. Fixes #6185. Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
* demux_cue: auto-detect CUE sheet charsetwnoun2019-09-215-0/+38
|
* command: add video-add/video-remove/video-reload commandsPaul B Mahol2019-09-212-0/+30
|
* wayland: add mouse buttons and fix axis scalingdudemanguy2019-09-211-4/+24
| | | | | | | | | | Previously, the only mouse buttons supported in wayland were left, right, and middle click. This adds the thumb back/forward buttons as valid bindings. Also it removes the old, default behavior of always sending a right click if an unrecognized mouse button is clicked. In a related but different fix, the magnitude of an axis event in wayland is not important to mpv since it internally handles all scaling. The only thing we care about is getting the sign when the event occurs.
* client API: add mpv_command_retDark2019-09-213-0/+26
| | | | | | | | | | This change adds a version of `mpv_command` that also returns a result. The main rationale behind this is `mpv_command_node` requires defining multiple structs before you can even use it, which results in a pretty painful to use interface just to get the result from a command. There isn't really a good name for this function, so I'm open to suggestions on a better name for it.
* DOCS/contribute.md: license clarificationswm42019-09-212-0/+6
| | | | | | | | | Basically, both the license of the file and the preferred license of the project (LGPLv2.1+) counts. I'm doing that so that files with more liberal licenses don't get infected by LGPL, but allow copy & pasting to LGPL source files without jumping through lawyer bullshit hoops. Mention this in Copyright too.
* github: remove LGPL relicensing boilerplatewm42019-09-211-3/+2
| | | | | | Most files are LGPL anyway by now. contribute.md still requires contributors to provide changes under LGPL, which should cover changes to files that are LGPL, as well as GPL files.
* vo_sdl: Only create the SDL window onceCameron Cawley2019-09-211-54/+23
|
* ao_pulse: add --pulse-allow-suspendedTérence Clastres2019-09-212-1/+7
| | | | | | | | | | This flag makes mpv continue using the PulseAudio driver even if the sink is suspended. This can be useful if JACK is running with PulseAudio in bridge mode and the sink-input assigned to mpv is the one JACK controls, thus being suspended. By forcing mpv to still use PulseAudio in this case, the user can now adjust the sink to an unsuspended one.
* stream_libarchive: Always use LC_CTYPE_MASK for libarchiveJames Hilliard2019-09-212-2/+1
| | | | | | Using LC_ALL_MASK is unnecessary and unreliable on some systems. Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
* command: drop removed cache properties from cache update eventswm42019-09-201-2/+2
| | | | These did nothing anymore, maybe made it slightly slower.
* player: update status line cache displaywm42019-09-202-7/+5
| | | | | | | | | | | Replace the "+" with "/". The "+" was supposed to imply that the cache is the sum of the time (demuxer cache) and the size in bytes (stream cache). We could not provide something nicer, because we had no idea how many seconds of media was buffered in the stream cache. Now the stream cache is done, and both the duration and byte size show the amount buffered in the demuxer cache. Hopefully "/" is better to imply this properly. Update the manpage explanations too.
* context_drm_egl: Use eglGetPlatformDisplayEXT if availablememeka2019-09-201-1/+20
| | | | | | | | Check if eglGetPlatformDisplayEXT is available and try to use it to obtain the display connection. Fall back to eglGetDisplay if eglGetPlatformDisplayEXT is not available or failing. From PR #5992
* client API: fix missing property change events after property updatesGunnar Marten2019-09-201-24/+28
| | | | | | | | | | | | | | | | | | | | | | | | | When update_prop() successfully fetched a changed property value, it set prop->changed to true to indicate the success. mark_property_changed() also always set prop->changed to true and additionally prop->need_new_value to true This is the case since 6ac0ef78 If the observed property changes every frame and then due to timing the next mark_property_changed() is called before gen_property_change_event() and therefore directly after update_prop(), prop->need_new_value was again true and indicated that a new value has to be retrieved with update_prop(). As a result the event for the last successful update_prop() was never triggered. This meant that a property change event were never generated for frame-based properties only for properties that were observed with MPV_FORMAT_NONE or when the timing was different and gen_property_change_event() was called after update_prop(). To fix this, mark_property_change() and update_prop() should not use the same flag to indicate different things and therefore a new flag for successfully update a property is introduced. But with the now decoupled property changed and updated the need_new_value flag is redundant and removed completely. Fixes #4195
* loadfile: restore playlist prefetchingwm42019-09-201-4/+11
| | | | | | | | | | | | | | | | | | | | | | | With the stream cache gone, this function had almost no use anymore (other than opening the stream). Improve this by triggering demuxer cache readahead. This enables all streams. At this point we can't know yet what streams the user's options would select (at least not without great additional effort). Generally this is what you want, and the stream cache would have read the same amount of data. In addition, this will work much better for files that e.g. need to seek to the end when opening (typically mp4, and mkv files produced by newer mkvmerge versions). Remove the deselection call from add_stream_track(). This should be fine, as streams normally start out as deselected anyway. In the prefetch case, some code in play_current_file() actually deselects it. Streams that appear during demuxing are disabled by default, so this doesn't break this logic either. Fixes: #6753
* demux: propagate streaming flag through demux_timelinewm42019-09-203-3/+10
| | | | | | | | | | | | | | Before this commit, EDL or CUE files did not properly enable the cache if they were on "slow" media (stream->streaming==true). This happened because the stream is unset for demux_timeline, so the streaming flag could not be queried anymore. Fix this by adding this flag to struct demuxer, and propagate it exactly like the is_network flag. is_network is not used for checking the cache options anymore, and its main function seems to be something else. Normal http streams set the streaming flag already. This should fix #6958.
* client API, vo_libmpv: document random deadlock problemswm42019-09-202-0/+20
| | | | | | | I guess trying to make DR work on libmpv was a mistake. I never observed such a deadlock, but it's looks like it's theoretically possible.
* vo_libmpv: fix some more uninit issueswm42019-09-201-24/+35
| | | | | | | | | | | | | | | | | | | | | | This is mostly for the case when mpv_render_context_free() is called while video is going on. This is supposed to gracefully stop video and deinitialize everything properly. (I feel like it would put too much on the API user to require that video is stopped before calling this function. Whether video is running or not is a fairly highlevel thing, and the API user could not do it in a race-free way.) One problem was that unit() accessed ctx after ctx->in_use was set to false. The update(ctx) call was basically a racy use-after-free. It needed that call to wake up the mpv_render_context_free() loop that waited for VO uninit. Fix this by triggering the wakeup inside the lock, and then doing "barrier" locking in mpv_render_context_free(). Another problem was that the wait loop didn't really wait properly. IT seems the had_kill_update field was a botched attempt to do that. It's indeed quite hairy to do that with update(). Instead make use of the dispatch queue (infinite timeout, using mp_dispatch_interrupt()), which handles the problem of having to wait both for dispatch queue updates and VO uninit at the same time.
* client API: document unfortunate render API threading requirementwm42019-09-201-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is because dr_helper.c calls pthread_self(). It's used to avoid deadlocks. This was not a problem internal to mpv (dr_helper.c was first created for vo_gpu.c), but it accidentally leaked as an unintended consequence of an implementation detail to libmpv. This problem existed for MPV_RENDER_PARAM_ADVANCED_CONTROL users, ever since it was introduced. Maybe this could be done differently, but it's certainly very tricky. the pthread_t is used to avoid deadlocks when the caller is on the same thread as the one which needs to handle the calls. The critical code is in free_dr_buffer_on_dr_thread(). It's called when a DR image is free'd. Freeing a DR image requires access to the GL context, i.e. it just has to run on the "GL" thread. In libmpv's case, this is done by calling the API user's wakeup call, and the user will eventually call mpv_render_context_update() on the "GL" thread, which in turn calls mp_dispatch_queue_process() on the dispatch queue that was passed to dr_helper_create(), which then calls av_buffer_unref(), which calls gl_video_dr_free_buffer(). (God who came up with this rube goldberg shit.) The above case will typically happen when e.g. vd_lavc.c (internal mpv thread) frees images. Allocation works similarly; deallocation is just trickier because calls to free images are everywhere. Now consider if mpv_render_context_render() releases a DR image. This function is always called on the "GL" thread. Going through the dispatch queue would obviously deadlock, because according to the render API rules, the user's wakeup callback must not mpv_render_context_update(), instead it has to signal the "GL" thread, which must wait until mpv_render_context_render() returns. To avoid this deadlock, dr_helper.c checks whether the calling thread is the "GL" thread, and if so, allows a reentrant call (basically gl_video_dr_free_buffer() is called directly). While with GL, you usually will stay on the same thread, API users were in theory allowed to e.g. move the GL context to a different thread. But this dr_helper issue means this is not possible. Moreover, other APIs will not have the same thread-locality problems as GL. FUCK THIS SHIT In theory, libmpv could provide an API to "move" the context to a separate thread, but let's not start with even more broken crap like this. I'm not sure yet whether there is an easy solution. Maybe all mpv_render() function could be guarded by entry/exit functions, which set/unset a flag that dr_helper.c should use reentrant calls. libmpv users which do not set MPV_RENDER_PARAM_ADVANCED_CONTROL were never affected.
* vo_libmpv: always create ctx->dispatchwm42019-09-201-19/+12
| | | | | | | | Preparation for the next commit. Until now, it was only needed if DR was involved. One reason for not always creating it was that you normally must not use it if advanced_control is not enabled. This is why e.g. VOCTRL_SCREENSHOT now checks for that variable; it still can't use ctx->dispatch if the render API user did not enable it.
* render api: fix use-after-freewnoun2019-09-203-33/+6
| | | | | | | | render api needs to wait for vo to be destroyed before frees the context. The purpose of kill_cb is to wake up render api after vo is destroyed, but uninit did that before kill_cb, so kill_cb tries using the freed memory. Remove kill_cb to fix the issue as uninit is able to do the work.
* rpi: Update for modern systemsCameron Cawley2019-09-205-25/+14
|
* Coypright: update list of fileswm42019-09-201-13/+1
|
* vo: remove unused equalizer control remainswm42019-09-201-14/+1
| | | | | | | | | | Equalizer control was redone in 03cf150ff3516789d5812 (over 2 years ago). Ever since, the equalizer control structs and the GET voctrl have been unused. Only the SET voctrl is still used as notification mechanism (actually a bad hack to avoid some further option change handling complexity). Remove the unused parts.
* oml_sync: fix typo in commentwm42019-09-201-2/+2
| | | | I think... Also reword another part of th