scaletempo2 has this optimization where it first uses a step size of 5
together with a quadratic interpolation to quickly get the approximate
position of the best overlap and then does a more thorough search aroun
that area.
Doing the same thing in scaletempo brought a 4.8x performance
improvement, however in my measurements a step size of 3 more
consistently finds good overlaps and it's still a 2.9x improvement for
this function.
I should note that while a step size of 3 produced better numbers,
I was not actually able to hear any difference in my test.
A step size of 3 was chosen just in case it actually makes an audible
difference in some cases and the cpu usage isn't really a problem
anymore, but that can be revisited in the future.
scaletempo2 is still faster then scaletempo with a step size of 5,
which I suspect is mostly because it uses some vectorized functions and
scaletempo does not.
This might seem counter intuitive at first, but we want to change the
sound in total as little as possible, not only the middle part of the
overlap.
This also removes the loop unrolling from the integer path to keep it as
close to the float path as possible. The difference in performance is
fairly small and if such an optimization is deemed desirable in the
future it should be implemented for both float and integer
This allows scripts to make the user choose from a list of entries by
typing part of their text and/or by navigating them with keybindings,
like dmenu or fzf.
Closes#13964.
Conditional jump or move depends on uninitialised value(s)
at 0x10FE22: drm_prime_remove_handle_ref (drm_prime.c:144)
by 0x10FCCD: drm_prime_destroy_framebuffer (drm_prime.c:107)
by 0x10FEB1: set_current_frame (hwdec_drmprime_drm.c:73)
by 0x11054F: overlay_frame (hwdec_drmprime_drm.c:223)
by 0xF1311: gl_video_render_frame (video.c:3315)
by 0xFA015: draw_frame (vo_gpu.c:85)
by 0xF8FDB: render_frame (vo.c:961)
by 0xF943F: vo_thread (vo.c:1099)
by 0x5EBE89B: start_thread (in /lib/libpthread-2.31.so)
Uninitialised value was created by a heap allocation
at 0x484713C: realloc (vg_replace_malloc.c:1437)
by 0x10258B: ta_realloc_size (ta.c:195)
by 0x10325D: ta_xrealloc_size (ta_utils.c:298)
by 0x10FDBF: drm_prime_add_handle_ref (drm_prime.c:133)
by 0x10FC57: drm_prime_create_framebuffer (drm_prime.c:87)
by 0x1102FF: overlay_frame (hwdec_drmprime_drm.c:188)
by 0xF1311: gl_video_render_frame (video.c:3315)
by 0xFA015: draw_frame (vo_gpu.c:85)
by 0xF8FDB: render_frame (vo.c:961)
by 0xF943F: vo_thread (vo.c:1099)
by 0x5EBE89B: start_thread (in /lib/libpthread-2.31.so)
Conditional jump or move depends on uninitialised value(s)
at 0x10FCE4: drm_prime_destroy_framebuffer (drm_prime.c:109)
by 0x10FEB1: set_current_frame (hwdec_drmprime_drm.c:73)
by 0x11054F: overlay_frame (hwdec_drmprime_drm.c:223)
by 0xF1311: gl_video_render_frame (video.c:3315)
by 0xFA015: draw_frame (vo_gpu.c:85)
by 0xF8FDB: render_frame (vo.c:961)
by 0xF943F: vo_thread (vo.c:1099)
by 0x5EBE89B: start_thread (in /lib/libpthread-2.31.so)
Uninitialised value was created by a heap allocation
at 0x484713C: realloc (vg_replace_malloc.c:1437)
by 0x10258B: ta_realloc_size (ta.c:195)
by 0x10325D: ta_xrealloc_size (ta_utils.c:298)
by 0x10FDBF: drm_prime_add_handle_ref (drm_prime.c:133)
by 0x10FC57: drm_prime_create_framebuffer (drm_prime.c:87)
by 0x1102FF: overlay_frame (hwdec_drmprime_drm.c:188)
by 0xF1311: gl_video_render_frame (video.c:3315)
by 0xFA015: draw_frame (vo_gpu.c:85)
by 0xF8FDB: render_frame (vo.c:961)
by 0xF943F: vo_thread (vo.c:1099)
by 0x5EBE89B: start_thread (in /lib/libpthread-2.31.so)
```
dd if=/dev/zero of=/tmp/10g.empty bs=1 seek=10G count=0
dd if=/dev/zero of=/tmp/10m.empty bs=1 seek=10M count=0
time mpv /tmp/10{g,m}.empty
```
I keep files with the name format `${name}-${hash}.${ext}.empty`
around, where the original is removed, and a sparse file with
the size of the original is created instead.
A lot of time is wasted on such files when going through
playlists/directories that include some of them.
This admittedly may not be that common of a use-case.
Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
`cuInit` wakes up the nvidia dgpu on nvidia laptops. This is bad news because the wake up process
is blocking and takes a few seconds. It also needlessly increases power consumption.
Sometimes, a VO loads several hwdecs (like `dmabuf_wayland`). When `cuda` is loaded, it calls
`cuInit` before running all interop inits. However, the first checks in the interops do not
require cuda initialization, so we only need to call `cuInit` after those checks.
This commit splits the interop `init` function into `check` and `init`. `check` can be called without
initializing the Cuda backend, so cuInit is only called *after* the first interop check.
With these changes, there's no cuda initialization if no OpenGL/Vulkan backend is available. This prevents
`dmabuf_wayland` and other VOs which automatically load cuda from waking up the nvidia dgpu unnecessarily,
making them start faster and decreasing power consumption on laptops.
Fixes: https://github.com/mpv-player/mpv/issues/13668
This avoids printing any stray messages in encode output stream.
--o is already pre-parse cli option which is designed to be parsed
before anything else is printed to output. So we can use that to force
stderr output if needed for encode mode.
Paths like foo.mkv, ./foo.mkv .//foo.mkv, ../"$(basename
"$PWD")"/foo.mkv, and C:\foo.mkv and C:/foo.mkv on Windows, use
different config files for resuming playback, so if you quit-watch-later
and later play the same file with a different path, mpv does not resume
playback. This commit normalizes the paths on Unix to fix this.
by default utilises the color space of the screen on which the window is
located. if a specific value is defined, it will instead be utilised.
depending on the chosen color space the macOS EDR (HDR) support is
activated and that OS's transformation (tone mapping) is used.
Fixes#7341
Misaki Kasumi
Christoph Heinrich
Guido Cella
Kacper Michajłow
repojohnray
Mohammad AlSaleh
nanahi
Jrelvas
der richter