This option allowed you to extend the range of the panscan controls, so
that you could essentially use it to scale the video. This will be
replaced by a separate option to set the zoom factor directly.
Now the code does the same as the original MPlayer VAAPI patch, instead
of trying to map the profiles exactly.
See previous commit for justification and discussion.
Instead, do what MPlayer did all these years. It worked for them, so
there's probably no reason to change this.
Apparently fixes playback with some files, where the VDPAU decoder does
not formally support a profile, but decoding works with a more powerful
profile anyway.
Though note that MPlayer did this because it couldn't do it in a better
way (no decoder reported profiles available when creating the VDPAU
decoder), so it's not entirely clear whether this is a good idea. An
alterbative implementation might try to map the profiles exactly, and
do some fall backs if the exact profile is not available. But this
hack-solution works too.
Apparently this was dropped some years ago, but judging from MPlayer's
handling of this, the original code wasn't so great anyway. The new
code handling clearing of panscan borders correctly, and integrates
better with the YUV path. (Although the VDPAU API sure makes this
annoying with its separate surface types for RGB.)
Note that we create 5 surfaces for some reason - I don't think this
makes too much sense (because we can't use the deinterlacer with RGB
surfaces), but at least it reduces the amount of differences with
the YUV code path.
Clearing the borders is done by drawing a single black pixel over the
window. This sounds pretty dumb, but it appears to work well, and
there is no other API for that. (One could try to use the video mixer
for this purpose, since it has all kinds of features, including
compositing multiple RGBA surfaces and clearing the window background.
But it would require an invisible dummy video surface to make the
video mixer happy, and that's getting too messy.)
When panscan was used, i.e. the video is cropped to make the video fill
the screen if video and screen aspects don't match, screenshots
contained only the visible region of the source video, stretched to
original video size.
The VDPAU default colorkey, although it seems to be driver specific, is
usually green. This is a pretty annoying color, and you usually see it
briefly (as flashes) if the VDPAU window resizes.
Change it to some shade of black. The new default color is close to what
MPlayer picks as colorkey (and apparently it worked well for them):
VdpColor vdp_bg = {0.01, 0.02, 0.03, 0};
Since our OPT_COLOR can set 8 bit colors only, we use '#020507' instead,
which should be the same assuming 8 bit colors.
Obviously, you can't use black, because black is a way too common color,
and would make it too easy to observe the colorkey effect when e.g.
moving a terminal with black background over the video window.
Formally, this sets the "background color" of the presentation queue.
But in practice, this color is also used as colorkey.
This commit doesn't change the VDPAU default yet.
Libav's <libavcodec/vdpau.h> header uses some libavocdec symbols without
forward-declaring them and without including the headers declaring them.
FFmpeg's header for this is fine.
About this issue, it would be better if the surfaces could be allocated
with the real size, and the vdpau video mixer could be created with that
size as well. That would be a bit hard, because the real surface size
had to be communicated to vdpau. So I'm going with this solution. vaapi
seems to be fine with either surface size, so there's hopefully no
problem.
Instead of passing AVFrame. This also moves the mysterious logic about
the size of the allocated image to common code, instead of duplicating
it everywhere.
This adds precise scrolling support. I ran some tests and it seems a little
bit smoother and well.. precise. The defaults are rebindable using: AXIS_UP,
AXIS_DOWN, AXIS_LEFT and AXIS_RIGHT.
This reverts commit 689a25003f, with some
adjustments to code that was added after that commit.
I just messed up big time. We don't need this, and in fact the commit
confused straight and premultiplied alpha at one point (just a simple
inverted condition due to an oversight), which is why it looked like
it was working.
In commit 2827295 I wrote:
Also, libva can't decide whether it accepts straight or premultiplied
alpha for OSD sub-pictures [...]
That was just me messing up and being severely confused by my own bugs.
VA API uses premultiplied alpha, which by the way is nice and
thoughtful of the VA API devs.
Well, this was stupid. But in the end, I'm glad that I could actually
reduce codesize by a good amount again.
This is based on the MPlayer VA API patches. To be exact it's based on
a very stripped down version of commit f1ad459a263f8537f6c from
git://gitorious.org/vaapi/mplayer.git.
This doesn't contain useless things like benchmarking hacks and the
demo code for GLX interop. Also, unlike in the original patch, decoding
and video output are split into separate source files (the separation
between decoding and display also makes pixel format hacks unnecessary).
On the other hand, some features not present in the original patch were
added, like screenshot support.
VA API is rather bad for actual video output. Dealing with older libva
versions or the completely broken vdpau backend doesn't help. OSD is
low quality and should be rather slow. In some cases, only either OSD
or subtitles can be shown at the same time (because OSD is drawn first,
OSD is prefered).
Also, libva can't decide whether it accepts straight or premultiplied
alpha for OSD sub-pictures: the vdpau backend seems to assume
premultiplied, while a native vaapi driver uses straight. So I picked
straight alpha. It doesn't matter much, because the blending code for
straight alpha I added to img_convert.c is probably buggy, and ASS
subtitles might be blended incorrectly.
Really good video output with VA API would probably use OpenGL and the
GL interop features, but at this point you might just use vo_opengl.
(Patches for making HW decoding with vo_opengl have a chance of being
accepted.)
Despite these issues, decoding seems to work ok. I still got tearing
on the Intel system I tested (Intel(R) Core(TM) i3-2350M). It was also
tested with the vdpau vaapi wrapper on a nvidia system; however this
was rather broken. (Fortunately, there is no reason to use mpv's VAAPI
support over native VDPAU.)
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.
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.
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.
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).
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).
