Timeline handling converted the pts values from demuxed subtitles to
timeline scale. Change the code to do most subtitle handling in
original subtitle source pts, and instead convert current playback
timeline pts to those units when deciding which subtitle to show.
The main functionality changes are that now demuxed subtitles which
overlap chapter boundaries are handled correctly (at least for libass
subtitles), and external subtitles are assumed to use same pts scale
as current source (this needs improvements later).
Before, a video subtitle that had a duration continuing past the end
of the chapter would continue to be shown for the original duration,
even if the chapter ended and playback switched to a position in the
source where the subtitle shouldn't exist. Now, the subtitle will
correctly end.
Before, external subtitle files were interpreted as specifying pts
values in timeline scale. Now, they're interpreted as specifying pts
values in source file time scale, for _every_ source file. This is
probably more likely to be what the user wants for the "main" source
file in case there is one, but almost certainly not quite right for
multiple source files where the same subs could be shown over
different scenes. If the user wants them to match some main source
file, it's probably still better to have incorrect extra subs for
video from some files than to have every subtitle appearing at the
wrong time. The new code makes it easier to change the interpretation
of the subtitle times, and some configurability should be added in
the future.
Windows uses a legacy codepage for char* / runtime functions accepting
char *. Using UTF-8 as the codepage with setlocale() is explicitly
forbidden.
Work this around by overriding the MSVCRT functions with wrapper
macros, that assume UTF-8 and use "proper" API calls like _wopen etc.
to deal with unicode filenames. All code that uses standard functions
that take or return filenames must now include osdep/io.h. stat()
can't be overridden, because MinGW-w64 itself defines "stat" as a
macro. Change code to use use mp_stat() instead.
This is not perfectly clean, but still somewhat sane, and much better
than littering the rest of the mplayer code with MinGW specific hacks.
It's also a bit fragile, but that's actually little different from the
previous situation. Also, MinGW is unlikely to ever include a nice way
of dealing with this.
Some of the code, especially the dshow and windows codec loader parts,
are extremely hacky and likely full of bugs. The goal is merely getting
rid of warnings that could obscure more important warnings and actual
bugs, instead of fixing actual problems. This reduces the number of
warnings from over 500 to almost the same as when compiling on Linux.
Note that many problems stem from using the ancient wine-derived
windows headers. There are some differences to the "proper" windows
header. Changing the code to compile with the proper headers would be
too much trouble, and it still has to work on Unix.
Some of the changes might actually break compilation on legacy MinGW,
but we don't support that anymore. Always use MinGW-w64, even when
compiling to 32 bit.
Fixes some warnings in the win32 loader code on Linux too.
libpostproc has been removed from Libav and the library now exists as
a separate project. Because it's not essential, separate it from the
Libav library check and allow compiling without it.
The vd_ffmpeg decode() function returned without doing anything if the
input packet had size 0. This meant that flushing buffered frames at
EOF did not work. Remove this test. Have the core code skip such
packets coming from the file being played instead (Libav treats
0-sized packets as flush signals anyway, so better assume such packets
do not represent real frames with any codec).
Libav has changed back to not modifying avctx->has_b_frames based on
the extra buffering caused by thread use. Add back the code to do the
adjustment on the player side once again.
The timing mode using the buffering info is no longer the default, so
in most cases having this right or not won't matter for playback.
Remove the private bswap and intreadwrite.h implementations and use
libavutil headers instead.
Originally these headers weren't publicly installed by libavutil at
all. That already changed in 2010, but the pure C bswap version in
installed headers was very inefficient. That was recently (2011-12)
improved and now using the public bswap version probably shouldn't
cause noticeable performance problems, at least if using a new enough
compiler.
Change various code to use the latest Libav API. The libavcodec
error_recognition setting has been removed and replaced with different
semantics. I removed the "--lavdopts=er=<value>" option accordingly,
as I don't think it's widely enough used to be worth attempting to
emulate the old option semantics using the new API. A new option with
the new semantics can be added later if needed.
Libav dropped APIs that were necessary with all Libav versions
until quite recently (like setting avctx->age), and it would thus not
be possible to keep compatibility with previous Libav versions without
adding workarounds. The new APIs also had some bugs/limitations in the
recent Libav release 0.8, and it would not work fully (at least some
avcodec options would not be set correctly). Because of those issues,
this commit makes no attempt to maintain compatibility with anything
but the latest Libav git head. Hopefully the required fixes and
improvements will be included in a following Libav point release.
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.
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).
Uoti Urpala
wm4
harklu