summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* wayland: adjust hidden state detectiondudemanguy2019-12-101-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The wayland backend needs to keep track of whether or not a window is hidden for presentation time. There is no presentation feedback when a window is hidden which means we shouldn't be sending information to the vo_sync_info structure (i.e. just leave it all at -1). This seemed to work fine, but recent changes to presentation time in one notable compositor (Sway; it was probably always broken in Weston actually) changed the presentation time behavior. For reasons that aren't clear, there is a greater than 16.666ms delay between the first presentation time event and the second presentation time event (compositor latency?) when you switch back to an mpv window after it is hidden for long enough (a few seconds). When using presentation time, this causes mpv to feed in some bad values in its vsync timing mechanism thus causing the A/V desync spike as described in issue #7223. This solution is not really ideal. It would be better if the presentation time events received by the compositors did not have the aforementioned inconsistency. However since this occurs in both Sway and Weston and clients can't really fight compositors in wayland-world, here's a reasonable enough workaround. Basically, just add a slight delay before we start feeding information into the vo_sync_info again. We already do this when the window is hidden, so it's not a huge leap. The delay chosen here is arbitrary, and it basically just recycles the same parameters used to detect if a window is hidden. If vo_wayland_wait_frame times out 60 times in a row (or whatever your monitor's refresh rate is), then we assume the window is hidden. This is a pretty safe assumption; something has to be terribly wrong for you to miss 60 vblanks in a row while a window is on the screen. In this case, we basically just do the reverse of that. If mpv receives 60 frame callbacks in a row (or whatever your monitor's refresh rate is), then it assumes the window is not hidden. Previously, as soon as it received 1 frame callback it was declared not hidden. Essentially, there's just 1 second of delay after reshowing a window before the presentation time statistics are used again. This should be more than enough time to skip over the weird inconsistent behavior presentation time behavior and avoid the A/V desync spike. Fixes #7223
* osc: explicitly re-init the osc on a change in border visibilityPhilip Langdale2019-12-091-0/+1
| | | | | | | | | | | | | | I had previously wondered whether to do this, but in my testing with x11 and wayland, the osc was being re-inited on a border toggle already so I didn't add it. However, on win32, things are different and there is no re-init when toggling borders. I belive this is because the active window size doesn't change in anyway, while on x11/wayland, toggling the border actually changes the window size - and that trigger a re-init. So, let's just be explicit and request a re-init when the border is toggled.
* console.lua: add this scriptJames Ross-Gowan2019-12-0810-1/+822
| | | | | | | | | | | | | | | | | | | | | Merged from mpv-repl git repo commit 5ea2bf64f9c239f0326b02. Some changes were made on top of it: - Tabs were converted to 4 spaces indentation (plus some manual indentation fixes in some places). - All user-visible mentions of "repl" were renamed to "console". - The README was converted to a manpage (with heavy changes, some additions taken from stats.rst; rossy converted the key bindings table to RST). - The method to change the default key binding was changed. - Change minor detail about "font" default value setting (not a functional change). - Integrate into the player as builtin script, including an option to prevent loading it. Above changes and commit message done by wm4. Signed-off-by: wm4 <wm4@nowhere>
* vo_drm: replace drmModeAddFB usage with drmModeAddFB2Anton Kindestam2019-12-071-7/+13
| | | | | | drmModeAddFB is legacy, and might not pick the pixel format you expect, depending on your driver. Use drmModeAddFB2 which specifies this explicitly using a fourcc.
* drm: avoid division by 0 in drm_pflip_cb with bad driversAnton Kindestam2019-12-074-0/+12
| | | | | | | | | | | | | | Seems like some drivers only increment msc every other page flip when running in interlaced mode (I'm looking at you nouveau). I.e. it seems to be incremented at the frame rate, rather than the field rate. Obviously we can't work with this, so shame the driver and bail. On intel this isn't an issue, as msc is incremented at field rate there. This means presentation feedback won't work correctly in interlaced modes with those drivers, but who in their right mind uses an interlaced mode these days, anyway?
* drm_common: fix display FPS estimation for interlaced modessfan52019-12-071-1/+4
|
* vo_drm: fix potentially broken capability checksfan52019-12-071-2/+3
| | | | If the capability is available it may still be 0 to signal absence of support.
* drm_common: log more useful thingssfan52019-12-071-0/+18
|
* lua: make later key bindings always have higher prioritywm42019-12-071-2/+13
| | | | | | | | | | | | | | | | | | | Later calls to mp.add_key_binding() should take priority over previous calls with the same key. Until now, the order was random (due to using table pairs() iteration order). Do this by simply sorting by a counter that is never reset. Since input.c also gives later bindings priority, this works out. Calling mp.remove_key_binding() on a newer binding makes an older still existing binding with the same key active again. New bindings override older ones, but do not overwrite them. I think these are good semantics for most use cases. (Note that the Lua code cannot determine whether two bindings use the same key. Keys are strings, and two different strings could refer to the same key. The code does not have access to input.c's key name normalization, so it cannot compare them.)
* filters: move prefix check from f_lavfi.c to user_filters.cwm42019-12-072-6/+10
| | | | | | | | It's user_filters.c which allows the "lavfi-" prefix to distinguish libavfilter filters from mpv builtin filters. f_lavfi.c is a layer below, and strictly passes anything it gets to libavfilter. So the correct place for this is in user_filters.c, which also has the code for stripping the prefix in the normal filter instantiation code.
* vo_gpu: hwdec_vaapi_gl: use gl_check_extension() instead of strstr()wm42019-12-071-3/+3
| | | | | | | | | | | | In theory, using strstr() to search for extensions is a bad idea, because some extension names might be prefixes for other names, so you could get false positives. gl_check_extension() avoids this case. It's not clear whether this is really needed; maybe not. Surely the EGL committee is aware of these practices (many GL clients do this, which is why it's widely considered bad practice), and would avoid defining new extension names which contain existing names as sub-strings, but whatever.
* vo_gpu: hwdec_vaapi_gl: do not include eglext.hwm42019-12-071-9/+0
| | | | | | | Adding an ifdef mess to deal with insufficient system headers is kind of a mess. It's easier to just provide the definitions manually. This sucks a bit too, but it's the approach we've been using with OpenGL headers in general, and I think that worked pretty well.
* vo_gpu: hwdec_vaapi_gl: add missing PLANE3 defines as wellwm42019-12-071-0/+8
| | | | | | | | | | | | On systems whose EGL headers do not define these extensions, the build still failed due to missing ..._PLANE3_... defines. Although we supplied missing EGL_LINUX_DMA_BUF_EXT defines manually, the PLANE3 ones are actually from a separate extension, which explains why they were not added to the fallback defines in the first place. Add them, now it builds without the eglext.h include. See #6838.
* command: fix unintended reset of filterswm42019-12-061-1/+1
| | | | | | | | | | | | | | | | | | | | | Since the recent option changes (probably b16cea750f527), using the "vf" or "af" commands to change the filter chain did not write the option value correctly. This led to the option value being reset the next time an option changed. This happened because the new option value was not copied to the m_config_cache's internal storage. So on the next option update, it looked like the option value changed, because the user-side value was different from the internal value. It was copied back, which meant the original option value was reinstated, and the previous "vf"/"af" command was undone. Fix this by using the correct way to store the option value. This also takes care of property change notification (because the function is specifically separate from m_config_cache_write_opt() to do that), so remove the old call. Fixes: #7220
* player: loadfile overrides previous stop commandwm42019-12-061-1/+1
| | | | | | | | | | | | | | | | Both the "stop" and "loadfile" commands are asynchronous. "stop" starts terminating playback, which used to be done in the same playloop iteration, but now it may take longer, so a "loadfile" command can be received while this is going on. (Possible that it used to work if the second command was issued at least in the next playloop iteration.) Make the "loadfile" override the "stop" mode, so the next file will be played, instead of quitting or going into idle mode. Unlike the referenced bug report claims, this has nothing to do with IPC. Fixes: #7225
* build: fix zimg message in configure outputwm42019-12-061-1/+1
| | | | It's useful as software scaler in general, not just that video filter.
* f_lavfi: mp_lavfi_is_usable: check for "lavfi-" prefixekisu2019-12-061-0/+4
| | | | | Without this, adding filters with the prefix would fail, and some filters that have conflicting names with mpv ones were unusable.
* DOCS: fix wayland-frame-wait offset value rangedudemanguy2019-12-051-1/+1
| | | | It actually goes down to -500 not -100.
* vo: redraw dropped frame if paused between queuing and drawing framewm42019-12-041-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | When frame-stepping with display-sync mode enabled in high framerate video, the frame was sometimes not redrawn correctly. Only the first OSD interaction (or something similar) made it visible. In this case, the core schedules many frames as dropped (because it's ignorant of pausing/frame-stepping, as in theory the player is _not_ paused during frame-stepping, only at the end of it). There's a race between the VO rendering the queued frame, and the core calling vo_set_paused() after it has queued the frame. If the latter happens first, the existing logic to redraw the previous dropped frame does things correctly. If the former happens, the frame is not redrawn automatically, but will be redrawn on the next user input (or if OSD is enabled, and the pause state change updates it, which leads to an immediate redraw). Fix this by never actually dropping a frame in paused mode. The request by the core to drop it is simply ignored. Maybe this could be done slightly nicer by updating the pause state with the VO atomically. Then we wouldn't have the frame drop counter going up either (it's actually dropped, but then redrawn; but I doubt any user, or me in a few weeks, would understand this). But I'm not really interested in polishing this by increasing the complexity of the frame-step code.
* README: fix typoRemita Amine2019-12-041-1/+1
|
* osc: rework window control configuration to add auto modePhilip Langdale2019-12-043-19/+61
| | | | | | | | | | | | | | | | To aid in discoverability, and to address the most common case directly, I'm adding an 'auto' mode for the window controls. In this case, we will show the controls if there is no window border and hide them if there are borders. This also respects the option being toggled at runtime. To ensure that it works in the wayland case, I've also made sure that the wayland code explicitly forces the option to false if decoration support is missing. Based on feedback, I've split the config in two, with one option for whether controls are active, and one for alignment. These are new enough that we can get away with ignoring compatibility.
* osc: ensure that window control show/hide zone is handled dynamicallyPhilip Langdale2019-12-041-6/+6
| | | | | | | | | | | | | | | | | | | As preparation for adding the auto mode for window controls, we need to make sure that the controls can be successfully toggled at runtime, rather than only being able to configure them once at startup. Right now, there is a problem with the handling of the show/hide zone for the window controls. The previous fix for #7212 was to avoid registering the input mapping for the window control show/hide zone. If there is no input mapping, then there is no input, and the zone is a no-op, even if it exists. But this only happens at startup. After that point, the input mapping doesn't exist and cannot be turned on. In this change, I'm switching the approach; we now go back to always registering the input mapping, and instead, we zero out the show/hide zone if window controls are disabled, and set its size appropriately if they are enabled.
* wayland: fix cursor behavior on an edge casedudemanguy2019-12-042-7/+2
| | | | | | | | | | | | | | | | | This small regression was introduced by #7216. Previously, the wayland backend used a trick which kept track of the previous fullscreen state and used that logic for showing the cursor. Since vo_opts now keeps track of the current fullscreen state, most of this stopped being neccessary. However, there was one edge case where the cursor didn't behave the same: passing a fullscreen flag for the inital window. The cursor would initially be visible here which is not desirable. This can be remedied pretty easily by just setting the cursor visiblity to false if the pointer entry event occurs on fullscreen. The only thing we need to do is to make sure that the autohide delay isn't completely disabled (i.e. the cursor is always visible). Hence the need for the previous commit.
* options: move cursor autohiding opts to mp_vo_optsdudemanguy2019-12-044-11/+12
| | | | | | Certain backends (i.e. wayland) will need to do special things with the mouse. It makes sense to expose the values of these options to them, so they can behave correctly.
* sd_lavc: add a hack ontop of another hack to fix completely fucked filewm42019-12-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Do what we do best in multimedia: add conflicting hacks on top of other hacks, that fix a single sample, and may break other ones. In this case, it only happens if the file is most likely already broken (subtitle bounding boxes go outside of the subtitle "canvas"), so it's OK. The file still looks broken (and, in fact, the file is completely fucking broken), but you can see the subtitles. But in summary, this is not actually something I should have bothered about. I noticed that MPlayer shows the subtitles "correctly", but this is only because they have a hack that extends subtitles with small resolution to a larger hardcoded resolution. This hack was removed from mpv, because it broke some completely legitimate files. As another really funny fact, MPlayer's default video output (vdpau) appears to display this file correctly, but only because it handles narrow aspect ratios (that extend the height instead of the width) incorrectly. It extends the height, but leaves the video with 1:1 aspect ratio at the top. It seems to repeat the last video line. (-vo xv and -vo gl show it correctly, i.e. stretched like mpv, by the way.) For some reason, the sample file at hand is extended with black, so the subtitles are rendered into a black area below the video, which is almost reasonable. So, MPlayer may display this file "correctly", but in fact it only happens to do so because of 1 hack that breaks legitimate files, and 1 bug. What the fuck. Fixes: #7218 (sort of)
* player: don't apply weird timestamp tolerance on backstepwm42019-12-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | Hr-seek has some sort of tolerance against timestamps, where it allows for up to 5ms deviation. This means it can work only for videos with up to 200 FPS framerate. There were complains about how it doesn't work with videos beyond some high fps. (1000 was mentioned, although that sounds more like it's about the limit that .mkv has.) I suspect this is because otherwise, it might be hard to hit a timestamp with --start, which specifies timestamps as integer, and thus will most likely never represent a timestamp exactly. Another part of the problem is that mpv uses 64 bit floats for timestamps, so fractional parts are never represented exactly. (Both the "tolerance" and using floats for timestamps were things introduced before my time.) Anyway, in the backstep case, we can be relatively sure that the timestamp will be exact (as in, the same unmodified value that was returned by the filter chain), so we can make an exception for that, in order to fix backstep. Untested. (For that you have users.) May help with #7208.
* demux_lavf: export demuxer_id for more formats which have itwm42019-12-031-5/+8
| | | | | | | | | | | | | | | | | | See previous commit. libavformat exports this information as AVStream.id field. The big problem is that the libavformat field is simply 0 if it's unknown (i.e. the demuxer never sets it). So it needs to remain a whitelist. Just add more formats which are known to have a meaningful ID. I considered exporting IDs for all formats, and then either leaving the values as they are, or filtering duplicate values (and choosing arbitrary but unique different IDs). But then again, I think it's sort of mpv's job to filter FFmpeg's absurd bullshit API, and it should make an effort to hide it rather than to reflect it. See: #7211
* demux: do not make up demuxer_idwm42019-12-034-10/+8
| | | | | | | | | | | | | | | | | | The demuxer_id (exported in as "src-id" property) is supposed to be the native stream ID, as it exists in the file, or -1 if that does not exist (actually any negative value), or if it is unknown. Until now, an ID was made up if it was missing. That seems like strange non-sense, and I can't find the reason why it was done. But it was probably for convenience by the EDL stuff or so. Stop doing this. Fortunately, the src-id property was documented as being unavailable if the ID is not known. Even the code for this was present, it was just inactive until now. Extend input.rst with some explanations. Also fixing 3 other places where negative demuxer_id was ignored or avoided.
* wayland: update remaining legacy VOCTRL usage to optionsPhilip Langdale2019-12-022-31/+27
| | | | | | | | | | | The remaining legacy VOCTRLs are for the fullscreen and border properties. For fullscreen this largely just replacing the private state field with the vo option but there are small semantic differences that we need to be careful of. For the border setting, it's trivial as we don't have external mechanisms for changing the state, but I also can't test it as I'm not using a compositor that supports it.
* osc: don't show error if windowcontrols=yesPhilip Langdale2019-12-021-1/+2
| | | | | | | | I always intended for this to be accepted and mean "right" but I made it show an error for any value that's not explicitly recognised (while considering all unrecognised values to mean "right"). So let's explicitly recognise "yes".
* osc: don't always set window control keybindingsDudemanguy2019-12-011-4/+6
| | | | | Only set the window control keybindings if the window control option is actually enabled. Fixes #7212.
* wayland: update Maximize and Minimize handling to use new optionsPhilip Langdale2019-12-014-30/+43
| | | | | | | | | | | I wanted to get this done quickly as I introduced the new VOCTRL behaviour for minimize and maximize and it was immediately made legacy, so best to purge it before anyone gets confused. I did not sort out fullscreen as that's more involved and not something I've educated myself about yet. But I did replace the VOCTRL_FULLSCREEN usage with the new option change mechanism as that seemed simple enough.
* vf_gpu: render subtitleswm42019-11-304-12/+25
| | | | | | | Pretty annoying affair. The vo_gpu code could of course not trigger rendering from filters yet, so it needed to be extended. Also, this uses some icky stuff made for vf_sub (and this was the reason I marked vf_sub as deprecated), so everything is terrible.
* build: require at least GL 2.0 headers for GLXwm42019-11-301-0/+4
| | | | | | | | The previous hack for fixing #7201 requires this, but it wasn't checked. It's easy to check, so do it. (Yes, we could just have required OpenGL 3.2 headers and skipped the earlier fix.) For #7201.
* m_config: remove change callback before unintializationwm42019-11-301-0/+1
| | | | | | | | | | | | | | | We don't want m_config uninitialization to call random change callbacks. This happens at the end of mp_destroy(), when almost everything else is already destroyed, and the change callbacks would probably trigger UB all over the place. The change callbacks could be trigger by m_config_restore_backups(), which is just used as a cheap way to free the remaining state. The worst is that this depends on which options may still have been part of this "backup" state, which depends on user input. Probably never a practical problem, since the backup state is most likely guaranteed to be empty before uninit is performed, but still.
* vo_gpu: opengl: add hack for ancient Mesa/GLXwm42019-11-301-23/+47
| | | | | | | | | | | | | | | | glx.h recursively includes gl.h, and there is no way to prevent this. Old Mesa defines some GL symbols, but not all which mpv needs. In particular, one user who was too lazy to update his ancient Ubuntu and preferred to bother us with obscure bug reports, had Mesa headers which did not define GL 3.2, so GLsync was not defined. All in all I still think the idea of providing the GL API definitions ourselves was a good idea; just GLX should have been isolated better. But isolating GLX now is too much effort. Not sure why I'm bothering with this at all. Fixes: #7201 (unconfirmed)
* osc: ensure the window-controls mouse area is initially zero sizedPhilip Langdale2019-11-301-0/+1
| | | | | | This is necessary to avoid breaking input behaviour in the 'idle' state when not playing a video. Otherwise, the mouse area starts off covering the whole window and blocks normal input.
* js: mp.add_key_binding: allow false-y name (match 311cc5b)Avi Halachmi (:avih)2019-11-301-1/+3
| | | | | This is in addition to the allowed omission of name and/or flags (as documented).
* lua: unbreak mp.add_key_binding(key, fn)Avi Halachmi (:avih)2019-11-301-1/+1
| | | | | | | Commit 311cc5b6 added the ability use flags while omitting name, but broke the case where both name and flags are omitted. Now omitting either name or flags or both works as documented.
* osc: fix typo wsc_geo -> wc_geoPhilip Langdale2019-11-301-1/+1
|
* osc: apply boxvideo margins to the window controlsPhilip Langdale2019-11-302-1/+6
| | | | | | It seems logical to account for the window controls if `boxvideo` is in use (which has the effect of reducing the size of the video so that the osc is not covering the video).
* filters: fix incorrect #if for vf_gpuwm42019-11-301-1/+1
| | | | | | | This didn't match what is in wscript_build.py. Also, it should work on non-X11 platforms... probably. (The condition is convoluted and almost nonsensical, but the offscreen context creation needs to be cleaned up anyway as soon as other backends, e.g. for win32, are added.)
* command: remove property change notification from property dispatcherwm42019-11-301-3/+2
| | | | | | Properties should handle this themselves. This basically sent redundant notifications. I found only two places where the "proper" notification was missing.
* command: merge two functionswm42019-11-301-11/+3
| | | | Due to recent changes, it makes no sense anymore to keep them separate.
* command: remove another unneeded hackwm42019-11-301-12/+2
| | | | | | | | | | | Now that the option-to-property bridge is gone, this is not needed anymore. It always took the "silent" path. Also, at least as of before this commit, this didn't correctly print a warning when accessing a deprecated option as property. This was because m_config_get_co_raw() was used, which intentionally does not print any warnings, so switch to the non-raw one. (Affects only options that have .deprecation_message set.)
* vf_gpu: add video filter using vo_gpu's rendererwm42019-11-295-0/+405
| | | | | | | | | Probably pretty useless in this form (see: the wall of warnings), but someone wanted this. I think this should be useful to perform some automated tests, maybe. Fixes: #7194
* vo_gpu: opengl: do not free "GL" sub-allocationswm42019-11-291-1/+1
| | | | | | | | | | | | | | | | | | | | | |