summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* wayland: adjust hidden state detectionHEADmasterdudemanguy12 hours1-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 Langdale25 hours1-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-Gowan3 days10-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 Kindestam3 days1-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 Kindestam4 days4-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 modessfan54 days1-1/+4
|
* vo_drm: fix potentially broken capability checksfan54 days1-2/+3
| | | | If the capability is available it may still be 0 to signal absence of support.
* drm_common: log more useful thingssfan54 days1-0/+18
|
* lua: make later key bindings always have higher prioritywm44 days1-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.cwm44 days2-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()wm44 days1-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.hwm44 days1-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 wellwm44 days1-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 filterswm44 days1-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 commandwm44 days1-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 outputwm44 days1-1/+1
| | | | It's useful as software scaler in general, not just that video filter.
* f_lavfi: mp_lavfi_is_usable: check for "lavfi-" prefixekisu4 days1-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 rangedudemanguy5 days1-1/+1
| | | | It actually goes down to -500 not -100.
* vo: redraw dropped frame if paused between queuing and drawing framewm46 days1-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 Amine7 days1-1/+1
|
* osc: rework window control configuration to add auto modePhilip Langdale7 days3-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 Langdale7 days1-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 casedudemanguy7 days2-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_optsdudemanguy7 days4-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 filewm47 days1-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 backstepwm47 days1-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 itwm47 days1-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_idwm47 days4-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 Langdale9 days2-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 Langdale9 days1-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 keybindingsDudemanguy9 days1-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 Langdale10 days4-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 subtitleswm411 days4-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 GLXwm411 days1-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 unintializationwm411 days1-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/GLXwm411 days1-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 Langdale11 days1-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)11 days1-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)11 days1-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 Langdale11 days1-1/+1
|
* osc: apply boxvideo margins to the window controlsPhilip Langdale11 days2-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_gpuwm411 days1-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 dispatcherwm411 days1-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 functionswm411 days1-11/+3
| | | | Due to recent changes, it makes no sense anymore to keep them separate.
* command: remove another unneeded hackwm411 days1-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 rendererwm411 days5-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-allocationswm411 days1-1/+1
| | | | | | | | | | | | | | | | | | | | | | This function always expects the GL struct pointer to be a talloc allocation. So far so bad. But the terrible thing is that _lots_ of code in mpv didn't quite get this (including the code which introduced the way it is used this way). For example, in context_glx.c you see this: struct priv { GL gl; ... GL is not a talloc allocation, but since it's at the start of a talloc allocation, it works anyway. So far so bad. But the really terrible thing is that mpgl_load_functions2() calls talloc_free_children() on the GL pointer, which means that all of priv's. This would be unintentional and could create dangling pointers. And this happens at the about 1 dozen of callers. I'm amazed it didn't broke yet anywhere. Removing this anti-pattern with making GL "implicitly" a talloc allocation would be too much effort at this point. So just manually free the only allocation that the function attached to GL.
* osc: fix operation when window controls are disabledwm412 days1-2/+4
| | | | | It seems this area is simply not defined when window controls are disabled, so ipairs() will crash on it.
* x11: implement unminimizationwm412 days2-2/+6
| | | | This appears to work with IceWM.
* osc: handle deadzone and barmargin for window controlsPhilip Langdale12 days1-6/+28
| | | | | | | | | | | | | | | | I missed these due to only testing with my personal osc config. The deadzone needs to be correctly handled for the window controls, or they will fail to appear when the mouse is close to or over them. In the process of doing that, I realised that the controls should respect the barmargin, if set. This is because the controls should remain aligned when layout=topbar and as the control bar is top aligned, it should be equally affected if the user needs to set the barmargin. I also fixed a mistake in trying to the use the mpv-osd-symbols font for the window controls.
* x11: handle maximize/minimize with new option stuffwm412 days1-43/+31
| | | | | | | | | Should restore full functionality. The initial state setting is a bit shoddy (instead of setting the properties before map, we use the WM commands to change it after, so you will see the normal window state for a moment; the WM commands do not work on unmapped windows, so fixing this would require more code).
* command: change window-minimized/window-maximized to optionswm412 days6-64/+28
| | | | | Unfortunately, this breaks window state reporting for all VOs which supported it. This can be fixed later (for x11 in the next commit).
* x11: add change notification for --on-all-workspaceswm412 days1-0/+18
| | | | | Not particularly important and nobody asked for this, but demonstrates how such things can be easily done now.
* x11: handle some more options with new option stuffwm412 days1-15/+14
|
* x11: use new option stuff to implement fullscreenwm412 days4-14/+24
| | | | | | | | | | | | | | | - remove VOCTRL_FULLSCREEN and VOCTRL_GET_FULLSCREEN - have your own m_config_cache for the fullscreen option (vo->opts_cache cannot be used because you lose per-option change notifications, and it'd be a mess anyway) - use VOCTRL_VO_OPTS_CHANGED to update it (it's used for convenience) - when updating it, check for the fullscreen option (wasn't sure how to do it best; currently, it compares the raw option pointers, but this could be changed) - do not send VO_EVENT_FULLSCREEN_STATE on FS change - instead write the option on FS change (assign in opt. struct + m_config_cache_write_opt)
* player: change m_config to use new option handling mechanismswm412 days7-86/+142
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of making m_config a special-case, it more or less uses the underlying m_config_cache/m_config_shadow APIs properly. This makes the player core a (relatively) equivalent user of the core option API. In particular, this means that other threads can change core options with m_config_cache_write_opt() calls (before this commit, this merely led to diverging option values). An important change is that before this commit, mpctx->opts contained the "master copy" of all option data. Now it's just another copy of the option data, and the shadow copy is considered the master. This is why whenever mpctx->opts is written, the change needs to be copied to the master (thus why this commits add a bunch of m_config_notify... calls). If another thread (e.g. a VO) changes an option, async_change_cb is now invoked, which funnels the change notification through the player's layers. The new self_notification parameter on mp_option_change_callback is so that m_config_notify... doesn't trigger recursion, and it's used in cases where the change was already "processed". It's still needed to trigger libmpv property updates. (I considered using an extra m_config_cache for that, but it'd only cause problems with no advantages.) I think the recent changes actually forgot to send libmpv property updates in some cases. This should fix this anyway. In some cases, property updates are reworked, and the potential for bugs should be lower (probably). The primary point of this change is to allow external updates, for example by a VO writing the fullscreen option if the window state is changed by the window manager (rather than mpv changing it). This is not used yet, but the following commits will.
* m_config: make m_config_cache_write_opt() check/return changeswm412 days2-8/+14
| | | | | | Goes in line with the recent changes to always checking for option value changes. The player core will use this to determine whether it should send additional change events.
* options: get rid of GLOBAL_CONFIG hackwm412 days10-43/+34
| | | | | | | Just an implementation detail that can be cleaned up now. Internally, m_config maintains a tree of m_sub_options structs, except for the root it was not defined explicitly. GLOBAL_CONFIG was a hack to get access to it anyway. Define it explicitly instead.
* m_config: untangle new and old code somewhatwm412 days1-75/+177
| | | | | | | | | | | | | | The original MPlayer m_config was essentially only responsible for handling some command line parsing details, handling profiles, and file-local options. And then there's the new mpv stuff (that stuff was regretfully written by me), which is mostly associated with making things thread-safe (includes things like making it all library-safe, instead of stuffing all option data into global variables). This commit tries to separate them some more. For example, m_config_shadow (the thread-safe thing) now does not need access to m_config anymore. m_config can hopefully be reduced to handling only the "old" mplayer-derived mechanisms.
* m_config: allow writing options through m_config_cachewm412 days2-0/+74
| | | | | | | | | | | | | | This will allow any other threads to write to the global option data in a safe way. The typical example for this is the fullscreen option, which needs to be written by VO (or even some other thing running completely separate from the main thread). We have a complicated and annoying contraption which gets the value updated on the main thread, and this function will help get rid of it. As of this commit, this doesn't really work yet, because he main thread uses its own weird copy of the option data.
* m_config: add fine-grained option reporting mechanismwm412 days2-34/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds m_config_cache_get_next_changed() and the change_flags field in m_config_cache. Both can be used to determine whether specific options changed (rather than the entire sub-group). Not sure if I'm very happy with that. The former rather compact update_options() is now a bit of a mess, because it needs to be incremental. m_config_cache_get_next_changed() will not be too nice to use, and change_flags still relies on global "allocation" of change flags (see UPDATE_* defines in m_option.h). If C weren't such a primitive language that smells like grandpa, it would be nice to define per-option change callbacks or so. This compares options by value to determine whether they have changed. This makes it slower in theory, but in practice it probably doesn't matter (options are rarely changed after initialization). The alternative would have been per-option change counters (wastes too much memory; not a practical problem but too ugly), or keep all m_config_caches in a global list and have bitmaps with per-option change bits (sounds complicated). I guess the current way is OK. Technically, this changes semantics slightly by ignoring setting an option to the same value. Technically this wasn't a no-op, although the effect was almost almost no-op. Some code would actually become cleaner by ignoring such redundant change events, and them being no-op is probably also what the user would normally assume.
* m_config: move stuff aroundwm412 days2-53/+77
| | | | | | | | | | Create a separate struct for internal fields of m_config_cache, so API users can't just mess with stuff they shouldn't access. Move the ts field out of m_config_data, so we don't need unnecessary atomics in one case. This is just preparation, and shouldn't change any behavior.
* atomic: add mp_atomic_uint64wm412 days1-0/+2
|
* m_option: remove an outdated ancient commentwm412 days1-7/+1
| | | | | | | The exact type name (m_obj_list_t) was removed in 2013. I don't think this stub comment helps much with understanding this complicated thing anyway (this code is for the --vf/--af options, and makes up almost half of m_option.c).
* f_output_chain: use m_option_equal()wm412 days1-30/+3
| | | | | | | | | This is used to detect whether any filters were changed. This code was essentially ported to m_option.c. One possible difference is how the old code did name comparison. It did not actually compare the name (!?!?), so this might change behavior, hopefully to the better.
* command: use m_option_equal()wm412 days1-16/+1
| | | | No more converting the option values to a string to compare it.
* m_option: add option comparisonwm412 days2-1/+156
| | | | | | Looks like this will be needed for fine-grained option change notifications. There are some other parts in the player which implement parts of this.
* man/osc: fix typoPhilip Langdale12 days1-1/+1
|
* x11: implement minimize and maximize related VOCTRLsPhilip Langdale12 days2-2/+49
| | | | | This allows the pseudo client side decorations to be used under x11, which might be desirable when running in border=no mode.
* osc: implement pseudo client side decorations via OSCPhilip Langdale12 days2-7/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Today, if window decorations are not present, either because they were disabled, or because the platform doesn't support them (eg: gnome-shell on wayland), there are no window controls, meaning it is not possible to minimize/maximize/close a window without knowing keyboard shortcuts. While you can imagine various ways of offering client side decorations, it is attractive to consider using OSC because that is functionality that we already have. The main work here is defining a separate input area from the main OSC box with its own buttons, etc. While we could probably handle auto-detection based on whether decorations are present or not, it's manually controlled for now. The window control logic is mostly disconnected from the OSC itself, except in the case of the `topbar` layout, where there has to be coordination so that the controls don't get drawn on top of each other. I had to do fine-positioning of the buttons based on the font on my system, so don't be surprised if it looks wrong elsewhere. You could also argue that window controls should be unscaled, even if the main OSC box is scaled, but I've not tried to do this.
* wayland: implement minimize and maximize related VOCTRLsPhilip Langdale12 days1-0/+27
| | | | | | | We primarily care about pseudo-decorations for wayland, where the compositor may not support server-side decorations. So let's implement the minimize and maximize commands and return the maximized window state.
* command: add `window-maximized` and make `window-minimized` settablePhilip Langdale12 days2-3/+43
| | | | | | | | | | | If we want to implement window pseudo-decorations via OSC, we need a way to tell the vo to minimize and maximize the window. Today, we have minimized as a read-only property, and no property for maximized. Let's made minimized settable and add a maximized property to go with it. In turn, that requires us to add VOCTRLs for minimizing or maximizing a window, and an additional WIN_STATE to indicate a maximized window.
* wayland: restore window geometry after un-maximizePhilip Langdale12 days1-3/+2
| | | | | | | | | | | | | At least with gnome-shell (I know, I know), the compositor does not provide the old window size when leaving the maximized state. Instead, we get a toplevel_config event with a 0x0 size and no additional states. Today, we already save the window geometry to restore it when leaving the fullscreen state, so we just need a small change for it to kick in for leaving the maximized state. If I read this correctly, we'll still respect the size passed by a compositor that actually provides the old size.
* wayland: make the edge grab zone width user configurablePhilip Langdale12 days2-5/+8
| | | | | | | Rather than hard-coding the edge grab zone width, we can make it user configurable. It seems worthwhile to have separate configs for pointer and touch usage as the defaults should be different, and a user might have both input methods in use.
* wayland: add grab zone for resizing window with mousePhilip Langdale12 days2-40/+54
| | | | | | | | Today, we support resizing wayland windows when we detect a touch event in a defined grab zone. As part of implementing pseudo-decorations, we should have equivalent functionality for mouse input. And if we detect support for actual decorations we will not activate the grab zone as the decorations will provide this.
* DOCS/interface-changes.rst: more details about track property changeswm413 days1-1/+4
| | | | | Another subtle thing that should be mentioned. May or may not matter to someone.
* x11_common: don't use vo->opts directlywm413 days2-25/+26
| | | | | | | | | Use x11->opts instead of vo->opts. This doesn't matter currently, and x11->opts is actually set to vo->opts. However, there's a chance that either option access changes, or that the way backends integrate with struct vo changes. This is just a preemptive change to make this less of a mess, and it's generally a good idea to reduce accesses to struct vo anyway.
* options: remove options-to-property bridgewm42019-11-256-85/+6
| | | | | | | | The previous bunch of commits made this unnecessary, so this should be a purely internal change with no user impact. This may or may not open the way to future improvements. Even if not, at least the property/option interaction should now be much less buggy.
* command: shuffle around even more crapwm42019-11-252-79/+23
| | | | | | | | | | | | | | | | | | Convert some remaining properties to work without the option-to-property bridge. Behavior shouldn't change (except for the corner case that it tries to reapply the new state when setting a property, while it used to ignore redundant sets). As it is the case with many of these changes, much of the code is not in its final proper state yet, but is rather a temporary workaround. For example, these "VO flag" properties should just be fully handled in the VO backend. (Currently, the config or VO layers don't provide enough mechanism yet as that all the backends like x11, win32, etc. could be changed yet, but that's another refactoring mess for another time.) Now nothing relies on this option-to-property bridge anymore, which opens the way to even more refactoring, which eventually may result in tiny improvements for the end user.
* command: change vid/aid/sid property behavior slightlywm42019-11-253-48/+35
| | | | | Again in line with the option-to-property bridge changes. As usual, this causes subtle behavior changes, which may affect some users.
* options: pre-check filter names when using vf/af libavfilter bridgewm42019-11-255-1/+29
| | | | | | | | | | | | | Until now, using a filter not in mpv's builtin filter list would assume it's a libavfilter filter. If it wasn't, the option value was still accepted, but creating the filter simply failed. But since this happens after option parsing, so the result is confusing. Improve this slightly by checking filter names. This will reject truly unknown filters at option parsing time. Unfortunately, this still does not check filter arguments. This would be much more complex, because you'd have to create a dummy filter graph and allocate the filter. Maybe another time.
* command: change af/vf property behavior wrt. filter creation failureswm42019-11-253-12/+19
| | | | | | The behavior is slightly different in a messy way. The change is in line with the option-to-property bridge removal mentioned some commits ago and thus is deemed necessary.
* command: remove redundant reinit_filters() call on filter change failurewm42019-11-251-1/+0
| | | | | | This attempted to restore the old filter chain if setting a new one at runtime failed. This is not needed anymore, because changing the filter chain is done in a "transactional" way now.
* f_output_chain: fix possible crash when changing filterswm42019-11-251-2/+4
| | | | | | When changing filters at runtime (vf/af commands/properties), this could crash due to a NULL pointer access. The code for comparing the old and new option values (to detect changes) was simply buggy.
* m_config: discourage mp_read_option_raw()wm42019-11-251-0/+1
| | | | | | This function is dangerous, because it disables the already basic/week type checking the option system has at all. I'm tend towards thinking that all of its uses should be replaced.
* command, options: deprecate old --display-fps behaviorwm42019-11-255-9/+40
| | | | | | | See changelog and manpage changes. (So much effort to fix an ancient dumb mistake for an option nobody should use anyway.)
* command: shuffle some crap aroundwm42019-11-256-170/+109
| | | | | | | | | | | | | | | | | | | | | | | | This is preparation to get rid of the option-to-property bridge (mp_on_set_option). This is a pretty insane thing that redirects accesses to options to properties. It was needed in the ever ongoing transition from something to... something else. A good example for the need of this bridge is applying profiles at runtime. This obviously goes through the config parser, but should also make all changes effective, for which traditionally the property layer is used. There isn't much left that needs this bridge. This commit changes a bunch of options (which also have a property implementation) to use option change notifications instead. Many of the properties are still left, but perform unrelated functions like OSD formatting. This should be mostly compatible. There may be some subtle behavior changes. For example, "hwdec" and "record-file" do not check for changes anymore before applying them, so writing the current value to them suddenly does something, while it was ignored before. DVB changes untested, but should work.
* manpage: remove audio-file etc. caveat descriptionwm42019-11-241-13/+0
| | | | | | | These properties actually were removed/replaced, so there is no conflict with the options of the same name anymore. For example, there is no "audio-file" property anymore, but you still can set "audio-files" (and --audio-file simply maps to --audio-files-append).
* options: remove deprecated --playlist-pos aliaswm42019-11-243-5/+1
| | | | | This causes problems because it has the same name as a property which behaves differently.
* input: use array instead of linked list for sectionswm42019-11-231-26/+26
| | | | Shouldn't change behavior.
* lua: make add_key_binding() rotate optional arguments correctlywm42019-11-232-2/+8
| | | | | | | | add_key_binding() makes the name argument optional (in weird Lua fashion), which did not work if there were additional arguments. So there is no way to avoid specifying a name while passing a rp argument. Fix this, declare this way of skipping the argument as deprecated, and allow passing name=nil as the preferred way to skip the name argument.
* input: remove potential minor memory leakwm42019-11-231-0/+1
|
* vo_gpu: fix infinite scaler reinit spamNiklas Haas2019-11-231-8/+9
| | | | | | | | | Handling the window with this function makes no sense, since windows and kernels are not the same thing and don't share the same option list. The only reason it's done is to make sure the char* points at the static string rather than the dynamically allocated one, which we can do manually in this function. Rewrite a bit for clarity/quality.
* input: export input.conf comments ot input-bindings propertywm42019-11-234-7/+34
| | | | | | | | | | | | | | This is supposed to turn input.conf comments into inline documentation. Whether this will be useful depends on whether there'll be a script using this field. This changes a small aspect of input.conf parsing fundamentally: this attempts to strip comments/whitespace from the command string, which will later be used to generate the command when a key binding is executed. This should not have any negative effects, but there could be unknown bugs. (For some reason, every command is parsed when input.conf is parsed, but it still only stores the string for the command. I guess that saves some minor amount of memory.)
* command, input: add input-bindings propertywm42019-11-234-1/+105
| | | | | | Read-only information about all bindings. Somewhat hoping someone can make a nice GUI-like overlay thing for it, which provides information about mapped keys.
* command: add command-list propertywm42019-11-232-0/+33
|
* input: change mp_cmd.original from bstr to cstrwm42019-11-234-8/+9
| | | | | | | | No reason to have this as bstr, just makes everything more complex. Also clear mp_cmd.sender when it's copied. Otherwise it would be a dangling pointer. Apparently it's never set to non-NULL in this situation, but this is cleaner anyway.
* demux_lavf: log packet read errorsAman Gupta2019-11-221-1/+1
| | | | Signed-off-by: Aman Gupta <aman@tmm1.net>
* input: make MP_INPUT_RELEASE_ALL a pseudo-keywm42019-11-222-3/+2
| | | | | | | Should be without consequences. I think this is less trouble, because code frequently wants to add/remove bits for modifiers and key state from key codes, and with this change you can't accidentally break it by testing or removing bits from the old -1 value.
* msg: show how many messages were droppedwm42019-11-221-1/+3
| | | | Although repl.lua will probably not use this.
* msg: drop old instead of new messages on overflowwm42019-11-221-43/+57
| | | | | | | | | | | | It did that because there was no other way. It used a lock-free ring buffer, which does not support this. Use a "manual" ring buffer with explicit locks instead, and drop messages from the start. (We could have continued to use mp_ring, but it was already too late, and although mp_ring is fine, using it for types other than bytes looked awkward, and writing a ring buffer yet again seemed nicer. At least it's not C++, where mp_ring would have been a template, and everything would have looked like shit soup no matter what.)
* msg: fix missing wakeup callback in terminal-default log levelwm42019-11-221-0/+2
| | | | | | | | | In the referenced commit, I forgot about this part, and a client which tried to use this was actually not woken up when needed. (Also why the hell does the subject line of that commit say "removed"?) Fixes: 8c2d73f11205
* input: add text produced by key to script key eventswm42019-11-227-7/+32
| | | | | | | Particularly for "any_unicode" mappings, so they don't have to special-case keys like '#' and ' ', which are normally mapped to symbolic names for input.conf reasons. (Though admittedly, this is a pretty minor thing, since API users could map these manually.)
* manpage: correct "complex" key binding descriptionwm42019-11-221-2/+2
| | | | | | | The key is never nil if it's invoked through the normal input path. The key name could be "" if mp_cmd.key_name==NULL. This should not happen, but there's no strong guarantee in input.c that it cannot happen, so whatever.
* manpage: improve "complex" key binding list of table entrieswm42019-11-221-6/+13
|
* input: introduce a pseudo key name that grabs all text inputwm42019-11-224-4/+19
| | | | | | | | | The intended target for this is the mpv.repl script, which manually added every single ASCII key as a separate key binding. This provides a simpler mechanism, that will catch any kind of text input. Due to its special nature, explicitly do not give a guarantee for compatibility; thus the warning in input.rst.
* input: fix ineffective mp_msg_test callwm42019-11-221-1/+1
| | | | | | This was supposed not to go through key lookup if the message wasn't going to be output, but for whatever reason the log levels were mismatched.
* js: complex key binding: use key_name like the docs sayAvi Halachmi (:avih)2019-11-201-1/+1
|
* js: report key name for "complex" key bindings - match b08c8f50Avi Halachmi (:avih)2019-11-201-4/+5
|
* lua: complex key binding: use key_name like the docs sayAvi Halachmi (:avih)2019-11-201-1/+1
|
* player: Optionally validate st_mtime when restoring playback stateChris Down2019-11-206-0/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I often watch sporting events. On many occasions I get files with the same filename for each session. For example, for F1 I might have the following directory structure: F1/ FP1.mkv FP2.mkv FP3.mkv Qualification.mkv Race.mkv Since usually one simply watches one race after the other, I usually just rsync the new event's files over the old ones, so, for example, Race.mkv will be replaced from the file for the last event with the file from the new event. One problem with this is that I like to use --resume-playback for other kinds of media, so I have it on by default. That works great for, say, a movie, but doesn't work so well with this scheme, because you can trivially forget to pass --no-resume-playback on the command line and end up 2 hours in, watching spoilers as the race results scroll down the screen :-) This patch adds a new option, --resume-playback-check-mtime, which validates that the file's mtime hasn't changed since the watch_later configuration was saved. It does this by setting the watch_later configuration to have the same mtime as the file after it is saved. Switching back and forth between checking mtime and not checking mtime works fine, as we only choose whether to compare based on it, but we update the watch_later configuration mtime regardless of its value.
* manpage: extend documentation of key nameswm42019-11-191-0/+74
| | | | These things weren't written down anywhere yet.
* lua: report key name for "complex" key bindingswm42019-11-192-7/+9
| | | | This might make certain use cases less of a mess.
* manpage: deprecate input section commandswm42019-11-192-0/+8
| | | | | | | | | | These were a bad idea and are obscure. Scripting key mapping support still uses them, but this is not relevant to scripting authors, because the mpv provided helper code (defaults.lua) takes care of this. In addition, the OSC uses a legacy form of this. Hopefully, this input section stuff can be removed, and replaced by a simpler mechanism.
* audio: add ao_audiotrack for androidAman Gupta2019-11-193-0/+722
|
* misc: add jni helpersAman Gupta2019-11-193-0/+591
|
* audio: fix minor whitespace issue in out/internal.hAman Gupta2019-11-191-1/+1
|
* js: don't pre-filter log level argument in mp.enable_messages()Avi Halachmi (:avih)2019-11-191-2/+3
| | | | Match lua's 8e5642ff
* DOCS/contribute.md: some clarificationswm42019-11-181-3/+7
| | | | Even if nobody ever reads this file.
* video/out/bitmap_packer: Avoid empty initializer listMichael Forney2019-11-181-1/+1
|
* video/out/vo_tct: Use octal escape sequence instead of non-standard \eMichael Forney2019-11-181-9/+9
|
* video/out/gpu: Remove stray top-level ';'Michael Forney2019-11-182-2/+2
|
* player: remove mechanisms for better logging with repl.luawm42019-11-185-8/+87
| | | | | | | | | | | | | | | | | | | | | | As preparation for making repl.lua part of the core (maybe), add some mechanisms which are supposed to improve its behavior. Add a silent mode. Calling mpv_request_log_messages() with the log level name prefixed with "silent:" will disable logging from the API user's perspective. But it will keep the log buffer, and record new messages, without returning them to the user. If logging is enabled again by requesting the same log level without "silent:" prefix, the buffered log messages are returned to the user at once. This is not documented, because it's far too messy and special as that I'd want anyone to rely on this behavior, but it will be perfectly fine for an internal script. Another thing is that we record early startup messages. The goal is to make the repl.lua script show option and config parsing file errors. This works only with the special "terminal-default" log level. In addition, reduce the "terminal-default" capacity to only 100 log messages. If this is going to be enabled by default, it shouldn't use too much resources.
* lua: don't pre-filter log level argument in mp.enable_messages()wm42019-11-181-2/+4
| | | | | | | | | | | | This will just make it not work if mpv_request_log_messages() gets extended to accept more names. Pass the argument without checking. To keep the behavior the same (for whatever reasons, probably not important), still raise an error if the libmpv API function returns an error that the argument was bad. (The check_loglevel() function is still used when the script _emits_ log messages, which is different, and for which there is no API anyway.)
* vo_gpu: hwdec_cuda: Reduce message level of errors while probingPhilip Langdale2019-11-172-5/+7
| | | | | | We should only be printing errors that occur when not probing, to avoid creating the impression that something is wrong - and errors during probing isn't a problem.
* options: deprecate --video-sync=display-adropwm42019-11-173-0/+9
| | | | A stupid thing that will probably be in the way.
* player: remove some unnecessary coverart special caseswm42019-11-173-4/+2
| | | | | | | | These should not be needed, since video is in EOF mode in this case anyway. Not too sure about the video.c case to be honest, well, here goes nothing.
* video: make track switching work for external imageswm42019-11-171-7/+13
| | | | | | | | Until now, this didn't work, since the external image had pts 0; so enabling video at a later time did nothing, because the image was discarded. Since hrseek now ends on the last frame (instead of nothing), reusing the hrseek mechanism solves this, and we don't even need to treat the cursed coverart case separately.
* player: remove commented declarationwm42019-11-171-1/+0
| | | | It was commented almost 2 years ago in a "rewrite everything" commit.
* audio: log A/V initial sync statuswm42019-11-171-0/+3
|
* demux_mf: fix backward seeking behaviorwm42019-11-171-6/+8
| | | | | | | If SEEK_FORWARD is set, a demuxer should skip to the next frame if the timestamp does not fall on the start of a frame. If that flag is not set, it should always seek to the first frame before the target timestamp (or the first frame in the file).
* video: set EOF status as soon as possiblewm42019-11-171-1/+7
| | | | | | | | | | | | See what the added code comment says. Normally when this is needed, it's the cover art case. But this flag is not set when using an external image. This gives weird seek behavior, because the frame will be "normally" displayed for its determined duration, and during normal video playback, the video pts will be used - which is always 0 here. This should happen only if audio is active. Otherwise, we're more or less in image viewer mode, where the image should be displayed for a configured duration.
* video: if hr-seek goes past last frame, seek to last framewm42019-11-171-7/+6
| | | | | | | | | | | | This gives much better behavior in general, and is what we want if video somehow ends earlier than audio. A common special is using an audio file with an external image file. This commit makes things like switching aspect ratio work (provided the demuxer for the image behaves correctly, which currently isn't the case with demux_mf.c). Since the image file had timestamp 0, it was usually skipped by hr-seek, and changed properties weren't applied to it at the start of the filter chain.
* f_decoder_wrapper: put coverart through image output logicwm42019-11-171-2/+4
| | | | | | This wasn't done, probably regression from one of the last dozen of times this special code path was touched. This meant coverart images ignored the user-set aspect ratio completely, and some other things.
* vo_gpu: context_glx: Add X11 native resourcePhilip Langdale2019-11-161-0/+2
| | | | | | | Surprisingly, we've managed to get this far without context_glx ever adding the X11 display as a native resource. But with the recent change to attempt to enable vdpau when using EGL, the hwdec now requires the display to be added. So let's add it.
* wayland: use eglGetPlatformDisplay()Dudemanguy2019-11-161-1/+2
| | | | | See aacc194. The same logic all applies to Wayland. In fact, we already require EGL 1.5 for wayland anyway, so it's better to do it right.
* x11: require EGL 1.5 and use eglGetPlatformDisplay()wm42019-11-162-8/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | eglGetPlatform() is a broken API, since it takes a windowing specific argument, yet is supposed to work for multiple APIs at the same time. On Linux, it can take both a X11 "Display" and a "wl_display". Obviously there is no way to specify what kind of display the argument is (it's just a void*). Mesa has _eglNativePlatformDetectNativeDisplay, which does funny stuff to try to guess the display type, including trying to call mincore() to determine whether the pointer can be accessed at all. I guess this recently accidentally broke (as a bug), but on the other hand, maybe it's time to do this properly. The fix is using eglGetPlaformDisplay(). This requires EGL 1.5, plus Mesa needs to support the associated platform extension (EGL_KHR_platform_x11). Since I see no reasonable way to do this in a compatible way, just require that EGL 1.5 is available. The problem is that EGL 1.4 seems to require you to create a display to query EGL version and extension, and you have a chicken-and-egg problem. It's very stupid. Maybe you could jump through some more hoops to get something compatible, but fuck that. Users on "too old" Mesa will fall back to GLX (which we keep around for a regrettable company known by the name of Nvidia). I think Wayland and GBM should do the same. They're sufficiently bleeding-edge that you can expect them to have EGL 1.5. On the other hand, the cursed RPI code will have to stay with a eglGetDisplay(). Speculative fix for #7154. (Rant about EGL follows. Actually I deleted it.)
* vo_gpu: sync duplicated condition on peak computationwm42019-11-161-0/+2
| | | | | | | | | | | | | | | | | | | | pass_color_map() (in video_shaders.c) and pass_colormanage() (video.c) both duplicate the condition on whether to do peak computation. Peak computation requires a compute shader, so if the duplicated conditions don't match, video_shaders.c will generate a compute shader, but video.c will try to run it as fragment shader. This leads to a "blue screen". This can be reproduced by playing a HDTV video with --target-peak=99. It's not clear how to fix this. Should pass_tone_map() be only invoked if mp_trc_is_hdr() == true (what pass_colormanage() uses to decide whether to enable peak computation), or should pass_colormanage() just tell pass_color_map() to skip peak computation? Decide for the latter, as it's more robust. Even if not correct, at least it gets rid of the blue shit. Fixes: #7149
* client API: remove sync. property notification code againwm42019-11-161-41/+14
| | | | | | | | | | | | It's too easy to introduce unintended circular lock dependencies. Just now we found that the (old) cocoa vo_gpu backend is also affected by this, because it waits on the Cocoa main thread, which in turn uses libmpv API for OSX... stuff. Also fix a missing initial property update after observe. This leaves me unhappy, because it just leads to a stupid thread ping pong. Will probably rewrite this later.
* manpage: add section about using mpv from programs and scriptswm42019-11-161-0/+45
| | | | | | | | | | | | | | | Give an overview over the various methods. I feel like I've written text like this over and over again (compatibility.rst and interface-changes.rst for example duplicate the list of mpv API abstractions), but such is life in hell. Use this in particular to strongly suggest not to parse terminal output. This suggestion got lost or de-emphasized at some point (maybe when removing MPlayer and "slave mode" references). Some of this text is still there, but it can be considered "fine print" at best, that nobody will see. Now we have it in a more prominent place. This is especially important since MPlayer-style use of mpv still seems to be prevalent, see for example #7153.
* options: deprecate --input-filewm42019-11-163-1/+6
| | | | | | I have no idea why this still exists, since we have --input-ipc-server. I think there was something about Windows, but the latter option is implemented even on Windows.
* video: take first frame into account in audio-sync modewm42019-11-161-3/+2
| | | | | | | | | | | | | | | It appears commit 4ad68d94523c3d101a broke handling the first video frame duration through roundabout ways (I think because the duration of the first frame was now available at all in the normal case). The first frame was cut short, which showed up especially with looping, or if the file had a low FPS. This questionable change seems to fix it without breaking any other known cases => push and call it a day. The display-sync mode did not have this problem. Fixes: #7150
* demux_lavf: fight ffmpeg API some more and get the timeout setwm42019-11-162-2/+41
| | | | | | | | | | | | | | | | | | | | | | | | It sometimes happens that HLS streams freeze because the HTTP server is not responding for a fragment (or something similar, the exact circumstances are unknown). The --timeout option didn't affect this, because it's never set on HLS recursive connections (these download the fragments, while the main connection likely nothing and just wastes a TCP socket). Apply an elaborate hack on top of an existing elaborate hack to somehow get these options set. Of course this could still break easily, but hey, it's ffmpeg, it can't not try to fuck you over. I'm so fucking sick of ffmpeg's API bullshit, especially wrt. HLS. Of course the change is sort of pointless. For HLS, GET requests should just aggressively retried (because they're not "streamed", they're just actual files on a CDN), while normal HTTP connections should probably not be made this fragile (they could be streamed, i.e. they are backed by some sort of real time encoder, and block if there is no data yet). The 1 minute default timeout is too high to save playback if this happens with HLS. Vaguely related to #5793.
* demux_playlist: fix previous commitwm42019-11-151-3/+2
| | | | | | | This just froze, due to obvious stupidity (I forgot to deal with all semantic changes done to the the former stream_skip()). Fixes: ac7f67b3f23
* player: enable "pause caching" code for local playback toowm42019-11-141-2/+1
| | | | | | | | There isn't really a need to disable this for local playback. I think originally I did this because I was afraid the code could mess up or be annoying on local mode, but that's not really a good argument. I'd rather test this code in local mode too. In this case, it shouldn't really happen that it runs out of cache in the first place.
* stream_lavf: set --network-timeout to 60 seconds by defaultwm42019-11-144-12/+23
| | | | | | | | | | | Until now, we've made FFmpeg use the default network timeout - which is apparently infinite. I don't know if this was changed at some point, although it seems likely, as I was sure there was a more useful default. For most use cases, a smaller timeout is more useful (for example recording something in the background), so force a timeout of 1 minute. See: #5793
* demux_mkv, stream: attempt to improve behavior in unseekable streamswm42019-11-146-15/+16
| | | | | | | | | | | | | | | | | stream_skip() semantics were kind of bad, especially after the recent change to the stream code. Forward stream_skip() calls could still trigger a seek and fail, even if it was supposed to actually skip data. (Maybe the idea that stream_skip() should try to seek is worthless in the first place.) Rename it to stream_seek_skip() (takes absolute position now because I think that's better), and make it always skip if the stream is marked as forward. While we're at it, make EOF detection more robust. I guess s->eof shouldn't exist at all, since it's valid only "sometimes". It should be removed... but not today. A 1-byte stream_read_peek() call is good to get the s->eof flag set to a correct value.
* wayland: use hidpi-window-scale optiondudemanguy2019-11-122-1/+3
|
* github: ask for build/config.logPhilip Sequeira2019-11-101-2/+2
|
* build: fix compilation conditions for vaapi interop initsPhilip Sequeira2019-11-101-2/+2
| | | | | | | | | This makes the condition for including each init match the condition for compiling the file that defines it. It's possible to e.g. HAVE_GL and HAVE_VAAPI without HAVE_VAAPI_EGL, which resulted in "undefined reference to `vaapi_gl_init'" with the old code.
* options: remove M_SETOPT_RUNTIMEwm42019-11-105-20/+10
| | | | | | | Used to contain flags for "save" setting of options at runtime. Now there is nothing special needed anymore and it's 0. So drop it completely, and remove anything that distinguishes between runtime and initialization time.
* options: remove M_OPT_FIXEDwm42019-11-106-49/+36
| | | | | | | | | | | | | | | | | | | | | | | Options marked with this flag were changed to strictly read-only after initialization (mpv_initialize() in the client API, after option parsing and config file loading with the CLI player). This used to be necessary, because there was a single option struct that could be accessed by multiple threads. For example, --config-dir sets MPOpts.force_configdir, which was read whenever anything accessed the mpv config dir (which could be on different threads, e.g. font initialization tries to lookup fonts.conf from an arbitrary thread). This isn't needed anymore, because threads now access these in a thread safe way. In the case of --config-dir, the path is actually just copied on init. This M_OPT_FIXED mechanism is thus not strictly needed anymore. It still prevents writing to some options that cannot take effect at runtime, but even that can be dropped. In general, all mpv options can be changed any time at runtime, even if they never take effect, and there's no need to make an exception for a very low number of options. So just get rid of it.
* audio: more alignment nonsensewm42019-11-101-1/+5
| | | | | | | | | | | It's hard to see what FFmpeg does or what its API requires. It looks like the alignment in our own allocation code might be slightly too lenient, but who knows. Even if this is not needed, upping the alignment only wastes memory and doesn't do anything bad. (Note that the only reason why we have our own code is because FFmpeg doesn't even provide it as API. API users are forced to recreate this, even if they have no need for custom allocation!)
* audio: work around ffmpeg being a piece of shitwm42019-11-101-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "amultiply" filter crashes in AVX mode on unaligned access if an audio pointer is unaligned (on 32 or 64 bytes I assume). A requirement that audio data needs to be aligned isn't documented anywhere. In our case, the data is still sample- and channel-aligned, which is completely sane. Sure, you can imagine optimizations which make some algorithms even faster by requiring higher alignment. But, and this is a big but, you shouldn't crash api users because you just invented a new undocumented requirement. And even more importantly, your user-crashing optimization won't matter because it's just a trivial algorithm working on audio. You don't need to pretend to be an optimization devil, and nobody will give you a prize for this. But no, lets random make API users crash (and then probably blame them for it!) for something that wouldn't matter at all. Not to mention that they do "document" some requirements on _video_ data, yet their vf_crop probably can still produce unaligned video pointers. Oh how hilarious that the same documentation also talks about libswscale alignment requirements. (This is weird because libswscale is just one of many, many things which consume video data. Also did you know that zimg, written in C++ and using intrinsics, i.e. the antithesis to FFmpeg development, is much faster than libswscale, easier to use, and produces more correct results, even if you ignore that libswscale flat out doesn't support some very important features?) Fucking tired of this bullshit. Can't wait until someone comes up with a better framework than this... (well let's not write this out). Fix this by copying instead of adjusting the start pointer when skipping samples. This makes general operations slower just to fix interoperating with a single filter. Thank you for your "optimization", FFmpeg. Go die in a fire. Didn't check whether this is correct. It probably is? If the frame needs to be copied (due to COW), and memory allocation fails, it just silently (or audibly lol) doesn't skip samples, because a never-fail function can suddenly fail. Well, who cares. Fixes: #7141
* vo_gpu: yuv alpha is always full rangewm42019-11-091-8/+6
| | | | | | | | | | | | | | Probably. It's not like these pixel formats are formally specified - FFmpeg added them because _some_ file format or decoder supports it, and while that format/codec may define it precisely, the pixel format is sort of disconnected and just a FFmpeg thing. In any case, the yuva sample I had at hand uses the full range the component data type can provide. The old code used the same "shifted" range as for Y/U/V components, which must have been wrong. This will not work correctly for packed YUVA formats, but fortunately they matter even less.
* github: suggest using as github attachment for log fileswm42019-11-091-5/+5
| | | | | | | | | | It's not that we _want_ the log to be on an external site. We just want the log, somehow. Probably not pasted inline into the issue text. Also reword the "we are assholes who really want logs" part of the text. It's a subtle balance between trying to be nice and being a complete asshole, but no matter what you do, it will always sound like the latter, so be direct.
* manpage: expand MPV_LEAK_REPORT environment variable descriptionwm42019-11-091-1/+5
|
* README.md: fix dead FAQ link due to syntax errorTimothy DeHerrera2019-11-091-3/+3
|
* test: add tests for zimg RGB repackingwm42019-11-0910-4/+349
| | | | | | | | | | | | | | | | | | | | | | | | This tests the RGB repacker code in zimg, which deserves to be tested because it's tricky and there will be more formats. scale_test.c contains some code that can be used to test any scaler. Or at least that would be great; currently it can only test repacking of some byte-aligned-component RGB formats. It should be called repack_test.c, but I'm too lazy to change the filename now. The idea is that libswscale is used to cross-check the conversions performed by the zimg wrapper. This is why it's "OK" that scale_test.c does libswscale calls. scale_sws.c is the equivalent to scale_zimg.c, and is of course worthless (because it tests libswscale by comparing the results with libswscale), but still might help with finding bugs in scale_test.c. This borrows a sorted list of image formats from test/img_format.c, for the same reason that file sorts them. There's a slight possibility that this can be used to test vo_gpu.c too some times in the future.
* test: fix --unittest matchingwm42019-11-081-1/+1
| | | | Hurrr.
* vo_gpu: context_x11egl: check eglGetConfigAttrib() for errorswm42019-11-081-1/+4
| | | | | Not sure why it assumes that it always succeeds (although generally it won't fail).
* img_format: remove some unneeded alpha flag handlingwm42019-11-082-6/+0
| | | | Don't know what this was for, but the result doesn't change.
* test: add dumping of img_format metadatawm42019-11-087-98/+2079
| | | | | | | | | | | | | | | | | | | | This is fragile enough that it warrants getting "monitored". This takes the commented test program code from img_format.c, makes it output to a text file, and then compares it to a "ref" file stored in git. Originally, I wanted to do the comparison etc. in a shell or Python script. But why not do it in C. So mpv calls /usr/bin/diff as a sub-process now. This test will start producing different output if FFmpeg adds new pixel formats or pixel format flags, or if mpv adds new IMGFMT (either aliases to FFmpeg formats or own formats). That is unavoidable, and requires manual inspection of the results, and then updating the ref file. The changes in the non-test code are to guarantee that the format ID conversion functions only translate between valid IDs.
* test: merge test_helpers.c and index.cwm42019-11-0810-66/+53
| | | | | No need to keep them separate. Originally I thought index.c was only going to contain the list of tests, but that didn't happen.
* player: do not require dummy file arguments to use --unittestwm42019-11-081-5/+5
| | | | | Move the test execution above the point where it checks for an empty playlist and exits if that's the case.
* test: make build fail if NDEBUG is definedwm42019-11-081-0/+4
| | | | | | | | | | | | | Defining NDEBUG via CFLAGS is the canonical way to disable assertions in C. mpv respects this (and ta.c actually disables some debugging machinery if it's defined). But for tests, this is not useful at all. So if --enable-tests is passed to configure, the user must not define NDEBUG, even if the rest of the player does not care. (We could just #undef NDEBUG, but let's not. Tests calling into the rest of the player might depend on asserts there, or so.)
* test: just always provide a context for all entrypointswm42019-11-086-19/+24
|
* wscript: add --enable-ta-leak-report optionwm42019-11-083-1/+11
| | | | Kind of more convenient because I'm lazy.
* wscript: remove outdated --enable-libafwm42019-11-081-6/+0
| | | | | | | This stopped doing anything since how many years? The only actual effect was that af_rubberband was made GPL only. Now it is available in LGPL builds too.
* test: make tests part of the mpv binarywm42019-11-0815-209/+271
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, each .c file in test/ was built as separate, self-contained binary. Each binary could be run to execute the tests it contained. Change this and make them part of the normal mpv binary. Now the tests have to be invoked via the --unittest option. Do this for two reasons: - Tests now run within a "properly" initialized mpv instance, so all services are available. - Possibly simplifying the situation for future build systems. The first point is the main motivation. The mpv code is entangled with mp_log and the option system. It feels like a bad idea to duplicate some of the initialization of this just so you can call code using them. I'm also getting rid of cmocka. There wouldn't be any problem to keep it (it's a perfectly sane set of helpers), but NIH calls. I would have had to aggregate all tests into a CMUnitTest list, and I don't see how I'd get different types of entry points easily. Probably easily solvable, but since we made only pretty basic use of this library, NIH-ing this is actually easier (I needed a list of tests with custom metadata anyway, so all what was left was reimplement the assert_* helpers). Unit tests now don't output anything, and if they fail, they'll simply crash and leave a message that typically requires inspecting the test code to figure out what went wrong (and probably editing the test code to get more information). I even merged the various test functions into single ones. Sucks, but here you go. chmap_sel.c is merged into chmap.c, because I didn't see the point of this being separate. json.c drops the print_message() to go along with the new silent-by-default idea, also there's a memory leak fix unrelated to the rest of this commit. The new code is enabled with --enable-tests (--enable-test goes away). Due to waf's option parser, --enable-test still works, because it's a unique prefix to --enable-tests.
* msg: try to document purpose of log levels betterwm42019-11-071-8/+9
| | | | (But I bet nobody ever reads this anyway.)
* vo_gpu: vdpau actually works under EGLwm42019-11-072-6/+3
| | | | | | | | | | | | | | | | | | The use of glXGetCurrentDisplay() restricted this to the GLX backend. But actually it works under EGL as well. Removing the GLX-specific call and using the general mpv-internal method to get the X "Display" makes it work in mpv. I didn't know this. Nvidia didn't list this as extension in the EGL context when I still used their GPUs. Note that this might in theory break use of vdpau in some libmpv clients using the render API. But only if MPV_RENDER_PARAM_X11_DISPLAY is not used, and they relied on mpv using glXGetCurrentDisplay(). EGL does not provide such an API, and hwdec_vaapi.c also uses what hwdec_vdpau.c uses now. Considering that vaapi is preferable these days, it's not bad at all if these clients get "broken". They can be easily fixed by passing the display to mpv correctly.
* manpage: vdpauglx backend was removedwm42019-11-071-5/+0
| | | | A while ago. It was 100% useless.
* builtin.conf: set minimal --stream-buffer-sizewm42019-11-071-0/+1
| | | | | | | Some stream inputs may have higher latency with higher buffer sizes, for example network filesystems via normal OS filesystem interface (these have to wait until the full buffer is read, which means higher latency). Probably doesn't matter in practice, but why take chances.
* DOCS/contribute.md: add #include order to coding stylewm42019-11-071-0/+11
| | | | Another thing nobody will read, or consciously follow.
* DOCS/contribute.md, zimg: remove 2 instances of an extraneous "s"wm42019-11-072-2/+2
|
* stats, demux: log byte level stream seekswm42019-11-076-0/+14
|
* stream: remove unused read_chunk fieldwm42019-11-077-10/+0
| | | | | | | | | | | | | It was set, but its value was never used. The stream cache used to use it, but it was removed. It controlled how much data it tried to read from the underlying stream at once. The user can now control the buffer size with --stream-buffer-size, which achieves a similar effect, because the stream will in the common case read half of the buffer size at once. In fact, the new default size is 128KB, i.e. 64KB read size, which is as much as stream_file and stream_cb requested by default. stream_memory requested more, but it doesn't matter anyway. Only stream_smb set a larger size with 128KB.
* stream: replace STREAM_CTRL_GET_SIZE with a proper entrypointwm42019-11-0711-92/+46
| | | | | This is overlay convoluted as a stream control, and important enough to warrant "first class" functionality.
* stream_dvdnav: ok, this makes no sense at allwm42019-11-071-1/+4
| | | | | | | | | | | | | | | | | The dvdnav API reads in 2K blocks (dvdnav_get_next_block()). The mpv wrapper (fill_buffer() in this file) expects that the read size done by the mpv core is at least 2K for this reason. If not, it returns an error. This used to be OK, because there was a thing called section alignment in the core code. This was removed because the core shouldn't suffer from optical disc idiosyncrasies. Which means that ever since, it has been working only by coincidence, or maybe not at all. Fixing this would require keeping a buffer in the priv struct, and returning it piece by piece if the core makes smaller reads. I have no intention of writing such code, so add an error message asking for a patch. If anyone actually cares about DVD, maybe it'll get fixed.
* stream_bluray: remove size getterwm42019-11-071-3/+0
| | | | | | This isn't really needed, since it doesn't support byte seeking (only for avoiding that demux_disc fucks up even more if the nested demux_lavf tries to seek in the TS).
* stream: change buffer argument types from char* to void*wm42019-11-0713-27/+27
| | | | | | | This is slightly better, although not much, and ultimately doesn't matter. The public API in stream_cb.h also uses char*, but can't change that.
* stream: avoid a duplicate conditionwm42019-11-071-6/+3
| | | | | | stream_read_peek() duplicated what stream_read_more() checks for anyway (whether the forward buffer is large enough). This can be skipped by making the stream_read_more() return value more consistent.
* stream: fix typos in a commentswm42019-11-072-4/+4
|
* stream: remove eof getterwm42019-11-072-6/+1
| | | | | | | demux_mkv was the only thing using this, and everything else accessed it directly. No need to keep the indirection wrapper around. (Funny how this getter was in the initial commit of MPlayer.)
* vo_gpu: unconditionally clear framebuffer on start of framewm42019-11-061-5/+3
| | | | | | | | | | | | | | | | | | | | | | For some reason, the first frame displayed on X11 with amdgpu and OpenGL will be garbled. This is especially visible if the player starts, displays a frame, but then still takes a while to properly start playback. With --interpolation, the behavior somehow changes (usually gets worse). I'm not sure what exactly is going on, and the code in video.c is way too abstruse. Maybe there is some slight possibility that a frame with uncleared contents gets displayed, which somehow also corrupts another frame that is displayed immediately after that. If clear is unconditionally run, this somehow doesn't happen, and you see a video frame. By any logic this shouldn't happen: a video frame should always overwrite the background. So I can't exclude that this isn't some sort of driver bug, or at least very obscure interaction. Clearing should be practically free anyway, so always do it. Fixes: #7105
* stream: bump default buffer size from 2K to 64Kwm42019-11-062-2/+2
| | | | | | | | | (Only half of the buffer is actually used in a useful way, see manpage or commit which added the option.) Might have some advantages with broken network filesystem drivers. See: #6802
* stream: remove inline buffer optimizationwm42019-11-062-18/+9
| | | | | | | | | | Was probably worthless, and I can't measure a difference anymore (I used to be able and it still seemed worth doing so back then). When the default buffer size is enlarged in the next commit, the inline buffer probably won't even be useful in theory, because the data will rarely be on the same page as the other stream fields. It surely makes the inline buffer seem like a ridiculous micro-optimization. Farewell...
* stream: turn into a ring buffer, make size configurablewm42019-11-0613-178/+317
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some corner cases (see #6802), it can be beneficial to use a larger stream buffer size. Use this as argument to rewrite everything for no reason. Turn stream.c itself into a ring buffer, with configurable size. The latter would have been easily achievable with minimal changes, and the ring buffer is the hard part. There is no reason to have a ring buffer at all, except possibly if ffmpeg don't fix their awful mp4 demuxer, and some subtle issues with demux_mkv.c wanting to seek back by small offsets (the latter was handled with small stream_peek() calls, which are unneeded now). In addition, this turns small forward seeks into reads (where data is simply skipped). Before this commit, only stream_skip() did this (which also mean that stream_skip() simply calls stream_seek() now). Replace all stream_peek() calls with something else (usually stream_read_peek()). The function was a problem, because it returned a pointer to the internal buffer, which is now a ring buffer with wrapping. The new function just copies the data into a buffer, and in some cases requires callers to dynamically allocate memory. (The most common case, demux_lavf.c, required a separate buffer allocation anyway due to FFmpeg "idiosyncrasies".) This is the bulk of the demuxer_* changes. I'm not happy with this. There still isn't a good reason why there should be a ring buffer, that is complex, and most of the time just wastes half of the available memory. Maybe another rewrite soon. It also contains bugs; you're an alpha tester now.
* common: add a helper to round up to next power of 2wm42019-11-062-0/+15
| | | | | | This is something relatively frequently needed, and there must be half a dozen ad-hoc implementations in mpv. The next commit uses this, the suspected duplicate implementations are hiding.
* demux: unconditionally reposition stream to start before openingwm42019-11-061-2/+3
| | | | | | | | | | | The old code made it depend on ->seekable. If it isn't seekable, and something discarded the data, then it'll just show an error message, which will at least be somewhat informative. If no data was discarded, the seek call is always a no-op. There's a weird "timeline" condition in the old code; this doesn't matter anymore, because timeline stuff does not pass streams down to nested demuxers anymore.
* manpage: update input protocolswm42019-11-041-55/+20
| | | | | | | | | tv:// and pvr:// are gone, DVD almost. The former didn't really have any uses left, except webcams. Provide a replacement example for that. We don't need a separate section for DVD. If you use DVD, you're on your own. There's still enough documentation left to puzzle things together even if you don't read the source code.
* manpage: opengl-cb -> libmpvwm42019-11-041-5/+5
| | | | | This was renamed ages ago. Fix the outdated usage. Except where opengl-cb was correct.
* manpage: fix global config file path in --hwdec descriptionwm42019-11-041-1/+1
|
* build: fix strict ABI optionwm42019-11-041-0/+1
| | | | Fixes: #7118
* manpage: shovel around --hwdec description (again)wm42019-11-041-25/+39
| | | | | | | Not like anyone reads it. Although putting all this text before listing the allowed option values sort of has the intention to discourage users from using the option at all. Advertise Ctrl+h, which is a decent way of enabling hardware decoding temporarily.
* DOCS/interface-changes.rst: improve entry about sws changeswm42019-11-031-2/+7
| | | | | This was pretty vague. Add some context, and explicitly mention how these options now affect screenshots.
* img_format: remove some unused format flagswm42019-11-033-26/+3
| | | | | | | | | | | | | | | | | They were used at some point, but then fell into disuse. In general, these old flags are all a bit fuzzy, so it's a good idea to remove them as much as possible. The comment about MP_IMGFLAG_PAL isn't true anymore. The old meaning was deprecated at some point, and the flag was removed from "pseudo paletted" formats. I think mpv at one point changed its own flag from AV_PIX_FMT_FLAG_PSEUDOPAL to AV_PIX_FMT_FLAG_PAL, when the former was deprecated, and it became unnecessary to allocate a palette for non-paletted formats. (The one who deprecated in FFmpeg was me, if you wonder.) MP_IMGFLAG_PLANAR was used in command.c, use a relatively similar flag as replacement.
* vo_x11: accept zimg formatswm42019-11-031-1/+2
| | | | | | | | | | | | This is slightly helpful for testing, and otherwise useless and without consequence. I'm not using the correct output format and using IMGFMT_RGB0 as placeholder. This doesn't matter currently, as both sws and zimg support this as output (and support any input for it). I'm doing this because it's surprisingly tricky to get the correct output format at this point, without digging deeper into x11 shit or refactoring parts of the VO. I don't care enough about this.
* sws_utils: remove some unnecessary sws bug work aroundwm42019-11-031-11/+0
| | | | | Seems like this was needed in 2012. The comment indicates the bug was fixed in ffmpeg git, so it's long gone.
* vd_lavc: don't keep packets for fallbacks if errors are toleratedwm42019-11-022-1/+8
| | | | | | | | | | | | | | The user can raise the number of tolerated hardware decoding errors. On the other hand, we have a static limit on packets that are "saved" for fallback handling (and that's a good idea to avoid unbounded memory usage). In this case, it could happen that the start of a file was fine after a fallback, but after that buffered amount of data, it would suddenly skip. It's more useful to skip buffering entirely if the number of tolerated decoding errors exceeds the fixed buffer. (And also, I'm sure nobody gives a shit about this feature.)
* vd_lavc: fix prepare_decoding() failure modeswm42019-11-021-9/+14
| | | | | | | | | | | | prepare_decoding() returned a bool that was supposed to tell whether decoding could work, or if something was fucked. After recent changes to the decoder loop, this did not work anymore, and caused an endless loop. Redo it, so it makes more sense. avctx being NULL (software fallback initialization failed) now signals EOF. hwdec_failed needs to be handled on send_packet() only, where it probably never happens anyway. (Who was the idiot who made libavcodec have two entrypoints for decoding? Oh right, it was me. PEBKAC.)
* vd_lavc: mention hw decoding if decoding fails in hwdec modewm42019-11-021-1/+2
| | | | Just so the user knows. Provides some context.
* vd_lavc: simplify fallback handling for full stream hw decoderwm42019-11-022-21/+19
| | | | | | | | | | | | Shovel the code around to make the data flow slightly simpler (?). At least there's only one send_packet function now. The old code had the problem that send_packet() could be called even if there were queued packets; due to sending the queued packets in the receive_frame function, this should not happen anymore (the code checking for this case in send_packet should normally never be called). Untested with actual full stream hw decoders (none available here); I created a test case by making hwaccel decoding fail.
* vd_lavc: signal packet consumed in drop-all casewm42019-11-021-1/+1
| | | | | This is just a very special code path. This probably got stuck, now that the previous commit returned the EAGAIN properly. Untested.
* vd_lavc: change incorrect bool return type to intwm42019-11-021-1/+1
| | | | | | | | Forgotten in commit 5d5fdb7. This failed to return the error code properly. In particular, if the decoder rejected the packet, this was not properly detected. Normally, this mattered only in specific cases. Fixes: #7115
* README.md: reduce focus on MPlayer, small improvementswm42019-11-021-9/+20
| | | | | | | | MPlayer isn't all too well-known anymore. It does not make sense to "advertise" with it (and it actually never did). The GPU comment needed clarification. I think originally, it was just to signal that you'll have a bad time with Intel. Make that broader.
* zimg: support subsampled chroma with non-aligned image sizeswm42019-11-021-2/+9
|
* zinmg: stop using GBRP for RGBwm42019-11-021-23/+28
| | | | | | | | | | | | | | | Instead, use a YUV planar format. It doesn't matter, since we use the format only internally and for "management" purposes. We're only interested in the physical layout, not what colorspace FFmpeg "forcibly" associates with it. Also get rid of using the old and slightly sketchy mp_imgfmt_find() function. Yep, the IMGFMT_RGB30 now "constructs" the planar format, instead of using a pixfmt constant. Slightly inconvenient, tricky, and fragile, but I like it, so bugger off. This whole thing gets rid of some of the strange plane permutations that were needed earlier.
* zimg: correct RGB30 order (probably)wm42019-11-021-1/+1
| | | | | | | | According to the definition of the GL format, and the definition in img_format.h, and the actual output by vo_gpu, the order of components was probably wrong. It's exceedingly likely that the vo_drm format (for which this was originally written) has the same layout, so this was probably a bug from when the zimg wrapper code was refactored.
* video: mess with the filte chain to enable zimg IMGFMT_RGB30 outputwm42019-11-024-8/+7
| | | | | | | | | | | This was too hardcoded to libswscale. In particular, IMGFMT_RGB30 output is only possible with the zimg wrapper, so the context needs to be taken into account (since this depends on the --sws-allow-zimg option dynamically). This is still slightly risky, because zimg currently will still fall back to swscale in some cases, such as when it refuses to initialize the particular color conversion that is requested. f_autoconvert.c could actually handle this better, but I'm tool fucking lazy right now, and nobody cares anyway, so go away, OK?
* vo_gpu: opengl: add support for IMGFMT_RGB30wm42019-11-021-0/+11
| | | | | | | | This integrates it as "special" format, with no alpha component, as the equivalent IMGFMT_RGB30 isn't meant to contain any. Nothing can produce this format in the video chain yet, so the next commits are needed to make this actually work.
* ass_mp: reset packer when allocation failsDan Elkouby2019-11-021-1/+3
| | | | | | | | | Sometimes the atlas can get so large that it exceeds the maximum allowed size for an mp_image. Since the atlas will never shrink naturally, this breaks subtitles entirely until mpv is restarted. Reset the packer so that subtitles can rendered properly once the atlas fits again. This is a partial workaround for #6286.
* manpage: update --framedrop optionwm42019-11-021-10/+26
| | | | | | | | | | | | | The statement about the display FPS is outdated by several years. "audio"-sync mode does not use the display FPS anymore, and that it's X11 only also isn't true anymore. These modes have separate implementations for audio and display video sync. modes, so the explanations are separate. Why the hell are users playing around with this anyway? The explanations are probably too special to make sense for anyone who doesn't know the code (and who knows the code doesn't need them anyway), but whatever.
* zimg: make --zimg-fast=yes defaultwm42019-11-023-2/+2
| | | | | | This is mostly just because of the odd RGB default gamma issue, which shouldn't have any real impact. This also sets allow_approximate_gamma, which I hope is fine for normal use cases.
* zimg: pass through Y plane when repacking nv12wm42019-11-021-31/+38
| | | | | | | | | | | | | | | Normally, the Y plane can just be passed directly to zimg, and only the chroma plane needs to be (de)interleaved. It still needs a copy if the Y pointer is not aligned, though. (Whether this is actually a problem depends on the CPU and probably zimg's compiler.) This requires deciding per plane whether the plane should go through the repack buffer or not. This logic is active in non-nv12 cases, because not doing so would require extra code (maybe 2 lines or so). repack_align is now always called, even if it's planar->planar with all input aligned, but it won't actually do anything in that case. The assumption is that zimg won't change behavior if you pass a callback that does nothing versus passing NULL as callback.
* zimg: add semi-planar repackerwm42019-11-021-1/+123
| | | | | | | | | | | | | | | | This is for formats like nv12 (including p010, nv24, etc.). Might be important for hardware decoding. Previously, this would have forced a libswscale fallback. The genericism makes this only slightly more complicated. The main complication is due to the fact that mixing planar and packed stuff is insane (thanks, Nvidia). P010 output will actually happily set any of the 6 bit "padding" LSB, that are normally supposed to be 0 (for unpadded data there is P016). Scaling happens with 16 bit precision. Not going to bother adding an extra packer which zeros them out, or with shifting them in packing/unpacking. Lets just hope nobody notices.
* img_format: add function to find image format by layoutwm42019-11-022-0/+36
| | | | | | This is similar to mp_imgfmt_find(), but probably a bit saner. Used by the next commit. The previous commit is required to map this unambiguously between all formats.
* img_format: add mp_regular_imgfmt.forced_csp fieldwm42019-11-022-0/+7
| | | | | | As the code comment says, this is needed to disambiguate FFmpeg formats. This struct only describes the "physical" layout of a format, while FFmpeg also attaches part of the colorspace information to the format.
* img_format: add more explanations to component_pad fieldwm42019-11-021-0/+5
| | | | | Weird shit. I thought this was a clever way to elegantly handle two cases at once, but maybe it's just confusing.
* zimg: fix out of bounds memory accesses due to broken zmaskwm42019-11-021-39/+37
| | | | | | | | | We've set all planes to the same zmask. But for subsampled chroma, the zmask obviously needs to be smaller. This could lead to out of bounds memory read and write accesses. Move the align repacker to a single function, since this is now more convenient.
* github: we want a -v -v log nowwm42019-11-011-1/+1
| | | | | --log-file uses debug log level by default. On command line, -v -v will use debug log level.
* f_decoder_wrapper: reduce uninit message log levelwm42019-11-011-1/+1
| | | | For vd/ad.
* client API: reduce log level of client exitingwm42019-11-011-1/+1
| | | | See previous commit message.
* demux: reduce log level for cache index resizingwm42019-11-011-2/+2
| | | | Now that I probably removed all bugs in this (?), this is uninteresting.
* lua: change config file loggingwm42019-11-011-2/+3
| | | | | | | | Make the existing "not found" messages debug only, and add a new verbose message if a config file was opened. The idea is that logging should make it apparent whether or not config files are loaded, and it's more common to use scripts without config files, leading to fewer log messages in verbose mode.
* x11: reduce log level for relatively uninteresting thingswm42019-11-011-9/+9
| | | | | Normally nobody cares about the WM detection stuff etc., so log this only at debug log levels.
* demux_mkv: reduce log level of mkvinfo part to debugwm42019-11-011-61/+58
| | | | | | demux_mkv has lots of logging that shows information about the file. It sort of reminds of mkvinfo output. While this is sometimes interesting, it's too much for verbose mode, and should be in debug log level.
* m_config: log applying profileswm42019-11-011-0/+1
|
* m_config: raise log level of setting options to verbosewm42019-11-011-2/+2
| | | | | | | | In 2017, we lowered this to debug level. But I think setting options is important enough that it should be logged even in verbose, at least compared to all the other dumb noise. This might be reduced again if verbose logging becomes much cleaner.
* zimg: add more packers/unpackerswm42019-10-311-59/+106
| | | | | | | | This probably covers all packed formats which have byte-aligned component, no alpha, and no subsampling. Everything else needs more imgfmt metadata, or something even more complicated. Alpha is primarily not supported, because zimg requires a second scaler instance for it, and handling packing/unpacking with it is an unacceptable mess.
* m_option: remove an unused functionwm42019-10-312-12/+0
| | | | I think the last real use of this went away in 2014 or so.
* options: make --show-profile without parameters list all profileswm42019-10-313-9/+17
|
* manpage: fix another typowm42019-10-311-1/+1
|
* manpage: update --zimg-scaler defaultwm42019-10-311-3/+3
| | | | Forgotten in previous commit.
* sws_utils, zimg: destroy vo_x11 and vo_drm performancewm42019-10-319-44/+133
| | | | | | | | | | | | | | | | | | | | | | | | | Raise swscale and zimg default parameters. This restores screenshot quality settings (maybe) unset in the commit before. Also expose some more libswscale and zimg options. Since these options are also used for VOs like x11 and drm, this will make x11/drm/etc. much slower. For compensation, provide a profile that sets the old option values: sw-fast. I'm also enabling zimg here, just as an experiment. The core problem is that we have a single set of command line options which control the settings used for most swscale/zimg uses. This was done in the previous commit. It cannot differentiate between the VOs, which need to be realtime and may accept/require lower quality options, and things like screenshots or vo_image, which can be slower, but should not sacrifice quality by default. Should this have two sets of options or something similar to do the right thing depending on the code which calls libswscale? Maybe. Or should I just ignore the problem, make it someone else's problem (users who want to use software conversion VOs), provide a sub-optimal solution, and call it a day? Definitely, sounds good, pushing to master, goodbye.
* screenshot, vo_image: use global swscale/zimg parameterswm42019-10-316-12/+35
| | | | | | | | | | Lots of dumb crap to do... something. Instead of adding yet another dumb helper, just use the main" sws_utils API in both callers. (Which, unfortunately, has been duplicated for glorious webp screenshots, despite the fact that webp is crap.) Good part: can enable zimg for screenshots (as far as needed). Bad part: uses "default" swscale parameters instead of HQ now.
* sws_utils: shuffle around some shitwm42019-10-3111-41/+72
| | | | | | | | | | | Purpose uncertain. I guess it's slightly better, maybe. The move of the sws/zimg options from VO opts (vo_opt_list) to the top-level option list is tricky. VO opts have some helper code in vo.c, that sends VOCTRL_SET_PANSCAN to the VO on every VO opts change. That's because updating certain VO options used to be this way (and not just the panscan option). This isn't needed anymore for sws/zimg options, so explicitly move them away.
* Use mp_log2() instead of av_log2()wm42019-10-313-11/+7
|
* common: add mp_log2()wm42019-10-312-0/+20
| | | | | | | | | | | To be used in the next commit. According to compiler explorer, __builtin_clz is very widely available, and it barely makes sense to provide a fallback. clang also eats this (and identifies at least as GCC 4). Actually, there's doubt that a fast log2 implementation is needed at all (I guess UTF-8 parsing needs it, but something UTF-8-specific would probably make it faster than using log2). So the fallback is just something naive.
* Replace uses of FFMIN/MAX with MPMIN/MAXwm42019-10-3116-78/+66
| | | | And remove libavutil includes where possible.
* stream_memory: remove trivial ffmpeg dependencywm42019-10-311-3/+1
|
* manpage: document stats page 3wm42019-10-311-0/+3
|
* player: simplify --stream-dump codewm42019-10-311-4/+4
| | | | | Not sure why it was so complicated. It avoided allocation data on the stack and copying it twice, but who cares.
* stream: move stream_read_line to demux_playlist.cwm42019-10-313-72/+72
| | | | | demux_playlist.c is the only remaining user of this. Not sure if it should stay this way, but for now I'll say yes.
* stream: stop accessing buffer internals in stream_read_line()wm42019-10-312-8/+16
| | | | | Getting this out of the way in preparation for reworking stream internals.
* interface-changes: fixup the location of d3d11-output-cspJan Ekström2019-10-301-1/+2
| | | | 0.30.0 is already cut, so +1 it is.
* vo_gpu/opengl: fully initialize FBO when passing it to renderingJan Ekström2019-10-301-2/+4
| | | | | | | Until now, we only properly initialized two values, leaving the rest be garbage. Fixes #7104
* vo_gpu/d3d11: add support for configuring swap chain color spaceJan Ekström2019-10-305-5/+198
| | | | | | | | | | | | | | | | By default utilizes the color space of the desktop on which the swap chain is located. If a specific value is defined, it will be instead be utilized. Enables configuration of the PQ color space (BT.2020 primaries, PQ transfer function) for HDR. Additionally, signals the swap chain color space to the renderer, so that the render looks correct without having to specify target-trc or target-prim manually. Due to all of the APIs being Win10+ only, will only work starting with Windows 10.
* vo_gpu/d3d11: add helpers for getting names for DXGI formats & CSPsJan Ekström2019-10-302-4/+178
| | | | | Additionally, define the few enum values that are currently missing in mingw-w64 headers.
* vo_gpu: add and utilize color space information from ra_fboJan Ekström2019-10-302-8/+40
| | | | | | | | This lets us set primaries, transfer function and the target peak based on what the presenting layer would want us to have. Now that this mechanism is available, warn if the user has overridden values such as primaries or transfer function.
* osc: calculate osc_geo position after aspect correctionJan Janssen2019-10-291-6/+8
| | | Fixes #7098
* vo_caca: Implement VOCTRL_UPDATE_WINDOW_TITLECameron Cawley2019-10-291-2/+4
|
* osc: Unify bottom and topbar codeJan Janssen2019-10-282-181/+33
| | | | | | Among the pointless duplication the right timecode label was given some extra space that wasn't needed. Fixes: #6904
* manpage: Update information about default mouse bindingsCameron Cawley2019-10-281-3/+12
|
* vo_sdl: Acknowledge when the mouse enters or leaves the windowCameron Cawley2019-10-281-0/+6
|
* input: Add default bindings for MBTN_BACK and MBTN_FORWARDCameron Cawley2019-10-281-0/+2
|
* vo_sdl: Improve mouse button inputCameron Cawley2019-10-281-6/+28
| | | | SDL_BUTTON_X1 and SDL_BUTTON_X2 are now correctly mapped to MP_MBTN_BACK and MP_MBTN_FORWARD.
* vo_sdl: Support mouse wheel inputCameron Cawley2019-10-281-1/+11
|
* DOCS/release-policy.md: clarify a few detailssfan52019-10-271-3/+7
|
* vo_gpu: log ra_format.storable with the other flagsJames Ross-Gowan2019-10-271-3/+5
| | | | | | This seems to have been missed when the storable flag was added, since all the other flags were logged here. It can be useful to know if an RA format is storable, so log it as well.
* vo_gpu: d3d11: set the ra_format.storable flagJames Ross-Gowan2019-10-271-3/+12
| | | | | This flag was added in e2976e662d92, but it was only set for Vulkan. In D3D11 it can be set from info in D3D11_FEATURE_FORMAT_SUPPORT2.
* vo_gpu: attempt to fix 0bgr formatwm42019-10-261-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | Using e.g. --vf=format=0bgr showed obviously wrong colors with --vo=gpu. The reason is that leading padding wasn't handled correctly. Try to hack fix it. While the code in copy_image() is somewhat reasonable, I can't tell what the fuck is going on with that HOOKED shit. For some reason this HOOKED shit doesn't use copy_image() (???), or uses it incorrectly. It affects debanding. --deband=no works correctly. If it's enabled, the crap in hook_prelude() is needed. I bet there are many more bugs with this. For example, the deband shader will try to deband the alpha channel if the format abgr is used (because the correct component order is only established later). This can be tested by inserting a "color.x = 0;" at the end of the deband shader, and using --vf=format=rgba vs. abgr. I cannot comprehend why it doesn't just store explicitly which components a texture contains, and why it doesn't just read the components always in an uniform way. There's a big chance this fix works only by coincidence. This shouldn't have been so hard either. Time for a complete rewrite?
* mp_image: copy closed captions when copying attributeswm42019-10-251-0/+1
| | | | | | | | | | With hwdec copy modes, mp_image_copy_attributes() is used to transfer metadata other than the image data when copying the image from the hardware surface. It didn't copy the closed caption data. Fix this. This makes closed captions in copy mode work. Fixes: #6376
* mp_image: move buffer ref assigning to a functionwm42019-10-251-7/+10
| | | | | | | Mostly untested, for the next commit. There's another case of this in this file (ref_buffer()), but it's too weird, so ignore it.
* sdl: prevent concurrent use of SDL in different threadswm42019-10-252-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | sdl_gamepad.c and vo_sdl.c both have their own event loops and run in separate threads. They don't know of each other (and shouldn't). Since SDL only has one global event loop (why didn't they fix this in SDL2?), these obviously clash. The actual behavior is relatively subtle, which event being randomly dispatched to either of the threads. This is very regrettable. Very. Work this around. "Fortunately" SDL exposes its global state to some degree. SDL_WasInit() returns whether a "subsystem" was initialized, and you could say the one who initialized it owns it. Both SDL_INIT_VIDEO and SDL_INIT_GAMECONTROLLER implicitly enable SDL_INIT_EVENTS, and the event loop is indeed the resource that cannot be shared. Unfortunately, this is still racy, since SDL_InitSubSystem is a second call, and succeeds if the subsystem is already initialized (increases a refcount I think). But good enough. Blame SDL for everything. (I think I made this commit message too long. Nobody cares even.) Fixes: #7085
* build: make vo_sdl conflict with cocoawm42019-10-251-0/+1
| | | | | | | | | | These are inherently incompatible. As far as I'm aware, SDL must be used from the main thread on OSX. (Technically, this condition is wrong: the problem happens on OSX in general, or more precisely, when SDL uses Cocoa. I didn't find the waf OSX dependency name after 5 second of searching, so I'm just using cocoa, without which mpv is useless on OSX anyway.)
* vo_sdl: put on do not use stampwm42019-10-251-0/+3
| | | | | | | | | It seems some users try to use it (!). This VO was always an experiment, and intended for low power devices. Whether this experiment succeeded or not, it's a rather obscure VO. Recently I've seen a regrettable user, who seemed to use this only because mpv was built without x11 support (!). Add this warning, like other fallback VOs have it. (The message was copied from vo_x11.)
* input: disable gamepad code by defaultwm42019-10-253-5/+1
| | | | | | | Enabling this by default probably causes a number of issues, such as breaking vo_sdl, or reacting to various input devices while the window is not focused. It's also pretty obscure, or at least new. Disable it by default.
* f_decoder_wapper: trust frame return over error codewm42019-10-251-5/+5
| | | | | | | | | | | | | | | | | lavc_process() calls the receive/send callbacks, which mirror libavcodec's send/receive API. The receive API in particular can return both a status code and a frame. Normally, libavcodec is pretty explicit that it can't return both a frame and an error. But the receive callback does more stuff in addition (vd_lavc does hardware decoding fallbacks etc.). The previous commit shows an instance where this happened, and where it leaked a frame in this case. For robustness, check whether the frame is set first, i.e. trust it over the status code. Before this, it checked for an EOF status first. Hopefully is of no consequence otherwise. I made this change after testing everything (can someone implement a test suite which tests this exhaustively).
* vd_lavc: fix draining with hwdec copy modeswm42019-10-251-4/+4
| | | | | | | | | | | | | | | | | | | | | | Commit 5d5fdb77e99 changed details of the decoding control flow, and called it a "high-risk" change. It turns out that this broke with with hwdec copy mode, where there is some sort of delay queue (supposedly increases efficiency, but more likely worthless cargo-cult). It simply used the wrong (basically inverted) condition for the draining case. This was the only case that did not work properly. Other tests, including video/audio decoding errors, software decoding fallbacks, etc., seemed to work well. Might still not be exhaustive, as there are so many corner cases. Also change two error code returns. This don't/shouldn't really matter, though the second error code led it to return both a frame and AVERROR_EOF, which is unexpected, and makes lavc_process() leak a frame. But also see next commit. Fixes: 5d5fdb77e99
* vo_gpu: d3d11: prevent wraparound in queued frames calcJames Ross-Gowan2019-10-261-1/+2
| | | | | | | If expected_sync_pc is greater than submit_count, the unsigned subtraction will wraparound, which breaks playback. This bug was found while experimenting with bit-blt model present, but it might be possible to trigger it with the flip model as well, if there was a dropped frame.
* Update VERSIONsfan52019-10-251-1/+1
|
* Merge branch 'release/0.30'sfan52019-10-252-135/+77
|\
| * Release 0.30.0v0.30.0release/0.30sfan52019-10-252-135/+77
| |
| * manpage: fix --script docswm42019-10-251-3/+3
| | | | | | | | | | | | | | | | This doesn't take a ',' separated list. --script is just an alias for --scripts--append. --scripts accepts a list, but uses the mplayer-inherited platform-dependent path separator. Fixes: #5996
| * command: remove some unused property metadatawm42019-10-251-16/+2
| | | | | | | | Also add an OSD entry for the video aspect.
| * options: set correct range for --video-aspect-overridewm42019-10-251-3/+2
| | | | | | | | | | It appears this option didn't have min/max enabled for quite a while (broken while it was still called --aspect).
| * json: write NaN/Infinity float values as stringswm42019-10-251-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | JSON doesn't support these for some god-awful reason. (JSON would have been so much better if it weren't based on JavaScript, the plague of this world.) We don't really care whether these specific values "round trip", so we might as well write them in a standard-compliant way. Untested. I was too lazy to even run this, but it probably works. See #6691.
| * vo_gpu, options: don't return NaN through APIwm42019-10-256-19/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Internally, vo_gpu uses NaN for some options to indicate a default value that is different depending on the context (e.g. different scalers). There are 2 problems with this: 1. you couldn't reset the options to their defaults 2. NaN is a damn mess and shouldn't be part of the API The option parser already rejected NaN explicitly, which is why 1. didn't work. Regarding 2., JSON might be a good example, and actually caused a bug report. Fix this by mapping NaN to the special value "default". I think I'd prefer other mechanisms (maybe just having every scaler expose separate options?), but for now this will do. See you in a future commit, which painfully deprecates this and replaces it with something else. I refrained from using "no" (my favorite magic value for "unset" etc.) because then I'd have e.g. make --no-scale-param1 work, which in addition to a lot of effort looks dumb and nobody will use it. Here's also an apology for the shitty added test script. Fixes: #6691
* | sdl_gamepad: fix typo in function namewm42019-10-251-2/+2
| | | | | | | | As pointed out by LaserEyess on IRC.
* | sdl_gamepad: fix function signaturewm42019-10-251-1/+1
| | | | | | | | This is semantically different in C.
* | vo_drm: allow use of zimgwm42019-10-251-0/+1
| |
* | client API: copy instead of move old value on async pathwm42019-10-251-4/+1
| | | | | | | | | | | | | | | | In theory, it's better to keep the old value, because that's more consistent with the logic of using change timestamps. With the current code, the old value will probably never be used (instead it will fetch a new value on every change), so this shouldn't make a difference in practice.
* | manpage: fix --script docswm42019-10-251-3/+3
| | | | | | | | | | | | | | | | This doesn't take a ',' separated list. --script is just an alias for --scripts--append. --scripts accepts a list, but uses the mplayer-inherited platform-dependent path separator. Fixes: #5996
* | client API: add async path; fix deadlock for vo_libmpv userswm42019-10-251-9/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 065c307e8e7db, I broke everything. It seemed like a nice idea, but it explicitly broke an assumption vo_libmpv were explicitly allowed to make: that observing properties does not lock the core. The commit did just that and locked the core for property updates. This made for example mpv's own OSX backend freeze (it uses vo_libmpv for convenience to make up for Apple's incredibly broken OpenGL shit). I don't want to revert that commit just because vo_libmpv's design is horrible. So instead add an optional asynchronous path, that is only used if vo_libmpv is in use (best idea ever?). Interestingly, this isn't so hard. It adds about 90 lines of code, which are only run on OSX and libmpv users, so I don't have to care about the crashes and weird behavior this might cause. It even worked on the first try except for a quickly fixed memory leak. The code path can be tested anywhere by just turning the uses_vo_libmpv condition into always true. The atomic is out of laziness. Saves some thinking how to get around the locking order.
* | command: remove some unused property metadatawm42019-10-251-16/+2
| | | | | | | | Also add an OSD entry for the video aspect.
* | options: set correct range for --video-aspect-overridewm42019-10-251-3/+2
| | | | | | | | | | It appears this option didn't have min/max enabled for quite a while (broken while it was still called --aspect).
* | json: write NaN/Infinity float values as stringswm42019-10-251-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | JSON doesn't support these for some god-awful reason. (JSON would have been so much better if it weren't based on JavaScript, the plague of this world.) We don't really care whether these specific values "round trip", so we might as well write them in a standard-compliant way. Untested. I was too lazy to even run this, but it probably works. See #6691.
* | vo_gpu, options: don't return NaN through APIwm42019-10-256-19/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Internally, vo_gpu uses NaN for some options to indicate a default value that is different depending on the context (e.g. different scalers). There are 2 problems with this: 1. you couldn't reset the options to their defaults 2. NaN is a damn mess and shouldn't be part of the API The option parser already rejected NaN explicitly, which is why 1. didn't work. Regarding 2., JSON might be a good example, and actually caused a bug report. Fix this by mapping NaN to the special value "default". I think I'd prefer other mechanisms (maybe just having every scaler expose separate options?), but for now this will do. See you in a future commit, which painfully deprecates this and replaces it with something else. I refrained from using "no" (my favorite magic value for "unset" etc.) because then I'd have e.g. make --no-scale-param1 work, which in addition to a lot of effort looks dumb and nobody will use it. Here's also an apology for the shitty added test script. Fixes: #6691
* | client API: avoid lost wakeupswm42019-10-241-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | The commit linked below added temporary unlocking to update_prop(), which is indirectly called by mpv_wait_event(). If an unlock happens, and no property change event is returned, we must re-poll the event queue. Rechecking the state on unlocks is basically a standard requirement for code using condition variables. Untested beyond a simple test. Fixes: 065c307e8e7dbf
* | ad_lavc, vd_lavc: return full error codes to shared decoder loopwm42019-10-244-56/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ad_lavc and vd_lavc use the lavc_process() helper to translate the FFmpeg push/pull API to the internal filter API (which completely mismatch, even though I'm responsible for both, just fucking kill me). This interface was "slightly" too tight. It returned only a bool indicating "progress", which was not enough to handle some cases (see following commit). While we're at it, move all state into a struct. This is only a single bool, but we get the chance to add more if needed. This fixes mpv falling asleep if decoding returns an error during draining. If decoding fails when we already sent EOF, the state machine stopped making progress. This left mpv just sitting around and doing nothing. A test case can be created with: echo $RANDOM >> image.png This makes libavformat read a proper packet plus a packet of garbage. libavcodec will decode a frame, and then return an error code. The lavc_process() wrapper could not deal with this, because there was no way to differentiate between "retry" and "send new packet". Normally, it would send a new packet, so decoding would make progress anyway. If there was "progress", we couldn't just retry, because it'd retry forever. This is made worse by the fact that it tries to decode at least two frames before starting display, meaning it will "sit around and do nothing" before the picture is displayed. Change it so that on error return, "receiving" a frame is retried. This will make it return the EOF, so everything works properly. This is a high-risk change, because all these funny bullshit exceptions for hardware decoding are in the way, and I didn't retest them. For example, if hardware decoding is enabled, it keeps a list of packets, that are fed into the decoder again if hardware decoding fails, and a software fallback is performed. Another case of horrifying accidental complexity. Fixes: #6618
* | client API: simplify (?) property change notification generationwm42019-10-241-75/+79
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Property change notification works by having the mpv core wake up all clients observing a property when the property potentially changes. The clients then read the property's value, and determine if there was an actual change. (The latter part depends what the property returned for the previous change notification, so it depends on the client, and cannot be generated by the core itself.) Until now, reading the property value was done in a pseudo-async way by queuing a callback back to the core, running it there, and then waking up the client thread again. I cannot comprehend why this was done in such a complicated, fragile way. Maybe it's a leftover from times when client.c had to do this (in short, because properties could access vo_opengl, which has thread-local state). One past idea was to make the implementation of true async properties easier (for which you would need such a state machine anyway). But they don't exist yet, and I doubt the current mess would be really helpful when actually implementing them. Simplify this, and run the update in the client's thread directly. In addition to the fundamental change, many roundabout things can be removed as a consequence. Unfortunately, I noticed that lock order issues force you to release ctx->lock before doing so, which makes things more complex due to possible concurrent mpv_unobserve_property() calls. Solve this by removing properties lazily, which means you may have to do multiple mpv_wait_event() calls before the property entry is actually destroyed. This should not matter in practice, and does not affect the semantics. It could also cause "leaks" by observing/unobserving properties in a loop, without ever calling mpv_wait_event(). Just don't do this, duh. (I considered making this dependent on whether the previous mpv_wait_event() call returned the property being removed, but a separate code path seemed too complicated. I also considered copying the name and property data when returning a MPV_EVENT_PROPERTY_CHANGE, but actually this doesn't solve the problem of update_prop() being interrupted by mpv_unobserve_property(); there are ways around it, but I just said no.) This was made using the cowboy coding software engineering methodology. If you find any bugs, keep them yourself.
* client API: move a functionwm42019-10-241-7/+7
| | | | May reduce the diff of the next commit.
* client API: remove unused global event maskwm42019-10-242-36/+0
| | | | | | Apparently this was only added and used for cache update stuff, which was changed in commit 8dbc93a94cdc3c. Now it's unused, messy, ugly, and is in the way, so get rid of it.
* lua: actually unobserve properties in mp.unobserve_property()wm42019-10-241-0/+1
| | | | | | | | | Not doing this looked like a memory leak. This looks like an oversight in the commit that added it: a94020e25bc5f, possible brain damage? Fixes: #6823
* demux_mkv: add V_MPEG4/MS/V3 mappingwm42019-10-241-0/+1
| | | | Fixes: #6547
* msg: always use terminal control codes for status linewm42019-10-241-6/+3
| | | | | | | | | | | Before this commit, the status line used terminal control codes only if stderr was a terminal. I'm not sure why this was done, and git blame tracks it back to a huge commit by me, which changed all of the terminal handling. A user complained, so just stop treating this specially for no reason. Fixes: #6617
* ytdl_hook: --vid=no should not ignore --ytdl-format in config filewm42019-10-241-3/+1
| | | | | | Do this only if ytdl-format was not set at all. Fixes: #6636
* manpage: fix RST formatting errorin vf_format descriptionwm42019-10-241-1/+1
|
* manpage: slap "do not use" label on vf_vapoursynthwm42019-10-241-4/+10
| | | | Plus some other minor corrections.
* vf: improve vf_vapoursynth descriptionwm42019-10-231-18/+71
| | | | | | | In particular describe dataflow issues (see #7020). Insert complaint that I'm wasting time on this crap instead of things that benefit me.
* input: add gamepad support through SDL2Stefano Pigozzi2019-10-2312-8/+378
| | | | | | | | | | | | | | | The code is very basic: - only handles gamepads, could be extended for generic joysticks in the future. - only has button mappings for controllers natively supported by SDL2. I heard more can be added through env vars, there's also ways to load mappings from text files, but I'd rather not go there yet. Common ones like Dualshock are supported natively. - analog buttons (TRIGGER and AXIS) are mapped to discrete buttons using an activation threshold. - only supports one gamepad at a time. the feature is intented to use gamepads as evolved remote controls, not play multiplayer games in mpv :)
* DOCS/client-api-changes.rst: fix formattingsfan52019-10-221-0/+1
|
* wayland: don't get data device if wl_seat is nulldudemanguy2019-10-221-2/+2
|
* manpage: finish an unfinished sentencewm42019-10-211-5/+7
|
* build: add --enable-ffmpeg-strict-abi optionwm42019-10-212-0/+8
| | | | | | | | | This can be used by distros to disable all known FFmpeg ABI violations. Currently only 1 is known, in demux_lavf.c. In addition to if-defing out the access to the private FFmpeg field, this disables the possibly fragile nested open callbacks, which make sense only if the aforementioned field can be accessed.
* filters: extend vf_format so that it can convert color parameterswm42019-10-216-43/+165
| | | | | | | | | | | | | | | | | | | | | | | | | Form some reason (and because of my fault), vf_format converts image formats, but nothing else. For example, setting the "colormatrix" sub-parameter would not convert it to the new value, but instead overwrite the metadata (basically "reinterpreting" the image data without changing it). Make the historical mistake worse, and go all the way and extend it such that it can perform a conversion. For compatibility reasons, this needs to be requested explicitly. (Maybe this would deserve a separate filter to begin with, but things are messed up anyway. Feel free to suggest an elegant and simple solution.) This demonstrates how zimg can properly perform some conversions which swscale cannot (see examples added to vf.rst). Stupidly this requires 2 code paths, one for conversion, and one for overriding the parameters. Due to the filter bullshit (what was I thinking), this requires quite some acrobatics that would not be necessary without these abstractions. On the other hand, it'd definitely be more of a mess without it. Oh whatever.
* sws_utils: improve zimg fallback messageswm42019-10-211-2/+2
| | | | | | | | | This could log: [swscale] falling back to swscale And that's a WTF, even if you're aware of the fucky way zimg was hacked into the filter chain.
* vf_fingerprint: don't print fallback warning on each framewm42019-10-211-2/+0
| | | | | | | | f_reset, which is called on seeks, was a good place for resetting the warning flag (so the warning would be print again). Except some other code abused f_reset when all metadata was read (in both cases you want to clear the metadata). Instead of spending more time on getting this flag reset correctly, just never reset it.
* zimg: minor name consistency improvementwm42019-10-211-3/+3
| | | | | Now these are like x2ccc10_pack: MSB to LSB, with bit width following each component (except for components with the same bit width).
* f_swscale: enable use of zimgwm42019-10-211-0/+1
| | | | The usual opt-in mechanism.
* wayland: fix presentation timeDudemanguy9112019-10-205-2/+23
| | | | | | | | | | There's 2 stupid things here that need to be fixed. First of all, vulkan wasn't actually using presentation time because somehow the get_vsync function in context.c disappeared. Secondly, if the mpv window was hidden it was updating the ust time based on the refresh_usec but really it should simply just not feed any information to the vsync info structure. So this adds some logic to assume whether or not a window is hidden.
* zimg: support RGB30 outputwm42019-10-201-1/+30
| | | | This may be used later elsewhere.
* zimg: move component order arrays to top of filewm42019-10-201-4/+6
|
* img_format: add RGB30 formatwm42019-10-202-1/+24
| | | | | | | FFmpeg does not support this from what I can see. This makes supporting it a bit awkward. Later commits use this format.
* sws_utils: provide function to check whether a format pair is supportedwm42019-10-202-0/+18
| | | | | | | | | | | | Normally, input and output are orthogonal. But zimg may gain image formats not supported by FFmpeg, which means the conversion will only work if zimg is used at all. This on the other hand, depends on whether the other format is also supported by zimg. (For example, a later commit adds RGB30 output to zimg. libswscale does not support this format. But if you have P010 as input, which the zimg wrapper does not support at all, the conversion won't work.) This makes such a function needed; so add it.
* manpage: describe stride parameter in screenshot-raw commandwm42019-10-201-0/+6
| | | | | This is mentioned and called "obvious", but it's conceivable users don't necessarily know about the concept. Just explain it.
* build: lower required FFmpeg versionwm42019-10-202-1/+3
| | | | | | | | The FFmpeg version was last bumped a long time ago, except in commit 1638fa7b4663e4ad46ccd9750, where it was used for some obscure pixel format. This is pretty annoying, so make it optional.
* wayland: add various render-related optionsdudemanguy2019-10-207-5/+50
| | | | | The newest wayland changes have some new logic that make sense to expose to users as configurable options.
* wayland: add presentation timedudemanguy2019-10-206-7/+298
| | | | | Use ust/msc/refresh values from wayland's presentation time in mpv's ra_swapchain_fns.get_vsync for the wayland contexts.
* sws_utils: make libswscale fallback a warningwm42019-10-201-1/+1
| | | | | Surely a user passing --sws-allow-zimg wants to know if zimg is actually used.
* zimg: support 3 component 16 bit pixel unpackingwm42019-10-201-0/+22
| | | | | | Works for RGB (e.g. rgb48le) and XYZ. It's unsure whether XYZ is really correctly converted.
* zimg: avoid theoretical FFmpeg planar RGB/YUV mixupwm42019-10-201-5/+17
| | | | | | | | | | | | | The RGB pack/unpack code in theory supports packed, non-subsampled YUV, although in practice FFmpeg defines no such formats. (Only one with alpha, but all alpha input is rejected by the current code.) This would in theory have failed, because we would have selected a GBRP format (instead of YUV), which makes no sense and would either have been rejected by zimg (inconsistent parameters), or lead to broken output (wrong permutation of planes). Select the correct format and don't permute the planes in the YUV case.
* zimg: add some more colorspace mappingswm42019-10-201-5/+5
| | | | | | | As suggested by the zimg author. This is mostly related to XYZ support. It's unclear whether this works. Using the only XYZ test sample we know, and the next commits to consume the pixfmt, it looks wrong.
* vf_fingerprint: remove single-plane optimizationwm42019-10-201-31/+1
| | | | | | | | | | | | | | According to the zimg author, YUV->GREY conversion does not even read the chroma planes, as long as no matrix conversion is involved. Since we try to avoid the latter anyway by forcing the source parameters on the target image, passing only the Y plane will not help with anything. An unscientific test seems to confirm this, so remove this. This would probably help with libswscale (I didn't test this), but on the other hand, libswscale will rarely be used in cases where we can extract the Y plane. (Except nv12, which should probably be added to the zimg wrapper's unpacking.)
* vf_fingerprint: use generic zimg wrapperwm42019-10-201-79/+29
| | | | | Don't duplicate the API usage. The result should be approximately the same.
* mp_image: infer XYZ as BT.2020 instead of BT.709Niklas Haas2019-10-201-9/+8
| | | | | | | | | And update the comment both explaining why this defaulting matters and why we use BT.2020 instead. tl;dr BT.709 clips even the one test file we *do* have, so if we don't handle XYZ "natively" in vo_gpu we might as well at least handle it in a way that runs less risk of clipping
* csputils: fix outdated commentNiklas Haas2019-10-201-2/+4
| | | | | | This no longer hard-codes BT.709, it converts to whatever primaries are tagged in the same metadata struct. The actual BT.709 defaulting comes from `mp_image_params_guess_csp`.
* vo_x11: enable use of zimgwm42019-10-201-0/+2
| | | | | | | | This will perform conversion and scaling of video with zimg, if --sws-allow-zimg is used. The performance probably depends on how well the compiler optimizes the RGB pack code in zimg.c, which is written in C.
* sws_utils: hack in zimg redirection supportwm42019-10-203-3/+64
| | | | | | | | | | | | | | | | Awful shit. I probably wouldn't accept this code from someone else, just so you know. The idea is that a sws_utils user can automatically use zimg without large code changes. Basically, laziness. Since zimg support is still very new, and I don't want that anything breaks just because zimg was enabled at build time, an option needs to be set to enable it. (I have especially especially obscure stuff in mind, which is all what libswscale is used in mpv.) This _still_ doesn't cause zimg to be used anywhere, because the sws_utils user has to opt-in by setting allow_zimg. This is because some users depend on certain libswscale features.
* video: add zimg wrapperwm42019-10-206-1/+686
| | | | | | | | | | | | | | | | This provides a very similar API to sws_utils.h, which can be used to convert and scale from one mp_image to another. This commit adds only the code, but does not use it anywhere. The code is quite preliminary and barely tested. It supports only a few pixel formats, and will return failure for many others. (Unlike libswscale, which tries to support anything that FFmpeg knows.) zimg itself accepts only planar formats. Supporting other formats requires manual packing/unpacking. (Compared to libswscale, the zimg API is generally lower level, but allows for more flexibility.) Only BGR0 output was actually tested. It appears to work.
* mp_image: remove old acrobatics in frame copy codewm42019-10-201-21/+7
| | | | | | This used to be needed for the "GPU memcpy" (shitty Intel methods to deal with certain uncached memory types). This is now done in FFmpeg, and the code in mp_image.c was just unnecessarily convoluted.
* img_format: update test programwm42019-10-201-8/+16
| | | | | | | | | | | | The plane pointer checking assert() triggered at least on gray8, because that has a "pseudo palettes" in ffmpeg, which mpv refuses to allocate. Remove a strange duplicated printf(). Log the component type where available. (Why is this even here, I hate it when there are commented test programs in source files.)
* img_format: document a minor guarantee for certain imgfmt metadatawm42019-10-201-0/+1
|
* manpage: docoument stream-open-filename propertywm42019-10-201-0/+9
|
* vaapi: remove hacks for pre-libva2 log callbackswm42019-10-181-65/+0
| | | | | Instead, you ancient libva will do default logging, which means printing to stderr. Not a loss, just update your libva.
* manpage: fix a typowm42019-10-181-1/+1
|
* player: avoid duplicate track auto selectionStephan Hilb2019-10-181-1/+14
| | | | | | | | | Since a track may not be selected twice, it makes sense e.g. for secondary subtitles to select the next best match and avoid the duplicate selection. This allows for example `--slang=en,ja --secondary-sid=auto` to select 'en' as primary and 'ja' as secondary without needing to know the actual sid for 'ja'.
* video, demux: rip out unused spherical metadata codewm42019-10-178-132/+1
| | | | | | This was preparation into something that never happened. Spherical video is a shit idea anyway.
* vo_gpu: hwdec_d3d11egl: add missing P010 format to supported listwm42019-10-171-1/+1
| | | | | | | | This was obviously missing from the recent commit, which probably broke 10 bit decoding. The original commit didn't test this for lack of working hardware; this commit isn't tested either. Fixes: a1c7d613935424b69b3
* video: remove mp_image_params.hw_flags fieldwm42019-10-175-30/+0
| | | | | | | | This was speculatively added 2 years ago in preparation for something that apparently never happened. The D3D code was added as an "example", but this too was never used/finished. No reason to keep this.
* vo_wlshm: use memfd_create() instead of shm_open()Emmanuel Gil Peyrot2019-10-174-25/+19
| | | | | | | | | | | This syscall avoids the need to guess an unused filename in /dev/shm and allows seals to be placed on it. We immediately return if no fd got returned, as there isn’t anything we can do otherwise. Seals especially allow the compositor to drop the SIGBUS protections, since the kernel promises the fd won’t ever shrink. This removes support for any platform but Linux from this vo.
* video: do not disable display-sync on A/V desyncwm42019-10-173-13/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | On a audio/video desync by more than 0.5 seconds, display-sync mode was disabled, and not enabled again (until playback restart, e.g. a seek). The idea was that it this only happens when this playback mode is broken and can't perform well anyway (A/V desync is a clear indication that something is very wrong). Instead of behaving like a god damn POS, it should revert to the more robust audio-sync mode. Unfortunately, this could happen sporadically due to temporary system performance problems, such as toggling fullscreen. Users didn't like this, and asked for a function to disable it, or to recover in some other way. This mechanism is questionable anyway. If an ignorant user enables display-sync, and encounters problems with it (without being able to determine that display-sync is messing up), the player will still behave like a POS on every playback, and even after every seek. It might actually be helpful to fail more consistently. Also, I've found that it's sill relatively reliable anyway even without this mechanism. So just remove the fallback. Fixes: #7048
* Reintroduce vo_wayland as vo_wlshmMichael Forney2019-10-174-0/+323
| | | | | | | | vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
* manpage: update --hwdec descriptionwm42019-10-171-17/+8
| | | | | vdpaurb, vaapi-glx, and ANGLE's NV12-restriction are gone, making things much simpler.
* vf_d3d11vpp: remove RGB conversion hackwm42019-10-163-60/+6
| | | | | | | With the previous commit, this is dead code. This also makes the f_autoconvert.c code for this dead code (fortunately). Will probably remove this later.
* vo_gpu: hwdec_d3d11eglrgb: remove thiswm42019-10-163-282/+0
| | | | | Finally. Since with the previous commit we can (probably) handle P010 directly, this hack isn't needed anymore.
* vo_gpu: hwdec_d3d11egl: adapt to newer ANGLE APIwm42019-10-161-24/+33
| | | | | | | | | | | | | | | | | | | 2 years ago, ANGLE removed the old NV12-specific extension, and added a new one that supports a number of formats, including P010. Actually they just renamed it and removed their initial annoying and obvious design error (bravo, Google). Since it broke 2 years ago, nobody should give a shit about this code, and it should just be removed. But for some reason I still dived the shit-tank (Windows development). I guess Intel code monkeys can't write drivers (or maybe the issue is because we're doing zero-copy, which probably maybe is not actually allowed by D3D11 due to array textures, see --d3d11va-zero-copy), so the P010 path is completely untested. It doesn't work, I'll delete all this ANGLE hwdec code. Fixes: #7054
* vo_gpu/d3d11: fix memleak of the adapter description stringJan Ekström2019-10-151-1/+5
|
* vo_gpu/d3d11: remove unnecessary nullptr checkJan Ekström2019-10-151-2/+2
| | | | mp_to_utf8 will abort in case of either invalid input or OOM.
* vo_gpu/d3d11: switch adapter selection to case-insensitive startswithJan Ekström2019-10-153-4/+9
| | | | | | This lets users set values such as "intel" or "nvidia" as the adapter vendor is generally noted in the beginning of the description string.
* vo_gpu/d3d11: fixup adapter selection by switching it all to bstrJan Ekström2019-10-153-12/+8
| | | | | I did ponder if I should have done this right away, and it seems like not doing it at first was a mistake.
* etc/mpv.conf: update outdated use of cache optionswm42019-10-141-7/+10
| | | | | | | | | | | | | | The --cache option does not take a number anymore. (Oh boy, this is going to break a lot of user configs?) The cache site is now configured with those obscure-sounding --demuxer options. --cache-secs is not useful anymore. The default is very high, so the obscure-sounding --demuxer options determine how much is cached. Advertise the --cache-on-disk option a bit. I found it useful once, and it will trick users into wearing out their SSD for no gain, or so.
* manpage: attempt to remove some more cache option confusionwm42019-10-141-6/+7
| | | | | | OK, so --cache-secs is useless, because the default is set to 10 hours. And that part about the "maximum" was obviously a lie (I wonder if it simply changed at some point).
* ytdl_hook: check youtube-dl version if it breaksNicolas F2019-10-131-2/+32
| | | | | | | | | | | | | | | | | | Some failures by youtube-dl prompt the user to submit a bug report. If such a failure occurs, we can compare youtube-dl's version to the current calendar date to see how old it is. We don't make this check on every youtube-dl failure, as failing to extract an URL is quite common, and waiting for a second blocking python interpreter startup for every such case would be a bit unpleasant. Here the assumption is made that any youtube-dl version older than 3 months is probably severely out of date. Users will be warned about this. We also output the trimmed stderr of youtube-dl with msg.error, as this appeared to have been the behaviour of utils.subprocess without stderr capturing. Since this uses mp.command_native now, we'll have to do this ourselves where appropriate.
* vo_gpu/d3d11: add support for configuring swap chain formatJan Ekström2019-10-136-2/+144
| | | | | | | Query information on the system output most linked to the swap chain, and either utilize a user-configured format, or either 8bit RGBA or 10bit RGB with 2bit alpha depending on the system output's bit depth.
* vo_gpu/d3d11: utilize actual backbuffer values for bit depthJames Ross-Gowan2019-10-131-1/+6
| | | | | And if backbuffer is not around, return an error value utilized elsewhere already.
* player: accept compatible later FFmpeg library runtime versionswm42019-10-112-11/+4
| | | | | | | | | | | | | | | | | | mpv warned if the FFmpeg runtime library version was not exactly the same as the build version. This seemed to cause frequent conflicts. At this point, most mpv code probably adheres to the FFmpeg ABI rules, and FFmpeg stopped breaking ABI "accidentally". Another source of problems were mixed FFmpeg/Libav installations, something which nobody does anymore. It's not "our" job to check and enforce ABI compatibility either. So I guess this behavior can be removed. OK, still check for incompatible libraries (according to FFmpeg versioning rules), i.e. different major versions, or if the build version is newer than the runtime version. For now. The comment about ABI problems is still true. In particular, the bytes_read field mentioned in the removed comment is still accessed, and is still an ABI violation. Have fun.
* av_log: use proper FFmpeg version extraction macroswm42019-10-111-1/+3
| | | | Though not like they will or can never change them.
* audio/out: rip out old unused app/softvolume reportingwm42019-10-117-21/+0
| | | | | | | | | | | This was all dead code. Commit 995c47da9a (over 3 years ago) removed all uses of the controls. It would be nice if AOs could apply a linear gain volume, that only affects the AO's audio stream for low-latency volume adjust and muting. AOCONTROL_HAS_SOFT_VOLUME was supposed to signal this, but to use it, we'd have to thoroughly check whether it really uses the expected semantics, so there's really nothing useful left in this old code.
* audio/out/pull, ao_sdl: implement new underrun reportingwm42019-10-112-2/+8
| | | | | | | | | | | | | | | | See previous commits. ao_sdl is worthless, but it might be a good test for pull-based AOs. This stops using the old underrun reporting if the new one is enabled. Also, since the AO's behavior can in theory not be according to expectations, this needs to be enabled for every single pull AO separately. For some reason, in certain cases I get multiple underrun warnings while cache-pausing is active. It fills the cache, restarts the AO, immediately underruns again, and then fills the cache again. I'm not sure why this happens; maybe ao_sdl tries to catch up when it shouldn't. Who knows.
* audio/out/pull: fix underflow reportingwm42019-10-111-2/+2
| | | | | | | | I think this was _always_ wrong. Due to the line above the first changed line, buffered_bytes==bytes always. I can only hope I broke this in a less under-tested edit when I originally wrote this. Fixes: c5a82f729bd097
* ao_alsa: use AO underrun reportingwm42019-10-111-1/+3
| | | | This enables the change introduced in the previous commit for ao_alsa.
* player: partially rework --cache-pausewm42019-10-114-8/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The --cache-pause feature (enabled by default) will pause playback for a while if network runs out of data. If this is not done, then playback will go on frame-wise (as packets are slowly read from the network and then instantly decoded and displayed). This feature is actually useless, as you won't get nice playback no matter what if network is too slow, but I guess I still prefer this behavior for some reason. This commit changes this behavior from using the demuxer cache state only, to trying to use underrun information from the AO/VO. This means if you have a very large audio buffer, then cache-pausing will trigger once that buffer is depleted, which will be some time _after_ the demuxer cache has run out. This requires explicit support from the AO. Otherwise, the behavior should be mostly the same as before this commit. This does not care about the AO buffer. In theory, the AO may underrun, then the player will write some data to the AO buffer, then the AO will recover and play this bit of data, then the player will probably trigger the cache-pause behavior. The probability of this happening should be pretty low, so I will hold off fixing this until the next refactor of the AO chain (if ever). The VO underflow detection was devised and tested in 5 minutes, and may not be correct. At least I'm fairly sure that the combination of all the factors should make incorrect behavior relatively unlikely, but problems are possible. Also, the demux_reader_state.underrun field may be inaccurate. It's only the present state at the time demux_get_reader_state() was called, and may exclude past underruns. In theory, this could cause "close" cases to be missed. Then you might get an audio underrun without cache-pausing acting on it. If the stars align, this could happen multiple times in the row, effectively making this feature not work. The most user-visible consequence of this change is that the user will now see an AO underrun warning every time the cache runs out. Maybe this cache-pause feature should just be removed...
* ao: add API for underrun reportingwm42019-10-114-1/+25
| | | | | | | | | | | | | | AOs can now call ao_underrun_event() (in any context) if an underrun has happened. It will print a message. This will be used in the following commits. But for now, audio.c only clears the underrun bit, so that subsequent underruns still print the warning message. Since the underrun flag will be used in fragile ways by the playback state machine, there is the "reports_underruns" field that signals strong support for underrun reporting. (Otherwise, underrun events will not be used by it.)
* ao_alsa: handle underruns in get_space() toowm42019-10-111-0/+2
| | | | | This is essentially optional. But it will give the higher level code a better guarantee that underruns were tested.
* player: format low cache duration with more decimalswm42019-10-111-0/+2
|
* ao_alsa: mess with underrun handling againwm42019-10-111-6/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit tries to prepare for better underrun reporting. The goal is to report underruns relatively immediately. Until now, this happened only when play() was called. Change this, and abuse that get_delay() is called "relatively often" - this reports the underrun immediately in practice. Background: In commit 81e51a15f7e1 (and also e38b0b245ed4), we were quite confused about ALSA underrun handling. The commit message showed uncertainty how case 3 happened, but it's blindingly obvious and simple. Actually reading the code shows that ALSA does not have a concept of a "final chunk" (or we don't use it). It's obvious we never pass the AOPLAY_FINAL_CHUNK flag along to the ALSA API in any way. The only thing we do is simply writing a partial fragment. Of course this will cause an underrun. Doing a partial write saves us the trouble to pad the last frame with silence, or so. The main reason why the underrun message was avoided was that play() was never called with a non-0 sample count again (except if reset() was called before that). That was OK, at least the goal of avoiding the unwanted message was reached. (And the original "bogus" message at end of playback was perfectly correct, as far as ALSA goes.) If network stalls, play() will called again only once new data is available. Obviously, this could take a long time, thus it's too late.
* wayland: use callback flag + poll for buffer swapdudemanguy2019-10-109-26/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old way of using wayland in mpv relied on an external renderloop for semi-accurate timings. This had multiple issues though. Display sync would break whenever the window was hidden (since the frame callback stopped being executed) which was really annoying. Also the entire external renderloop logic was kind of fragile and didn't play well with mpv's internal structure (i.e. using presentation time in that old paradigm breaks stats.lua). Basically the problem is that swap buffers blocks on wayland which is crap whenever you hide the mpv window since it looks up the entire player. So you have to make swap buffers not block, but this has a different problem. Timings will be terrible if you use the unblocked swap buffers call. Based on some discussion in #wayland, the trick here is relatively simple and works well enough for our purposes. Instead we basically build a way to block with a timeout in the wayland buffer swap functions. A bool is set in the frame callback function that indicates whether or not mpv is waiting for a frame to be displayed. In the actual buffer swap function, we enter into a while loop waiting for this flag to be set. At the same time, the wl_display is polled to block the thread and wakeup if it receives any events from the compositor. This loop only breaks if enough time has passed or if the frame callback bool is received. In the near future, it is better to set whether or not frame a frame has been displayed in the presentation feedback. However as a first pass, doing it in the frame callback is more than good enough. The "downside" is that we render frames that aren't actually shown on screen when the player is hidden (it seems like wayland people don't like that). But who cares. Accurate timings are way more important. It's probably not too hard to add that behavior back in the player though.
* Revert "vo: add support for externally driven renderloop and make wayland ↵dudemanguy2019-10-104-70/+4
| | | | | | | | | | use it" The externally driven renderloop was originally added for the wayland context (to make display sync somewhat work), but it has a lot of issues with mpv's internal structure. A different approach should be used. This reverts commit a743fef837bcab206b1e576db7e7a64b02890449.
* vo_gpu: d3d11: use linear filtering for wrapped texturesJames Ross-Gowan2019-10-101-1/+3
| | | | | | | | | | This affects hwdec_dxva2dxgi, which uses ra_d3d11_wrap_tex to wrap RGB video frames that are shared with a D3D9 device. Without it, mpv uses nearest instead of bilinear scaling with --scale=bilinear (the default) and --hwdec=dxva2. It's kind of hard to believe this bug has gone unnoticed for almost two years, but that seems to have been the case. Fixes: #7042
* demux_timeline, demux_edl: correctly enable cache in pseudo-DASH modewm42019-10-083-1/+8
| | | | | | | | | | | | | | | | | | In pseudo-DASH mode, we may have no real streams opened until the demuxer layer is fully loaded and playback actually starts. The only hint that the stream is from network is, at that point, the init segment, which is only opened as stream, and then separately as demuxer (which is dumb but happened to fit the internal architecture better). So just propagate the flags from the init segment stream. Seems like an annoyance, but doesn't hurt that much I guess. (Until someone gets the idea to pass the init segment data inline or so, but nothing does that.) The sample link in the linked issue will probably soon switch to another format, because that service always does this after recent uploads or so. Fixes: #7038
* skip-logo.lua: fix skipping in the first two frameswm42019-10-081-15/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mpv typically decodes and filters at least 2 frames before starting playback. This happens during seeks, as well as when playback starts from the beginning of the file. skip-logo.lua receives notifications for all filtered frames, even during seeking. It should interrupt during seeking, so as a crude heuristic, it ignored all frames while the player was seeking. This does not mean all these frames are skipped due to seeking (thus it's a "crude hueristic"). In particular, it means that the first 2 frames of a video cannot be skipped, since they're filtered within the playback restart phase (equivalent to "seeking"). Fix this by making the heuristic slightly less crude. Since we observe the property as "none", the property is not actually read until we do it explicitly. By not reading it during seeking, we can let the frames internally queue up (vf_fingerprint discards them in a ringbuffer-like fashion if they're too many). Then, if seeking ends, we get the current playback timestamp, and check queued up frames that are at or after that timestamp. (In some ways, this duplicates what the player's seeking logic does.) A disadvantage is that this is racy. While playback-time is guaranteed to be set when seeking changes from false to true, playback could already have progressed to the next frame (or more) before the script gets time to react. In theory, we could add a seek restart hook or so, but I don't want to. A property that returns the last playback restart time would also do it, but feels to special. Not an important problem in practice anyway.
* DOCS: explicitly mention that property observing has an initial eventwm42019-10-082-2/+9
| | | | | This is definitely intended from the start, and it's generally useful, but for some reason it wasn't actually documented.
* DOCS: some corrections around cache optionswm42019-10-082-3/+10
|
* demux_edl: better selection of part which defines the track layoutwm42019-10-062-1/+47
| | | | | | | | | | | | | | | Someone crazy is trying to mix images with videos in EDL files. Putting an image as first thing into the EDL disabled audio, because the first EDL entry was used to define the layout. Change this. Make it user-configurable, and use a "better" heuristic to select the default otherwise. In theory, EDL could be easily extended to specify track layout and mapping of parts to virtual EDL tracks manually and in great detail. But I don't think it's worth it - who would bother using it? Fixes: #6764
* video: always decode 2 frames on playback restartwm42019-10-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unless --video-latency-hacks, always decode 2 frames on playback restart. This in turn will always compute the correct frame duration (even for the first frame), which in turn happens to fix that playback with an image at the beginning breaks display. If a still image precedes video, and the size/format of the frame is different from that of the video following it, the incorrect frame duration caused vo_reconfig2() to be called early, causing the window to resize, and the renderer to clear the image to black. Specifically, it hit the default value of 1 second duration (for still images), so the image was displayed for 1 second, and changed to black until the next proper video frame was displayed. Normally this does not happen. Even if a video file displays still images, it normally repeats the still image at the video's FPS (which is sane). But you can construct such files, or use EDL to construct something similarly behaving. This change may increase seek latency a bit in audio video-sync mode (the default). It needs to wait until 2 frames are decoded, before it bothers to display the first frame. This is done even when seeking. In theory it might be good to introduce a "seek preview" mode, which shows the target image without all the preparations needed for starting playback. (For example, it could not decode audio.) But since I'm using video-sync=display-resample, which already needed to always decode 2 frames, I don't think this is a terribly high priority, nor do I consider the slightly slower seeking a regression. Fixes: #6765
* player: don't load external files when reading from stdinckath2019-10-061-1/+1
|
* audio: raise log level of playback reset on audio timestampwm42019-10-061-1/+1
| | | | | Make it a warning. This is such an intrusive and shitty hack (but of course my fault) that it should not be hidden.
* audio: do not try gapless if video is still ongoingwm42019-10-062-1/+7
| | | | | | | | | | In this case, gapless will most likely not work. It will result in (very slight) desync, or (more commonly with small buffer sizes), in an underflow. I think it would be legitimate to disable gapless at end of playback completely if video is enabled at all. But this would need an exception for cover art mode, so I guess the current solution is OK as well.
* ao_alsa: don't silence legitimate underrun if final chunk underrunswm42019-10-061-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that case 2) mentioned in the previous commit happened quite often when playback ended normally. There is probably a legitimate underrun with normal buffer sizes (100 ms, 4 fragments, gapless audio in "weak" mode). This is a result of the player waiting for video to end, and/or the time needed to kill the video window. The former case means that it depends on your test case whether it happens (a file where video ends slightly before audio is less likely to trigger it). This in turn is due to how gapless playback works. Achieving not having a "gap" requires queuing the audio of the next file without playing a partial chunk (as AOPLAY_FINAL_CHUNK would do). The partial chunk is then played as part of the first chunk played from the next file. But if it detects "later" that there is no next file, it still needs to get rid of the last fragment with AOPLAY_FINAL_CHUNK. At this point it's too late, and an underrun may have actually happened. The way the player uninits and reinits the entire playback engine for the next file in a "serial" manner means it cannot know in advance whether this works. This is the reason why the idiot who added the underrun exception for the last chunk in play() was wrong (I wrote that btw., before you accuse me of being rude). Yes, it's a real underrun, and you could probably hear it.
* ao_alsa: remove sometimes bogus XRUN messagewm42019-10-061-9/+2
| | | | | | | | | | | | | | | | | | | This XRUN (aka underrun) message was printed in the following situations: 1) legitimate underrun during playback 2) legitimate underrun when playing final chunk 3) bogus underrun when playing final chunk The old underrun case (in play()) happens in cases 1) and 2) as well, but 3) did not happen. It appears 3) is indeed something that happens, although it's not known for sure. It's still pretty annoying, so remove the new XRUN message. When testing, care should be taken to play with buffer sizes, video versus no video, and gapless enabled/disabled. Also, suspending the player with Ctrl+Z in the terminal (SIGSTOP) and then resuming is a good way to trigger a "normal" underrun.
* cocoa-cb: remove get_property_* usages and split up mpv helperder richter2019-10-0612-247/+285
| | | | | | | | | | all the get_property_* usages were removed because in some circumstances they can lead to deadlocks. they were replaced by accessing the vo and mp_vo_opts structs directly, like on other vos. additionally the mpv helper was split into a mpv and libmpv helper, to differentiate between private and public APIs and for future changes like a macOS vulkan context for vo=gpu.
* audio/filter: remove no longer used headerPaul B Mahol2019-10-051-47/+0
|
* DOCS/compatibility.rst: add this filewm42019-10-054-1/+185
| | | | | | | | | | | Another thing nobody will read. I'm attempting to document the rules by which incompatible changes can be made. These rules have always been present in this project, but I don't think they were written down. Or maybe they were, but I forgot where. I think due to the time of the day it became increasingly incoherent (not necessarily near the end of the text). Hopefully no logical or freudian lapses in there.
* DOCS/interface-changes.rst: simplify playback abort change descriptionwm42019-10-051-11/+2
| | | | | | | | | | | Although it was not true at the time this was written, both the "program" and "cache-size" are gone now. Since the changelog is for the entire next release, it makes no sense to mention these removed properties. It also happens to make the description of this much simpler, because it's a non-issue now. It's probably not even worth mentioning anymore.
* player: update for --video-aspect deprecationNiklas Haas2019-10-042-3/+3
| | | | We had some dangling references to this option.
* options: rename --video-aspect to --video-aspect-overrideNiklas Haas2019-10-046-22/+45
| | | | | | | | | | | | The justification for this is the fact that the `video-aspect` property doesn't work well with `cycle_values` commands that include the value "-1". The "video-aspect" property has effectively no change in behavior, but we may want to make it read-only in the future. I think it's probably fine to leave as-is, though. Fixes #6068.
* player: "subprocess" command should stop immediately in idle modewm42019-10-042-3/+15
| | | | | | | | | | | | The description of the "playback_only" field in the "subprocess" command says "you can't start it outside of playback". This did not work correctly: if the player was started in idle mode in the first place, the subprocess was allowed to run even with playback_only=yes. This is a bug, and this change fixes it. Add a test for this to command-test.lua. For #7025.
* manpage: clarify some details about async. commands and "subprocess"wm42019-10-043-4/+38
| | | | | | | | | There's potential confusion about how long a process started with the "subprocess" command is allowed to live. Add some more explanations regarding "subprocess" specifics (such as the playback_only field), and things that apply to asynchronous commands in general. Partially for #7025.
* wayland opengl: actually call uninit if init failsdudemanguy2019-10-031-1/+3
| | | | | | | | This is the proper fix to the memory leak @wm4 pointed out. It turns out that when you autoprobe opengl and vo_wayland_init returns false, vo_wayland_uninit is never actually executed. So you have a leftover pointer. The vulkan context does this correctly which was why my old, dumb "fix" broke it.
* Revert "wayland: free wayland_state on a false return"dudemanguy2019-10-031-11/+3
| | | | | | | | Dumb idea. The correct thing to do is to fix the preinit and context creation so that the uninit is correctly executed when probing fails (and then everything gets freed). This reverts commit defc8f359c5e4bb666e8ad1d4a097a8ac66cc1e2.
* wayland: free wayland_state on a false returnDudemanguy9112019-10-021-3/+11
| | | | | | wm4 mentioned that the wayland autoprobe leaked. A simple oversight in the wayland_common code forgot to free the vo_wayland_state if vo_wayland_init returned false.
* vf_fingerprint: fix an obvious memory leakwm42019-10-031-4/+12
| | | | | | Leaks the entire zimg state on filter deinit. Not sure what I was thinking; with some luck, I just didn't give a shit about this case, but most likely I was thinking the same thing as always: nothing.
* vf_vapoursynth: fix crashing memory management mistakewm42019-10-031-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As pointed out by @olifre in #7016, this line of code was wrong. p->opts at this point is a struct allocated and managed by m_config. opts->file is a string, and m_config explicitly frees it on destruction. The line of code in question replaced the opts->file value, and made both the old and new value children of the talloc allocation, so they were _also_ freed on destruction. This crashed due to a double-free. First, talloc auto-freeing freed the string, then m_config explicitly called talloc_free() on the stale pointer again. As @v-fox pointed out, commit 36dd2348a1e1 seems to have triggered the crash. I suspect this code merely worked out of coincidence, since it allowed m_config to free the value first. This removed it from the auto-free list, and thus did not result in a double-free. The change in order of calling alloc destructors changed the order of these calls. There is no strong reason why new behavior (as introduced by commit 36dd2348a1e1) would be wrong (it feels like cleaner behavior). On the other hand, what the vf_vapoursynth code did is clearly unclean and going by the m_config API, you're not at all supposed to do this. m_config manages all memroy referenced by option structs, the end. @olifre's suggested fix also would have been correct (not just hiding the issue), I prefer my fix, as it doesn't mess with the option struct in tricky ways. This wouldn't have happened if mpv were written in Haskell.
* vf_vapoursynth: do not call vsscript_finalize() if init failedwm42019-10-031-1/+5
| | | | | If vsscript_finalize() is not matched by a successful vsscript_init(), an assert in the vsscript library triggers. Makes sense, I guess.
* vf_vapoursynth: remove some Lua backend remainswm42019-10-031-6/+0
| | | | Pretty funny.
* wayland: always create wl_output before renderingDudemanguy9112019-10-021-7/+6
| | | | | | | | | | | I previously skipped creating the wl_output if the --fullscreen flag with no --fsscreen_id was inputted, so the fullscreen video lands on the correct output (where mpv was launched). This has breakage if someone combines the --autofit flag (or other similar options with it). Instead, just actually read xdg_shell spec and realize that you can pass NULL to xdg_toplevel_set_fullscreen and let the compositor choose the output if the user doesn't specify it. If this has issues, get a better compositor.
* demux: restore some of the DVD/BD/CDDA interaction layerswm42019-10-039-32/+751
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This partially reverts commit a9d83eac40c94f44d19fab7b6955331f10efe301 ("Remove optical disc fancification layers"). Mostly due to the timestamp crap, this was never really going to work. The playback layer is sensitive to timestamps, and derives the playback time directly from the low level packet timestamps. DVD/BD works differently, and libdvdnav/libbluray do not make it easy at all to compensate for this. Which is why it never worked well, but not doing it at all is even more awful. demux_disc.c tried this and rewrote packet timestamps from low level TS to playback time. So restore demux_disc.c, which should bring behavior back to the old often non-working but slightly better state. I did not revert anything that affects components above the demuxer layer. For example, the properties for switching DVD angles or listing disc titles are still gone. (Disc titles could be reimplemented as editions. But not by me.) This commit modifies the reverted code a bit; this can't be avoided, because the internal API changed quite a bit. The old seek resync in demux_lavf.c (which was a hack) is replaced with a hack. SEEK_FORCE and demux_params.external_stream are new additions. Some of this could/should be further cleaned up. If you don't want "proper" DVD/BD support to disappear, you should probably volunteer. Now why am I wasting my time for this? Just because some idiot users are too lazy to rip their ever-wearing out shitty physical discs? Then why should I not be lazy and drop support completely? They won't even be thankful for me maintaining this horrible garbage for no compensation.
* f_auto_filters: use f_autoconvert for hw downloadwm42019-10-021-23/+22
| | | | | | | | Instead of using custom code. Now if only f_lavfi knew what formats FFmpeg's vf_yadif accepts, this could look much nicer, and wouldn't require the additional converter filter setup.
* f_autoconvert: provide a function to determine if conversion workswm42019-10-022-41/+75
| | | | | | This adds the function as seen in the f_autoconvert.h part of the patch. It's pretty simple, but goes along with an intrusive code move. I guess the resulting code is slightly nicer anyway.
* f_autoconvert: add hw->sw download pathwm42019-10-022-18/+71
| | | | | For some reason it could do sw->sw and sw->hw (and, in some ways, even do hw->hw in special cases), but not hw->sw. Add this.
* f_auto_filters: use software conversion if hw deint is not possiblewm42019-10-021-7/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | Before this commit, enabling hardware deinterlacing via the "deinterlace" option/property just failed if no hardware deinterlacing was available. An error message was logged, and playback continued without deinterlacing. Change this, and try to copy the hardware surface to memory, and then use yadif. This will have approximately the same effect as --hwdec=auto-copy. Technically it's implemented differently, because changing the hwdec mode is much more convoluted than just inserting a filter for performing the "download". But the low level code for actually performing the download is the same again. Although performance won't be as good as with a hardware deinterlacer (probably), it's more convenient than forcing the user to switch hwdec modes separately. The "deinterlace" property is supposed to be a convenience thing after all. As far as the code architecture goes, it would make sense to auto-insert such a download filter for all software-only filters that need it. However, libavfilter does not tell us what formats a filter supports (isn't that fucking crazy?), so all attempts to work towards this are kind of hopeless. In this case, we merely have hardcoded knowledge that vf_yadif definitely does not support hardware formats. But yes, this sucks ass.
* f_hwtransfer: add a mp_hwdownload filterwm42019-10-022-0/+62
| | | | | | | | | This just wraps the mp_image_hw_download() function as a filter and adds some minor caching/error logging. (Shame that it needs to much boilerplate, I guess.) Will be used by the following commit. Wrapping it as filter seemed more convenient than other choices.
* filters: add another dumb helperwm42019-10-022-0/+22
| | | | | | | Can be used with mp_chain_filters() to combine multiple filters into a single one. This is a bit silly, but whatever. I'm making it an explicit separate filter, because it lets the user access mp_filter.ppins against all conventions.
* mp_image_pool: expose a function for reporting hw download formatwm42019-10-022-11/+22
| | | | | | | | Basically predicts what mp_image_hw_download() will do. It's pretty simple if it gets the full mp_image. (Taking just a imgfmt would make this pretty hard/impossible or inaccurate.) Used in one of the following commits.
* video: remove vf_vavpp from automatic deinterlace propertywm42019-10-022-12/+0
| | | | | | | | | | | | | | This reverts commit 6385a5fd1b8a67c051b82d48c993a6591e8f93c6, and in addition removes the code that automatically inserts the vavpp filter. The reason is the same as the commit that is being reverted: this filter seems to trigger driver bugs. It can cause GPU freezes or just doesn't work. This variant of disabling the filter is better. There was no way to add the "force" parameter to the automatically inserted filter, so the old approach just made manual filter insertion (with the --vf option or "vf" command) more cumbersome.
* DOCS/tech-overview.txt: caching has changedwm42019-10-021-3/+4
|
* README.md: minor cleanupswm42019-10-021-40/+3
| | | | | | | | | I don't think MPlayer/mplayer2 and Libav are well-known enough anymore to warrant such a prominent place in the top-level README file of this project. It's just useless noise to most users. So I've moved these things to the FAQ. Update some other minor things.
* README.md: remove dead homebrew-mpv linkVítor Galvão2019-10-021-1/+0
|
* autoload.lua: Configurable autoload typesMarek Sebera2019-10-021-4/+42
| | | | | | | | | | | Autoload script now suppports loading of not only video, but also image and audio files, in a manner, where one can configure which of the groups (audio, videos, images) is currently enabled. Use file script-opts/autoload.conf with key=value configuration keys disabled,images,videos,audio to configure autoload script. See documentation on top of the script
* DOCS: Document DVB changes in interface-changes.Oliver Freyermuth2019-10-021-0/+9
|
* stream_dvb: Remove now replaced stream-control code for good.Oliver Freyermuth2019-10-022-85/+0
|
* DOCS: Add documentation for dvbin-prog and dvbin-channel-switch-offset.Oliver Freyermuth2019-10-021-0/+16
|
* stream_dvb: Allow actual zapping of channels again.Oliver Freyermuth2019-10-023-0/+9
| | | | | | | | | | | | | | | This is realized by dvbin-channel-switch-offset, which is a numeric offset on the channel initially tuned to. Since the channel list is kept in the stream alone depending on detected hardware and chosen card, and no available backchannel to the player, there's no direct property which could be switched. Using input.conf like: H cycle dvbin-channel-switch-offset up K cycle dvbin-channel-switch-offset down Q set dvbin-prog "ZDF HD" allow fast and reliable channel switching again.
* player: Add mp_property_dvb_channel helper.Oliver Freyermuth2019-10-021-0/+17
| | | | | | | Reinitializes the player as is needed when tuning to a new DVB channel. Currently triggered when dvbin-prog is written to, i.e. when the user explicity switches to a channel by name.
* stream_dvb: Add dvb_update_config to poll config parameters.Oliver Freyermuth2019-10-022-0/+33
| | | | | | | | If any parameters have been updated, reinitiate streaming_start. Throttle checks since we poll from streaming_read. This also requires the player to re-initialize, since all video and audio streams and even the transport format may change. This is added in the next commit.
* stream_dvb: Move stream->is_on initialization to state preparation.Oliver Freyermuth2019-10-022-2/+1
| | | | | | Notably, this allows to call dvb_streaming_start more than once, simplifying e.g. channel switching. Also, get rid of unused timeout variable.
* stream_dvb: Factor out logic to determine program and card.Oliver Freyermuth2019-10-022-47/+75
| | | | | | | | This is now treated in dvb_parse_path consistently instead of logic scattered over various functions. This is a requirement to sensibly re-evaluate config after options have been changed, since we have two ways to configure the stream (decorated URI and config parameters).
* stream_dvb: Use separated out options struct.Oliver Freyermuth2019-10-022-27/+33
| | | | | This also allows the use of m_config_cache_alloc which allows to watch config updates.
* demux_lavf: remove recently added author name from license headerwm42019-10-011-1/+0
| | | | | | | | | | | | | | | | | This was added in 585f9ff42f3195c by @bbarenblat (github handle). We don't do this. This file alone probably has multiple dozen of authors (I didn't count, but it has a history of 15 years). If everyone added their names with each small change, this project would have giant lists of contributing authors on every source file. Neither copyright law nor any of the used licenses require listing authors in the license header. Authorship is recorded in the git log. So don't start with this, and remove this recent case to avoid setting a precedent. Some files still have an author in the header. These cases are grandfathered, and usually are the actual authors of the original code.
* DOCS/contribute.md: split into sections, random changeswm42019-10-011-17/+61
| | | | | | | | Still trying to get people to read it. Even though I wanted to make it less of a wall of text and more readable, it got bigger. Oops. While I'm at it, violate my own rules and mix these mostly cosmetic changes with some actual rule changes and clarifications.
* github: try to get contributors to read contribute.mdwm42019-10-011-5/+4
| | | | | | | | | | | | | | | | | How hard can it be? I know contribute.md is a shitty wall of text, but that doesn't make it less important, and each violation will make it take longer by adding another review round anyway. And we really don't need lazy pull requests. If you can't be assed to follow a few simple rules, your code is probably shit or you wanted to be quick and lazy. Why should we accept it? We're the ones who have to maintain it and fix bugs in it, and if the contributor is lazy, the chance of you maintaining it is probably slim as well. On the other hand, WE the maintainers are not obligated to anything. Don't say that though, the first contact doesn't need to be negative. I don't know if the "lazy pull requests" is still too strong, but I can't tell.
* demux_mkv: better behavior/warnings on partial files/unseekable streamswm42019-10-011-5/+8
| | | | | | | | | | | | | | demux_mkv may seek to the end of the file to read certain headers (which should probably be called "footers", but in theory they are just headers that have been placed at the end of the file unfortunately). This commit changes behavior not to seek if the stream is not marked as seekable. Before this, it only checked whether the stream size was unknown (end negative). In practice it doesn't make much of a difference, since seekable usually equals known stream size. Also improve the wording, and distinguish between actual incomplete files, and unseekable ones.
* vo_gpu/d3d11: add adapter name validation and listing with "help"Jan Ekström2019-09-294-9/+75
| | | | Not the prettiest way to get it done, but seems to work.
* vo_gpu/d3d11: refactor pthread_once d3d11 loading to functionJan Ekström2019-09-291-6/+15
| | | | Lets us reuse this in the future.
* vo_gpu/d3d11: utilize the passed adapter nameJan Ekström2019-09-291-5/+77
| | | | | | Normalize nullptr and an empty string both to nullptr to simplify handling. API users cannot set a value back to nullptr, so both an empty string as well as nullptr should behave the same.
* vo_gpu/d3d11: add an option for the adapter nameJan Ekström2019-09-292-0/+6
| | | | Set it from the adapter name in the d3d11 options.
* video/d3d11: add adapter selection by name into d3d11 optionsJan Ekström2019-09-293-0/+15
| | | | | This lets the user define an adapter name that can then be passed further into the internals.
* vo_gpu/d3d11_helpers: also load up CreateDXGIFactory1Jan Ekström2019-09-291-4/+13
| | | | Just a factory, without a device, is required for listing of devices.
* stream_lavf: add support for gopherLeonardo Taccari2019-09-291-1/+1
|
* vo_drm: fix flickering when setting pan/scanAnton Kindestam2019-09-291-4/+0
| | | | | | | | Turns out clearing all frambuffers in reconfig isn't such a great idea when you also end up here when setting pan/scan. I guess this is just a leftover from a previous iteration of vo_drm where doing this made sense.
* demux: make --record-file/cache dump command work with disabled streamswm42019-09-291-5/+18
| | | | | | | | | | | | | | | | This passed all streams to mp_recorder_create(), even disabled ones. The disabled streams never get packets, so recorder.c eventually errors out with unrelated-looking errors. The reason is that recorder.c waits for packets to appear on other streams, which in turn is because libavformat refuses to mux empty streams anyway. recorder.c could call demux_stream_is_selected(), which would have made the patch much smaller. But this feels like a bad idea, since recorder.c should use sh_stream only for metadata (and not in an "active" way), nor should it care what demux.c is currently doing with it. So make the API user (demux.c) pass only the streams it really wants. Fixes: #6999
* loadfile: make prefetching actually workwm42019-09-291-1/+3
| | | | | | | | | | | | | | | | Looks like this didn't actually work. Prefetching will do nothing if there isn't a thread to "drive" it, and the demuxer thread needs to be explicitly enabled. (I guess I did the worst possible job in verifying whether this actually worked when I implemented it. On the other hand, the user didn't confirm back whether it worked, so who cares.) Like in the previous commit, bad factoring makes everything worse. It duplicates logic and implementation of enable_demux_thread(), since the opener thread cannot access the mpctx->opts field freely. But it's deep night, so fuck it. Fixes: c1f1a0845e03885e Fixes: #6753
* loadfile: don't always accidentally always prefetchingwm42019-09-292-11/+16
| | | | | | | | | | | | | | demux_start_prefetch() was called unconditionally in two cases. This is completely wrong. I'm not sure what part of my brain died off that something this obviously wrong went in. The prefetch case is a bit more complicated. It's a different thread, so you can't access just access mpctx->opts there. So add an explicit field for this, which is the simplest way to get this done. (Even if it's bad factoring.) Fixes: c1f1a0845e03885eebe63 Fixes: 556e204a112ee286972e5
* recorder: don't use a magic index for mp_recorder_get_sink()wm42019-09-294-8/+16
| | | | | | | | | | | | | | | | | | | Although this was sort of elegant, it just seems to complicate things slightly. Originally, the API meant that you cache mp_recorder_sink yourself (which would avoid the mess of passing an index around), but that too seems slightly roundabout. In a later change, I want to change the set of streams passed to mp_recorder_create(), and then I'd have to keep track of the index for each stream, which would suck. With this commit, I can just pass the unambiguous sh_stream to it, and it will be guaranteed to match the correct stream. The disadvantages are barely worth discussing. It's a new linear search per packet, but usually only 2 to 4 streams are active at a time. Also, in theory a user could want to write 2 streams using the same sh_stream (same metadata, just writing different packets or so), but in practice this is never done.
* stream: rearrange open functionswm42019-09-294-56/+96
| | | | | | | | | | | | | | | | Add yet another variant of the stream open function. This time, make it so that it's possible to add new open parameters in an extendable way, which should put an end to having to change this every other year. Effectively get rid of the overly special stream_create_instance() function and use the new one instead, which requires changes in stream_concat.c and stream_memory.c. The function is still in private in stream.c, but I preferred to make the mentioned users go through the new function for orthogonality. The error handling (mostly logging) was adjusted accordingly. This should not have any functional changes. (To preempt any excuses, I didn't actually test stream_concat and stream_memory.)
* demux: sort filenames naturally when playing a directory / archivePhilip Sequeira2019-09-295-2/+95
|
* build: lower version requirement for EGLMarvin Schmidt2019-09-291-1/+1
| | | | | | | | `egl.pc` can be provided either by mesa or libglvnd. The latter doesn't follow the same version scheme as mesa but instead uses the API version that the library exposes, which is 1.5 for EGL[1] [1] https://github.com/NVIDIA/libglvnd/commit/0dfaea2bcb7cdcc785f95e244223bd004a2d7fba#diff-b58a140c00ea99fb9a708e15afaade62R8
* vo_gpu: hwdec_cuda: Synchronise OpenGL InteropPhilip Langdale2019-09-283-0/+8
| | | | | | | | | | | | | | | | | | | | | Previously, there appeared to be implicit synchronisation in the GL interop path, and we never observed any visual glitches. However, recently, I started seeing stuttering in the GL path and on closer examination it looked like read-before-write behaviour where GL would display an old frame again rather than the current one. After verifying that disabling hwdec made the problem go away, I tried adding a cuStreamSynchronize() after the memcpys and that also resolved the problem, so it's clearly sync related. cuStreamSynchronize() is a CPU sync and so more heavy-weight than you want, but it's the only tool we have. There is no mechanism defined for synchronising GL to CUDA (It looks like there is a way to synchronise CUDA to EGL but it appears one way and so wouldn't directly address this problem). Anyway, empirically, the output now looks the same as with hwdec off.
* build: silence OpenGL deprecation warnings on macOS for C/objCRodger Combs2019-09-281-1/+2
| | | | | We know of the deprecation since 10.14, and thus we do not need to be reminded of it with each compiled file.
* vo_drm: support controlling swapchain depth using swapchain-depth optionAnton Kindestam2019-09-281-10/+13
|
* vo: make swapchain-depth option generic for all VOsAnton Kindestam2019-09-2811-24/+21
| | | | In preparation for making vo_drm able to use swapchain-depth
* drm: refactor page_flipped callbackAnton Kindestam2019-09-284-109/+71
| | | | | Avoid duplicating the same callback function in both context_drm_egl and vo_drm.
* vo_drm: Implement N-buffering and presentation feedbackAnton Kindestam2019-09-281-39/+215
| | | | | | | | | | | Swapchain depth currently hard-coded to 3 (4 buffers). As we now avoid redrawing on repeat frames (we simply requeue the same fb again), this should give a nice performance boost when playing videos with a lower FPS than the display FPS in video-sync=display-resample mode. Presentation feedback has also been implemented to help counter the significant amounts of jitter we would otherwise be seeing.
* vo_drm: fix more than 2 buffersAnton Kindestam2019-09-281-1/+1
| | | | Now we can increase BUF_COUNT. Yay.
* drm: move struct vsync_tuple into drm_common as drm_vsync_tupleAnton Kindestam2019-09-282-9/+8
| | | | This struct will be useful in vo_drm as well.
* stream_cb: add cancel_fn callbackAman Gupta2019-09-274-1/+27
| | | | | | | | This allows stream_cb backends to implement blocking behavior inside read_fn, and still get notified when the user wants to cancel and stop playback. Signed-off-by: Aman Gupta <aman@tmm1.net>
* audio: fix copy&paste errorwm42019-09-271-1/+1
| | | | | | | This wasn't used at all in my tests, because it simply passed the frame directly to libswsresample. (And, by the way, will always do that, because s64 is so obscure literally NOTHING uses it except a sample specifically created to test this code. Screw FFmpeg.)
* ad_lavc: log on failure to read AVFramewm42019-09-271-1/+3
| | | | | | | | This can be due to unsupported sample formats (see previous commits), minor allocation failures, and similar things. For identifying the exact cause it's buried too deep in abstractions. But most time it doesn't happen anyway, since it's extremely rare that new audio formats are added.
* audio: add support for AV_SAMPLE_FMT_S64*wm42019-09-273-0/+8
| | | | | | | | | | What an idiotic format. It makes no sense, and should have been converted to S32 in the demuxer, rather than plague everyone with another extremely obscure nonsense format. Why doesn't ffmpeg add S24 instead? That's an actually useful format. May cause compilation failure with old FFmpeg or Libav libs, but I don't care.
* context_drm_egl: define EGL_PLATFORM_GBM_MESA, EGL_PLATFORM_GBM_KHR if not ↵Anton Kindestam2019-09-271-0/+8
| | | | | | | in system headers To account for oddball setups where EGL_PLATFORM_GBM_MESA or EGL_PLATFORM_GBM_KHR might not be defined for whatever reason.
* wscript: check tvOS define's value to be nonzeroJan Ekström2019-09-271-1/+4
| | | | | | TARGET_OS_TV seems to always be defined, but set according to the build configuration. This fixes all Apple configurations being mis-identified as tvOS.
* video: add pure gamma TRC curves for 2.0, 2.4 and 2.6.Wessel Dankers2019-09-276-0/+36
|
* ci: remove --enable-zsh-compPhilip Sequeira2019-09-271-2/+1
| | | | | This option no longer exists, as zsh completion is installed unconditionally now.
* zsh completion: move generation to runtime and improvePhilip Sequeira2019-09-275-307/+253
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The completion function itself now parses --list-options on the first tab press and caches the results. This does mean a slight delay on that first tab press, but it will only do this if the argument being completed looks like an option (i.e. starts with "-"), so there is never a delay when just completing a file name. I've also put some effort into making it reasonably fast; on my machine it's consistently under 100 ms, more than half of which is mpv itself. Installation of zsh completion is now done unconditionally because it's nothing more than copying a file. If you really don't want it installed, set zshdir to empty: `./waf configure --zshdir= ...` Improvements in functionality compared to the old script: * Produces the right results for mpv binaries other than the one it was installed with (like a dev build for testing changes). * Does not require running mpv at build time, so it won't cause problems with cross compilation. * Handles aliases. * Slightly nicer handling of options that take comma-separated values and/or sub-options: A space is now inserted at the end instead of a comma, allowing you to immediately start typing the next argument, but typing a comma will still remove the automatically added space, and = and : will now do that too, so you can immediately add a sub-option. * More general/flexible handling of values for options that print their possible values with --option=help. The code as is could handle quite a few more options (*scale, demuxers, decoders, ...), but nobody wants to maintain that list here so we'll just stick with what the old completion script already did.
* options: add M_OPT_FILE to some more options that take filesPhilip Sequeira2019-09-273-10/+10
|
* vo_gpu: hwdec_drmprime_drm: add hwdec ctxJonas Karlman2019-09-272-1/+15
| | | | | | | This allows to use drm hwaccels that require a hwdevice. Tested with v4l2request hwaccel and cedrus driver on an allwinner device running mpv with --vo=gpu --gpu-context=drm --hwdec=drm.
* hwdec_vaapi_gl: add missing compatibility defineswm42019-09-271-0/+6
| | | | | | | | | | | At first, this code used only 1 plane, so the compatibility stuff was sufficient. But then use of planes 1 and 2 was added, without extending the compatibility stuff. I think I've seen a case recently where this broke the build and caused users to apply invalid fixes, but I don't remember where. It's possible that I didn't get all defines that are needed.
* stream_cb: fix a typo in a commentwm42019-09-271-1/+1
|
* ao_pulse: add the newly added mappings for TrueHD/DTS-HD formatsJan Ekström2019-09-271-6/+11
| | | | | Originally DTS-HD was mapped to PA_ENCODING_DTS_IEC61937 which I'm actually not sure if it ever worked.
* vo_gpu: vulkan: add Android contextsfan52019-09-273-0/+99
|
* context_android: move common code to a separate filesfan52019-09-275-52/+153
| | | | | | In preparation for a Vulkan Android context. This also replaces querying for EGL_WIDTH and EGL_HEIGHT with equivalent ANativeWindow calls.
* DOCS: don't lie about the keybind commanddudemanguy2019-09-261-2/+1
| | | | | It turns out you can actually bind keybind to another keybind. Just be careful with all the quotes.
* wscript: detect tvOS and disable posix-spawn usageAman Gupta2019-09-261-1/+5
| | | | | | cc #5331 Signed-off-by: Aman Gupta <aman@tmm1.net>
* vo_gpu: d3d11: don't reset frame stats after pauseJames Ross-Gowan2019-09-261-9/+0
| | | | | | | | | | | | | | | | | | | | | | I think I was wrong about having to reset the stats when mpv stops producing frames, eg. when it's paused. As long as the swapchain doesn't underflow, last_queue_display_time will still be accurate, because the next frame produced should still be presented one vsync after the last one in the swapchain. If the swapchain underflows (which is the common case for when mpv is paused for more than 150ms,) the next predicted frame time should be in the past. It should be fine to leave last_queue_display_time unset in this case, since vo.c will use the current time instead, which is a decent guess (though it doesn't take vsync phase into account.) last_sync_refresh_count and last_sync_qpc_time should be kept on swapchain underflow as well. Assuming the display refresh rate doesn't change while mpv is paused, they'll only provide a more accurate guess of the vsync duration when mpv starts playing again. Also, vsync_duration_qpc never needs to get reset. It will get overwritten immediately in most cases, and when it doesn't, it's still a better guess of the vsync duration than nothing.
* player: document FFmpeg ABI rules we intentionally violatewm42019-09-261-0/+2
| | | | | | | | | | That's just a single one. It used to be more, when FFmpeg still required using pointless accessors for tons of fields, which historically broke compatibility with Libav. (I think I wrote the patch to deprecate that crap and to allow direct access myself.) There may be more exceptions, but I forgot about them. Another point is that we don't really trust FFmpeg ABI stability, though.
* audio: make playback end with --end and --audio-spdifwm42019-09-261-0/+3
| | | | | | | | | | | | | In spdif mode, there are hacks that try to cut audio on frame boundaries (blame spdif, which is a hack in itself). The "alignment" is used in a bunch of places, but --end does not respect it. This leads to some audio that can't be pushed because the alignment is off (I don't know why, not do I care), which puts audio into an underrun state forever. Fix this by discarding unusable extra samples if no new data can be expected. Fixes: #6935
* DOCS/contribute.md: talk about non-standard and C11 language featureswm42019-09-261-3/+4
| | | | | | | | | | | The C11 situation is complicated. For example, MinGW doesn't seem to have a full C11 implementation, but we pretty much rely on C11 atomics. Regarding "#pragma once": they say it's not standard because of unsolved (admittedly valid) issues. Btu still, fuck writing include guards, I just can't be bothered with this crap. (Does anyone even read this document?)
* client API: be explicit about usage rules and deadlocks some morewm42019-09-262-0/+9
| | | | | | | I think a popular libmpv application did exactly this: enabling advanced control, and then receiving deadlocks. I didn't confirm it, though. In any case, the API docs should avoid tricking users into making this easy mistake.
* client API: fix potential deadlock problems by throwing more shit at itwm42019-09-267-32/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The render API (vo_libmpv) had potential deadlock problems with MPV_RENDER_PARAM_ADVANCED_CONTROL. This required vd-lavc-dr to be enabled (the default). I never observed these deadlocks in the wild (doesn't mean they didn't happen), although I could specifically provoke them with some code changes. The problem was mostly about DR (direct rendering, letting the video decoder write to OpenGL buffer memory). Allocating/freeing a DR image needs to be done on the OpenGL thread, even though _lots_ of threads are involved with handling images. Freeing a DR image is a special case that can happen any time. dr_helper.c does most of the evil magic of achieving this. Unfortunately, there was a (sort of) circular lock dependency: freeing an image while certain internal locks are held would trigger the user's context update callback, which in turn would call mpv_render_context_update(), which processed all pending free requests, and then acquire an internal lock - which the caller might not release until a further DR image could be freed. "Solve" this by making freeing DR images asynchronous. This is slightly risky, but actually not much. The DR images will be free'd eventually. The biggest disadvantage is probably that debugging might get trickier. Any solution to this problem will probably add images to free to some sort of queue, and then process it later. I considered making this more explicit (so there'd be a point where the caller forcibly waits for all queued items to be free'd), but discarded these ideas as this probably would only increase complexity. Another consequence is that freeing DR images on the GL thread is not synchronous anymore. Instead, it mpv_render_context_update() will do it with a delay. This seems roundabout, but doesn't actually change anything, and avoids additional code. This also fixes that the render API required the render API user to remain on the same thread, even though this wasn't documented. As such, it was a bug. OpenGL essentially forces you to do all GL usage on a single thread, but in theory the API user could for example move the GL context to another thread. The API bump is because I think you can't make enough noise about this. Since we don't backport fixes to old versions, I'm specifically stating that old versions are broken, and I'm supplying workarounds. Internally, dr_helper_create() does not use pthread_self() anymore, thus the vo.c change. I think it's better to make binding to the current thread as explicit as possible. Of course it's not sure that this fixes all deadlocks (probably not).
* command: fix bitrate rounding errorStefan Pöschel2019-09-261-2/+2
| | | | | | | | | | | | | When the (float) bitrate is returned, it is implicitely converted to an int64 value, merely discarding the fractional part. However the bitrate of a CBR track can vary a bit due to timestamp precision loss after clock conversion (this can affect MPEG-TS audio tracks). So a bitrate like 191999.999... results in 191999 when being returned - instead of 192000. To fix this, apply proper rounding, as already done for the "old" case. Hereby refactoring the "old" case to also use `llrint`.
* cocoa-cb: add support for 10bit opengl renderingder richter2019-09-266-20/+65
| | | | | | | this will request a 16bit half-float framebuffer instead if a 8bit integer framebuffer. Fixes #3613
* sub: make font provider user-selectablewm42019-09-254-3/+30
| | | | | | | | | | | | | | | | | | | | libass had an API to configure this since 2013. mpv always used ASS_FONTPROVIDER_AUTODETECT, because usually there's little reason to use anything else. The intention of the now added option is to allow users to disable use of system fonts. I didn't consider it worth the trouble to add the coretext and directwrite enum items from ASS_DefaultFontProvider. The "auto" choice will have the same effect if they're available. Also, the part of the code which defines the option does not necessarily have libass available (it's still optional!), so defining all enum items as choices is icky. I still added fontconfig, since that may be nice to emulate a nostalgic 2010 feeling of mpv freezing on fontconfig. The option for OSD is even less useful. (But you get it for free, and why pass up a chance to add yet another useless option?) This is not quite what was requested in #6947, but as close as it gets.
* drm_common: add missing zero-initialization of struct vt_mode variableAnton Kindestam2019-09-241-1/+1
| | | | | Some fields were being left uninitialized. This could be a problem particularly on non-Linux OS:s with vt_mode (see PR #6976).
* demux: force reading packets again after seekswm42019-09-241-1/+1
| | | | | | | | | | | | | | | | in->eof is used as an indicator whether reading packets still makes sense. (Without this, the prefetcher would obviously burn CPU by retrying reading even though everything has been read.) This was not reset properly after seeks were performed. It led to getting stuck in at least one corner case: when enabling a track, the demuxer would seek backwards to get new packets from the current playback position ("refresh seeks"). But if playback was paused, and EOF was previously reached, it would not try to read packers again due to in->eof being false. There was not anything else that would make it retry reading, so it was stuck in a weird underrun/buffering state. Fixes: #6986
* demux: remove redundant seek range updateGunnar Marten2019-09-241-2/+0
| | | | | This was a leftover from commit b2752321 which fixed #6522 but after the recent demux refactoring this fix is superseded by commit 0f6cda4ab. Remove the redundant update call.
* cocoa-cb: fix title bar button state on start upder richter2019-09-231-0/+2
| | | | | on start up it was possible to click the hidden buttons. hide the buttons ons tart up to make the state consistent with the visible state.
* mac: add Open Playlist menu bar itemAkemi2019-09-231-0/+17
|
* context_drm_egl: Don't get stuck forever if drmHandleEvent failsAnton Kindestam2019-09-221-1/+3
|
* demux_lavf: fix seeking in ogg audio streamswm42019-09-221-0/+3
| | | | | | | | | | | | | | | | | This detected the first packet demuxed after a seek as timestamp discontinuity. Obviously this is non-sense. Since the OGG radio streams for which this feature was introduced are normally unseekable, it's simple to fix this: simply disable it (if in auto mode, the default) as soon as a seek is performed. This code is never called if the stream is considered unseekable, unless the user forced it. There's still a chance this linearization is performed before a seek happens. This will be a bit awkward, but no worse than without this feature, since seeking with timestamp resets is inherently broken in both mpv and libavformat. Fixes: #6974 Fixes: 27fcd4d
* travis: use macOS 10.14 image with xcode 11 instead of xcode 10.2der richter2019-09-221-1/+1
|
* build: optimise adding additional objects for linkingder richter2019-09-222-6/+6
| | | | | splitting the string by spaces isn't the best idea, so we use a proper list instead now.
* osxbundle: remove rpath definitions towards dev toolsder richter2019-09-221-1/+22
| | | | | | | | since the loading order of rpaths is system wide lib path, dev tool path and then bundle lib path it's possible for the xcode swift libs to be incompatible with the libs the bundle was build with. this leads to possible segfaults. if we distribute the bundle we don't want to load the libs from the dev tools anyway.
* build: fix swift linking with upcoming xcode 11der richter2019-09-222-0/+9
| | | | | | | in xcode 11 the dynamic swift libraries were moved to a separated versioned swift folder, which can't be used for linking and only for distribution. additional to the std dynamic swift lib folder the system wide folder is needed for linking too.
* draw_bmp: Fix for GBRP formats GBRP9 and upAnton Kindestam2019-09-221-5/+10
| | | | | | | | | | | | | | | | | | | First we shift the values up to the actual amount of bits in draw_ass, so that they will be drawn correctly when using formats with more than 8 bpc. (draw_rgba is already correct w.r.t. RGB formats with 9 or more bpc) Then, in scale_sb_rgba, by setting the amount of bits per channel used for planar RGB formats (formats are always planar at this point in draw_bmp) to be the same as the source from 9 to 16 bpc (in effect all the various GBRP formats) we manage to fit the special case that does not require any conversion in chroma_up and chroma_down when handling these formats (as long as the source itself is a planar format), instead writing directly to the combined dst/src buffer. This in turn works around a bug (incorrect colors) in libswscale when scaling between GBRP formats with 9 or more bpc. Additionally this should be more efficient, since we skip up- and down-conversion and temporary buffers.
* 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.