Adding these flags improves the quality of the YUV->RGB conversion when
screenshots are taken. It trades precision for performance.
This doesn't affect any other swscale uses, such as vf_scale or vo_x11.
Based on a patch by cantabile. Fixes#140.
This simplifies the code. It also can make loading of mkv files faster, as
initializing two ASS_Render instances required scanning mkv font
attachments twice.
Libav started automatically enabling threaded decoding a while ago.
This is not safe, as it means callbacks can suddenly get called from
other threads and outside calls to libavcodec. We need to know when
threading will be used and disable thread-unsafe callbacks in those
cases. Explicitly set thread count to 1 instead of leaving it at 0
(which triggers the autodetection) when we are not requesting more
threads; this should make sure that autodetection on libavcodec side
will not be used.
This patch adds a "size" parameter, which scales the filter radius
according to movie diagonal, the unit being percent of diagonal.
This makes the effect far more predictable across movies of different
resolutions.
Usage example (with possibly useless values):
-vf gradfun=strength=1.2:size=2.3
Based on a patch by Radosław Szkodziński <astralstorm@gmail.com>
Update various code using Libav libraries to remove use of API
features that were deprecated at Libav release 0.7. I think this
removes them all with the exception of URLContext functions still used
in stream_ffmpeg.c (at least other uses that generated deprecation
warnings with libraries from 0.7 are removed).
Require versions of the Libav libraries corresponding to Libav release
0.7. These are:
libavutil 51.7.0
libavcodec 53.5.0
libavformat 53.2.0
libswscale 2.0.0
libpostproc 52.0.0
Also disable the fallback to simple header check if these libraries
could not be found with pkg-config; now compiling without pkg-config
support for these always requires explicitly setting --enable-libav
and any needed compiler/linker flags. The simple check would have let
compilation proceed even if a version mismatch was detected.
Using the "expand" filter makes the image area larger by adding
borders to the video frame. These borders are supposed to be always
black. The filter relied on the borders in its output buffer staying
black without redrawing them for each frame. However, when using
direct rendering, a video filter inserted after vf_expand can draw
into these borders, for example the "unsharp" and "ass" filters. These
changes incorrectly stayed visible in the the following video frames.
Fix this by always clearing the borders in vf_expand. In some cases,
this might be more work than necessary, but vf_expand has no way of
detecting whether a subsequent filter draws into the borders or not,
and this avoids fragile assumptions about the existing contents of the
output buffer(s).
This also deals with frame size changes when config() is called again.
Before this commit, remains of the old video were visible if the new
video frame size was smaller than before.
Since we now always clear the borders, there's no more need for the
complicated code that cleared only the regions that were covered by the
OSD. Delete that.
When config() is called multiple times (e.g. aspect ratio changes
while the same file is playing), the user settings are not honoured,
because config() overwrites them. Don't do that.
This fixes a crash with vo_gl when the switch_ratio slave command is used
while a displaying an animated subtitle. switch_ratio will cause a config()
call to vo_gl, which will reset all state, including the EOSD state. Next
time the EOSD is rendered, its change detection will indicate that only
subtitle positions have changed. The render code will attempt to access
the EOSD data structures which have been deleted with config().
Fix this by forcing the change detection to indicate a full change if
config() has been called.
This only happens when doing switch_ratio with vo_gl, and the current
subtitle is only changing positions, i.e. mp_eosd_images_t.changed == 1.
This affects only the "new" VO API. The config() title argument was barely
used, and it's hardcoded to "MPlayer" in vf_vo.c. The X11 and the Cocoa
GUI backends, which are the only ones properly supporting window titles,
ignored this argument. Remove the title argument.
Add the vo_get_window_title function. All GUI VOs are supposed to use it
for the window title.
Avoid calling avcodec_close() in uninit() if avcodec_open() failed.
Calling avcodec_close() on a non-open codec context causes a crash
with recent Libav versions.
Previously the core sent VFCTRL_REDRAW_OSD to change OSD contents over
the current frame. Change this to VFCTRL_REDRAW_FRAME followed by
normal EOSD and OSD drawing calls, then vo_flip_page(). The new
version supports changing EOSD contents for libass-rendered subtitles
and simplifies the redraw support code needed per VO. vo_xv doesn't
support EOSD changes because it relies on vf_ass to render EOSD
contents earlier in the filter chain.
vo_xv logic is additionally simplified because the previous commit
removed the need to track the status of current and next images
separately (now each frame is guaranteed to become "visible" soon
after we receive it as "next", with no VO code running in the interval
between).
Add a VO command (VOCTRL_SCREENSHOT) which requests a screenshot
directly from the VO. If VO support is available, screenshots will be
taken instantly (no more 1 or 2 frames delay). Taking screenshots when
hardware decoding is in use will also work (vdpau). Additionally, the
screenshots will now use the same colorspace as the video display.
Change the central MPContext to be allocated with talloc so that it
can be used as a talloc parent context.
This commit does not yet implement the functionality for any VO (added
in subsequent commits).
The old screenshot video filter is not needed anymore if VO support is
present, and in that case will not be used even if it is present in
the filter chain. If VO support is not available then the filter is
used like before. Note that the filter still has some of the old
problems, such as delaying the screenshot by at least 1 frame.
The implementation of the switch_ratio command was hacky and called
mpcodecs_config_vo() to reconfigure the filter/VO chain from under an
existing decoder. This call no longer worked properly with vd_ffmpeg
after that started using mpcodec_config_vo2(). Add new video decoder
control command VDCTRL_RESET_ASPECT and use this to tell vd_ffmpeg to
reinitialize the output chain properly.
When not using direct rendering, vd_ffmpeg created an mp_image struct
before calling libavcodec decoder, so that possible slice support
could be checked from the mpi_image and output would be ready for
slice-drawing calls. However, this behavior is unsound with decoders
that can change output size, as the parameters can change after the
mp_image was created. Disable the code creating the mp_image at that
point, which also disables use of slices in this case. Slices are
disabled with threading anyway, so I think trying to add workarounds
to support them is not a high priority.
I think this code has always been buggy, but before common thread use
it was rarely executed because the direct-rendering case was used
instead.
Codec selection for audio and video decoding had a "dynamic plugin"
feature that tried to load a shared library for any codec that had not
been enabled at compilation (disabled by default, but could be enabled
with --enable-dynamic-plugins configure switch; for unknown reasons
some distro packages have enabled it). The implementation was buggy
and could cause normal codec selection fallback to fail if the feature
was enabled. I'm not aware of any real uses of such dynamic plugins
and the feature seems questionable anyway (there are no ABI guarantees
that would make it safe to use). Remove the buggy feature.
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
ad_ffmpeg init() function did not free resources if opening failed.
Outside code (dec_audio.c) does not automatically call uninit() if
init() returns failure, and the uninit function would have crashed in
some cases had it been called (it did freed lavc_context->extradata,
but lavc_context could have been NULL after early init failure). Add
explicit calls to uninit() after failure and make uninit function safe
to call at any point.
At least the libavcodec WavPack decoder can return output for an audio
frame in multiple parts and return 0 bytes input consumed for the
initial parts. Timing info was not set correctly in this case:
sh_audio->pts and pts_bytes were reset each time when decoding more
from the packet, as if the packet had been new (ds_get_packet_pts()
has a check to return MP_NOPTS_VALUE if the packet has already been
partially read, but that didn't trigger since libavcodec returned
exactly 0 bytes read so the demuxer-visible packet state didn't
change).
Add a field to keep track of whether a packet has already been decoded
from, and don't reset timing info again if so. Adding the field
requires adding a decoder context to store it (there wasn't one
before).
BTW the WavPack decoder behavior and avcodec_decode_audio3()
documentation don't match - the documentation says the return value is
"zero if no frame data was decompressed (used) from the input
AVPacket", while the decoder DOES return some frame data which comes
from the input packet.
Pass the libavformat packet side_data field from demux_lavf to
vd_ffmpeg. Libavcodec/libavformat use this field for palette data, and
passing it is required for the playback of some paletted video codecs.
The implementation works by giving vd_ffmpeg a copy of the struct
demux_packet used to store the video packet (from which it can access
the avpacket field). The definition of struct demux_packet is moved to
new file demux_packet.h so that vd_ffmpeg.c can use it without
including all of demuxer.h.
vf_screenshot checked for a list of pixel formats that were known to
work with swscale. However, the list was incomplete. If a pixel format
was used that was not on the vf_screenshot list, but was supported
both by swscale and the VO driver, mplayer2 would insert a useless
scale filter to convert to a format supported by vf_screenshot. Fix
this by making vf_screenshot check directly whether the pixel format
is supported by swscale with sws_isSupportedInput().
Add option --ass-vsfilter-aspect-compat and corresponding property
ass_vsfilter_aspect_compat. The setting controls whether to enable the
emulation of traditional VSFilter behavior where subtitles are
stretched if the video is anamorphic (previously always enabled for
native SSA/ASS subtitles). Enabled by default. Add 'V' as a new
default keybinding to toggle the property.
Libass rendering uses two renderer objects to support both VSFilter
aspect ratio (mis)behavior emulation and correct rendering. When
option values were changed during playback the changes were applied to
the renderer used for the currently active track only, and old values
could be used if the user then switched to a track using the other
renderer object. Fix to update both renderers.
Recent commit 5d5ca22a6d ("options: commandline: accept --foo=xyz
style options") left some bad code under "#ifdef MP_DEBUG" in
playtree.c, which caused a compilation failure if configured with
"--enable-debug". Fix this. Having the "#ifdef MP_DEBUG" there was
completely unnecessary; it only increased the risk for this kind of
problems for no real benefit - executing the asserts under it would
have no noticeable performance or other penalty in default builds
either. Remove several cases of such harmful "#ifdef MP_DEBUG".
Do the global initialization of libavcodec and libavformat
(avcodec_register_all(), av_register_all()) immediately on program
startup and remove the initialization calls from various individual
modules that use libavcodec/libavformat functionality.
Libavutil eval API seems to be enough for vf_qp, so enable the filter
if the API is available. Also clean up some left over lines for other
filters in Makefile.
Commit aba8a1838a which added 9- and 10-bit formats failed to change
the definition of the IMGFMT_IS_YUVP16() macro (which is misnamed btw,
it matches 9, 10 and 16 bits). This prevented vo_gl from accepting
input in supported 9 and 10 bit colorspaces. Fix.
Remove the copy of the "lowres" field that vd_ffmpeg kept in its
private struct and use the value from AVCodecContext directly instead.
The copy gave no benefit and it could be set to the wrong value if
someone used "-lavdopts o=lowres=X" (which would change the real value
but not the copy).
Support for -lavdopts skipframe had been broken since commit bc767c2a9
as framedrop logic now set the same field and thus overwrote the value
set from the option. Change that code to set it to the original value
instead of 0 when not dropping frames.
