| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Separate passing a new frame to VOs using the new API into two steps.
The first, vo_draw_image(), happens after a new frame is available
from the filter chain. In constrast to old behavior, now the frame is
not actually rendered yet at this point (though possible slice draw
calls can already reach the VO before). The second step,
vo_new_frame_imminent(), happens when we're close enough to the
display time of the new frame that we'll commit to flipping it as the
next action and will not change the OSD over the previous frame any
more.
This new behavior fixes a previous problem with vo_vdpau and vo_gl in
the situation where the player is paused after decoding a new frame
but before flipping it; previously changing OSD in that state would
switch to the new frame as a side effect. It would also allow an easy
way to fix extra output files produced with something like "--vo=png
--frames=1" with precise seeking, but this is not done yet.
The code now relies on a new mp_image from the filter chain staying
valid even after the vf_vo put_image() call providing it returns. In
other words decoders/filters must not deallocate or otherwise
invalidate their output frame between passing it forward and returning
from the decode/filter call.
|
| |
|
|
|
|
|
|
|
| |
Add native Cocoa code to display an OpenGL window. Some of the code is
based on the OpenGL parts of vo_corevideo but I took the time to remove
old code based on Carbon.
There is autodetection in the configure script but you can use
--enable[disable]-cocoa to enable[disable] this.
|
| |
|
|
|
|
|
|
| |
When interpreting a key event, use the "charactersIgnoringModifiers"
method of the event in order to extract Alt+key combinations while
keeping the normal meaning of "key". When the right alt modifier is
pressed use the "characters" method to allow AltGr behavior to be used
to generate different characters.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ARB shader code generated at the end of the shaders for scaling mode 4
and 5 was something like:
MAD yuv.g, b.r, {0.5}, a.r;
This appears to be semantically equivalent with:
MAD yuv.g, b.rrrr, {0.5, 0, 0, 0}, a.rrrr;
This has the consequence that the result register, yuv.g, will not contain
the value computed by the scale filter, but a.r. a.r is the unchanged
value sampled from the normal texture coordinates, so the filter did
effectively nothing and behaved as if cscale=0 was specified. The basic
mistake here is that yuv.g does not specify a single register, but it
specifies the full vector register yuv, with writing enabled on the g
channel. This means yuv.g will assigned the g channel of the the result
vector computed by the MAD instruction.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GL_LUMINANCE16 texture format had only 8 bit precision on Mesa
based drivers. This caused heavy degradation of the image when playing
formats with more than 8 bits per pixel, such as 10 bit h264. Use
GL_R16 instead, which at least Mesa and Nvidia drivers actually
implement as 16 bit textures. Since sampling from this texture format
doesn't return anything meaningful in the other color components
(unlike luminance textures), the shader code has to be slightly
changed.
GL_R16 requires the GL_ARB_texture_rg extension. Check for it, and fall
back to the old texture format if it's not available.
The low precision of the GL_LUMINANCE16 format has just been fixed in
upstream Mesa, but it'll take a while before that fix is available in
distros.
|
| |
|
|
|
|
|
|
|
| |
The shader code was generated from very long strings with lots of
format specifiers with snprintf calls. It was almost impossible to
quickly tell what variables were inserted where in the shader. Make
this more readable by implementing a kind of simple variable
substitution, which allows replacing the format specifiers in the code
templates with with variable names.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Caveat: the OSD will be included in the screenshots when the screenshot is
taken during normal playback. This doesn't happen when a screenshot is
taken while playback is paused.
Fixing this would introduce a small performance reduction during normal
playback, which is unacceptable for a possibly rarely used optional
feature.
Due to the nature of the Xv API, taking a screenshot of the scaled video
isn't possible either.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Make new_mp_image() allocate the struct with talloc and abort() if the
av_malloc for image plane data fails.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| |/
|
|
| |
Also a couple of smaller changes to other files.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Libavcodec has ignored the caller-set sub_id value since 2006.
|
| |
|
|
|
|
|
|
|
|
| |
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 20256a8a64c96 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.
|
| |
|
|
|
|
|
| |
This option enabled using Mesa specific functions, which have never been
widely supported, and were removed from Mesa in 2010.
http://cgit.freedesktop.org/mesa/mesa/commit/?id=cb2a66fd0c095fe03be5aaf88c8d48f5867425d3
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Before the SDL code would change screen resolution when switching to
fullscreen. Try to keep existing desktop resolution instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
--reuse-socket and --lavfdopts had the CONF_GLOBAL flag set. I see no
reason why they could not be set per file. Remove the flag from both
options.
|
|
