| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Add libswscale includes where they are actually needed instead.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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.
|
| |/
|
|
|
| |
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.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Also, implement mouse leave events for X11. But evne on other
platforms, these events will be generated if mouse crosses a section's
mouse area boundaries within the mpv window.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In fullscreen `s->window` is the windowed window. So freeing that didn't get
rid of the FS window and OpenGL view.
Fixes #122
[ci skip]
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Use the video decoder chroma location flags and render chroma locations
other than centered. Until now, we've always used the intuitive and
obvious centered chroma location, but H.264 uses something else.
FFmpeg provides a small overview in libavcodec/avcodec.h:
-----------
/**
* X X 3 4 X X are luma samples,
* 1 2 1-6 are possible chroma positions
* X X 5 6 X 0 is undefined/unknown position
*/
enum AVChromaLocation{
AVCHROMA_LOC_UNSPECIFIED = 0,
AVCHROMA_LOC_LEFT = 1, ///< mpeg2/4, h264 default
AVCHROMA_LOC_CENTER = 2, ///< mpeg1, jpeg, h263
AVCHROMA_LOC_TOPLEFT = 3, ///< DV
AVCHROMA_LOC_TOP = 4,
AVCHROMA_LOC_BOTTOMLEFT = 5,
AVCHROMA_LOC_BOTTOM = 6,
AVCHROMA_LOC_NB , ///< Not part of ABI
};
-----------
The visual difference is literally minimal, but since videophiles
apparently consider this detail as quality mark of a video renderer,
support it anyway. We don't bother with chroma locations other than
centered and left, though.
Not sure about correctness, but it's probably ok.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
A redraw forces recalculation of panscan and other stuff not accounted for in
the resize_redraw codepath. This is actually a hack but works really well in
my tests.
Thanks @wm4 and @Cpuroast for the idea.
Fixes #86
[ci skip]
|
| |\ \ \
| | | |
| | | |
| | | | |
...the return.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Seems like a completely unnecessary complication. Instead, always add a
1 byte padding (could be extended if a caller needs it), and clear it.
Also add some documentation. There was some, but it was outdated and
incomplete.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Recent work in the OS X parts of the code started using clang's support for
Obj-C's support for Literals and Subscripting. These particular language
features remove a lot of boilerplate code and allow to interact with
collections as consicely as one would do in scripting languages like Ruby or
Python.
Even if these are compiler features, Subscripting needs some runtime support.
This is provided with libarclite (coming with the compiler), but we need to
add the proper method definitions since the 10.7 SDK headers do not include
them. That is because 10.7 shipped before this language features.
This will cause some warnings when compiling with the 10.7 SDK because the
commit also redefines BOOL to make autoboxing/unboxing of BOOL literals to
work.
If you need to test this for whatever reason on 10.8, just pass in the correct
SDK to configure's extra cflags:
./configure --extra-cflags='-mmacosx-version-min=10.7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk'
Fixes #117
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Doing this makes the encoder force the same pict type as original, which
is often not even possible. Rather let the codec decide!
As there is no documented value to mean "decoder shall pick", I rather
save/restore the default value filled by libavcodec.
|
| |/ / / |
|
| | | | |
|
