| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
It sometimes happens on exit, and it's probably a bad idea. If the
process hangs on exit (possibly due to stupid hardcoded timeouts it's
doing), mpv will also hang now, unfortunately.
(cherry picked from commit be9bf4cc7c1b61a8abcbb3f64386ef10d8aa9f61)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It appears some WMs have a problem with out method of setting initial
fullscreen mode. We assume that if the window's _NET_WM_STATE includes
_NET_WM_STATE_FULLSCREEN before mapping the window, the WM will show it
as fullscreen at mapped. EWMH doesn't say anything that this should
work, although one could argue that it's implied.
In any case, since it's not standard behavior without at least some
doubt, it's probably a good idea to try the "old" method as well.
Fortunately, it should be idempotent.
See #1937, #1920.
(cherry picked from commit a4f3df5970cc34d8899dbd31b3475f7bd6547f3f)
|
|
|
|
|
|
| |
Leads to some nice memory corruption otherwise.
(cherry picked from commit 06bfa9309d848b41ef1394ebc4311a879f8f4093)
|
|
|
|
|
|
|
| |
pts can never be 0 or negative. If there is no frame, some code below
catches this case by checking hasframe.
(cherry picked from commit 372b85b9d20e3bc97120e2506ef9f89224e0f84e)
|
|
|
|
| |
(cherry picked from commit 9251fa125f6ebc0f485c93af1809efb7b6da19bd)
|
|
|
|
|
|
|
|
| |
Some code always calls vo_event(), even with event==0, which leads to
immediate wakeup, which in turn causes the function to be called again.
This would burn CPU, which was especially noticeable when paused.
(cherry picked from commit 0bdef9979f74db33d1c84ee788c45f5e1d8e0d0d)
|
|
|
|
|
|
| |
Quite an oversight.
(cherry picked from commit 4d9255a5e1a1c5be805800070a79ef1bcc1a150a)
|
|
|
|
|
|
|
|
|
| |
Gives the VOs more flexibility.
gl_video.c already ignores the timing info if no interpolation is
active, so this requires no further changes.
(cherry picked from commit af157db7e5803fbe8b323ba2e9671e65c8fd6c2c)
|
|
|
|
|
|
|
|
|
| |
There is not much of a reason to have these wrappers around. Use POSIX
standard functions directly, and use a separate utility function to take
care of the timespec calculations. (Course POSIX for using this weird
format for time values.)
(cherry picked from commit 92b9d75d7256be71d8c8b18438af9494b78f0e96)
|
|
|
|
|
|
|
| |
The first one (for VOCTRL_GET_DISPLAY_FPS) could have led to undefined
behavior if the FPS was unknown. The second is for general symmetry.
(cherry picked from commit 10149f68a5c6cb9783ed7595998985d7e586e871)
|
|
|
|
|
|
|
|
|
|
|
| |
Now among other things panscan can be changed during playback.
Unfortunately, it flickers. The issue is that reconfig() clears the
framebuffer. Removing the clearing shows that the "unused" parts of
the picture are not cleared - even though OSD could render there. As
such, this is a separate issue.
(cherry picked from commit 56310605690288f44c49363413e68f7c73325ed1)
|
|
|
|
|
|
|
|
| |
When running with --panscan=1, this could crash - because the current
frame was reduced in size each time the image was redrawn, which would
result in a failed assertion the second time it's drawn.
(cherry picked from commit 859ddc99064357c752c6f6dfa475cb96430531d2)
|
|
|
|
|
|
| |
This reverts commit af930e2a2e3f33aa11a0fea3d6c3e3c7344b21fb.
Better avoid big behavior changes within a release series.
|
|
|
|
| |
(cherry picked from commit f58d3591d9c192c9d68a76a0a4ffddd7516c0ef2)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should fix some crashes due to dangling pointers.
The problem was that with_cocoa_lock_on_main_thread() is asynchronous.
It will not wait until it is finished. In the uninit case, this means
the VO could be deallocated and destroyed while cocoa was still running
uninit code.
So simply wait until it is done by using dispatch_sync(). There were
concerns that this could introduce a deadlock by the main thread trying
to wait for something on the VO thread. But from what I can see, this
never happens, and even if it does, it would crash anyway since the VO
is already gone.
One remaining worry is the video_resize_redraw_callback. From what I can
see, it still can mess things up, and will need a more elaborate fix.
(cherry picked from commit e7777563018fc711c873ba9480744f0961786077)
|
|
|
|
|
|
|
|
|
|
| |
Reduces (but likely does not remove) the danger of rounding intermediate
values down to 8 bit. This is important for cscale, or any other
processing that might store raw YUV values in framebuffers.
Fixes #1918.
(cherry picked from commit cf210c4ffc6d008dd2bdd7c5d4d031ecdcf05fb7)
|
|
|
|
|
|
|
| |
This lets us avoid having to maintain two separate copies of the
colorspace mapping functions.
(cherry picked from commit 08d3ef3d9e94609d1fc6c4c0892b17945bc7d0f8)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This unbreaks compiling command line player and libmpv at the same
time. The problem was that doing so silently disabled the OSX
application thing - but the command line player can not use the
vo_opengl Cocoa backend without it.
The OSX application code is basically dead in libmpv, but it's not
that much code anyway.
If you want a mpv binary that does not create an OSX application
singleton (and creates a menu etc.), you must disable cocoa
completely, as cocoa can't be used anyway in this case.
(cherry picked from commit 19a5b20752ecc7465cf17781f908e12bf4ca136d)
|
|
|
|
| |
(cherry picked from commit dce941b99c9e098b8471528908d1509ab040b7a4)
|
|
|
|
|
|
|
|
|
|
| |
(Not sure why it worked without this when I tested the previous
changes.)
Untested, but should be fine. This is equivalent what is done on e.g.
panscan changes.
(cherry picked from commit 94a3a76ee31bdc00255dc231e99be9f9ad6f38fa)
|
|
|
|
|
|
|
|
|
| |
I think this used to be quite important, because the ancient VfW support
in MPlayer used to output flipped frames. This code has been dead in mpv
for quite some time (because VfW decoders were removed, and the --flip
option was dropped too), so get rid of it.
(cherry picked from commit e185887ba0da9967337541ebd71e244fb2833c4f)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the wayland backend needs extra work to avoid drawing more
often than the wayland frame callback allows. (This is not ideal, but
will be fixed at a later time.)
Unify this with the start_frame callback added for cocoa. Some details
change for the better. For example, if a frame is dropped, and a redraw
is done afterwards, the actually correct frame is redrawn, instead
whatever was in the textures from before the dropped frame.
(cherry picked from commit 0a7abbda6b555fb7746f737b52d0f00fb3e614db)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With --idle --force-window, or when started from the bundle, the cocoa
code dropped the first frame. This resulted in a black frame on start
sometimes.
The reason was that the live resizing/redrawing code was invoked, which
simply set skip_swap_buffer to false, blocking redrawing whatever was
going to be rendered next. Normally this is done so that the following
works:
1. vo_opengl draw a frame, releases GL lock
2. live resizing kicks in, redraw the frame
3. vo_opengl wants to call SwapBuffers, drawing a stale buffer
overwritten by the live resizing code
This is solved by setting skip_swap_buffer in 2., and querying it in 3.
Fix this by resetting the skip_swap_buffer at a known good point: when
vo_opengl starts drawing a new frame.
The start_frame function returns bool, so that it can be merged with
is_active in a following commit.
(cherry picked from commit e23e4c7c603fc1cd911621d0f833031be4a6f7c7)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit f1746741dee6000b7fd139e7a10f72aba0674b3b changed the drop
logic to have more slack (drop more frames but less frequent) to prevent
drops due to timing jitter when the clip and screen have similar rates.
However, if the clip has higher rate than the screen (or just higher
playback rate), then that policy hurts smoothness since these "chunked
drops" look worse than one frame drop at a time.
This patch restores the old drop logic when the playback frame rate is
higher than ~5% above the screen refresh rate, and solves this issue.
Fixes #1897
(cherry picked from commit ffcad1a72b9a3bf5a7ac5ddcbfa71ec19b6faf9b)
|
|
|
|
| |
(cherry picked from commit 8c7f3adb413ccea35aef3878f020d6a10e9ad5de)
|
|
|
|
|
|
|
|
|
|
| |
Also factor the display size initialization into a separate function.
For some reason this seems to work, although setting the background
color using this 1x1 pixel bitmap does not work. I blame the RPI
beign a terrible piece of hardware with even worse drivers.
(cherry picked from commit 6ae66e717faa4e9ce286ff0532d4ec19a66faf49)
|
|
|
|
|
|
|
| |
The previous version of this logic resulted in black crush and incorrect
brightness scaling when combined with limited range (TV) output.
(cherry picked from commit 99439f11ea6add0996adc6f5fb04bb7d27da265e)
|
|
|
|
|
|
|
|
|
|
| |
It's weird that this basically adjusts the contrast between luma and
chroma, and not blackness.
This is more in line with the behavior of libswscale, the vdpau
"procamp" (which mpv doesn't use), and Xv.
(cherry picked from commit 0600d378f9afb20d92e75d26c0df7d255e1df554)
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now, the default behavior is to pick the numerically lowest screen
ID that overlaps the window in any way - but this means that mpv will
decide to pick an ICC profile in a pretty arbitrary way even if the
window only overlaps another screen by a single pixel.
The new behavior is to query it based on the center of the window
instead.
(cherry picked from commit daf4334697145f771c5085fb183e64dc65a967bd)
|
|
|
|
| |
(cherry picked from commit 1e2e5043496aaf55c29e89289582f9fbf8001f8c)
|
|
|
|
| |
(cherry picked from commit 5f21a68ce9a7aeef3f6c395661af06ce9266c91e)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vo_opengl (or gl_hwdec_vdpau.c to be specific) calls
mp_vdpau_mixer_render() with video_rect=NULL, which means to use the
full surface. This is incorrect if the surface is actually cropped, as
it can happen with h264. In this case, it was rendering the parts
outside of the image.
Fix it by making this case use the cropped size instead.
Alternative fix for PR #1863.
(cherry picked from commit a5ed6e49bf87500ed606437901f00ae9b3da138f)
|
|
|
|
| |
Requested. Works similar to the property with the same name.
|
|
|
|
|
| |
Suggested by avih. This handles x/1.001 frame rates for all multiples of
24 and 30 under 144.
|
| |
|
|
|
|
|
|
| |
gpu_mempcy should to be called from code which targets SSE
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
| |
MP_IMGFIELD_TOP/MP_IMGFIELD_BOTTOM were completely unused, and
MP_IMGFIELD_ORDERED was always set (even though vf_vdpaupp.c strangely
checked for the latter).
|
|
|
|
| |
These changed in VapourSynth. Also, "_Field" is now unused.
|
|
|
|
|
| |
It passed the unconverted image to the writer function. Broken since
2469cb5d.
|
| |
|
| |
|
|
|
|
|
|
| |
If user switched terminals frantically, mpv could get SIGUSR1 twice in a
row, which, up until now, resulted in destroying CRTC twice. This caused
it to segfault. After this fix, double SIGUSR1 should be ignored.
|
| |
|
|
|
|
|
| |
These are basically MPlayer leftovers, and barely useful due to being
redundant with other messages. The FPS message is used somewhere else.
|
|
|
|
| |
Needed for a later commit.
|
|
|
|
| |
Instead of using int like bool, use bool directly.
|
|
|
|
|
|
|
|
| |
Vapoursynth made an incompatible API change: clips with unknown length
are not supported anymore. In fact, Vapoursynth abort()s the program
(which by the way invalidate all of its claims of API/ABI stability).
So add some nonsense to make it work again.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the old implementation for these properties. It was never very
good, often returned very innaccurate values or just 0, and was static
even if the source was variable bitrate. Replace it with the
implementation of "packet-video-bitrate". Mark the "packet-..."
properties as deprecated. (The effective difference is different
formatting, and returning the raw value in bits instead of kilobits.)
Also extend the documentation a little.
It appears at least some decoders (sipr?) need the
AVCodecContext.bit_rate field set, so this one is still passed through.
|
|
|
|
|
|
|
| |
Since e207c24b32a457859ab6e3a5b1f5f9eaeea36ed1, vf_mirror requires
libavfilter.
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
| |
This prevents the machine from going to sleep while a video-only stream
is playing. When audio is playing, the audio stack should make this
request for us.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Logging was meant to be silenced only when user uses connector
auto-detection feature. If user supplies connector ID manually, he
should see exact reason why connecting to this specific connector
failed.
|
|
|
|
| |
Fixes #1828
|
|
|
|
| |
Fixes #1827
|
|
|
|
| |
These are redundant.
|
|
|
|
|
| |
Currently, libavfilter's equivalent vf_hflip is probably not faster or
anything, but there's still no reason to keep the internal code.
|
|
|
|
|
| |
I assume this was intended to generate an initial change event in order
to make the user read the initial values.
|
|
|
|
|
| |
And also undoxygenify a comment. (There used to be some inconsistent
doxygen comments in MPlayer time; they are being removed on sight.)
|
|
|
|
|
|
| |
It's entirely useless, especially now that vo.c handles screenshots in a
generic way, and requires no special VO support. There are some
potential weird use-cases, but actually I've never seen it being used.
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We already use 2 screensaver APIs when attempting to disable the
screensaver: XResetScreenSaver() (from xlib) and XScreenSaverSuspend
(from the X11 Screen Saver extension). None of these actually work.
On modern desktop Linux, we are expected to make dbus calls using some
freedesktop-defined protocol (and possibly we'd have to fallback to a
Gnome specific one). At least xscreensaver doesn't respect the "old"
APIs either.
Solve this by running the xdg-screensaver script. It's a terrible, ugly
piece of shit (just read the script if you disagree), but at least it
appears to work everywhere. It's also simpler than involving various
dbus client libraries.
I hope this can replace the --heartbeat-cmd option, and maybe we could
remove our own DPMS/XSS code too.
|
|
|
|
|
| |
Use a choice instead of an integer. This is incompatible, but I'm not
adding any compatibility since this option was added recently.
|
|
|
|
|
|
|
| |
This is optional, but ensures that linking with -Wl,--as-needed does
not drop the MMAL VC driver. The driver normally "registers" itself
in the library constructor, but since no symbols are explicitly
referenced, the linker could remove it with as-needed enabled.
|
|