| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This commit removes the pointer to the single different structures for input
and window and puts them as anonymous structures inside the wayland_state
structure.
This has the disadvantage of passing the substructure to the listeners, but the
advantage is that we don't have to allocate them and check for NULL pointers.
This makes it more reliable and easier to follow.
|
| |
|
|
|
|
| |
The vo_wayland_fullscreen handles resizing for the video, because the video
could still be in fullscreen mode and resizing it in gl_wayland could make it
grow or shrink.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a MPOpts fullscreen field, a mp_vo_opts.fs field, and
VOFLAG_FULLSCREEN. Remove all these and introduce a
mp_vo_opts.fullscreen flag instead.
When VOs receive VOCTRL_FULLSCREEN, they are supposed to set the
current fullscreen mode to the state in mp_vo_opts.fullscreen. They
also should do this implicitly on config().
VOs which are capable of doing so can update the mp_vo_opts.fullscreen
if the actual fullscreen mode changes (e.g. if the user uses the
window manager controls). If fullscreen mode switching fails, they
can also set mp_vo_opts.fullscreen to the actual state.
Note that the X11 backend does almost none of this, and it has a
private fs flag to store the fullscreen flag, instead of getting it
from the WM. (Possibly because it has to deal with broken WMs.)
The fullscreen option has to be checked on config() to deal with
the -fs option, especially with something like:
mpv --fs file1.mkv --{ --no-fs file2.mkv --}
(It should start in fullscreen mode, but go to windowed mode when
playing file2.mkv.)
Wayland changes by: Alexander Preisinger <alexander.preisinger@gmail.com>
Cocoa changes by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
|
| |
|
|
|
|
| |
This was bad, because it was the only aspdat member updated by
vo_get_src_dst_rects() instead of vo_reconfig(). Now it isn't
accessed anymore, so remove it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, only formats directly supported by OpenGL were supported.
This excludes various permutations of 8-bit RGB[A|0]. But we can simply
permutate the color channels in the shader, so do that. This also adds
support for all these weird RGB0 formats.
Note that we could use libavutil's pixfmt list instead of the
mp_packed_formats array, but trying to decrypt the pixfmt info would
probably end in pain, so this array with duplicated information is
actually better and shorter.
Note: I didn't actually test whether the alpha components are reproduced
correctly with alpha formats.
|
| | |
|
| |
|
|
|
|
|
| |
Using the term "color class" to avoid confusion with the other
colorspace related concepts.
Also get rid of MP_IMGFLAG_FMT_MASK, since it was unused.
|
| |
|
|
| |
No need to duplicate this on the call-site.
|
| |
|
|
| |
Add libswscale includes where they are actually needed instead.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Image parameters like colorspace, color levels, and chroma location are
generally less important, and many filters don't set them correctly.
Force them instead in the generic VF code, which is probably better and
more convenient over all. So we designate this is a proper solution,
instead of a dirty hack.
|
| |
|
|
|
|
|
|
|
|
| |
This splits the monolithic mp_image_swscale() function into a bunch of
functions and a context struct. This means it's possible to set
arbitrary parameters (e.g. even obscure ones without getting in the
way), and you don't have to create the context on every call.
This code is preparation for removing duplicated libswscale API usage
from other parts of the code.
|
| |
|
|
|
|
|
|
|
| |
libswscale doesn't seem to require this (anymore?), and libavfiltert's
vf_scale doesn't do it either. Moreover, this wasn't done for most other
subsampled formats, not even very old ones. So just remove it.
(It'd be quite easy to align on chroma boundaries with all pixel
formats, though.)
|
| |
|
|
|
|
|
|
|
| |
Until now, vf_scale only tried formats listed in the outfmt_list array.
Extend this and try every pixel format supported by mpv if trying
outfmt_list doesn't lead to success.
Also add some checks whether swscale really supports a given input or
output format. This was implicitly done with outfmt_list before.
|
| |
|
|
|
|
| |
ffmpeg's and the internal palette format used to have different
endianess, but that is not the case anymore. This code was forgotten
when that change was made.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I guess this code was supposed to handle cases like drawing RGBA as ARGB
by offsetting it by 1 byte.
The code didn't make any sense, though. It used to make sense before mpv
switched internal pixel formats from FourCCs to a simple enum. With the
FourCCs, "fmt | 128" selected the big endian version of a format. Of
course this doesn't work this way with the new pixel formats. It just so
happens that there are no formats with whose values match
IMGFMT_RGB32|128 or IMGFMT_BGR32|128, so this code was inactive.
All involved pixel formats seem to play fine on my setup (though it's
little endian only), and the code strictly matches the mpv pixel formats
against the format of the X image, so I'm not quite sure why this code
was there in the first place.
The original commit that added this was b333ae1 (svn 21602):
Support for different endianness on client and server with -vo x11
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Calculate the aspect ratio in vo_config, when we get the window size and in the
inside the resize function we calculate the aspect ratio of the output in order
to determine if we have to change the height or the width of the video.
If the ratio of the output is bigger than the ratio of the video then we have
to set the width accordingly and if the ratio is smaller we change the size.
But only if no resize edges are passed, because this indicates that we want to
change the windows state instead of just a simple resize and the video should
not grow bigger than the requested size.
|
| |
|
|
|
| |
I misunderstood how the different methods work and if we set the size
accordingly to the wayland configure event then METHOD_DEFAULT is what we want.
|
| |
|
|
|
|
|
|
| |
aspdat.asp is a problem, because it's updated when the VO calls
vo_get_src_dst_rects(). Nothing guarantees that the value has been
updated when the w32 code accesses it.
Instead, use the aspect vo_w32_config() was called with.
|
| |
|
|
|
|
|
| |
The previous commit fixed Libav git, but it was still broken on
Libav 9.8.
Also, while we're at it, add a note to lavc_dr1.c and its status.
|
| |
|
|
|
|
| |
Much has been said about this topic, we don't need to say even more.
See additions to options.rst.
|
| |
|
|
|
|
| |
This is probably going to be unused, but might help with debugging and
such. It returns the image parameters as determined by the video
decoder.
|
| |
|
|
|
|
|
|
|
|
| |
Guess the colorspace directly in mpcodecs_reconfig_vo(), instead of in
set_video_colorspace(). The difference is that the latter function just
makes the video filter chain (and VOs) force the detected colorspace,
and then throws it away, while the former is a bit more general and
central. Not really a big difference and it doesn't matter much in
practice, but it guarantees that there is no internal disagreement about
the colorspace.
|
| |
|
|
|
| |
Slightly cleaner, although rather redundant. But still, why wasn't this
added 10 years ago?
|
| |
|
|
| |
Slightly cleaner.
|
| |
|
|
| |
This probably has more potential for breakage than it would be of use.
|
| |
|
|
| |
This actually handles XYZ too.
|
| |\
| |
| |
| |
| |
| |
| |
| | |
The merged branch doesn't actually just remove old demuxers, but also
includes a branch of cleanups and some refactoring.
Conflicts:
stream/stream.c
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This removes the dependency on DEMUXER_TYPE_* and the file_format
parameter from the stream open functions.
Remove some of the playlist handling code. It looks like this was
needed only for loading linked mov files with demux_mov (which was
removed long ago).
Delete a minor bit of dead network-related code from stream.c as well.
|
| | |\
| | |
| | |
| | |
| | |
| | | |
Conflicts:
DOCS/man/en/changes.rst
DOCS/man/en/options.rst
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Delete demux_avi, demux_asf, demux_mpg, demux_ts. libavformat does
better than them (except in rare corner cases), and the demuxers have
a bad influence on the rest of the code. Often they don't output
proper packets, and require additional audio and video parsing. Most
work only in --no-correct-pts mode.
Remove them to facilitate further cleanups.
|
| | | |
| | |
| | |
| | | |
Didn't work on Windows. Apparently, WIN32 is not set in the Makefile.
|
| | | |
| | |
| | |
| | |
| | | |
This improves the situation when moving a window from screens with different
DPIs.
|
| | |/
|/| |
|
| |\ \
| |/
|/|
| |
| | |
Conflicts:
video/out/gl_video_shaders.glsl
|
| | |\
| | |
| | |
| | |
| | |
| | | |
Conflicts:
video/out/gl_video_shaders.glsl
video/out/vo_opengl.c
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This fixes compilation with broken libcs, like on Cygwin. C99
absolutely requires long double and associated functions like expl,
even if long double is double. But newlib (used by cygwin) omits
declaration for these if long double is equivalent to double.
The extra precision is not needed here, so remove it to make life
easier for the single person using mpv with cygwin.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
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.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Making key up events implicit was sort-of a nice idea, but it's too
tricky and unreliable and makes the key lookup code (interpret_keys())
hard to reason about. See e.g. previous commit for subtle bugs and
issues this caused.
Make key-up events explicit instead. Add key up events to all VOs.
Any time MP_KEY_STATE_DOWN is used, the matching key up event must
use MP_KEY_STATE_UP.
Rewrite the key lookup code. It should be simpler and more robust now.
(Even though the LOC increases, because the new code is less "compact".)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Handling SC_MONITORPOWER doesn't seem to prevent the screen from
dimming. The recommended way to do this in Windows XP and Vista is to
call SetThreadExecutionState with ES_DISPLAY_REQUIRED. Windows 7 also
has the PowerCreateRequest/PowerSetRequest/PowerClearRequest APIs but
they're probably too complicated for this task.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Instead of sending a single event on click, send both down and up
events.
|
