| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change how the HW decoding stuff is organized, the way it's initialized
in particular. Instead of duplicating the list of supported codecs for
hwaccel decoders, add a probe function which allows each decoder to
report whether it supports a given codec.
Add an "auto" choice to the --hwdec option, which automatically enables
hardware decoding if libavcodec and/or the VO supports it.
What mpv prints on the terminal changes a bit. Now it will just print
a single line whether hw decoding is used or not (and nothing at all if
no hw decoding at all was requested). The pretty violent fallback from
hw decoding to software decoding is still quite verbose and evil-looking
though.
|
|
|
|
|
|
|
|
| |
Disable the hack by default, because it's interfering with some more
modern WMs. MWM (Motif Window Manager) is probably pretty dead, but
we still allow enabling the old hack with "--fstype=mwm_hack".
See github issue #179.
|
|
|
|
|
|
|
|
| |
This is in theory more correct with respect to hardware decoding. With
hardware decoding, the VOs play the role of the video surface allocator,
and nothing is allowed to reference surfaces past the VO lifetime. But
in theory waiting_mpi could be a reference to a HW video surface, so it
should be relased before the VO is uninitialized.
|
|
|
|
|
|
|
|
| |
The default value for a standard mouse is 10.0. Because we don't want to
multiply the value in the input config file we scale it down to 1.0.
Hopefully this should work for more precise mousewheels or touchpad, but
I don't have access to such hardware.
|
|
|
|
| |
Followup commit. Fixes all the files references.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allocate textures big enough to include the bottom/right borders (so the
chroma texture sizes are rounded up instead of down). Make the texture
large enough to include the additional luma border. Conceptually, we
pretend that the video frame is fully aligned, and then crop away the
unwanted borders. Filtering (even just bilinear) will access the
borders anyway, so it's possible that we might need to switch to
"harder" cropping instead, but at least pixels not close to the
border should be displayed correctly now.
Add a comment to mp_image.c about this luma border. These semantics are
kind of subtle, and the image allocation code handle this in a subtle
way too, so it's better to document this explicitly. The libavutil
image allocation code does similar things.
|
|
|
|
|
| |
Also removes the printing of the OpenGL info when using verbose mode since
gl_common already does that.
|
|
|
|
|
| |
This file was alredy written in C. The only remaining part was the file
exension and `#import`s.
|
| |
|
| |
|
|
|
|
| |
The first step; also serves as example.
|
|
|
|
|
| |
This means that "mpv -vo opengl-hq:help" will actually show the correct
defaults, instead those of plain vo_opengl.
|
|
|
|
|
|
|
|
|
|
| |
This introduces some changes in resize behaviour. Most importantly the window
frame is not constrained to it's screen's `visibleFrame`. Anyone who still wants
that kind of behaviour when opening a video, can use `--autofit-larger`.
Even though the size of the window is not constrained, it's position is, so
that the titlebar will always be visible. When using `--no-border` even the
position will not be constrained in any way.
|
|
|
|
|
| |
At least currently, this case pretty much happens only in the case vdpau
is requested, but not compiled in.
|
|
|
|
|
|
| |
CONFIG_VDPAU was just defined to 0, instead of undefined when vdpau was
unavailable. I blame the old mplayer code, which apparently can't have
consistent conventions.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of generating vdpau_template.c with a Perl script, just include
the generated file in git. This is ok because it changes very rarely,
and the script is larger than the output it generates.
It also simplify the Makefile, and fixes the build. The problem was that
transitive dependencies do not work with generated files: there is no
dependency information yet when building it the first time. I overlooked
this because I didn't delete the .d files for testing (which contained
the correct dependencies, but only _after_ a first successful build).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This
file is named so because because it's written against the "old"
libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau").
Add support for the "new" libavcodec vdpau support. This was recently
added and replaces the "old" vdpau parts. (In fact, Libav is about to
deprecate and remove the "old" API without deprecation grace period,
so we have to support it now. Moreover, there will probably be no Libav
release which supports both, so the transition is even less smooth than
we could hope, and we have to support both the old and new API.)
Whether the old or new API is used is checked by a configure test: if
the new API is found, it is used, otherwise the old API is assumed.
Some details might be handled differently. Especially display preemption
is a bit problematic with the "new" libavcodec vdpau support: it wants
to keep a pointer to a specific vdpau API function (which can be driver
specific, because preemption might switch drivers). Also, surface IDs
are now directly stored in AVFrames (and mp_images), so they can't be
forced to VDP_INVALID_HANDLE on preemption. (This changes even with
older libavcodec versions, because mp_image always uses the newer
representation to make vo_vdpau.c simpler.)
Decoder initialization in the new code tries to deal with codec
profiles, while the old code always uses the highest profile per codec.
Surface allocation changes. Since the decoder won't call config() in
vo_vdpau.c on video size change anymore, we allow allocating surfaces
of arbitrary size instead of locking it to what the VO was configured.
The non-hwdec code also has slightly different allocation behavior now.
Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau
doesn't work anymore (a warning suggesting the --hwdec option is
printed instead).
|
|
|
|
|
|
|
|
| |
See previous commits. This time, the lock is kept for rather long
times (e.g. for the duration of a big image memory allocation), but
this (probably) still doesn't matter at all.
This also affects legacy code only (pre-refcounting libavcodec).
|
|
|
|
|
|
|
|
| |
See previous commits. Also simplify this thing: 2 flags per pool image
are enough to avoid a weird central refcount and an associated shared
object keeping the refcount. We could even just store these two flags
in the mp_image itself (like in mp_image.flags or mp_image.priv), but
let's not for the sake of readability.
|
|
|
|
|
|
|
|
|
|
| |
This hasn't been done yet, because pthreads is still an optional
dependency, so this is a bit annoying. Now doing it anyway, because
maybe we will need this capability in the future.
We keep it as simple as possible. We (probably) don't need anything
more sophisticated, and keeping it simple avoids introducing weird
bugs. So, no atomic instructions, no fine grained locks, no cleverness.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change how m_config is initialized. Make it more uniform; now all
m_config structs are intialized in exactly the same way. Make sure
there's only a single m_option[] array defining the options, and keep
around the pointer to the optstruct default value, and the optstruct
size as well. This will allow reconstructing the option default values
in the following commit.
In particular, stop pretending that the handling of some special options
(like --profile, --v, and some others) is in any way elegant, and make
them explicit hacks. This is really more readable and easier to
understand than what was before, and simplifies the code.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change affects vf_lavfi. Until recently, libavfilter was not
colorspace aware at all. This changed with the addition of colorspace
fields to AVFrame. libavfilter's vf_scale picks them up (as of recent
ffmpeg git). Since this support is still kind of wonky and not part of
the normal format negotiation, this won't set the correct output
colorspace, though.
Not adding a separate test for HAVE_AVFRAME_COLORSPACE. This is slightly
unclean, but on the other hand adding an explicit test seems like a
waste of effort.
|
|
|
|
|
|
| |
The symptom was that "-vf scale,format=rgba" broke the vsfilter
colorspace hack in sd_ass. vf->reconfig is allowed to overwrite its
input parameter for convenience (maybe that was a bad idea).
|
|
|
|
| |
Makes sure the chroma_location doesn't get lost.
|
| |
|
|
|
|
| |
It seems working on getch2 gave me some brain damage.
|
|
|
|
|
|
|
|
|
| |
Windows doesn't send WM_MOUSELEAVE by default unless you ask it to;
request tracking for leave events when the mouse enters the window (or is
moved).
Tracking is automatically de-activated once the mouse leaves the window,
so we have to re-request it every time the mouse re-enters the window.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It appears the API requires you to cover all plane data with AVBuffers
(that is, one AVBuffer per plane in the most general case), because
certain code can make certain assumptions about this. (Insert rant
about how this is barely useful and increases complexity and potential
bugs.) I don't know any cases where the current code actually fails,
but we want to follow the API, so do it anyway.
Note that we don't really know whether or not planes are from a single
memory allocation, so we have to assume the most general case and create
an AVBuffer for each plane. We simply assume that the data is padded to
the full stride in the last image line. All these extra dummy references
are stupid, but the code might become much simpler once we only support
libavcodec versions with refcounting and can use AVFrame directly.
|
|
|
|
|
|
| |
In general, this warning can hint to actual bugs. We don't enable it
yet, because it would conflict with some unmerged code, and we should
check with clang too (this commit was done by testing with gcc).
|
|
|
|
|
| |
This means that AOs/VOs with no options set do not take the legacy
option parsing path, but instead report that they have no options.
|
|
|
|
|
| |
All VOs use proper option parsing now, and compatibility hacks are not
needed.
|
|
|
|
| |
Finally not used by anything anymore. Farewell.
|
|
|
|
| |
This was forgotten in commit b81f5e2.
|
|
|
|
|
|
| |
Doing "mpv --vo=opengl:lscale=help" now lists possible scalers and
exits. The "backend" suboption behaves similar. Make the "stereo"
suboption a choice, instead of using magic integer values.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Commit 6ab2eeb attempted to fix it on Cygwin, but now it broke on MinGW
in turn. Don't think too hard about it and just remove the code. (vo.c
already prints the video rectangle anyway.)
|
|
|
|
|
| |
These can't be used manually. Encoding is enabled with -o instead, and
the encoding AO/VO is selected using internal mechanisms.
|
|
|
|
|
|
|
|
|
| |
Nothing should change from user perspective.
mpv --vo=opengl:help now works.
Remove the vo_opengl inline help text. The new code can list option
names for you, but that's it. Refer to the manpage if you have trouble.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason, both m_config and m_struct are somewhat similar, except
that m_config is much more powerful. m_config is used for VOs and some
other things, so to unify them. We plan to kick out m_struct and use
m_config for everything. (Unfortunately, m_config is also a bit more
bloated, so this commit isn't all that great, but it will allow to
reduce the option parser mess somewhat.)
This commit also switches all video filters to use the option macros.
One reason is that m_struct and m_config, even though they both use
m_option, store the offsets of the option fields differently (sigh...),
meaning the options defined for either are incompatible. It's easier to
switch everything in one go.
This commit will allow using the -vf option parser for other things,
like VOs and AOs.
|
| |
|
|
|
|
| |
Regression introduced in 8fb064de5. Prevented the OSC from working correctly.
|
| |
|
|
|
|
| |
This makes the tracking area work when going in and out of fullscreen.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the cursor was in the window border, it could be hidden but it
wouldn't appear again, since mpv doesn't process mouse input there.
The code used ShowCursor, which is a horrid stateful API designed for
mouseless Win16 systems that incremented or decremented a global counter
to keep track of how many applications needed to display a special
cursor (like a busy cursor.) Replace that with a simple flag, handle
WM_SETCURSOR and use SetCursor(NULL) to hide the mouse cursor, but only
when the mouse is in the client area. DefWindowProc will set the correct
cursor on the border as long as it isn't hidden with ShowCursor.
PowerPoint also uses SetCursor(NULL) to hide the cursor when showing a
presentation, so it's probably safe.
See http://blogs.msdn.com/b/oldnewthing/archive/2009/12/17/9937972.aspx
|
| |
|
|\ |
|
| |
| |
| |
| | |
This fixes playback on Wayland with older GPUs.
|
| |
| |
| |
| |
| | |
This makes the cocoa backend follow more closely the new fullscreen semantics
added in c4b08a9a.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This change which also flipse the coordinate system of the view, greatly
simplifies the mouse event handling code.
There are still some uglities mostly related to the cursor visibility
code. For instance the core doesn't show the cursor when it receives a mouse
leave event.
|
| |
| |
| |
| | |
Surely it's copy pasta's fault.
|
| |
| |
| |
| |
| | |
This is needed for the OSC. At the moment I'm sending a notification for any
mouse movement outside of the video surface. This might be overkill.
|
| |
| |
| |
| |
| |
| | |
This was more roundabout than expected, since it looks like the framework
caches isMovabileByWindowBackground so in mpv's case it's needed to set it
with setMovableByWindowBackground.
|
|/ |
|
|
|
|
|
|
|
|
|
|
| |
This commit removes the pointer to the single different structures for input
and window and puts them as anonymous structures inside the wayland_state
structure.
This has the disadvantage of passing the substructure to the listeners, but the
advantage is that we don't have to allocate them and check for NULL pointers.
This makes it more reliable and easier to follow.
|
|
|
|
|
|
| |
The vo_wayland_fullscreen handles resizing for the video, because the video
could still be in fullscreen mode and resizing it in gl_wayland could make it
grow or shrink.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a MPOpts fullscreen field, a mp_vo_opts.fs field, and
VOFLAG_FULLSCREEN. Remove all these and introduce a
mp_vo_opts.fullscreen flag instead.
When VOs receive VOCTRL_FULLSCREEN, they are supposed to set the
current fullscreen mode to the state in mp_vo_opts.fullscreen. They
also should do this implicitly on config().
VOs which are capable of doing so can update the mp_vo_opts.fullscreen
if the actual fullscreen mode changes (e.g. if the user uses the
window manager controls). If fullscreen mode switching fails, they
can also set mp_vo_opts.fullscreen to the actual state.
Note that the X11 backend does almost none of this, and it has a
private fs flag to store the fullscreen flag, instead of getting it
from the WM. (Possibly because it has to deal with broken WMs.)
The fullscreen option has to be checked on config() to deal with
the -fs option, especially with something like:
mpv --fs file1.mkv --{ --no-fs file2.mkv --}
(It should start in fullscreen mode, but go to windowed mode when
playing file2.mkv.)
Wayland changes by: Alexander Preisinger <alexander.preisinger@gmail.com>
Cocoa changes by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
|
|
|
|
|
|
| |
This was bad, because it was the only aspdat member updated by
vo_get_src_dst_rects() instead of vo_reconfig(). Now it isn't
accessed anymore, s |