Bump xkbcommon version and use the new xkb_keymap_from_buffer. This is more
secure, because the from_string expects a 0 terminated string, but this cannot
be guaranteed with mmap.
This commit remove a lot of linux specific code, like epoll. It also reduces
the complexity of the code. Instead of epoll we use poll which makes the
wayland backend more portable to other platforms.
This removes a good chunk of code trying to recreate key repeat.
Because the wayland protocol and xkbcommon don't have an interface for
auto-repeating pressed keys.
The code was attempting to get the ceiling of the double. Too bad NSSize has
floats inside of it and the int cast is nowhere to be seen. This caused
rounding errors by one pixel in the window size.
libavcodec decoder initialization failure caused a segfault, because it
wasn't properly reported back in init().
Also remove the return value from init_avctx(), which actually makes
things simpler. Instead, ctx->avctx can be checked to see whether
initialization was ok.
libavfilter changed the way a format list is passed to vf_format. Now
you have to separate formats with "|" instead of ":". If you use "|",
it prints an annoying message on every reinit:
[format @ 0x8bbaaa0]This syntax is deprecated. Use '|' to separate the list items.
...and it will probably stop working without warning at some point in
the future.
We need some very annoying ifdeffery to detect this case, because
libavfilter version numbers are just plain incompatible between Libav
and ffmpeg. There is no other way to detect this.
(Sometimes I wonder whether ffmpeg and especially Libav actually like
causing unnecessary pain for their users, and intentionally break stuff
in the most annoying way possible. Sigh...)
Resetting the filter graph helps dealing with filters which save state
between frames. This is important especially if they modify frame timing
or emit additional frames.
Unfortunately the libavfilter API doesn't have a way to do this
directly, so we have to use a dirty trick: we recreate the whole graph,
including format negotiation down and filter string parsing. ffplay does
this too. If libavfilter somehow decides to change output format or size
from what the first run in config() returned, mpv will explode. The same
applies to vf_next_query_format() return values (although this could be
mitigated, should it really happen).
Block X11's native key repeat, and use mpv's key repeat handling in
input.c instead.
No configure check for XKB. Even though it's an extension, it has been
part of most (all?) xlibs since 1996. If XKB appears to be missing,
just refuse enabling x11.
This is a potentially controversial change. mpv will use its own key
repeat rate, instead of X11's. This should be better, because seeking
will have a standardized "speed" (seek events per seconds when keeping
a seek key held down). It will also allow disabling key repears for
certain commands, though this is not done anywhere yet.
The new behavior can be disabled with the --native-keyrepeat option.
The VO warns by default that the nomanyfmts option should be used if
video display fails. This is almost completely useless, but people
keep asking what it means.
Requires recent FFmpeg/Libav git versions. Earlier versions will not
be supported, as the API is different. (A libavfilter version that
uses AVFrame instead of AVFilterBuffer is needed.)
Note that this is sort of useless, because the option parser prevents
you from making use of the full libavfilter graph syntax. This has to be
fixed later.
Most of the filter creation code (half of the config() function) has
been taken from avplay.c.
This code is not based on MPlayer's vf_lavfi. The MPlayer code doesn't
compile as it hasn't been updated through multiple libavfilter API
changes, making it completely useless as a starting point.
This refactor makes the code easier to understand. Also corrects a bug that
caused the window to move to the left when the new size was bigger than the
visible frame.
It is now possible to show images and videos with alpha information correctly.
This was disalbed before, because there was a bug that made black parts of
videos also transparent.
The previous attempt was missing some code paths, so there were still
shaders generated that triggered the shader compilation error. Fix it
instead by special handling USE_CONV in the shader.
By the way, the shader compiler did not accept:
#if defined(USE_CONV) && (USE_CONV == ...)
In my opinion this should be perfectly fine, but it gives the same
error as before. So test USE_CONV separately with #ifndef.
The OSX shader compiler was giving this error:
ERROR: 0:235: '' : syntax error incorrect preprocessor directive
on this line:
[235] #if USE_CONV == CONV_PLANAR
USE_CONV was undefined in some cases. The expected behavior is that the
shader preprocessor interprets this as branch not taken (AFAIK exactly
as in C), which is probably what the standard would dictate. This is
possible an OSX bug. But admittedly, I'm not sure whether this is really
standard behavior (in C or GLSL), and doing this is extremely weird at
best, so make sure that USE_CONV is always defined.
Should fix behavior on OSX.
Allows playing video with alpha information on X11, as long as the video
contains alpha and the window manager does compositing. See vo.rst.
Whether a window can be transparent is decided by the choice of the X
Visual used for window creation. Unfortunately, there's no direct way to
request such a Visual through the GLX or the X API, and use of the
XRender extension is required to find out whether a Visual implies a
framebuffer with alpha used by XRender (see for example [1]). Instead of
depending on the XRender wrapper library (which would require annoying
configure checks, even though XRender is virtually always supported),
use a simple heuristics to find out whether a Visual has alpha. Since
getting it wrong just means an optional feature will not work as
expected, we consider this ok.
[1] http://stackoverflow.com/questions/4052940/how-to-make-an-opengl-rendering-context-with-transparent-background/9215724#9215724
When displaying YUV with alpha plane (an extremely rare special case),
we didn't upload the alpha plane, because we don't do anything with it.
This actually created some annoying special cases, so upload the alpha
planes as well, even if they're unused.
This is a bit cleaner. Also don't repeat the chroma shift calculations
over and over, but store the image size instead, which is simpler and
will give us a chance to fix display of non-mod-2 image sizes.
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.
Do this instead of stuffing all x11/cocoa/win32/wayland specific code
into gl_common.c. The cocoa specific parts could probably go directly
into cocoa_common.m, possibly same with wayland.
Also redo how the list of backends is managed. Get rid of the GLTYPE_
constants. Instead of having a big switch() on GLTYPE_, each backend
entry has a function pointer to setup the MPGLContext callback (e.g.
mpgl_set_backend_x11()).
Makes the code a bit simpler to follow, at least in the "modern"
decoding path (update_video_nocorrect_pts() is used with old demuxers,
which don't return proper packets and need further parsing, so this code
looks less simple now).
Good news: MPV worked fine even without the fixes, but pointer size
mismatch warnings aren't the nicest things to leave lying around.
Fix macro that assumed HWND is uint32_t-sized.
Win64 is also a special butterfly and is an LLP64 platform on amd64
CPUs, while all the other amd64 platforms are LP64. Cygwin decided to go
with the other platforms, and thus sizeof(long) != sizeof(int), and in
cygwin's windows headers LONG is int-sized. Fix an mp_msg that assumed
LONG is long.
The vo_x11_clearwindow_part() function assumed that the video is always
centered. Replace it with a new vo_x11_clear_background() function
instead, which essentially does the same as the old function. It takes
the video rectangle instead of just the video size, and doesn't have to
make the assumption that the video rectangle is centered.
Also make vo_x11 use it (seems advantageous).
This was probably enabled to guarantee that panscan is always reset in
windowed mode. However, the window size should be exactly the video size
in windowed mode, unless in cases where the user forcibly changed the
window size (e.g. --geometry). In the former case, panscan will have no
influence at all, and in the latter case we want it to have influence.
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.
The code that is changed is responsible for scaling the video size to
display size, so that the resulting video rectangle is letter-boxed
inside the display window. This is before panscan calculations, which
can actually enlarge the video and make it larger than the display size
again. (src_dst_split_scaling() in vo.c takes cares of clipping the
video size to window size.)
I'm not sure why this rounding is done, as using panscan controls can
introduce odd sizes again. The rounding has been part of the code since
the initial commit. On the other hand, this rounding can slightly
influence the aspect ratio of the displayed image to the worse. It
forces the image to be scaled by an additional pixel, without actually
correcting the display size into the other direction.
Although video sizes are usually at least aligned on 2 (and often more),
odd sizes can still happen when playing e.g. anamorphic DVDs.
Remove the additional rounding.
(Note that we still round the _source_ image position and size when the
displayed image is larger than the screen, e.g. when panscan is used.
This is needed by some VOs so that the image source rectangle starts on
full chroma pixels. Maybe this rounding should be moved to the
respective VOs, which includes at least vo_direct3d.)
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.
The draw_osd change is a bit tricky: I guess originally, there was some
intention not to second-guess the generic aspect code, but the result is
the same and the code is more confusing.
The rescaling is rather silly. vo_get_src_dst_rects() doesn't return an
uncropped image, so the texture coordinates have to be recalculated,
which looks more complicated, but is actually what the other OpenGL VOs
also do.
Tested and fixed by Stefano Pigozzi.
Instead of manually calculating aspect ratio etc., use
vo_get_src_dst_rects(). This has the advantage that we can drop some
special cases in aspect.c later.
Simplify the code, and move resizing the X images from draw_image() to a
new resize() function.
Do some other simplifications. The gXErrorFlag check was actually dead
code, even in mplayer-svn. Special-casing on WinID is not needed
anymore (we created an embedded window, and its size is updated by
x11_common.c).
I introuced this regression in 8fc0b618d5. The backend would go into
incosistent state caused by calling `vo_cocoa_fullscreen` where it wasn't
needed.
Fixes#44
This only matters for those who want to use vf_pp. The old API is marked
as deprecated, and doesn't work on Libav. It was broken on FFmpeg, but
has recently started working again - the fields in question were not un-
deprecated though. Instead you're supposed to use a new API, which does
exactly the same thing (what...?).
Also don't pass the QP table with mp_image_copy_attributes() - it
probably does more harm than it's useful.
By the way, with -vf=dlopen=TOOLS/vf_dlopen/showqscale.so, it appears
the table as output by recent FFmpeg is offset by 1 macroblock in X
direction and 2 macroblocks in Y direction, which most likely will
interfere with normal vf_pp operation. However, this is not my problem.
The only real reason for this commit is that we can finally get rid of
all libav* related deprecation warnings. (Though they are constantly
deprecating APIs, so this will not last long.)
The old names have been deprecated a while ago, but were needed for
supporting older ffmpeg/libav versions. The deprecated identifiers
have been removed from recent Libav and FFmpeg git.
This change breaks compatibility with Libav 0.8.x and equivalent
FFmpeg releases.
avcodec_encode_video() was deprecated, and was finally removed from
Libav and FFmpeg git.
This change breaks compatibility with Libav 0.8.x. Thank the Libav
developers, not me.
Removes the local ret because it was only in an assert statement and also
removes the window size assignments, because they are already done in
config_wnidow_wayland.
Fix a regression introduced in commit 979ce46c64 causing a window to take up
more space than what the display allows.
Add keepCentered:YES, so that the video area is always clipped to the current
visible frame (even when using scale).
Fixes#38.
Latest nvidia drivers ignore the application setting, so this switch
makes even less sense than before. It's still possible to control this
with VO specific suboptions.
Commit a0b43a1 changed textures to an array, because additional
per-texture information was needed and managing this as array is more
elegant. This broke playback on Windows with Intel drivers (window
shows green video, even though subtitles/OSD work correctly). So change
it back to make it work again.
Affected driver: Intel(R) HD Graphics 3000 9.17.10.2932
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
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.
Commit 9efe32120 stops recreating the hidden window used for OpenGL's
extensions autodetection. The `cocoa_common` code assumed the hidden flag could
only come when creating a window which is now not true anymore.
Move some code around so that hidden, fullscreen and window position are
respected on subsequent calls of config.
Apparently newer Mesa versions changed their <GL/glx.h> header, and
unconditionally define GLX_CONTEXT_MAJOR_VERSION_ARB and others. This
clashed with gl_header_fixes.h, a header which quarantines bad hacks
to make compilation possible on systems with outdated GL headers.
Specifically, our header was included before glx.h, so the hacks were
always active, and somehow Mesa's glx.h used to deal with this by not
redefining existing identifiers.
Fix the gl_header_fixes.h logic so the hacks are checked after including
glx.h.
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.
This was done so because the X11 code had a hard to track down issue
with some window managers, and caused the VO window to be placed
incorrectly. This was fixed in the previous commit. Consequently, we can
remove this bad hack.
vo_opengl creates an invisible window with VOFLAG_HIDDEN in order to
test whether the OpenGL context is useable. The visible window is
created at a later point. This has been broken forever (in vo_gl,
now called vo_opengl_old, it could be avoided by disabling auto-
detection explicitly using the "yuv" sub-option). Avoiding
VOFLAG_HIDDEN only mitigates the issue, and a related bug can still
happen with some window managers (see below).
As a hack, code was added to vo_gl to destroy the (hidden) window so
that all state was destroyed. Later, more hacks were added to deal with
some caveats that came with recreating the window, such as probing for
the context up to 4 times.
Attempt to fix the problem properly. There were two problems: first,
the window was not resized to video size before mapping. This was the
main cause for the placement issue, e.g. mapping the window as 320x200,
and then resizing it. Second, mpv tried to force the window position
with XSetWMNormalHints and PPosition with values it just read with
XGetGeometry. This messes up the window manager's default placement.
It seems to be a race condition, and behavior is different across
various WMs too: with IceWM, the window manager's placement is usually
preferred, and with Fluxbox, mpv's position is preferred. mpv's default
position is centering the window on the screen, which is much nicer for
video in general than typical WM default placement, so it's possible
that this bug was perceived as a feature. (Users who want this have to
use --geometry="50%:50%", doing this by default is probably not safe
with all WMs.)
Since the old code was hard to follow and full of issues, it's easier
to redo it. Move general window creation stuff out of the
vo_x11_config_vo_window function, and move the resize logic into it.
This has been tested on IcwWM, Fluxbox, awesome, Unity/Compiz.
Store the window state (position and size) in vo_x11_state, instead of
in vo->dx/dy/dwidth/dheight. The VO variables are overwritten by vo.c on
every vo_config() call, which is extremely not helpful.
Now vo->dx/dy are mostly unused (except for passing the position forced
by the --geometry option), and vo->dwidth/dheight are set for the VO,
and otherwise read for resize detection only.
In the long term, the way vo_config() handles the --geometry option
should be changed, and vo->dx/dy should be removed.
Remove some useless stuff: VO_EVENT_MOVE and VO_EVENT_KEYPRESS were
generated, but unused. Wayland changes by Alexander Preisinger.
It was once used for vo_sdl (the old one based on SDL 1.2), since SDL
apparently lost the GL state when switching to fullscreen. The new
vo_sdl (using SDL 1.3) doesn't use or need this. It's dead code, so
get rid of it.
OPT_BASE_STRUCT defines which struct the OPT_ macros (like OPT_INT etc.)
reference implicitly, since these macros take struct member names but no
struct type. Normally, only cfg-mplayer.h should need this, and other
places shouldn't be bothered with having to #undef it.
(Some files, like demux_lavf.c, still store their options in MPOpts. In
the long term, this should be removed, and handled like e.g. with VO
suboptions instead.)
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_old could disable OSD rendering when a
very old OpenGL version was detected, and had an option to explicitly
disable it as well.
Remove VFCAP_OSD from everything (and some associated logic). Now the
vo_driver.draw_osd callback can be set to NULL to indicate missing OSD
support (important so that vo_null etc. don't single-step on OSD
redraw), and if OSD support depends on runtime support, the VO's
draw_osd should just do nothing if OSD is not available.
Also, do not access vo->want_redraw directly. Change the want_redraw
reset logic for this purpose, too. (Probably unneeded, vo_flip_page
resets it already.)
All wayland only specific routines are placed in wayland_common.
This makes it easier to write other video outputs.
The EGL specific parts, as well as opengl context creation, are in gl_common.
This backend works for:
* opengl-old
* opengl
* opengl-hq
To use it just specify the opengl backend
--vo=opengl:backend=wayland
or disable the x11 build.
Don't forget to set EGL_PLATFORM to wayland.
Co-Author: Scott Moreau
(Sorry I lost the old commit history due to the file structure changes)
This allowed making the player switch the monitor video mode when
creating the video window. This was a questionable feature, and with
today's LCD screens certainly not useful anymore. Switching to a random
video mode (going by video width/height) doesn't sound too useful
either.
I'm not sure about the win32 implementation, but the X part had several
bugs. Even in mplayer-svn (where x11_common.c hasn't been receiving any
larger changes for a long time), this code is buggy and doesn't do the
right thing anyway. (And what the hell _did_ it do when using multiple
physical monitors?)
If you really want this, write a shell script that calls xrandr before
and after calling mpv.
vo_sdl still can do mode switching, because SDL has native support for
it, and using it is trivial. Add a new sub-option for this.
The --wid switch (for embedding the player into other applications)
didn't create a new window, and instead tried to use the window that
was passed via --wid directly. This made the code more complex, caused
strange X errors (mpv and host application fighting for exclusive X
resources), and actually could cause issues if the --wid window wasn't
created with the X Visual needed for OpenGL.
Always create a window instead. This makes it always possible to embed
the player into foreign windows. --geometry doesn't work anymore - the
controlling application should always create a new window to place the
player inside it, and can control the video window by moving and
resizing this window.
w32_common.c actually did this right, and always creates a new window.
create_window is really bad naming, because this function can be called
multiple times, while the name implies that it always creates a new
window. At least the name config_window is not actively misleading.
Allow the backend code to create a GL context on best effort basis,
instead of having to implement separate functions for each variation.
This means there's only a single create_window callback now. Also,
getFunctions() doesn't have the gl3 parameter anymore, which was
confusing and hard to explain.
create_window() tries to create a GL context of any version. The field
MPGLContext.requested_gl_version is taken as a hint whether a GL3 or a
legacy context is preferred. (This should be easy on all platforms.)
The cocoa part always assumes that GL 3 is always available on
OSX 10.7.0 and higher, and miserably fails if it's not. One could try
to put more effort into probing the context, but apparently this
situation never happens, so don't bother. (And even if, mpv should be
able to fall back to vo_corevideo.)
The X11 part doesn't change much, but moving these functions around
makes the diff bigger.
Note about some corner cases:
This doesn't handle CONTEXT_FORWARD_COMPATIBLE_BIT_ARB on OpenGL 3.0
correctly. This was the one thing getFunctions() actually needed the
gl3 parameter, and we just make sure we never use forward compatible
contexts on 3.0. It should work with any version above (e.g. 3.1, 3.2
and 3.3 should be fine). This is because the GL_ARB_compatibility
extension is specified for 3.1 and up only. There doesn't seem to be
any way to detect presence of legacy GL on 3.0 with a forward
compatible context. As a counter measure, remove the FORWARD_COMPATIBLE
flags from the win32 code. Maybe this will go wrong. (Should this
happen, the flag has the be added back, and the win32 will have to
explicitly check for GL 3.0 and add "GL_ARB_compatibility" to the extra
extension string.)
Note about GLX:
Probing GL versions by trying to create a context on an existing window
was (probably) not always possible. Old code used GLX 1.2 to create
legacy contexts, and it required code different from GLX 1.3 even before
creation of the X window (the problem was selections of the X Visual).
That's why there were two functions for window creation (create_window_old
and create_window_gl3). However, the legacy context creation code was
updated to GLX 1.3 in commit b3b20cc, so having different functions for
window creation is not needed anymore.
The backend sub-option for vo_opengl and vo_opengl-old accepted numeric
values (like -1, 0, ...) for compatibility with MPlayer. This was added
in mplayer2 times, and is not important anymore.
You can just use --wid=0 if you really want this.
This only worked/works for X11, and even then it might interact badly
with most desktop environments. All the option did was setting --wid to
0, and the property did nothing.
And support the PIX_FMT_MONOWHITE pixel format. (This is really weird:
unlike PIX_FMT_MONOBLACK, it uses white pixels. I have no idea why
libavcodec doesn't just convert the pixel format on the fly, instead of
bothering everyone with really special pixel formats.)
Recent changes to the OSD code made vo_caca crash when showing OSD.
Since this is a joke VO (== I'd rather not waste my time with it),
remove the OSD support. It wasn't that great anyway.
This fixes the issue that black borders (e.g. on fullscreen) are not
redrawn, even if OSD rendering changes these areas.
In theory, the code could try some clever things to determine whether
clearing the window is really necessary, but that's probably not worth
the trouble and won't bring any significant performance gain, or might
even make things slower (because the GPU can't discard the old
contents).
Also fix redrawing when changing panscan with OSD disabled.
Use the option parser instead of sscanf. Remove the parameter changing
the field dominance (it has been marked deprecated for ages). Add a new
suboption "enabled", which can be used to disable the filter by default,
until it's enabled at runtime:
mpv -vf yadif=enabled=no
For all suboptions, "flat" options were available by separating the
parent option and the sub option with ":", e.g. "--rawvideo:w=123". Drop
this syntax and use "-" as separator. This means even suboptions are
available as normal options now, e.g. "--rawvideo-w=123". The old syntax
doesn't work anymore.
Note that this is completely separate from actual suboptions. For
example, "-rawvideo w=123:h=123" still works. (Not that this syntax is
worth supporting, but it's needed anyway, for for other things like vf
and vo suboptions.)
As a consequence of this change, we also have to add new "no-" prefixed
options for flag suboptions, so that "--no-input-default-bindings"
works. ("--input-no-default-bindings" also works as a consequence of
allowing "-input no-default-bindings" - they are handled by the same
underlying option.)
For --input, always use the full syntax in the manpage. There exist
suboptions other than --input (like --tv, --rawvideo, etc.), but since
they might be handled differently in the future, don't touch these yet.
M_OPT_PREFIXED becomes the default, so remove it. As a minor unrelated
cleanup, get rid of M_OPT_MERGE too and use the OPT_SUBSTRUCT() macro in
some places.
Unrelated: remove the duplicated --tv:buffersize option, fix a typo in
changes.rst.
`--fs-screen` allows to decide what display to go fullscreen into. The
semantics of `--screen` changed and now it is only used to select the windowed
display when starting the application.
This is useful for people using mpv with an external TV. They will start
windowed on their laptop's screen and switch to fullscreen on the TV.
@wm4 worked on the x11 and w32 parts of the code. All is squashed in one
commit for history clarity.
Also some other cosmetic changes. And reformat the two remaining doxygen
comments.
Removing MSGLEN in x11_errorhandler() is technically not just a cosmetic
change, but the result is the same anyway.
The string is deallocated by the callee after initialization, so
fallback at runtime passes a deallocated string to libavcodec, which
results in random crashes. Regression introduced by commit 4d016a9.
Fixes#29. When a user used dead input keys (like the accent key), `mpv`
crashed because the code tried to access the 0 element of a characters array
(which was empty).
While I was closing this bug, I refactored some related conditionals to
make the code more readable.
Do this to reduce conflicts with <linux/input.h>, which contains some
conflicting defines.
This changes the meaning of MP_KEY_DOWN:
KEY_DOWN is renamed to MP_KEY_DOWN (cursor down key)
MP_KEY_DOWN is renamed to MP_KEY_STATE_DOWN (modifier for key down state)
Instead of putting codec header data into WAVEFORMATEX and
BITMAPINFOHEADER, pass it directly via AVCodecContext. To do this, we
add mp_copy_lav_codec_headers(), which copies the codec header data
from one AVCodecContext to another (originally, the plan was to use
avcodec_copy_context() for this, but it looks like this would turn
decoder initialization into an even worse mess).
Get rid of the silly CodecID <-> codec_tag mapping. This was originally
needed for codecs.conf: codec tags were used to identify codecs, but
libavformat didn't always return useful codec tags (different file
formats can have different, overlapping tag numbers). Since we don't
go through WAVEFORMATEX etc. and pass all header data directly via
AVCodecContext, we can be absolutely sure that the codec tag mapping is
not needed anymore.
Note that this also destroys the "standard" MPlayer method of exporting
codec header data. WAVEFORMATEX and BITMAPINFOHEADER made sure that
other non-libavcodec decoders could be initialized. However, all these
decoders have been removed, so this is just cruft full of old hacks that
are not needed anymore. There's still ad_spdif and ad_mpg123, bu neither
of these need codec header data. Should we ever add non-libavcodec
decoders, better data structures without the past hacks could be added
to export the headers.
Rearrange some code to make it easier readable. Remove some dead code,
and stop printing AVI headers in demux_lavf. (These are not actual AVI
headers, just for internal use.)
There should be no functional changes, other than reducing output in
verbose mode.
Use codec names instead of FourCCs to identify codecs. Rewrite how
codecs are selected and initialized. Now each decoder exports a list
of decoders (and the codec it supports) via add_decoders(). The order
matters, and the first decoder for a given decoder is preferred over
the other decoders. E.g. all ad_mpg123 decoders are preferred over
ad_lavc, because it comes first in the mpcodecs_ad_drivers array.
Likewise, decoders within ad_lavc that are enumerated first by
libavcodec (using av_codec_next()) are preferred. (This is actually
critical to select h264 software decoding by default instead of vdpau.
libavcodec and ffmpeg/avconv use the same method to select decoders by
default, so we hope this is sane.)
The codec names follow libavcodec's codec names as defined by
AVCodecDescriptor.name (see libavcodec/codec_desc.c). Some decoders
have names different from the canonical codec name. The AVCodecDescriptor
API is relatively new, so we need a compatibility layer for older
libavcodec versions for codec names that are referenced internally,
and which are different from the decoder name. (Add a configure check
for that, because checking versions is getting way too messy.)
demux/codec_tags.c is generated from the former codecs.conf (minus
"special" decoders like vdpau, and excluding the mappings that are the
same as the mappings libavformat's exported RIFF tables). It contains
all the mappings from FourCCs to codec name. This is needed for
demux_mkv, demux_mpg, demux_avi and demux_asf. demux_lavf will set the
codec as determined by libavformat, while the other demuxers have to do
this on their own, using the mp_set_audio/video_codec_from_tag()
functions. Note that the sh_audio/video->format members don't uniquely
identify the codec anymore, and sh->codec takes over this role.
Replace the --ac/--vc/--afm/--vfm with new --vd/--ad options, which
provide cover the functionality of the removed switched.
Note: there's no CODECS_FLAG_FLIP flag anymore. This means some obscure
container/video combinations (e.g. the sample Film_200_zygo_pro.mov)
are played flipped. ffplay/avplay doesn't handle this properly either,
so we don't care and blame ffmeg/libav instead.
OPT_MAKE_FLAGS() used to emit two options (one with "no" prefixed),
but that has been long removed by special casing flag options in the
option parser. OPT_FLAG_ON() used to imply that there's no "no-"
prefixed option, but this hasn't been the case for a while either.
(Conceptually, it has been replaced by OPT_FLAG_STORE().)
Remove OPT_FLAG_OFF, which was unused.
Normally, all flag options can be negated by prepending a "no-", for
example "--no-opt" becomes "--opt=no". Some flag options can't actually
be negated, so add a CONF_TYPE_STORE option type to disallow the "no-"
fallback.
Do the same for choice options. Remove the explicit "no-" prefixed
options, add "no" as choice.
Move the handling of automatic "no-" options from parser-mpcmd.c to
m_config.c, and use it in m_config_set_option/m_config_parse_option.
This makes these options available in the config file. It also
simplifies sub-option parsing, because it doesn't need to handle "no-"
anymore.
mpv -ao help and mpv -vo help shouldn't show the encoding outputs (named
"lavc" on both cases). Also make it impossible to select these manually
when not encoding.
Basically, move vo_opengl above the other VOs (except vo_vdpau). This
changes preferences on Windows and Linux.
Move vo_opengl_old further down and make it the last fallback (before
vo_x11).
vo_caca is crap (no pun intended), and should never be autoprobed.
Add more vf_stereo3d output formats.
Adds high quality green-magenta and yellow-blue dubois
anaglyph 3D output support.
Patch by thomas schorpp, thomas.schorpp gmail
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35906 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
video/filter/vf_stereo3d.c
Apply setLevel hacks for fullscreen switching with ontop active only in
fullscreen. This keeps the window correctly on top even when losing focus.
Fixes#21
I also reverted NSScreenSaverWindowLevel to NSNormalWindowLevel + 1, so that
the cmd-tab UI is visible
The main problem this commit addresses is when you switched spaced back and
forth with `--ontop` active the video window didn't recive focus again.
Turns out that setting a normal window level just before conceding focus to
other apps / spaces fixes the problem. I think Cocoa is misbehaving here, and
should probably file a radar.
I found 3 related improvements while fixing this:
* fullscreen_window_level is a dead body from an older implementation.
* Use NSScreenSaverWindowLevel for ontop. This should be a really high window
level. Definitely higher than NSNormalWindowLevel + 1.
* The window level was set correctly only when out of fullscreen.
Make the window resizing menu items calculate the new window size based on the
video size and not the current window size.
This only makes a difference when using `--autofit`.
This functionality looked smart but created problems with some kinds of
multi touch events. Moreover some events coming from the windows server – like
hovering a corner for window resize – didn't cause the player to wake up
immediately.
The "correct" non hacky way to implement async event polling with cocoa would
be having the vanilla cocoa event loop driving the player and setting up mpv's
terminal FDs as event sources for the cocoa event loop.
Fixes#20
Remove screenshot_force and associated logic. Always try to use the
screenshot video filter before trying taking screenshots with the VO,
which means that --vf=screenshot now takes the role of --vf=screenshot_force.
(To make this clear, not adding a video filter is still the recommended
way to take screenshots; we just change how VF screenshots are forced.)
Preferring VO over VF and having --vf=screenshot_force used to make
sense when not all VOs supported screenshots, and some VOs had somewhat
broken screenshots (like vo_xv taking screenshots with OSD in it). But
all these issues are fixed now, so just get rid of the cruft.
This commit makes `is_osx_version_at_least` cache the result of reading
`/System/Library/CoreServices/SystemVersion.plist`. Since that is a file
read operation it was bad to use this function frequently (i.e.: when
processing user events).
Remove `is_lion_or_above` (introduced in c9396c0a) as that was a more
specialized wrapper which had the only advantage of adding it's own cache.
Don't force VOs to pick an arbitrary default Visual and Colormap. They
still can override them if needed. This simplifies the X11 VO interface.
Always create a Colormap for simplicity. Using CopyFromParent fails if
the selected visual is not the same of that of the parent window, which
happens for me with vo_opengl.
vo_vdpau and vo_xv explicitly set CWBorderPixel, do that in x11_common
instead (it was already done for native windows, but not for slave mode
windows).
What gl_common did was incorrect in theory: freeing a colormap while a
window uses it will change the colormap of the window to "None", and
the color mapping for such windows is "undefined".
The original video mode wasn't reliably restored, so just store the
mode separately.
For some reason, window decorations got into the picture, possibly due
to an incorrect initial window position or something like this.
Normally, the window is positioned and sized such that it covers the
screen entirely, even though the window still has decorations and is
not in fullscreen mode (fullscreen wouldn't be correct, because the
virtual desktop size is not screen size). Hack-fix by forcing window
decorations off when VM-switching.
All in all, VM switching is still buggy and useless.
Some parts for initiating mode switches were duplicated in every VO
supporting X11 (except vo_opengl/gl_common, which didn't support mode
switching). Move this to x11_common.c.
Note that this might be slightly risky: is it really guaranteed that no
VO needed to do "special" setup that depends on X parameters changing
after a mode switch, such as bit depth, visuals etc.? From what I can
see, this shouldn't be the case (X probably can't even change depth on
the fly). Even if this should be a one-way road, VM switching is in
general very useless, and its implementation buggy, so it can just be
removed should unfixable problems arise.
Do this because we want to remove the global variables required with the
old code. In particular, there doesn't seem any way to set a secure user
data pointer with xlib.
XSelectInput() causes a BadAccess error when some of the requested event
flags are reserved (for exclusive flags like ButtonPress). The custom
error handler caught this and set a global variable, so that the code
could retry the XSelectInput() call without the conflicting flags. Use a
different approach that doesn't need a custom error handler. (Although
we still assume that the error handler doesn't terminate the program.)
Move things that are used by vo_xv only into vo_xv, same for vo_x11.
Rename some functions exported by x11_common, like vo_init to
vo_x11_common. Make functions not used outsode of x11_common.c private
to that file. Eliminate all global variables defined by x11_common
(except error handler and colormap stuff).
There shouldn't be any functional changes, and only code is moved
around. There are some minor simplifications in the X11 init code, as
we completely remove the ability to initialize X11 and X11+VO
separately (see commit b4d9647 "mplayer: do not create X11 state in player frontend"),
and the respective functions are conflated into vo_x11_init() and
vo_x11_uninit().
Dithering was disabled if the input bit depth was not larger than the
output bit depth of the screen framebuffer. But since scaling, RGB
conversion, and other filters change the number of significant bits
anyway, dithering could still benefit image quality even in these
cases. Always do dithering, unless dithering is completely disabled.
The original intention of this mechanism was not to change the image
needlessly when playing video that matches the native bit depth of the
screen.
The decoder returns with AVFrame.format not correctly set for some h264
files (strangely only some). We have to access AVCodecContext.pix_fmt
instead. On newer libavcodec versions, it's the other way around: the
AVCodecContext.pix_fmt may be incorrectly set on pixel format changes,
and you are supposed to use AVFrame.format.
The same problem probably exists on older ffmpeg versions too.
Exactly the same issue as with the previous commit. Just like the vdpau
code, this was apparently copy-pasted from the vo_x11 code, even though
it doesn't make much sense.
Using vdpau on an X server configured to a bit depth of 30 (10 bit per
component) failed finding a visual. The cause was a hack that tried to
normalize the bit depth to 24 if it was not a known depth. It's unknown
why/if this is needed, but the following things speak against it:
- it prevented unusual bit depths like 30 bit from working
- it wasn't needed with normal bit depth like 24 bit
- it's probably copy-pasted from vo_x11 (where this code possibly makes
sense, unlike in vo_vdpau)
Just remove this code and look for a visual with native depth.
-x/-y were rather useless and obscure. The only use I can see is
forcing a specific aspect ratio without having to calculate the aspect
ratio float value (although --aspect takes values of the form w:h).
This can be also done with --geometry and --no-keepaspect. There was
also a comment that -x/-y is useful for -vm, although I don't see how
this is useful as it still messes up aspect ratio.
-xy is mostly obsolete. It does two things: a) set the window width to
a pixel value, b) scale the window size by a factor. a) is already done
by --autofit (--autofit=num does exactly the same thing as --xy=num, if
num >= 8). b) is not all that useful, so we just drop that
functionality.
--autofit=WxH sets the window size to a maximum width and/or height,
without changing the window's aspect ratio.
--autofit-larger=WxH does the same, but only if the video size is
actually larger than the window size that would result when using
the --autofit=WxH option with the same arguments.
This also means the option is verified on program start, not when the VO
is created. The actual code becomes a bit more complex, because the
screen width/height is not available at program start.
The actual parsing code is still the same, with its unusual sscanf()
usage.
Now the calculations of the final display size are done after the filter
chain. This makes the difference between display aspect ratio and window
size a bit more clear, especially in the -xy case.
With an empty filter chain, the behavior of the options should be the
same, except that they don't affect vo_image and vo_lavc anymore.
Drop queued frames on seek. Reset the internal state of some filters
that seem to need it as well: at least vf_divtc still produced some
frames using the previous PTS.
This fixes weird behavior with some filters on seeking. In particular,
this could lead to A/V desync or apparent lockups due to the PTS of
filtered frames being too far away from audio PTS.
This commit does only the minimally required work to fix these PTS
related issues. Some filters have state dependent on previously filtered
frames, and these are not automatically reset with this commit (even
vf_divtc and vf_softpulldown reset the PTS info only). Filters that
actually require a full reset can implement VFCTRL_SEEK_RESET.
Options that take pixel format names now also accept ffmpeg names.
mpv internal names are preferred. We leave this undocumented
intentionally, and may be removed once libswscale stops printing
ffmpeg pixel format names to the terminal (or if we stop passing the
SWS_PRINT_INFO flag to it, which makes it print these).
(We insist on keeping the mpv specific names instead of dropping them
in favor of ffmpeg's name due to NIH, and also because ffmpeg always
appends the endian suffixes "le" and "be".)
<ctype.h> is needed at least for isalnum(). Most time this worked,
because some ffmpeg or Libav versions recursively include this header
from libavutil/common.h. Fix it so it always works.
This printed per-frame statistics into a file, like bitrate or frame
type. Not very useful and accesses obscure AVCodecContext fields
(danger of deprecation/breakage), so get rid of it.
This was a "broken misfeature" according to Libav developers. It wasn't
implemented for modern codecs (like h264), and has been removed from
Libav a while ago (the AVCodecContext field has been marked as
deprecated and its value is ignored). FFmpeg still supports it, but
isn't much useful due to aforementioned reasons.
Remove the code to enable it.
This was an awkward hack that attempted to avoid the use of 16 bit
textures, while still allowing rendering 10-16 bit YUV formats. The
idea was that even if the hardware doesn't support 16 bit textures,
an A8L8 textures could be used to convert 10 bit (etc.) to 8 bit in
the shader, instead of doing this on the CPU.
This was an experiment, disabled by default, and was (probably) rarely
used. I've never heard of this being used successfully. Remove it.
This is more correct. Not all frame specific fields are in AVFrame,
such as colorspace and color_range, and these are still queried
through the decoder context.
This field contained the "average" bit depth per pixel. It serves no
purpose anymore. Remove it.
Only vo_opengl_old still uses this in order to allocate a buffer that is
shared between all planes.
This used to mean that there is more than one plane. This is not very
useful: IMGFMT_Y8 was not considered planar, but it's just a Y plane,
and could be treated the same as actual planar formats. On the other
hand, IMGFMT_NV12 is partially packed, and usually requires special
handling, but was considered planar.
Change its meaning. Now the flag is set if the format has a separate
plane for each component. IMGFMT_Y8 is now planar, IMGFMT_NV12 is not.
As an odd special case, IMGFMT_MONO (1 bit per pixel) is like a planar
RGB format with a single plane.
In theory, vf_sub could take any format supported by swscale. But to be
sure that it's reasonably fast, only 420P was allowed. However, other
similar 8 bit planar formats will be just as fast and there's no reason
to exclude them. Even for completely different formats there doesn't
seem to be any significant advantage to force vf_sub to convert to a
simpler/more common format.
This did random things with some image formats, including 10 bit
formats. Fixes the mp_image_clear() function too.
This still has some caveats:
- doesn't clear alpha to opaque (too hard with packed RGB, and is rarely
needed)
- sets luma to 0 for mpeg-range YUV, instead of the lowest possible
value (e.g. 16 for 8 bit)
Needed because mplayer* basically tracks DAR, which makes it harder for
filters which want to keep the SAR.
The contents of this function are duplicated in a few filters, and will
be used instead of custom code as the filters are updated later.
This makes it behave like vo_lavc.
Unfortunately, the code for setting up the OSD dimensions (mp_osd_res)
is copied from vo_lavc, but it doesn't look like something that should
be factored out.
redraw_frame() copied the image into the currently visible buffer. This
resulted in flicker when doing heavy OSD redrawing (like changing the
subtitle size to something absurdly large).
Use the same logic as draw_image instead.
In order to support OSD redrawing for vo_xv and vo_x11, draw_bmp.c
included an awkward "backup" mechanism to copy and restore image
regions that have been changed by OSD/subtitles.
Replace this by a much simpler mechanism: keep a reference to the
original image, and use that to restore the Xv/X framebuffers.
In the worst case, this may increase cache pressure and memory usage,
even if no OSD or subtitles are rendered. In practice, it seems to be
always faster.
It's not easy to tell whether the OSD/subs are empty, or if something is
drawn. In general you have to use osd_draw() with a custom callback. If
nothing is visible, the callback is never invoked. (The actual reason
why this is so "hard" is the implementation of osd_libass.c, which
doesn't allow separating rendering and drawing of OSD elements, because
all OSD elements share the same ASS_Renderer.)
To simplify avoiding copies, make osd_draw_on_image() instead of the
caller use mp_image_make_writeable(). Introduce osd_draw_on_image_p(),
which works like osd_draw_on_image(), but gets the new image allocation
from an image pool. This is supposed to be an optimization, because it
reduces the frequency of large allocations/deallocations for image data.
The result of this is that the frequency of copies needed in conjunction
with vf_sub, screenshots, and vo_lavc (encoding) should be reduced.
vf_sub now always does true pass-through if no subs are shown.
Drop the pts check from vf_sub. This didn't make much sense.
Remove the strange things the old mp_image_setfmt() code did to the
image format parameters. This includes setting chroma shift to 31 for
gray (Y8) formats and more.
Y8 + vo_opengl_old didn't actually work for unknown reasons (regression
in this branch). Fix this. The difference is that Y8 is now interpreted
as gray RGB (LUMINANCE texture) instead of involving YUV (and levels)
conversion.
Get rid of distinguishing RGB and BGR. There wasn't really any good
reason for this.
Remove mp_get_chroma_shift() and IMGFMT_IS_YUVP16*(). mp_imgfmt_desc
gives the same information and more.
Even though #ifdef ACCURATE is removed, the result should be about the
same. The fallback is only used by packed YUV formats (YUYV, NV12), and
doing 16 bit for them instead of 8 bit is not useful.
A side effect is that Y8 (gray) is not converted drawing subs, and for
alpha formats, the alpha plane is not removed. This means the number of
planes after upsampling can be 1-4 (1: gray, 2: gray+alpha, 3: planar,
4: planar+alpha). The code has to be adjusted accordingly to work on the
color planes only. Also remove the workaround for the chroma shift 31
hack.
