| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
In init_vo(), if sh->aspect is 0 or last_sample_aspect_ratio is set,
sh->aspect is overwritten. With software decoding fallback behaviour,
this makes the aspect ratio from container ignored since
last_sample_aspect_ratio is already set in first try with hardware
decoding.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The --deinterlace option does on playback start what the "deinterlace"
property normally does at runtime. You could do this before by using the
--vf option or by messing with the vo_vdpau default options, but this
new option is supposed to be a "foolproof" way.
The main motivation for adding this is so that the deinterlace property
can be restored when using the video resume functionality
(quit_watch_later command).
Implementation-wise, this is a bit messy. The video chain is rebuilt in
mpcodecs_reconfig_vo(), where we don't have access to MPContext, so the
usual mechanism for enabling deinterlacing can't be used. Further,
mpcodecs_reconfig_vo() is called by the video decoder, which doesn't
have access to MPContext either. Moving this call to mplayer.c isn't
currently possible either (see below). So we just do this before frames
are filtered, which potentially means setting the deinterlacing every
frame. Fortunately, setting deinterlacing is stable and idempotent, so
this is hopefully not a problem. We also add a counter that is
incremented on each reconfig to reduce the amount of additional work per
frame to nearly zero.
The reason we can't move mpcodecs_reconfig_vo() to mplayer.c is because
of hardware decoding: we need to check whether the video chain works
before we decide that we can use hardware decoding. Changing it so that
this can be decided in advance without building a filter chain sounds
like a good idea and should be done, but we aren't there yet.
|
|
|
|
|
|
| |
Problem: I own the buffer and I destroyed while still being displayed.
Solution: Add a temporary buffer and destroy it when the next buffer is
attached.
|
|
|
|
| |
These messages are only helpful when debugging.
|
| |
|
| |
|
|
|
|
|
|
|
| |
This reverts commit beab54506e61bc080880e827e351439f76542e68.
Conflicts:
video/out/wayland_common.c
|
| |
|
| |
|
|
|
|
|
| |
Have to deal with some dumb stuff in LittleCMS2's API: its error handler
is global.
|
|
|
|
| |
Hopefully this works on Wayland and Cocoa, which I didn't test.
|
|
|
|
|
| |
Doesn't touch some parts, like the X11 error handler (which doesn't
allow setting a context pointer).
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is mostly related to the fullscreen behaviour. cecbd8864 introduces an
option to make mpv behave like a OSX user would expect. This commit changes
the Cocoa parts of the code to be consistent with the behaviour on X11. Old
behaviour is still available through the option mentioned in cecbd8864.
There is still custom logic in the cocoa backend and it can probably be moved
to core:
* Don't perform autohide if the mouse is down
* Don't perform autohide outside of the video window
Fixes #218 (by accident)
|
|
|
|
|
| |
The previous error message were not very usefull.
Also include a hint where to look for solutions.
|
| |
|
|
|
|
| |
The previous method would break on the next release. Because I am stupid.
|
|
|
|
| |
I have no idea why it exists, as it's redundant to --(no-)mouse-movements.
|
|
|
|
|
|
|
|
|
| |
icon_size is the number of array items of type long, not bytes. Change
the type of icon_size to int, because size_t makes you think of byte
quantities too quickly.
As an unrelated change, change the (char *) cast to (unsigned char *),
because it matches the common XChangeProperty idiom better.
|
|
|
|
|
| |
For the time being there will be a check if someone uses wayland from git,
because I really really like to have the others formats too.
|
|
|
|
|
| |
This was added in the past to prevent a deadlock, but is not needed
anymore.
|
|
|
|
|
| |
Just because everything is in a single file it doesn't excuse us to have high
coupling between C and ObjC code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The png file added to etc/ are taken from the link mentioned in commit
303096b, except that they have been converted to 16 bit, sRGB (with
color profile info dropped, if there was one), and transparent pixels
reset for better compression.
The file x11_icon.bin is generated by gen-x11-icon.sh. I'm adding it to
the git repo directly, because the script requires ImageMagick, and we
don't want to make building even more complicated.
The way how this is done is basically a compromise between effort
required in x11_common.c and in gen-x11-icon.sh. Ideally, x11_icon.bin
would be directly in the format as required by _NET_WM_ICON, but trying
to write the binary width/height values from shell would probably be a
nightmare, so here we go.
The zlib code in x11_common.c is lifted from demux_mkv.c, with some
modifications (like accepting a gzip header, because I don't know how to
make gzip write raw compressed data).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the mpv window is unfocus, clicking on the OSC should focus the
window (done by the window manager) and allow interaction with the OSC.
But somehow X sends a spurious LeaveNotify event, immediately followed
by an EnterNotify event. This happens at least with IceWM. The result is
that the OSC will disappear (due to receiving MOUSE_LEAVE). The OSC will
stay invisible, because EnterNotify isn't handled, and there's nothing
that could make the OSC appear again.
Solve this by handling EnterNotify. We cause a redundant MOUSE_MOVE
event to be sent, which triggers the code to make the OSC visible. We
have to remove the code from input.c, which ignores redundant mouse move
events.
Since the code ignoring redundant mouse move events is still needed on
Windows, move that code to w32_common.c. The need for this is documented
in the code, also see commit 03fd2fe. (The original idea was to save
some code by having this code in the core, but now it turns out that
this didn't quite work out.)
|
|
|
|
|
|
|
|
| |
These keys can be found on various "multimedia" and "internet" keyboard.
X defines many keycodes, so I'm not adding all, just what I found on my
own keyboard.
Other key codes can be added on request.
|
|
|
|
|
|
| |
Generate a mouse down event on the first click so that one can interact
with the OSC directly as opposed to wasting the first click in order to focus
the window.
|
|
|
|
|
| |
This is really only important with the OSC and makes the tracking code behave
more consistently with the X11 one.
|
| |
|
|
|
|
|
|
|
|
| |
This probably has been broken since bbc865a: a test was added that uses
a FBO, but it's always run, even if FBOs were not detected. On the other
hand, fbotex_init() just runs into an assert. Fix the test that
triggered this condition, and make fbotex_init() "nicer" by just failing
if FBOs are not available.
|
|
|
|
| |
Use a linked list for all supported formats and make the format table const.
|
| |
|
|
|
|
| |
A cocoa bug doesn't allow to do otherwise. Will open a radar later.
|
|
|
|
| |
This was more problematic than useful ([vo/wayland/wayland])
|
|
|
|
|
|
| |
Make use of opaque regions on non-alpha formats. This allows the compositor to
improve the drawing of the surface, because he can discard everything behind
the window when drawing.
|
|
|
|
|
|
|
|
|
| |
Odd video sizes if pixel formats with chroma subsampling and PBOs were
used, garbage was rendered. This was because the PBO path created
buffers with an unpadded size, and then tried to upload a padded
image to it. Fix it by explicitly setting the padded size. (As with
the non-PBO path, we rely that image allocations are somehow padded,
which is normally the case.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
The obtained information from the shm listener isn't used by anything and is
also wrong now in wayland git master branch because of new shm formats which
need a different way of saving the supported formats.
|
|
|
|
|
|
|
|
|
| |
Moves a good chunk of the resizing code to wayland_common.c. This makes it
possible to share it with future video drivers.
It doesn't resizit it immediatly, it calcutlates the new position and size and
then shedules a resizing event. This removes the ugly callback and void pointer
from the wayland data structure.
|
|
|
|
|
| |
In the previous commit I wrongly used params->d_h/d_w which happened to work
by chance.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The current code uses GL_YCBCR_422_APPLE texture format. This allows to handle
transparently the conversion to RGB but always use BT.601 colormatrix [1].
Hopefully I can adapt gl_video to take CVPixelBuffers soon so that `vo=opengl`
can be used instead of `vo=corevideo` with `hwdec=vda`
[1]: http://www.opengl.org/registry/specs/APPLE/ycbcr_422.txt
http://www.opengl.org/registry/specs/APPLE/rgb_422.txt
|
|
|
|
|
|
|
|
|
|
| |
Regression since 18b6c01d92. That commit changed the colorspace handling to
always reinit the video output. Since the CVPixelBuffers are lazily created,
VOCTRL_SET_YUV_COLORSPACE was always called when the CVPixelBufferRef was NULL.
Since CoreVideo functions do not complain when called on NULL, no one noticed
that CVBufferSetAttachment, which stored the color matrix meta data was called
on NULL.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
mp_image_set_params() doesn't check whether the colorspace parameters
are consistent (e.g. setting YUV colorspaces with RGB formats), and
shouldn't need to.
|
|
|
|
|
| |
Also add a note to mp_msg.h, since it might be not clear which of the
two mechanisms is preferred.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
cocoa_common contains some locking calls to support video outputs that support
live resizing (at this moment only vo=opengl).
These should not be used unless the VO declares it is multithreaded by
registering the resize_redraw callback used for live resizing.
Fixes #200
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Decoding H264 using Video Decode Acceleration used the custom 'vda_h264_dec'
decoder in FFmpeg.
The Good: This new implementation has some advantages over the previous one:
- It works with Libav: vda_h264_dec never got into Libav since they prefer
client applications to use the hwaccel API.
- It is way more efficient: in my tests this implementation yields a
reduction of CPU usage of roughly ~50% compared to using `vda_h264_dec` and
~65-75% compared to h264 software decoding. This is mainly because
`vo_corevideo` was adapted to perform direct rendering of the
`CVPixelBufferRefs` created by the Video Decode Acceleration API Framework.
The Bad:
- `vo_corevideo` is required to use VDA decoding acceleration.
- only works with versions of ffmpeg/libav new enough (needs reference
refcounting). That is FFmpeg 2.0+ and Libav's git master currently.
The Ugly: VDA was hardcoded to use UYVY (2vuy) for the uploaded video texture.
One one end this makes the code simple since Apple's OpenGL implementation
actually supports this out of the box. It would be nice to support other
output image formats and choose the best format depending on the input, or at
least making it configurable. My tests indicate that CPU usage actually
increases with a 420p IMGFMT output which is not what I would have expected.
NOTE: There is a small memory leak with old versions of FFmpeg and with Libav
since the CVPixelBufferRef is not automatically released when the AVFrame is
deallocated. This can cause leaks inside libavcodec for decoded frames that
are discarded before mpv wraps them inside a refcounted mp_image (this only
happens on seeks).
For frames that enter mpv's refcounting facilities, this is not a problem
since we rewrap the CVPixelBufferRef in our mp_image that properly forwards
CVPixelBufferRetain/CvPixelBufferRelease calls to the underying
CVPixelBufferRef.
So, for FFmpeg use something more recent than `b3d63995` for Libav the patch
was posted to the dev ML in July and in review since, apparently, the proposed
fix is rather hacky.
|
|
|
|
|
|
|
|
|
|
|
| |
Regression since ff3b98d11c. The window positioning code relied on the
visibleFrame's height without taking into account the dock's presence.
Also moved the constraining code to the proper method that overrides the
original NSWindow behaviour. This avoids having to check for border since the
constraining is performed by Cocoa only for titled windows.
Fixes #190
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using -vf eq and changing brightness, contrast, etc. using key bindings
with e.g. "add brightness 1" didn't work well: with step width 1, the
property gets easily "stuck". This is a rounding problem: e.g. setting
gamma to 3 would actually make it report that gamma is set to 2, so
the "add" command will obviously never reach 3 with a step width of 1.
Fix this by storing the parameters as integers.
This was broken in cac7702. This commit effectively changed these
properties to use the value as reported by vf_eq, instead of the
previously set value for the "add" command. This was more robust,
but not very correct either, so we keep the new behavior and make
vf_eq report its parameters more accurately.
|
|
|
|
|
|
| |
The display, window, keyboard and cursor structures are now cleanly and
logically separated. Also could prevent a future bug where no shm format is set
when the cursor image is loaded (Never happened until now).
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
|
|
| |
This option allowed you to extend the range of the panscan controls, so
that you could essentially use it to scale the video. This will be
replaced by a separate option to set the zoom factor directly.
|
|
|
|
|
|
|
| |
Now the code does the same as the original MPlayer VAAPI patch, instead
of trying to map the profiles exactly.
See previous commit for justification and discussion.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, do what MPlayer did all these years. It worked for them, so
there's probably no reason to change this.
Apparently fixes playback with some files, where the VDPAU decoder does
not formally support a profile, but decoding works with a more powerful
profile anyway.
Though note that MPlayer did this because it couldn't do it in a better
way (no decoder reported profiles available when creating the VDPAU
decoder), so it's not entirely clear whether this is a good idea. An
alterbative implementation might try to map the profiles exactly, and
do some fall backs if the exact profile is not available. But this
hack-solution works too.
|