| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
See previous commit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, vo_reconfig() calculates the requested window size and sets
the vo->dwidth/dheight fields _if_ VOCTRL_UPDATE_SCREENINFO is
implemented by the VO or the windowing backend. The window size can be
different from the display size if e.g. the --geometry option is used.
It will also set the vo->dx/dy fields and read vo->xinerama_x/y.
It turned out that this is very backwards and actually requires the
windowing backends to workaround these things. There's also
MPOpts.screenwidth/screenheight, which used to map to actual options,
but is now used only to communicate the screen size to the vo.c code
calculating the window size and position.
Change this by making the window geometry calculations available as
separate functions. This commit doesn't change any VO code yet, and just
emulates the old way using the new functions. VO code will remove its
usage of VOCTRL_UPDATE_SCREENINFO and use the new functions directly.
|
|
|
|
|
| |
This file was copied from gl_hwdec_vaglx.c to have a basic skeleton, but
no actual code is left from it.
|
|
|
|
|
|
| |
Commit 433161 actually broke vo_opengl (and maybe others), because
config_ok is not necessarily set correctly yet _during_ reconfig. So a
vo_get_src_dst_rects() call during reconfig did nothing.
|
|
|
|
|
|
|
|
|
|
| |
When the VO was not initialized with vo_reconfig(), or if the last
vo_reconfig() failed, changing panscan would cause a crash due to
vo_get_src_dst_rects() dereferencing vo->params (NULL if not
configured).
Just do nothing if that happens, as there is no video that could be
displayed anyway.
|
|
|
|
|
|
|
|
| |
Doesn't really seem to be much of use. Get rid of the remaining uses of
it.
Concerning vo_opengl_old, it seems uninitGl() works fine even if called
before initialization.
|
|
|
|
|
|
|
| |
This was a minor code duplication between vf_vdpaupp.c and vo_vdpau.c.
(In theory, we could always require using vf_vdpaupp with vo_vdpau, but
I think it's better if vo_vdpau can work standalone.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Renamed options:
--aspect → --video-aspect
--fstype → --x11-fstype
--native-fs → --fs-missioncontrol
--name → --x11-name
Renamed properties:
aspect → video-aspect
|
|
|
|
|
|
|
| |
Change how the video decoding loop works. The structure should now be a
bit easier to follow. The interactions on format changes are (probably)
simpler. This also aligns the decoding loop with future planned changes,
such as moving various things to separate threads.
|
|
|
|
|
| |
Currently, only the configured format is accepted, so assert that the
playback core code (which handles format changes) is correct.
|
|
|
|
|
| |
Since vdpau_mixer.c initializes the YUV conversion using the mp_image
flags, these images should have all flags set properly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the special casing of vo_vdpau vs. other VOs. Replace the
complicated interaction between vo.c and vo_vdpau.c with a simple queue
in vo.c. VOs other than vdpau are handled by setting the length of the
queue to 1 (this is essentially what waiting_mpi was).
Note that vo_vdpau.c seems to have buffered only 1 or 2 frames into the
future, while the remaining 3 or 4 frames were past frames. So the new
code buffers 2 frames (vo_vdpau.c requests this queue length by setting
vo->max_video_queue to 2). It should probably be investigated why
vo_vdpau.c kept so many past frames.
The field vo->redrawing is removed. I'm not really sure what that would
be needed for; it seems pointless.
Future directions include making the interface between playloop and VO
simpler, as well as making rendering a frame a single operation, as
opposed to the weird 3-step sequence of rendering, drawing OSD, and
flipping.
|
| |
|
|
|
|
|
| |
This is a horrible hack to keep compatibility with the vo_vdpau deint
sub-option.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous commits changed vo_vdpau so that these options are set by
vf_vdpaupp, and the corresponding vo_vdpau were ignored. But for
compatibility, keep the "old" options working.
The value of this is questionable - maybe the vo_vdpau options should
just be removed. For now, at least demonstrate that it's possible.
The "deint" suboption still doesn't work, because the framerate doubling
logic required for some deint modes was moved to vf_vdpaupp. This
requires more elaborate workarounds.
|
|
|
|
| |
So a caller can override the filter options dictated by vf_vdpaupp.
|
|
|
|
|
|
|
|
|
|
| |
This is slightly incomplete: the mixer options, such as sharpen and
especially deinterlacing, are ignored. This also breaks automatic
enabling of interlacing with 'D' or --deinterlace. These issues will be
fixed later in the following commits.
Note that we keep all the custom vdpau queue stuff. This will also be
simplified later.
|
|
|
|
|
|
|
| |
This uses mp_vdpau_mixer_render(). The benefit is that it makes vdpau
deinterlacing just work. One additional minor advantage is that the
video mixer creation code is factored out (although that is a double-
edged sword).
|
| |
|
|
|
|
| |
This field will also removed in the future.
|
|
|
|
|
|
|
| |
In theory, returning the screenshot with original pixel aspect would
allow avoiding scaling them with image formats that support non-square
pixels, but in practice this isn't used anyway (nothing seems to
understand e.g. jpeg aspect ratio tags).
|
|
|
|
|
|
|
|
|
| |
This extracts the scheduling logic to a single function which is nicer to keep
it consistent.
Additionally make sure we don't schedule sync operations from a sync operation
itself since that could cause deadlocks (even if it should not be happening
with the current code).
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Previously the window could be made to completly exit the screen with a
combination or moving it close to an edge and halving it's size (via cmd+0).
This commit address the problem in the most simple way possibile by
constraining the window to the closest edge in these edge cases.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a couple of issues with the Cocoa `--native-fs` mode, primarily:
- A ghost titlebar at the top of the screen in full screen:
This was caused by the window constraining code kicking in during
fullscreen. Simply returning the unconstrained rect from the constraining
method fixes the problem.
- Incorrect behavior when using the titlebar buttons to enter/exit
fullscreen, as opposed to the OSD button.
This was caused by mpv's internal fullscreen state going out of sync with
the NSWindow's one. This was the case because `toggleFullScreen:`
completely bypassed the normal event flow that mpv expects.
Signed-off-by: Ryan Goulden <percontation@gmail.com>
Change style for mpv, simplify and refactor some of the constraining code.
Signed-off-by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 6e34b0ec1f50612cb2767da3dbc27be0be63041d.
There has always been an error message "proxy already has a listener" and
I couldn't reproduce where it is comming from until now. The display interface
already has a listener and we can't overwrite it. Now remove the code and avoid
this error message.
Conflicts:
video/out/wayland_common.c
|
|
|
|
| |
fixes #741
|
|
|
|
|
|
| |
Add the event FD after preinit, remove it before destroy. There's no
need to do it on vo_config, and there's no need to remove the event
FD when vo_config fails.
|
|
|
|
| |
Group together related functionality.
|
| |
|
|
|
|
|
|
|
|
|
| |
Unfortunately, if a VO can't display something as intended, we can just
complain to the user, and leave it at it. But it's still better than
silently displaying things differently with different VOs.
For now, this is used for rotation only. Other things that we should
check includes colorspace and colorlevels stuff.
|
|
|
|
|
|
|
|
|
|
|
| |
This turned out much more complicated than I thought. It's not just a
matter of adjusting the texture coordinates, but you also have to
consider separated scaling and panscan clipping, which make everything
complicated.
This actually still doesn't clip 100% correctly, but the bug is only
visible when rotating (or flipping with --vf=flip), and using something
like --video-pan-x/y at the same time.
|
|
|
|
|
|
| |
For rotation, we assume that the source image will be rotated within the
VO, so the aspect/panscan code needs to calculate its param using
rotated coordinates. VOs which support rotation natively can use this.
|
|
|
|
|
| |
Shuffle the special cases around so that it looks cleaner. The result
should be equivalent to the code before.
|
|
|
|
|
| |
Minor cleanup, so that we can stuff more information into
mp_image_params later.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix all include statements of the form:
#include "libav.../..."
These come from MPlayer times, when FFmpeg was somehow part of the
MPlayer build tree, and this form was needed to prefer the local files
over system FFmpeg.
In some cases, the include statement wasn't needed or could be replaced
with mpv defined symbols.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces translate_key_input with a solution that gives mpv more
control over how keyboard input is converted to unicode. As a result:
- Key up/down events are generated the same way for all keys.
- Dead keys generate their base character instead of being combined with
the following character.
- Many Ctrl and Ctrl+Alt key combinations that were previously broken
are fixed, since it's possible to discover the base keys.
- AltGr doesn't produce special characters when mp_input_use_alt_gr is
false.
This also fixes some logic to do with detecting AltGr and adds proper
UTF-16 decoding.
|
| |
|
|
|
|
|
| |
Set a zero sized input region for the osd surfaces in order to avoid getting
input for the subsurfaces which might dissapear any time.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I hate tabs.
This replaces all tabs in all source files with spaces. The only
exception is old-makefile. The replacement was made by running the
GNU coreutils "expand" command on every file. Since the replacement was
automatic, it's possible that some formatting was destroyed (but perhaps
only if it was assuming that the end of a tab does not correspond to
aligning the end to multiples of 8 spaces).
|
|
|
|
| |
mpv was resizing to the same size before it went to fullscreen, we don't need to schedule a resize because the compositor will send a configure event with the new dimensions and thats when we should do it.
|
|
|
|
|
|
| |
The stats were retrieved and written on every encode call, instead of
every encode call that actually returned a packet. ffmpeg.c also does it
this way, so it must be "more correct". Fixes 2-pass encoding.
|
|
|
|
|
|
|
|
|
|
| |
This might be a good idea in order to prevent queuing a frame too far in
the future (causing apparent freezing of the video display), or dropping
an infinite number of frames (also apparent as freezing).
I think at this point this is most of what we can do if the vdpau time
source is unreliable (like with Mesa). There are still inherent race
conditions which can't be fixed.
|
|
|
|
| |
This wasn't necessarily clear.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The strange thing about this code was the shift parameter of the
prev_vs2 function. The parameter is used to handle timestamps before the
last vsync, since the % operator handles negative values incorrectly.
Most callers set shift to 0, and _usually_ pass a timestamp after the
last vsync. One caller sets it to 16, and can pass a timestamp before
the last timestamp.
The mystery is why prev_vs2 doesn't just compensate for the % operator
semantics in the most simple way: if the result of the operator is
negative, add the divisor to it. Instead, it adds a huge value to it
(how huge is influenced by shift). If shift is 0, the result of the
function will not be aligned to vsyncs.
I have no idea why it was written in this way. Were there concerns about
certain numeric overflows that could happen in the calculations? But I
can't think of any (the difference between ts and vc->recent_vsync_time
is usually not that huge). Or is there something more clever about it,
which is important for the timing code? I can't think of anything
either.
So scrap it and simplify it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vo_vdpau used a somewhat complicated and fragile mechanism to convert
the vdpau time to internal mpv time. This was fragile as in it couldn't
deal well with Mesa's (apparently) random timestamps, which can change
the base offset in multiple situations. It can happen when moving the
mpv window to a different screen, and somehow it also happens when
pausing the player.
It seems this mechanism to synchronize the vdpau time is not actually
needed. There are only 2 places where sync_vdptime() is used (i.e.
returning the current vdpau time interpolated by system time).
The first call is for determining the PTS used to queue a frame. This
also uses convert_to_vdptime(). It's easily replaced by querying the
time directly, and adding the wait time to it (rel_pts_ns in the patch).
The second call is pretty odd: it updates the vdpau time a second time
in the same function. From what I can see, this can matter only if
update_presentation_queue_status() is very slow. I'm not sure what to
make out of this, because the call merely queries the presentation
queue. Just assume it isn't slow, and that we don't have to update the
time.
Another potential issue with this is that we call VdpPresentationQueueGetTime()
every frame now, instead of every 5 seconds and interpolating the other
calls via system time. More over, this is per video frame (which can be
portantially dropped, and not per actually displayed frame. Assume this
doesn't matter.
This simplifies the code, and should make it more robust on Mesa. But
note that what Mesa does is obviously insane - this is one situation
where you really need a stable time source. There are still plenty of
race condition windows where things can go wrong, although this commit
should drastically reduce the possibility of this.
In my tests, everything worked well. But I have no access to a Mesa
system with vdpau, so it needs testing by others.
See github issues #520, #694, #695.
|
|
|
|
|
| |
This is needed to preserve the same path used when opening the cache file, and
correctly expands ~ when icc-cache is added to the mpv config file.
|
|
|
|
| |
Might help to debug certain problems with Mesa.
|
|
|
|
| |
Was broken in b0ee9334e.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds support for automatic selection of color profiles based on
the display where mpv is initialized, and automatically changes the color
profile when display is changed or the profile itself is changed from
System Preferences.
@UliZappe was responsible with the testing and implementation of a lot of this
commit, including the original implementation of `cocoa_get_icc_profile_path`
(See #594).
Fixes #594
|
|
|
|
| |
Probably.
|
|
|
|
|
|
|
|
|
| |
Reduce most dependencies on struct mp_csp_details, which was a bad first
attempt at dealing with colorspace stuff. Instead, consistently use
mp_image_params.
Code which retrieves colorspace matrices from csputils.c still uses this
type, though.
|
|
|
|
|
| |
The changes in vo_opengl.c are merely for adding the icc options to the
set of options than can be changed with the vo_cmdline command.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were some bad interactions with the OSC.
For one, dragging the OSC bar, and then moving the mouse outside of the
OSC (while mouse button still held) would suddenly initiate window
dragging. This was because win_drag_button1_down was not reset when
sending a normal mouse event, which means the window dragging code can
become active even after we've basically decided that the preceding
click didn't initiate window dragging.
Second, dragging the window and clicking on the OSC bar after that did
nothing. This was because no mouse button up event was sent to the core,
even though a mouse down event was sent. So make sure the key state is
erased with MP_INPUT_RELEASE_ALL.
|
|
|
|