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
There are some Microsoft Windows symbols which are traditionally used by
the mplayer core, because it used to be convenient (avi was the big
format, using binary windows decoders made sense...). So these symbols
have the exact same definition as the Windows one, and if mplayer is
compiled on Windows, the symbols from windows.h are used.
This broke recently just because some files were shuffled around, and
the symbols defined in ms_hdr.h collided with windows.h ones. Since we
don't have windows binary decoders anymore, there's not the slightest
reason our symbols should have the same names. Rename them to reduce the
risk for collision, and to fix the recent regression.
Drop WAVEFORMATEXTENSIBLE, because it's mostly unused. ao_dsound defines
its own version if the windows headers don't define it, and ao_wasapi is
not available on systems where this symbol is missing.
Also reindent ms_hdr.h.
We had some code for checking profiles earlier, which was removed in
commits 2508f38 and adfb71b. These commits mentioned that (working) hw
decoding was sometimes prevented due to profile checking, but I can't
find the samples anymore that showed this behavior. Also, I changed my
opinion, and I think checking the profiles is something that should be
done for better fallback to software decoding behavior.
The checks roughly follow VLC's vdpau profile checks, although we do
not check codec levels. (VLC's profile checks aren't necessarily
completely correct, but they're a welcome help anyway.)
Add a --vd-lavc-check-hw-profile option, which skips the profile check.
This one really did bite me hard (see previous commit), so enable it by
default.
Fix some cases of shadowing throughout the codebase. None of these
change behavior, and all of these were correct code, and just tripped up
the warning.
As preparation for resizing the window with input commands in the
following commit.
Since there are already so many functions which somehow resize the
window, add the word "highlevel" to the name of this new function.
We mixed the "old" AVFrame management functions (avcodec_alloc_frame,
avcodec_free_frame) with reference counting. This doesn't work
correctly; you must use av_frame_alloc and av_frame_free. Of course
ffmpeg doesn't warn us about the bad usage, but will just mess up
things silently. (Thanks a lot...)
While the alloc function seems to be 100% compatible, the free function
will do bad things, such as freeing memory that might still be
referenced by another frame. I didn't experience any actual bugs, but
maybe that was pure luck.
This stopped working when the code was changed to create a window even
if --wid is used.
It appears we can't create our own window in this case, because in X11
there is no difference between a window with the root window as parent,
and a window that is managed by the WM. So make this (kind of worthless)
special case use the root window itself.
On systems that provide legacy OpenGL (up to 2.1), but not GL3 and
later, creating a GL3 context will fail. We then revert to legacy GL.
Apparently the error message printed when the GL3 context creation
fails is confusing. We could just silence it, but there's still a X
error ("X11 error: GLXBadFBConfig"), which would be quite hard to
filter out. For one, it would require messing with the X11 error
handler, which doesn't even carry a context pointer (for application
private data), so we don't even want to touch it. Instead, change
the error message to inform the user what's actually happening: a
fallback to an older version of OpenGL.
Trying to toggle the border during fullscreen (with "cycle border")
would leave the window stuck without border, and it couldn't be
restored. This was because vo_x11_decoration() always excepted to be
called when toggling the state, and thus confusing the contents of the
olddecor variable. Add got_motif_hints to hopefully prevent this.
Also, when changing the border, don't take fs in account. May break on
older/broken WMs, but all in all is in fact more robust and simpler,
because you do not need to update the border state manually when
returning from fullscreen.
The default behavior of weston changed some time ago to not fill the surface
black for fullscreen windows.
Now let mpv draw the whole screen in fullscreen mode.
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 code did not set and unset the current context inside sync sections. I am
not sure if this was an actual problem but this is better since the context is
linked to a single thread. In my brief tests this seems to avoid garbage to
show up in fullscreen.
Instead of removing dragging we now test if it we should drag the window or
not. Because if the OSC shows up we can not drag the window because that would
cause mouse events that makes the OSC disappear.
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.
This could cause the OSC to be displayed without mouse interaction: for
example, starting mpv with --fs, and putting the mouse to where the OSC
area is beforehand, would cause the OSC to appear and stay visible. We
don't want that. The simplest solution is not generating artificial
mouse move events from mouse enter events, because they make the OSC
think the mouse was actually moved.
Also see commit 0c7978c, where handling of mouse enter events was added.
This was supposed to fix certain corner cases, but they're not relevant
anymore due to changes in OSC behavior.
Commit 9777047 fixed this as well (by resetting the mouse state on
MOUSE_LEAVE), but all the behavior reverted with this commit as perhaps
a bad idea. It wasn't very robust, made it hard to distinguish real
events from artificial ones, and finally made the mouse cursor more
often visible than needed. (Now switching between workspaces doesn't
make the cursor visible again when switching to a fullscreened mpv.)
vo_image didn't handle OSD redrawing correctly anymore after OSD
redrawing behavior was changed in commit ed9295c (or maybe it has been a
problem for a longer time, and only showed up now). Basically, flip_page
was called unexpectedly and when no image was stored, which made it
crash trying to access the image. This could happen when for example
provoking OSD redrawing by pausing while using --vo=image, or by using
this command line: mpv --vo=image '-vf=lavfi="select=not(mod(n\,3))"'
Fix by removing the code that pretends vo_image can redraw OSD, and by
removing the framestepping fallback, which could make bad things happen
if the VO didn't support OSD redrawing. By now, there aren't any real
VOs that can't redraw the OSD properly, so this code is not needed and
just complicates things like vo_image.
This change likely will also be useful for vo_lavc (encoding).
Change talloc destructor so that they can never signal failure, and
don't return a status code. This makes our talloc copy even more
incompatible to upstream talloc, but on the other hand this is
preparation for getting rid of talloc entirely.
(The talloc replacement in the next commit won't allow the talloc_free
equivalent to fail, and the destructor return value would be useless.
But I don't want to change any mpv code either; the idea is that the
talloc replacement commit can be reverted for some time in order to
test whether the talloc replacement introduced a regression.)
This only shows any differences when mpv isn't frontmost and is in fullscreen.
Cmd+Tab overlay is still at a higher level as to avoid complete usability fail.
glXGetVisualFromFBConfig() specifies specifies that it can return NULL
if there is no associated X visual. Instead of crashing, let
initialization fail. I'm not sure if this is actually supposed to work
with a fallback visual (passing a NULL visual to vo_x11_config_vo_window
would just do this), but let's play safe for now.
Apparently this can happen when trying to use vo_opengl over a remote
X display.
Stefano Pigozzi
wm4
Alexander Preisinger
Mad Fish