| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
mp_get_chroma_shift() modifies its argument even if it fails, so we have
to restore that.
mp_image didn't set chroma shifts for yuy2.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes awkward framestepping when seeking with -vo null while paused
(caused because seeking by default draws an OSD bar, and mplayer trying
to redraw the OSD in that case; this logic is actually needed with
vo_xv).
It would have been simpler to just check vo->driver->draw_osd (and leave
that callback to NULL for VOs which don't support OSD), but for now try
to retain the capability to let VOs decide based on the image format
whether to support OSD or not.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Normally, we can redraw the OSD any time. But some drivers don't support
OSD redrawing (vo_null etc.), or only "sometimes" (vo_xv). For that,
some additional logic is needed. Simplify that logic. This might also
fix subtle bugs with the OSD not updating or endless frame stepping in
unforseen corner cases.
Do this by adding a new flag, which tells whether the OSD should be
redrawn.
Remove some minor code duplication.
|
|
|
|
|
|
|
|
| |
Fix the "grammar" of such commands to be hopefully less confusing. Also,
add the "-" for such arguments, which skips optional arguments without
changing their default value.
Also change some mentions of "mplayer" to "mpv".
|
|
|
|
|
|
| |
The new EOSD code suffered from artifacts due to missing setup of a projection
matrix. This commit fixes the problem and uniforms the resize code to the one
driving vo_opengl_old.
|
|
|
|
|
|
|
| |
"screenshot" now maps to "screenshot subtitles" by default, instead of
"screenshot video". Swap the argument order: the more useful argument
should come first. Remove the compatibility aliases for numeric choices
(e.g. "screenshot 1 0" won't work anymore).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a new screenshot mode "subtitles", which basically takes the
video frame as decoded, and renders subtitles into it.
This may fail for some pixel formats, because libswscale sucks. If this
becomes ever a real problem, the code could be changed to convert the
image to RGBA first (or whatever the image writer wants), and then
render the subtitles into it. This would avoid the additional image
copy needed with vo_xv too. But for now, it seems better to go with the
current method in the common case: vo_opengl creates an image copy
anyway, and drawing bitmaps to yv12 is better, as no color space
conversion is involved in draw_bmp.c's up/downsampling conversion.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD,
VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT.
Remove draw_osd_with_eosd(), which rendered the OSD by calling
VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes
a callback as argument. (This basically works like the old OSD API,
except multiple OSD bitmap formats are supported and caching is
possible.)
Remove all mentions of "eosd". It's simply "osd" now.
Make OSD size per-OSD-object, as they can be different when using
vf_sub. Include display_par/video_par in resolution change detection.
Fix the issue with margin borders in vo_corevideo.
|
|
|
|
| |
If that happens, we silently fail.
|
|
|
|
| |
This caches scaled RGBA sub-bitmaps.
|
|
|
|
|
|
|
|
|
|
| |
Do this by replacing all the old vf_ass drawing code by draw_bmp.c.
Change sub.c to always use osd_draw() for the other OSD drawing
routines, and simplify the code a bit.
spudec.c subtitles (i.e. DVD subs) are now considered subtitles, and
are rendered by vf_ass, if that filter is inserted.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes that vo_xv didn't display text subtitles correctly when
using anamorphic video. It didn't pass the aspect information to the
subtitle renderer. Also, try to render OSD correctly with respect to
aspect ratio settings: on vo_xv, the OSD is rendered into the video,
and needs to be "stretched" too when playing anamorphic video. When
the -monitorpixelaspect option is used, even with VOs such as vo_opengl
the OSD has to be rendered with that aspect ratio.
As preparation for future commits, replace the weird vsfilter_scale
value with a somewhat more sensible video_par member.
Also, struct mp_eosd_res is a better place for the aspect ratio
parameters, as OSD needs this too.
Use osd_draw_on_image() directly in vo_lavc, which fixes aspect ratio
issues as well.
|
|
|
|
|
| |
When demux_demuxers was removed, and -subfile was moved to the frontend,
setting the non_interleaved for -subfile was forgotten.
|
|
|
|
|
|
|
|
| |
This is to get rid of swscale alignment warnings with the new OSD code.
Only image formats used by it are fixed.
Solving this generally would require some more effort. (Possibly by
using libav's allocation functions plus lots of testing.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just to get rid of that conversion copy&pasted from the internet.
R and G are swapped for unknown reasons. Testing various subtitles
seem to yield the same results as VLC. The sub-bitmap renderers output
the correct colors. The colorspace conversion is used without problems
for vo_gl, vo_gl3 and vo_vdpau. The problem is most likely that
apparently, the DVD palette read from the subtitle track extradata is
converted to YUV using vobsub_palette_to_yuv(), and swapped in the
process. Or in other words, the YUV colors spu->global_palette are
encoded with R and G swapped.
Add some utility definition to csputils.c/h to make converting single
color values easier.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To ease changing all the VOs to the new OSD rendering, fallbacks,
conversions, support code etc. was left all over the code. Now that
all VOs have been changed, all that code is inactive. Remove it.
Strip down spudec.c. We don't need the old grayscale and scaling stuff
anymore. (Not removing spudec itself yet - I'm not confident that the
libavcodec DVD sub decoder is sufficient, and it would also require
some hacks to get DVD palette and resolution information from libdvdread
to libavcodec.)
The option --spuaa, --spualign, --spugauss were used with the old sub
scaling code, and don't do anything anymore.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
draw_bmp.c uses libswscale, which has strict alignment requirements on
input images. Since imp_convert.c is currently the only producer of RGBA
sub-bitmaps, the overall code becomes easier if the alignment is done on
image allocation, rather than forcing draw_bmp.c to create an aligned
copy.
talloc doesn't align to 16 bytes, as required by libswscale. Apparently,
system malloc (glibc/Linux/32 bit) aligns to 8 bytes only, so talloc's
own code to align to 16 bytes is ineffective. Work around by using
mp_image to allocate the image.
|
| |
|
|
|
|
|
|
| |
We now have a simple function to get a XvImage buffer as mp_image.
Return that as screenshot. We don't even need to copy the image (we
allocate a mp_image struct only, no image data).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Aspect ratio stuff needs to be fixed later. "Fixing" the position of OSD
elements outside of the screen due to panscan needs to be added back as
well (what the removed fixup_osd_position() function did).
The amount of data needed to "backup" an image when OSD is rendered
increases. This is because we support color OSD/subtitles now. The old
code rendered into the Y plane only, while the new code touches all 3
planes. For YV12, which is probably the only format supported not
considering chroma-swapped and packed formats, 0.5 times more memory
is copied when the OSD is used in pause mode.
|
|
|
|
| |
Merged by wm4 from commits c93978f17b76 and following.
|
|
|
|
|
|
|
|
| |
The osd_draw_on_image() function renders the full OSD into the provided
image.
It uses the mp_draw_sub_bitmaps() function added in the previous commit
to do the actual work.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libswscale tends to overwrite the area between (w,y)-(0,y+1). It tries
to process multiple pixels at once, and if the memory past the last x
pixel is inside a SIMD operation, but still below the image stride, it
overwrites that data with black.
This happens with vo_x11 and 32 bit RGBA formats. The bug is visible as
black bar right of the subtitle bounding box. Fix by giving libswscale
more alignment. Then the "outside" pixels are inside, and are processed
normally instead of overwritten with black.
NOTE: we do not increase the alignment constant, because this is a
separate issue from pointer alignment. libavutil's av_malloc() wouldn't
actually satisfy the increased alignment either.
|
| |
|
|
|
|
|
| |
Merged by wm4 from commits 93978f17b76d..13211ef5fc20. Changed copyright
header in draw_bmp.c to "mpv", and removed the one in draw_bmp.h.
|
|
|
|
|
|
|
| |
Merged by wm4.
copy_mpi() assumed that planar YUV formats always used 1 byte per
component, which is not true for 9/10/16 bit YUV formats.
|
|
|
|
|
| |
Extracted/rebased by wm4 from commits 93978f17b76d..13211ef5fc20.
Actual mp_image_swscale is added in a later commit.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
Makefile
command.c
libvo/gl_common.c
libvo/vo_corevideo.m
libvo/vo_opengl.c
libvo/vo_opengl_old.c
libvo/vo_opengl_shaders.glsl
sub/ass_mp.c
sub/osd_libass.c
sub/sd_ass.c
|
| |
| |
| |
| |
| |
| |
| |
| | |
Mention the FBO format chaos.
Some other things were not entirely correct anymore.
Also update the "builtin" documentation in vo_opengl.c.
|
| |
| |
| |
| |
| | |
mp_input_feed_key() didn't free the command, if it was discarded due
to the queue exceeding its maximum size.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Reduces code needed for implementing string and int64_t read-only
properties.
Originally, there actually was a m_property_string_ro(), but it was
removed, as that would have implicitly strdup'ed the string. But the
new name m_property_strdup_ro() should make it quite clear what is
happening.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In input test mode, key bindings won't be executed, but are shown on the
OSD. The OSD includes various information, such as the name of the key,
the command itself, whether it's builtin, and the config file location
it was defined.
The input test mode can be enabled with "--input=test". No effort is
spent trying to react to key bindings that normally exit the player;
they are treated just like any other binding.
|
| |
| |
| |
| |
| |
| | |
If parsing a command fails, its location is printed. The location is
the path to the input.conf, and the line number of the key binding and
the associated input command.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Apparently libass can't be made to not interpret "\n" as escape. That
means "\n" can't be printed literally. Use the same hack that was added
to mplayer2 when that project merged osd_libass.c: add an invisible
zero-width joiner character between "\" and "n". It seems U+FEFF is
deprecated, because it has been redefined as BOM mark. Use U+2060, which
seems to be the replacement.
|
| |
| |
| |
| |
| |
| |
| | |
open_stream() and open_output_stream() checked for filename==NULL, and
if true, printed an error message asking to report this as bug.
Internal logic errors should just crash. Use assert() instead.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Clean up handling of libquvi (which resolves URLs of streaming sites
into URLs to the actual media playable by mpv). Move the code out of
open.c to quvi.c, and invoke it explicitly from mplayer.c, instead of
trying to resolve every filename passed to open_stream().
This allows easily passing metadata from the quvi context to the
frontend. Expose QUVIPROP_PAGETITLE as "media-title" property, and use
that instead of "filename" for the mplayer window title. (For YouTube,
this is the video title.) It's cleaner too.
Handle a potential reliability issue: check quvi_getprop return values.
Since open.c contains barely anything but the open_stream() stub, move
that to stream.c and delete open.c.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Always recognize input commands for optional features (like TV commands
etc.). If these features are disabled, the commands are parsed, but
simply do nothing.
This fixes annoying warnings on start with the default/builtin
input.conf, if certain optional features are not compiled.
|
| |
| |
| |
| |
| |
| |
| | |
The second scaling filter (cscale) was never reset correctly due to a
fatal oversight. In particular, this could lead to OpenGL errors, if
the new filter needs a 2D texture, but the old texture was 1D (because
init_scaler reuses the texture).
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
FFmpeg and Libav are starting to return a growing number of planar samples
when decoding formats that save data like that.
In this first implementation planar formats are immediately converted to
packed formats. Fututre developments should move to use libavresample.
Original work by Nicolas George on mplayer(1).
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Change fmt-conversion.h to include <libavutil/pixfmt.h> instead of
<libavutil/avutil.h> which no longer indirectly includes the former.
This fixes compilation with latest Libav. Also remove superfluous
config.h #include.
The pixfmt.h #include is needed for 'enum PixelFormat'. avutil.h
already stopped including pixfmt.h more than a year ago, but that did
not cause visible breakage at the time. AFAIK the C standard does not
allow incomplete enum types, but it seems that GCC and other relevant
compilers accept function declarations using not-yet-defined enum
types without warnings. However, Libav now renamed 'enum PixelFormat'
to 'enum AVPixelFormat', adding a '#define PixelFormat AVPixelFormat'
for backwards compatibility. We need this compatibility define because
we're still using the PixelFormat name, but it of course does not work
if pixfmt.h is not included; thus the missing include now caused a
compilation failure.
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
DOCS/man/en/vo.rst
etc/input.conf
input/input.c
m_property.c
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Allow the values "up" and "down" as step argument for the cycle input
command. Previously, this argument was a float, which specified an
arbitrary step value and direction (similar to the add command).
Instead of "1" and "-1", "up" and "down" is to be used.
Float values are still accepted. That capability might be removed in the
future, as there's probably hardly any actual use for arbitrary step
values.
|
| | |
| | |
| | |
| | |
| | | |
In theory, this could take over the role of the get_property slave
command, and is more general.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There are a number of options which modify ASS subtitle rendering. Most
of these do things that can interfere with the styling done by subtitle
scripts, resulting in incorrect rendering. Add the --ass-style-override
option to make it easy to disable all overrides. This helps trouble-
shooting, and makes it more practical to use the override features. (You
can simply toggle the ass-style-override property at runtime, should
one of the style override options break subtitle rendering at a certain
point.)
This mainly affects whether most --ass-* options are applied, as well
as --sub-pos. Some things, like explicit style overrides loaded with
--ass-force-style, can't be changed at runtime using the
ass-style-override property.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The --sub-pos option and sub-pos property control the vertical position
of a subtitle.
Also change how sub-pos is handled in the old subtitle renderer (used
with -no-ass). The new behavior doesn't render subtitles out of the
screen if the subtitle is located near the top screen border and has
too many lines.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Replaces the status line with a custom string.
This is probably useful for hacking old slave mode applications into
working again. Even if not, this might be generally useful.
|