summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* stats.lua: show HDR meta if not equal to 203Kacper Michajłow2023-10-141-4/+7
| | | | | SDR white (203) is indeed not interesting, but anything else, even if lower is.
* stats.lua: separate video parameters from video outKacper Michajłow2023-10-141-42/+85
| | | | | | | | Source video parameters are interesting, but we mix them with video output/target parameters. Which will differ. Add "Display" showing true output params from VO, including HDR passthrough info and everything. This makes much more consistent output and alows to quickly diagnose how is source video translated to target display.
* f_decoder_wrapper: change video-codec to show description or nameKacper Michajłow2023-10-142-2/+3
| | | | | | | | Not both of them. Formating it as `<name> (<desc>)` produced arguably silly string like `hevc (HEVC (High Efficiency Video Coding))`. Unpack this to show only description if available or name otherwise. Produces way nicer results in stats.lua and similar places where this name is printed.
* command: fix fps property nameKacper Michajłow2023-10-141-1/+1
| | | | fps property was not renamed in events.
* command: early exit in some properties to avoid going through VOCTRLKacper Michajłow2023-10-141-18/+39
|
* m_property: add read_sub_validate to check if should be processedKacper Michajłow2023-10-142-0/+22
| | | | | In many cases it makes sense to early exit instead of preparing all the data only to return type or not implemented.
* vo_gpu_next: only increment osd_sync in update_overlays if pausedDudemanguy2023-10-131-1/+1
| | | | | While the video playing, it's not actually needed and can cause unnecessary redraws. Fixes #12623.
* command: fix segfault with playlist-{next,prev}-playlistGuido Cella2023-10-132-1/+2
| | | | | | | | | | | | | | | | | | | | This was wrongly assuming that playlist_path is always set for the current playlist entry, but it's only set when a file was added by expanding a playlist. The crash in playlist_get_first_in_next_playlist can be reproduced with mpv foo.mkv foo.zip, playlist-next, playlist-prev, playlist-next-playlist. You need to run playlist-next, playlist-prev first because foo.zip's playlist_path is NULL until you do that, which makes playlist_get_first_in_next_playlist return immediately. The crash in cmd_playlist_next_prev_playlist can be replicated with mpv --loop-playlist foo.zip foo.mkv, running playlist-next until foo.mkv, and playlist-play-next. Again, you need to open foo.zip first or its playlist_path is NULL which skips running strcmp(entry->playlist_path, mpctx->playlist->current->playlist_path). Fixes https://github.com/mpv-player/mpv/issues/12495#issuecomment-1760968608
* README: update release frequencyGuido Cella2023-10-131-4/+4
| | | | Updates README.md like 1e9a2cbebff updated DOCS/release-policy.md.
* terminal-unix: make stop/cont sighandlers pipe basedNRK2023-10-131-16/+37
| | | | | | | | | there are currently some silly data-races in the stop/cont sighandler due to the fact that the signal handler might get invoked in a different thread. this changes those sighandlers to a pipe-based approach similar to the existing "quit" sighandler.
* terminal-unix: avoid data race + simplifyNRK2023-10-131-13/+4
| | | | | | | | | | | | tio_orig and tio_orig_set are being touched inside of signal handler which might be invoked from another thread - which makes this a data race. there's no real reason to set tio_orig inside of do_activate_getch2() which is registered as a signal handler. just set it once, in terminal_init(), before any signal handlers come in play. this also allows removing the tio_orig_set variable completely.
* terminal-unix: avoid data-race on do_deactivate_getch2NRK2023-10-131-2/+3
| | | | | | | | | | | | | do_deactivate_getch2() touches some global variables which *might have* been fine if the terminal thread was the one that received the signal but AFAIK which thread will handle the signal is not well defined. in my case, when quitting mpv with CTRL+C the main thread receives the signal rather than the terminal thread and touches those globals without synchronization. caught by ThreadSanitizer. the solution is to move the do_deactivate_getch2() call outside of the signal handler.
* drm_common: don't spoil errno in signal handlerNRK2023-10-131-0/+2
| | | | same rationale as last commit
* terminal-unix: don't spoil errno in signal handlerNRK2023-10-131-1/+6
| | | | | | | otherwise the resuming code might end up seeing a spoiled errno and end up taking unintended branches based on it. caught via ThreadSanitizer
* console.lua: print the log and input line to the terminalGuido Cella2023-10-111-0/+33
|
* ytdl_hook.lua: set metadata with single tracksGuido Cella2023-10-111-3/+4
| | | | | | | | | | Use EDL for single tracks with metadata to set the uploader, channel url and description metadata with --ytdl-format=best. Currently, these are only set with the other ytdl formats with video and audio in different streams. The uploader tag is commonly available in sites other than Youtube too, so it may be simpler to always use EDL with single tracks.
* defaults.lua: add a disabled parameter to timer constructorsMike Will2023-10-112-6/+12
| | | | | | | | Added to the functions `mp.add_timeout` and `mp.add_periodic_timer`. If the `disabled` argument is set to `true` or a truthy value, the timer will wait to be manually started with a call to its `resume()` method.
* DOCS/options: vdpau requires GLXGuido Cella2023-10-111-1/+2
| | | | | | | Only vpdau-copy works with EGL. 2d1d815cc7 already added this to manpage, and 1c8d2246bf removed it again, but that seems to be a mistake because I can only get vdpau to work with GLX, and another user also reported that only vdpau-copy was working for him with the default EGL.
* win32: improve window snapping behaviorsunpenghao2023-10-101-53/+113
| | | | | | | | | | | Several window resizing operations (i.e., --auto-window-resize, border dragging with --keep-aspect-window, Alt+0/1/2) cause the window to detach from the snapped borders. This patch resolves this by recording to which borders the window is snapped, and using this info to determine how the window should be placed after resizing. Closes https://github.com/mpv-player/mpv/issues/6588
* osdep/timer-win2: use Waitable Timer for sleepingKacper Michajłow2023-10-101-7/+31
| | | | | | | Allows higher resolution sleeps than Sleep which has milliseconds resolution. In practice Windows kernel does not really go below 0.5ms, but we don't have to limit ourselves on API side of things and do the best we can.
* timer: change mp_sleep_us to mp_sleep_nsDudemanguy2023-10-109-28/+27
| | | | | | | | | | | Linux and macOS already use nanosecond resolution for their sleep functions. It was just being converted from microseconds before. Since we have mp_time_ns now, go ahead and bump the precision here. The timer for windows uses some timeBeginPeriod thing which I'm not sure what it does really but whatever just convert the units to ms like they were doing before. There's really no reason to keep the mp_sleep_us helper around. A multiplication by 1000 is trivial and underlying OS clocks have nanosecond precision.
* libmpv: add mpv_time_ns()Dudemanguy2023-10-103-2/+16
| | | | | | 9606c3fca9d568dc43711017dcb35a408c0d2883 added mp_time_ns(). Since we apparently expose the mp_time_us() to clients already, there's no reason to not also expose the new nanosecond one.
* vo: use mp_poll wrapper in wait_events when applicableDudemanguy2023-10-105-6/+27
| | | | | | | | | | On linux, several platforms poll for events over a fd. This has ms accuracy, but mpv's timer is in ns now so lots of precision is lost. We can use an mp_poll wrapper to use ppoll instead which takes a timespec directly with nanosecond precision. On systems without ppoll this falls back to old poll behavior. On wayland, we don't actually use this because ppoll completely messes up the event loop for some unknown reason.
* osdep: rename polldev to poll_wrapperDudemanguy2023-10-104-6/+7
| | | | | | | Originally, this was added as purely a shim for macOS. However since we want to do high resolution polling which is not neccesarily available on all platforms, making this a generic wrapper for poll functions is useful so rename it.
* vo: change vo->driver->wait_events to nanosecondsDudemanguy2023-10-1019-39/+39
| | | | | | | | | | | | In many cases, this is purely cosmetic because poll still only accepts microseconds. There's still a gain here however since pthread_cond_timedwait can take a realtime ts now. Additionally, 37d6604d70c8c594de2817db26356c4c950ac0fd changed the value added to timeout_ms in X11 and Wayland to ensure that it would never be 0 and rounded up. This was both incomplete, several other parts of the player have this same problem like drm, and not really needed. Instead the MPCLAMP is just adjusted to have a min of 1.
* vo: use nanoseconds for frame duration and ptsDudemanguy2023-10-104-16/+16
|
* player: store last_time timestamp in nanosecondsDudemanguy2023-10-102-3/+3
|
* vo: remove vo_get_estimated_vsync_interval conversion to secondsDudemanguy2023-10-102-3/+2
| | | | | This is weird. The caller should be responsible for converting the value if desired. Move the conversion to player/command.c instead.
* DOCS/lua: update read_options exampleGuido Cella2023-10-101-2/+2
| | | | | This still shows the old way of calling read_options even though it was deprecated 8 years in ago 327b091909e.
* console.lua: exit with with Ctrl+[Guido Cella2023-10-102-1/+2
| | | | | This binding commonly closes similar input buffers like vim's Command-line mode and dmenu.
* command: add playlist-next-playlist and playlist-prev-playlistGuido Cella2023-10-095-0/+123
| | | | | | | | | | | | playlist-prev-playlist goes to the beginning of the previous playlist because this seems more useful and symmetrical to playlist-next-playlist. It does not go to the beginning when the current playlist-path starts with the previous playlist-path, e.g. with mpv --loop-playlist foo/, which expands to foo/{1..9}.zip, the current playlist path foo/1.zip beings with the playlist-path foo/ of {2..9}.zip and thus playlist-prev-playlist goes to 9.zip rather than to 2.zip. Closes #12495.
* ci: add sanitizers to Tumbleweed buildKacper Michajłow2023-10-081-0/+1
| | | | | We don't have much test coverage, but even running the built binary doesn't harm to check with sanitizers.
* core: remove duplicate init_{audio,video}_decoder declarationsDudemanguy2023-10-081-2/+0
|
* core: remove declarations of unused functionslcksk2023-10-081-4/+0
|
* TOOLS/autocrop.lua: add support for detect_min_ratioKacper Michajłow2023-10-071-1/+9
| | | | This was lost in 6b963857c0
* DOCS/input: document the full sub-propertyGuido Cella2023-10-071-0/+30
|
* console: support utf8 for table formattingChristoph Heinrich2023-10-071-3/+18
|
* console: cull lines outside of visible areaChristoph Heinrich2023-10-071-18/+25
| | | | | | Lines that would be outside of the visible area are now culled. The log messages were already culled, however with the introduction of suggestions, they also needed a small update.
* console: show completion suggestions as tableChristoph Heinrich2023-10-072-10/+87
| | | | | | | | | | | | Completion suggestions are now nicely formatted into a table. Maximum width of the table is estimated based on OSD size and font size. This requires a new scaling factor option `font_hw_ratio`. A factor of 2.15 works great for me, but the default is 2.0 to avoid problems with other fonts. The space between columns is automatically adjusted to be between 2 and 8 spaces. It tries to use as few rows as possible.
* console: show suggestions for completionChristoph Heinrich2023-10-071-17/+34
| | | | | | | Tab completion now shows a list of all potential completions between the log messages and prompt. The text is colored to differentiate it from regular text. The color matches the theme and is similar to the mpv logo.
* console: refactor text styles for log levelsChristoph Heinrich2023-10-071-9/+22
| | | | | | | The text styles are now in a table. The color definitions of the theme where the colors were taken from are now included in a comment for future reference. The colors have been converted to BGR as is required by ASS.
* TOOLS/autocrop.lua: simplify codeGuido Cella2023-10-071-30/+14
| | | | | Refactor code that is no longer necessary after replacing vf=crop with video-crop. There is no change in behavior.
* player/video: mention --profile=fast and --hwdec in AV desync messageKacper Michajłow2023-10-071-0/+1
|
* vo: remove frame timing check from vo_still_displaying()Kacper Michajłow2023-10-071-10/+3
| | | | | This timing dependency does not guarantee that we will wake up in the future, depending on processing times.
* Revert "video: remove another redundant wakeup"Kacper Michajłow2023-10-073-45/+20
| | | | | | | | | | | | | | | vo_still_displaying() is racey with vo_request_wakeup_on_done() and above that it doesn't work as expected. VO can run out of work and go to sleep for 1000s, while the play thread still returns on vo_still_displaying() check, because of a check `now < frame_end` so it never advances and go to sleep itself. This fixes dead lock that we have when image parameters changes during playback. This reverts commit 0c9ac5835be70ae26e4aa875e833fe2c7b3b3bf3. Fixes: #12575
* ci/mingw: use vulkan-loader v1.3.266Kacper Michajłow2023-10-071-2/+2
| | | | | | | | | | | Upstream has been changing buildsystem and current vulkan.pc is not functional with custom prefix path. Rollback to older version until it is fixed. See: https://github.com/KhronosGroup/Vulkan-Loader/issues/1318 https://github.com/KhronosGroup/Vulkan-Loader/issues/1319
* mp_image: don't copy crop value from opaque_refKacper Michajłow2023-10-071-1/+0
| | | | | | It is already set above. Fixes: #12577, #12587
* demux_playlist: use --metacode-codepage when parsing playlist filesDudemanguy2023-10-071-22/+63
| | | | | | | | | | | | It's 2023 and people don't use UTF-8 for their m3u, ini, etc. files. Well mpv already has the tools in place to try and guess other codepages, so we might as well use it I guess. This change is pretty awkward since we have to read line-by-line but mp_iconv_to_utf8 may sometimes allocate memory. So sometimes the bstr needs to be freed and sometimes not for every line. Also we need to make another copy of the line on the stack since splitting by tokens and such will mess up the original line which may possibly be allocated memory. The ugliness is mostly hidden in pl_free_line, but it's still weird. Fixes #10911.
* demux: change the default of metadata-codepage to autoDudemanguy2023-10-074-6/+7
| | | | | | | There's really no reason not to do this especially since sub-codepage already defaults to auto. Also change logging in charset_conv since telling us that the data is UTF-8 if the passed codepage value is "auto" or "utf-8" is really not useful information (that's the expectation).
* demux_cue: deprecate --demuxer-cue-codepage for --metadata-codepageDudemanguy2023-10-073-18/+7
| | | | | | | | | What are cue sheets not metadata or something? No reason this needs to be a separate option so just deprecate it. This does mean that the default value changes from "auto" to "utf-8" for this obscure fringe case. I really hope people don't use non-UTF-8 cuesheets, but the next commit will change the default of --metadata-codepage to "auto" so there's no actual change in behavior to users.
* charset_conv: remove ancient warning about deprecated syntaxDudemanguy2023-10-072-15/+0
| | | | | wm4 removed this in 4adfde5dd1e67775228a345cea00ea03ba6bc68f and left a warning. Nobody needs to know that enca:pl used to work.
* stream_lavf: use metadata-codepage option for codepage conversionDudemanguy2023-10-071-0/+16
| | | | | | a343666ab5121e7a3388be9aa2d8731d6d1f2f64 made demux options public, so we can take advantage of that here as well. This lets users guess the codepage if the stream doesn't use UTF-8 characters. Fixes #8844.
* af_scaletempo: overlap is a factor not a percentageChristoph Heinrich2023-10-072-6/+6
|
* DOCS/mpv: update mpv.conf's documentationGuido Cella2023-10-061-17/+21
|
* TOOLS/autocrop.lua: update commentGuido Cella2023-10-061-64/+44
|
* sd_ass: enable sub-start and sub-end with unknown duration subsGuido Cella2023-10-061-1/+1
| | | | | | | The function called to get sub-start and sub-end returns early when the subtitle's duration is unknown, but by just removing this check the properties work fine. The final sub line has a very large sub-end, but that is much better than not having the properties work at all.
* vo_gpu_next: improve updating overlaysDudemanguy2023-10-054-27/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | fbe154831a8addfc18a4f81e1c4b9284c31acace added a new VOCTRL to signal when the OSD changed for gpu-next's handling of subtitles, but this is both not necessary and actually incomplete. The VOCTRL would signal OSD changes, but not all subtitle changes (like selecting another non-external sub track for example). VOCTRL_OSD_CHANGED was used to increment p->osd_sync which would then redraw the blended subtitles if the player was paused. But there's already a VOCTRL_PAUSE and VOCTRL_RESUME. Plus, the sub_bitmap_list object will have items in it if it changed in any way, so we don't need the VOCTRL_OSD_CHANGED method at all. That can be removed. The check that fp->osd_sync < p->osd_sync stays in place since that's an optimization while the video is playing, but we also check the pause state as well since the VO can know this. If we're paused, then always do update_overlays since core must be signalling a redraw to us if we get a draw_frame call here. Additionally in update_overlays itself, the p->osd_sync counter is incremented if we have any items since the frame signature will need that. As for the actual bug that is fixed, changing subtitle tracks while paused with blended subtitles now correctly works. Previously, it was never updated so the old subtitle stayed there forever until you deselected it (since VOCTRL_OSD_CHANGED triggered there). Also include some cosmetic code fixes that were noticed.
* vo_dmabuf_wayland: correct full window size calculationDudemanguy2023-10-051-1/+3
| | | | | | | | | | | The current calculation makes the implicit assumption that the margins on both sides are always equal (the 2 times multiplication). This isn't true though. For example, a 720p video fullscreened on a 1680x1050 display will have a top margin of 52 but a bottom margin of 53. The current calculation just multiplies 52 by 2, so it's off by one. Fix this by adding together all the margins together (left + right or top + bottom) then adding that to the dst window size (width or height). This way, we get the full size of the window for the viewport. Fixes #12554.
* win32: clear client area to black earlyKacper Michajłow2023-10-051-2/+5
| | | | | | | | | | | | This fixes white background appearing for short period of time before first frame is drawn. Clear to black as this is way less distracting than bright white flash. Borderless window and fullscreen seems to be initially not drawn/transparent, so no need to clear it to black. Only when decorations are enabled (--border) the issue happens. Fixes: #12549
* player: remove unused mutate argument in mp_next_fileDudemanguy2023-10-053-7/+6
| | | | | | e277fadd60350caad1fc31e92a5076692e61dcc9 originally added this but it never actually did anything in the function... wm4 probably changed his mind but forget to delete it so just remove it here.
* loadfile: fix an old wonky playlist heuristicDudemanguy2023-10-052-17/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2c6a3cb1f27e02b2e66390a2465ab648905a64d0 originally added this struct member and then 1be863afdbe9017aa227234e8525b209fb818224 later added some more logic to loadfile that uses this. There's been more changes since then of course, but bits using playback_short and playback_start have mostly stayed the same. It's a bit strange it's worked this way for so long since it makes an assumption on how long files should be and leads to weird, broken behavior on playlists with shorter videos. The main reason for playlist_short, as far as I can tell, is to deal with some fringe cases with short videos and trying to go back in the playlist. More specifically, if you use --loop=inf on a very short video (say less than 1 second) and try to go back in the playlist, you won't be able to without any of this special logic that deals with it. But the current approach has several side effects like going back multiple items in the playlist instead of just one if the video is less than one second. This is just bad so delete everything related to playlist_short and playlist_start. Instead, let's handle this by keeping track of playlist-prev attempts. Going forward in the playlist doesn't require any special handling since a bad/broken file will just advance to the next one. So it's only going backwards that requires some special consideration. If we're going backwards and the user isn't using force, then mark the playlist entry with a special flag. If the file loads successfully in play_current_file, we can just clear the flag and not worry about it. However if there's a failure, then we set a bool telling play_current_file that it should go back one more item in the playlist if possible and try again. This way, we avoid the previously mentioned --loop=inf edgecase and the user can still attempt to retry previously failed items in the playlist (like a url or such). Fixes #6576, fixes #12548.
* af/vf-command: add ability to target a specific lavfi filterAshyni2023-10-054-15/+33
| | | | fixes: #11180
* vo_dmabuf_wayland: free frame if th