| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Will be needed for other parts (especially in gl_lcms.c).
|
| |
|
|
|
|
|
|
|
|
|
| |
Since m_option.h and options.h are extremely often included, a lot of
files have to be changed.
Moving path.c/h to options/ is a bit questionable, but since this is
mainly about access to config files (which are also handled in
options/), it's probably ok.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Use the scaled video size (i.e. as shown on the window) as reference for
zoom. This is the easiest way to fix different width/height scale
factors as they happen when zooming video with a pixel aspect ratio
other than 1:1.
Also fix the unscaled mode, so that it 1. doesn't scale even with
--video-zoom, and 2. doesn't scale by small amounts when the video is
cropped by making the window smaller than the video.
|
|
|
|
|
|
| |
Otherwise, next_pts2 can be == next_pts (and not MP_NOPTS_VALUE), in
which case the player thinks the first frame has duration 0. (Weird
corner case.)
|
|
|
|
|
|
|
|
| |
There are some use cases for this. For example, you can use it to set
defaults of automatically inserted filters (like af_lavrresample). It's
also useful if you have a non-trivial VO configuration, and want to use
--vo to quickly change between the drivers without repeating the whole
configuration in the --vo argument.
|
|
|
|
|
|
| |
This is not needed anymore, because we decided that the PAR of the
decoded video matters, and not the PAR of the filtered video that
arrives at the VO.
|
|
|
|
|
| |
This was way too misleading. osd.c merely calls the subtitle renderers,
instead of actually dealing with subtitles.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The configure followed 5 different convetions of defines because the next guy
always wanted to introduce a new better way to uniform it[1]. For an
hypothetic feature 'hurr' you could have had:
* #define HAVE_HURR 1 / #undef HAVE_DURR
* #define HAVE_HURR / #undef HAVE_DURR
* #define CONFIG_HURR 1 / #undef CONFIG_DURR
* #define HAVE_HURR 1 / #define HAVE_DURR 0
* #define CONFIG_HURR 1 / #define CONFIG_DURR 0
All is now uniform and uses:
* #define HAVE_HURR 1
* #define HAVE_DURR 0
We like definining to 0 as opposed to `undef` bcause it can help spot typos
and is very helpful when doing big reorganizations in the code.
[1]: http://xkcd.com/927/ related
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Keep track of the default values directly, instead of creating a new
instance of the option struct just to get the defaults.
Also get rid of the special handling of m_obj_desc.init_options.
Instead, handle it purely by the option parser. Originally, I wanted to
handle --vo=opengl-hq and --vo=direct3d_shaders with this (by making
them aliases to the real VOs with a different preset), but since --vo
=opengl-hq=help prints the wrong values (as consequence of the
simplification), I'm not doing that, and instead use something
different.
|
|
|
|
| |
The author and comment fields were printed only in -v mode.
|
|
|
|
|
|
|
|
|
| |
Was disabled by default, was never used, internal support was
inconsistent and poor, and there has been virtually no interest in
creating translations.
And I don't even think that a terminal program should be translated.
This is something for (hypothetical) GUIs.
|
|
|
|
|
|
|
| |
Reverts a small change made in commit ed9295c. This is needed, because
otherwise mplayer.c/update_video_attached_pic() thinks it never has to
update the picture after initialization. (Maybe there would be more
elegant ways to handle this, but not without adding extra state.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds the --force-window option, which will cause mpv always
to create a window when started. This can be useful when pretending that
mpv is a GUI application (which it isn't, but users pretend anyway), and
playing audio files would run mpv in the background without giving a
window to control it.
This doesn't actually create the window immediately: it only does so
only after initializing playback and when it is clear that there won't
be any actual video. This could be a problem when starting slow or
completely stuck network streams (mpv would remain frozen in the
background), or if video initialization somehow is stuck forever in
an in-between state (like when the decoder doesn't output a video
frame, but doesn't return an error either). Well, we can pretend only
so much that mpv is a GUI application.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before, a VO could easily refuse to respond to VOCTRL_REDRAW_FRAME,
which means the VO wouldn't redraw OSD and window contents, and the
player would appear frozen to the user. This was a bit stupid, and makes
dealing with some corner cases much harder (think of --keep-open, which
was hard to implement, because the VO gets into this state if there are
no new video frames after a seek reset).
Change this, and require VOs to always react to VOCTRL_REDRAW_FRAME.
There are two aspects of this: First, behavior after a (successful)
vo_reconfig() call, but before any video frame has been displayed.
Second, behavior after a vo_seek_reset().
For the first issue, we define that sending VOCTRL_REDRAW_FRAME after
vo_reconfig() should clear the window with black. This requires minor
changes to some VOs. In particular vaapi makes this horribly
complicated, because OSD rendering is bound to a video surface. We
create a black dummy surface for this purpose.
The second issue is much simpler and works already with most VOs: they
simply redraw whatever has been uploaded previously. The exception is
vdpau, which has a complicated mechanism to track and filter video
frames. The state associated with this mechanism is completely cleared
with vo_seek_reset(), so implementing this to work as expected is not
trivial. For now, we just clear the window with black.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, mouse positions were just passed to the core as-is, even if
the mouse coordinates didn't map to any useful coordinate space, like
OSD coordinates. Lua scripting (used by the OSC, the only current user
of mouse input) had to translate mouse coordinates manually to OSD space
using mp_get_osd_mouse_pos(). This actually didn't work correctly in
cases mouse coordinates didn't map to OSD (like vo_xv): the mouse
coordinates the OSC got were correct, but input.c was still expecting
"real" mosue coordinates for mouse areas.
Fix this by converting to OSD coordinates before passing the mouse
position to the core.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A wayland output based on shared memory. This video output is useful for x11
free systems, because the current libGL in mesa provides GLX symbols. It is also
useful for embedded systems where the wayland backend for EGL is not
implemented like the raspberry pi.
At the moment only rgb formats are supported, because there is still no
compositor which supports planar formats like yuv420p. The most used compositor
at the moment, weston, supports only BGR0, BGRA and BGR16 (565).
The BGR16 format is the fastest to convert and render without any noticeable
differences to the BGR32 formats. For this reason the current (very basic)
auto-detection code will prefer the BGR16 format. Also the weston source code
indicates that the preferred format is BGR16 (RGB565).
There are 2 options:
* default-format (yes|no) Which uses the BGR32 format
* alpha (yes|no) For outputting images and videos with transparencies
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, video output levels (obscure feature, like using TV screens
that require RGB output in limited range, similar to YUY) still required
handling of VOCTRL_SET_YUV_COLORSPACE. Simplify this, and use the new
mp_image_params code. This gets rid of some code. VOCTRL_SET_YUV_COLORSPACE
is not needed at all anymore in VOs that use the reconfig callback. The
result of VOCTRL_GET_YUV_COLORSPACE is now used only used for the
colormatrix related properties (basically, for display on OSD). For
other VOs, VOCTRL_SET_YUV_COLORSPACE will be sent only once after config
instead of twice.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This affects VOs which just reuse the mp_image from draw_image() to
return screenshots. The aspect of these images is never different
from the aspect the screenshots should be, so there's no reason to
adjust the aspect in these cases.
Other VOs still need it in order to restore the original image
attributes.
This requires some changes to the video filter code to make sure that
the aspect in the passed mp_images is consistent.
The changes in mplayer.c and vd_lavc.c are (probably) not strictly
needed for this commit, but contribute to consistency.
|
|
|
|
|
|
|
|
|
|
|
| |
Add --video-align-x/y, --video-pan-x/y, --video-scale options and
properties. See the additions to the manpage for description and
semantics.
These transformations are intentionally done on top of panscan. Unlike
the (now removed) --panscanrange option, this doesn't affect the default
panscan behavior. (Although panscan itself becomes kind of useless if
the new options are used.)
|
|
|
|
|
| |
Whoever had the idea of introducing mixed conventions for these
preprocessor symbols should be shot.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Followup commit. Fixes all the files references.
|
|
|
|
| |
The first step; also serves as example.
|
|
|
|
|
| |
All VOs use proper option parsing now, and compatibility hacks are not
needed.
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of handling colorspaces with VFCTRLs/VOCTRLs, make them part of
the normal video format negotiation. The colorspace is passed down like
other video params with config/reconfig calls.
Forcing colorspaces (via the --colormatrix options and properties) is
handled differently too: if it's changed, completely reinit the video
chain. This is slower and requires a precise seek to the same position
to perform an update, but it's simpler and less bug-prone. Considering
switching the colorspace at runtime by user-interaction is a rather
obscure feature, this is a good change.
The colorspace VFCTRLs and VOCTRLs are still kept. The VOs rely on it,
and would have to be changed to get rid of them. We'll do that later,
and convert them incrementally instead of in one go.
Note that controlling the output range now always works on VO level.
Basically, this means you can't get vf_scale to output full-range YUV
for whatever reason. If that is really wanted, it should be a vf_scale
option. the previous behavior didn't make too much sense anyway.
This commit fixes a few bugs (such as playing RGB video and converting
that to YUV with vf_scale - a recent commit broke this and forced the
VO to display YUV as RGB if possible), and might introduce some new
ones.
|
| |
|
|
|
|
| |
Now only the OSX and Wayland parts are using this.
|
|
|
|
|
|
|
|
|
|
| |
For some reason mp_fifo specifically handled double clicks, and other
than that was a pointless wrapper around input.c functionality.
Move the double click handling into input.c, and get rid of mp_fifo. Add
some compatibility wrappers, because so much VO code uses these
functions. Where struct mp_fifo is still used it's just a casted
struct input_ctx.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this commit, mouse movement events emitted a special command
("set_mouse_pos"), which was specially handled in command.c. This was
once special-cased to the dvdnav and menu code, and did nothing after
libmenu and dvdnav were removed.
Change it so that mouse movement triggers a pseudo-key ("MOUSE_MOVE"),
which then can be bound to an arbitrary command. The mouse position is
now managed in input.c. A command which actually needs the mouse
position can use either mp_input_get_mouse_pos() or mp_get_osd_mouse_pos()
to query it. The former returns raw window-space coordinates, while the
latter returns coordinates transformed to OSD- space. (Both are the same
for most VOs, except vo_xv and vo_x11, which can't render OSD in
window-space. These require extra code for mapping mouse position.)
As of this commit, there is still nothing that uses mouse movement, so
MOUSE_MOVE is mapped to "ignore" to silence warnings when moving the
mouse (much like MOUSE_BTN0).
Extend the concept of input sections. Allow multiple sections to be
active at once, and organize them as stack. Bindings from the top of
the stack are preferred to lower ones.
Each section has a mouse input section associated, inside which mouse
events are associated with the bindings. If the mouse pointer is
outside of a section's mouse area, mouse events will be dispatched to
an input section lower on the stack of active sections. This is intended
for scripting, which is to be added later. Two scripts could occupy
different areas of the screen without conflicting with each other. (If
it turns out that this mechanism is useless, we'll just remove it
again.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The filter chain and the video ouputs have config() functions. They are
strictly limited to transfering the video size and format. Other
parameters (like color levels) have to be transferred separately.
Improve upon this by introducing a separate set of reconfig() functions,
which use mp_image_params to carry format parameters. This struct
contains all image format related parameters from config(), plus
additional parameters such as colorspace.
Change vf_rotate to use it, as well as vo_opengl. vf_rotate is just
an example/test case, but vo_opengl will need it later.
The intention is also to get rid of VOCTRL_SET_YUV_COLORSPACE. This
information is now handed to the VOs via reconfig(). The getter,
VOCTRL_GET_YUV_COLORSPACE, will still be needed though.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code calculates the source/display video rectangle for scaling with
most VOs. It's responsible for clipping the display rectangle against
the screen and adjusting the source rectangle accordingly.
Until now, it assumed that the video was centered on the screen. Change
this so that any rectangle is possible. Basically, the clipping is
extended to two sides (e.g. left and right), instead of handling both at
the same time.
The rounding behavior slightly changes. It seems to be slightly better
than before. On the other hand, the video is not strictly centered
anymore (due to different rounding on either side). When using panscan
controls, the video can "jitter" by 1 or 2 pixels around the center as
the panscan value is changed.
|
|
|
|
|
|
|
| |
This was used by some VOs to do timing of cursor autohiding, but we
recently moved that out of the VOs. Even though this mechanism might
be a good idea and could be needed again in future (but for what?),
it's unused now. So better just get rid of it.
|
|
|
|
|
|
| |
Use VOCTRL_CHECK_EVENTS instead. Change the remaining VOs to use it.
Only vo_sdl and vo_caca actually need this, and vo_null, vo_lavc, and
vo_image had stubs only.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of having separate callbacks for each backend-handled feature
(like MPGLContext.fullscreen, MPGLContext.border, etc.), pass the
VOCTRL responsible for this directly to the backend. This allows
removing a bunch of callbacks, that currently must be set even for
optional/lesser features (like VOCTRL_BORDER).
This requires changes to all VOs using gl_common, as well as all
backends that support gl_common.
Also introduce VOCTRL_CHECK_EVENTS. vo.check_events is now optional.
VO backends can use VOCTRL_CHECK_EVENTS instead to implementing
check_events. This has the advantage that the event handling code in
VOs doesn't have to be duplicated if vo_control() is used.
|
| |
|
|
|
|
|
|
| |
gl_video.c contains all rendering code, gl_lcms.c the .icc loader and
creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is
reduced to interfacing between the various parts.
|
|
|
|
|
|
|
|
|
| |
If that's what the user asked for, there's no reason to introduce
special cases to ignore it on fullscreen.
The old behavior is perhaps accidentally due to the fact that aspect
calculations used to be disabled in windowed mode, rather than a
deliberate decision.
|
|
|
|
|
|
|
| |
Remove lots of weird logic and dead code.
The only difference is that when specifying a monitor aspect ratio, it
will always upscale and never downscale.
|
|
|
|
|
|
|
| |
Separate the video output options from the big MPOpts structure and also only
pass the new mp_vo_opts structure to the vo backend.
Move video_driver_list into mp_vo_opts
|
|
|
|
|
| |
This is needed by the encode stuff for some reason, so we have to
explicitly pass it. Functionality shouldn't change.
|
|
|
|
|
|
|
|
| |
Removes almost every global variabel in vo.h and puts them in a special struct
in MPOpts for video output related options.
Also we completly remove the options/globals pts and refresh rate because
they were unused.
|
|
|
|
|
|
|
|
| |
When paused, --cursor-autohide worked with a precision of 500ms, which
is the main loop's default sleep time when paused. Cursor hiding is
polled in x11_common, and the main loop never called the X11 code at
the right time. Fix this by allowing the VO to set a time when it
should be called next.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
VFCAP_OSD was used to determine at runtime whether the VO supports OSD
rendering. This was mostly unused. vo_direct3d had an option to disable
OSD (was supposed to allow to force auto-insertion of vf_ass, but we
removed that anyway). vo_opengl |