This guarantees that only subtitles are drawn. (Before this change, we
relied on the fact that OSD is only visible on user interaction, or if
explicitly request with --osd-level.)
This controlled the generation of the palette for DVD subs if no palette
was found. The option name and description is confusing, and it was
probably barely useful. Remove the option, and hardcode the behavior to
the option's default value.
The code for this option attempted to emulate the old as-documented
behavior. It wasn't very good at it, and now that the old OSD code has
been removed, it's entirely pointless.
This removes the factor 1.7 with which --subfont-text-scale was
multiplied.
Most of these cased working when the OSD was switched to libass, or
didn't do anything even before that.
Also don't recursively include subreader.h in sub.h.
Since most VOs support rendering subs directly, this doesn't change
much. Changes include: vo_null is faster, vo_image doesn't add subtitles
by default (while vo_lavc does), vo_caca doesn't render subs (but you
couldn't read them anyway).
This reflects the fact that this filter now renders all types of
subtitles, not just ASS subtitles.
Always compile this filter, not just on CONFIG_ASS.
Note that --no-ass still disables auto-inserting this filter. It's the
only way to disable auto-insertion, so keep it even though it's not
really ASS specific anymore. --no-ass also disables using libass for
rendering text subs directly.
Added screenshot capability to the corevideo VO by sending back the raw data
from the CVPixelBuffer.
Also added "screenshot window" functionality from the other OpenGL based VOs,
which uses glReadPixels to read image data back. This was moved to gl_common to
avoid duplication.
struct mp_image has two sets of size members: width/height and w/h. It's
not even sure which one of these is the ACTUAL dimension, and which is
the "stored" or "visible" dimension. vf_get_image() (a core function for
video filters) does something confusing with the sizes, and often sets
up cropped versions of other filter's image buffers. The screenshot code
uses w/h to store the display size for anamorphic video, while
width/height is the size of the pixel data. The draw_bmp.c code, as well
as sws_utils.c, always use w/h for the size of the pixel data.
It's an unholy mess, and the screenshot code potentially breaks it even
more. Work that around with a hack, until we hopefully clean up
mp_image and the video filter code.
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.
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.
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.
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.
This wasn't used anymore.
Remove the reference to IMGFMT_MJPEG in vf_dlopen as well. Thus format
is used as FourCC in the TV code (i.e. it's on the demuxer level, just
like raw formats), and never appears in the video filter chain. For
starters, vd_ffmpeg can never produce this format.
Fixes for palette allocation handling.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34304 b3059339-0415-0410-9bf9-f77b7e298cf2
This caused a crash with http://samples.ffmpeg.org/cdxl/fruit.cdxl if
direct rendering was used. (Which is rarely these days.)
With small changes: avoid av_freep() use, as this function is not sane.
The \xFF escape is used internally to insert special OSD symbols (which
need a font change to the internal OSD font). There was potential for
breakage when \xFF was followed by \0, because then "in" would be
advanced past the string's end.
Normally this can't happen, as it would require invalid UTF-8 input
data. But we don't check input for UTF-8 validness, so there's a
potential issue here. Garbled output is ok on invalid UTF-8 input,
but crashing is not.
Make it more robust by checking for this.
append_utf8_buffer() reallocates the buffer passed to it, and returns
the new pointer.
This bug was originally introduced in mplayer2 when that project merged
mpv's osd_libass.c. That merge changed some minor things, including ASS
escape handling. When mpv used this better method of escape handling too
(commit 0ff7dd992f), the bug was duplicated.
Attempting to take screenshots printed vdpau errors on the terminal,
and the resulting screenshots were filled with black.
The problem was that that the screenshot code tried to use an
unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]).
This used to refer to the last allocated surface, until this was
changed by a recently merged commit. That commit also added a separate
screenshot surface. The merge somehow went wrong, and that part was not
integrated.
<uau> wm4: you used an earlier buggy version of a commit
OK...
Always use the same function as the OSD does (get_current_time()). This
loses the logic to display "???" if the time is unknown, as
get_current_time() returns 0 in this case. (The function has far too
many uses to change that now, and it seems to happen rarely in
practice.)
wm4
Rudolf Polzer
Stefano Pigozzi
reimar