The screenshot command normally converts the currently displayed video
frame to an image. Add support for an alternative screenshot mode
that is supposed to capture the real window contents. Such a
screenshot contains a possibly scaled version of the frame, the OSD,
and subtitles.
Add a default key binding Alt+s for taking screenshots in this mode.
This needs special VO support, and might not work with all VOs (this
commit does not yet contain an implementation for any VO, only the
infrastructure).
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.
RenderCallbackSPDIF might call read_buffer with NULL data. The purpose
is to drain data from the buffer when the output is muted. Add a check
to call av_fifo_drain() in this case.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34241 b3059339-0415-0410-9bf9-f77b7e298cf2
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34242 b3059339-0415-0410-9bf9-f77b7e298cf2
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.
Some demuxers do not accurately seek to a keyframe before a given
time but instead start too late. This means that precise seeks cannot
work either. Most notably the libavformat mpeg demuxer exhibits this
behavior depending on the file being played (with the internal mpeg
demuxer precise seeks don't work at all). Add new option
--hr-seek-demuxer-offset which can be used as a workaround with such
demuxers. The value of the option is subtracted from the seek target
position given to the demuxer when doing a precise seek.
Before, precise seeking only worked if there was a video stream; in
the audio-only case playback always started from the demuxer seek
position. Add code to cut away samples from the demuxer seek position
to the seek target position.
Support "no-" prefix to negate boolean suboptions in the subopt helper
(used to parse VO etc suboptions). Previously only "no" was supported,
unlike toplevel options which gained "no-" support earlier.
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.
Information about individual chapters was printed during demuxer
opening phase, and total chapter count (ID_CHAPTERS) was printed
according to mpctx->demuxer->num_chapters. When playing a file with
ordered chapters, this meant that chapter information about every
source file was printed individually (even though only the chapters
from the first file would be used for playback) and the total chapter
count could be wrong. Remove the printing of chapter information from
the demuxer layer and print the chapter information and count actually
used for playback in core print_file_properties().
Also somewhat simplify the internal chapters API and remove possible
inconsistencies.
Something like the OSD menu functionality could be useful. However the
current implementation has several problems and would require a
relatively large amount of work to get into good shape. As far as I
know there are few users of the existing functionality. Nobody is
working on the existing code and keeping it compiling at all while
changing other code would require extra work. So delete the menu code
and some related code elsewhere that's used by nothing else.
Some functionality provided by the windowing backend (such as x11,
win32) is optional. The function pointers in MPGLContext are NULL if
the functionality is not implemented. Check them before calling them,
instead of crashing. This happened at least on Windows with the
"vo_ontop" command.
The register combiner color conversion is broken and seems to use a
slightly incorrect color matrix (the image looks gray-ish). Completely
remove all code related to nVidia register combiners.
Unless you have an ancient nVidia GPU, there's no reason to prefer register
combiners over fragment shaders. Users with ancient GPUs without fragment
shader support can just use -vo xv.
Passing yuv=1 (register combiners) as sub option will print a warning and
use yuv=2 (fragment shaders) instead.
Using the ati-hack and force-pbo suboptions (both can be enabled
automatically when particular ATI drivers are detected) could lead to
segfaults due to incorrect length calculation.
The problem is that width*((bpp+7)/8) == width*(bpp+7)/8 doesn't hold
true in general. The old code used bpp/8, because bpp was always
guaranteed to be divisible by 8. When commit 20256a8a64 fixed bugs
around 10 bit pixel formats, this assumption was broken, and resulted
in out of bounds memory accesses.
Additionally, the color values that were used to clear image borders
were incorrect and showed up as pink borders on the right/bottom sides
of the video when playing 10 bit content. Make the clear value
approximately correct; the borders are still filled with a single byte
value even though formats with 9-16 bits should be cleared with 2-byte
values with the low byte 0.
This commit also contains some other minor cleanups with no functional
changes.
Now modifiers such as shift, control, and alt are handled.
Unfortunately this requires a hack to deal with a SDL quirks when combining
CTRL and a letter key.
Also add some missing key syms.
Now all windowing specific code is in gl_common.c.
init_mpglcontext() used to set dummy callbacks for non-optional windowing
callbacks. Remove these, as they only lead to confusion.
The actual work is done by the existing SDL code. This commit merely
makes it possible to explicitly select the SDL backend ("gl" alone
uses SDL only if the X11 and win32 backends are not available, while
the new "gl_sdl" always forces use of SDL).
Also disable YUV conversion method autodetection when SDL is used.
This gets rid of a temporary window that appears for a moment and is
immediately closed again. SDL can't deal with the VOFLAG_HIDDEN flag,
which is needed to create an invisible GL context (when the
autodetection is run, the video size isn't yet known to the VO, and
creating a window then resizing would cause problems with window
placement). Instead always pick the fragment program method by default
(yuv=2). This change affects the normal "gl" VO too if it chooses the
SDL backend.
Apparently this is fully redundant given the global "noaspect" option.
Refuse this suboption, and output an error message suggesting the
correct option.
Reformat vo_gl.c, gl_common.c, gl_common.h.
Remove all global variables and move them into a context struct (the
Windows and SDL backends still refer to global_vo though).
Change vo_gl.c to use the "new" VO API.
Delete the vo_gl2 and vo_matrixview implementations.
vo_gl2 was barely useful anymore. It was a hack based on an old
vo_gl.c version, and all it did differently was rendering the video in
tiles instead of using a single texture. That made it work with some
crappy OpenGL implementations. These days all GPUs support textures of
at least 2048x2048 pixels, which is enough for HD playback. On the
other hand, gl2 suffered from various bugs and deficiencies, all of
which are fixed in gl. Its existence also confused users; many thought
that gl2 is the next version of gl and attempted to use it, even
though it's much worse than gl and they should have used that instead.
Should it turn out that tiling is actually useful, it should be
implemented in vo_gl, instead of keeping vo_gl2 alive.
vo_matrixview was a toy that couldn't even properly display a video.
All it did was display a screensaver-like animation that showed "a
Matrix-like running-text effect". (mplayer is not a screensaver.)
After commit 75eab4f72a ("video, options: implement better YUV->RGB
conversion control"), libvo/csputils.c symbols are required by core
code. However, the file was still only compiled if GL was enabled,
causing a build failure with GL disabled. Fix by making csputils.c
compilation unconditional.
Demux_demuxers checked a pts value against 0 to see if it was unset,
but other code uses MP_NOPTS_VALUE for that now. As a result audio and
subtitle streams could seek to a large negative position (effectively
to 0) instead of the correct target position. This broke --audiofile;
the --initial-audio-sync code could compensate for wrong demuxer seek
up to 5 minutes from the start of the file, masking the bug, but
seeking further than that audio would seek to 0 instead.
Note that the current --audiofile implementation using the
demux_demuxers wrapper is a fundamentally unsound design and still not
expected to generally work properly even after fixing this particular
problem.
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.
Libav stopped automatically filling missing codec_tag field for raw
codecs based on pix_fmt in libav commit bb416bd68c ("lavf: do not set
codec_tag for rawvideo"). This broke demux_lavf for raw video in
formats like YUV4MPEG, as the video format was not exported from
demux_lavf in any form (the information only existed in the pix_fmt
field of the struct AVCodecContext from libavformat, and that is not
exported). Add an explicit call to avcodec_pix_fmt_to_codec_tag() to
set the codec tag again so that selecting the correct raw decoder
based on the tag works.
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.
vo_gl.c hardcoded the assumption that YUV formats always use 1 byte per
component. This corrupted the output when playing 10 bit h264 video.
Only the PBO code path was affected. PBOs are normally unused, unless ATI
is detected, or the force-pbo option is used.
getch2.c read data into a "char" array, and returned values other than
escape sequences directly from there. This meant that it could return
negative values (except on platforms where "char" is unsigned) if the
input contained bytes >= 128. This would break later parsing in
input.c as the values would be interpreted as having the MP_KEY_DOWN
flag set, which would make the key binding code think a key is held
down (and never released). Fix by changing the buffer type to unsigned
char.
The bug itself was very old, but started triggering visible breakage
more easily after commit 82b8f89bae ("input: rework event reading and
command queuing"). Before that the key values would be passed through
the input.c "key read function" interface, which (mis)interpreted the
negative values as errors from the function, and in most cases
discarded them without much visible effect.
Libass has its own BiDi handling now, and preprocessing the subtitles
with FriBiDi before passing them to libass breaks things. Disable our
own FriBiDi code when libass rendering is used. This affects external
subtitle files of other formats parsed with subreader.c and converted
to ASS tracks.
Set the "Style" attribute for subtitle events created in sd_ass to
match the "default_style" attribute of the track. This is required to
make --ass-styles work with recent libass versions (otherwise the
event would use style 0, which is a fallback style added by libass
now).
Commit 378ada847c ("sub/ass: use default
style, not first style unconditionally") fixed the same issue for
external subtitles converted with mp_ass_read_subdata(); this commit
fixes it for muxed ones.
The last libpostproc major version change from 51 to 52 changed the
type of the "pp_help" symbol from a pointer to help text to the help
text itself. This made --pphelp crash. Change the option definition to
match the new type. This probably makes it crash if compiled against
older libpostproc, but the option is not important enough to try
supporting that (I've seen no reports of the crash, probably people
just don't use the option).
Add functionality to mark options that depend on features disabled at
compile time as disabled rather than not compiling the option
definitions at all. This allows printing a warning about the option
not being available because of a disabled feature, instead of just
"unknown option". Because the option definitions are still compiled
fully, this only works for definitions that do not reference symbols
which are not available if the feature is disabled. Use the new
functionality for options depending on libass.
1916b95b8 changed two function types from returning "void" to
returning "int", but was missing changes to add "return 0;" to the
functions. Fix.
The reason for the change in the original commit was that the
functions were called through a function pointer returning int anyway,
so the missing return probably made things no more likely to fail at
runtime than they were before that commit. However, it caused a
compilation failure with clang, which treats non-void function not
returning a value as a fatal error (in GCC it's just a warning).
wm4
reimar
Zongyao Qu
Uoti Urpala