Fix spudec change detection. The internal changed-flag was not reset
when retrieving indexed bitmaps, and subtitles were rescaled every
frame, even if they were not changing.
Simplify subtitle decoders by not requiring them to check whether the
passed-in screen size has changed. sd_lavc did this, and spudec would
have needed to do the same. Instead, leave this to the osd_object
force_redraw flag. Subtitle decoders (such as libass) can still signal
that only the positions of subtitles have changed, but making _all_
subtitle decoders do this just to deal with screen size changes is
worthless.
Crop subtitle images produced by spudec.c: instead of returning a frame-
sized bitmap (with possibly large transparent regions), return a cropped
down rectangle of the visible part only. The old spudec scaler code had
this as spudec_cut_image(), but it worked on the data converted to the
old OSD format only.
Move most code to setup the sub-bitmap from spudec_get_indexed() to
spudec_process_data(), so that cropping can be done every time a new
subtitle is decoded, instead of every frame.
Set the sub_bitmaps->scaled flag. Without it, vo_gl and vo_vdpau
produced ugly artifacts on the borders.
Fixes problems with ugly borders.
Note that at least in the DVD sub case, we could have just set all
transparent pixels to black to solve this.
vo_direct3d.c change untested, because mingw is a miserable pile of
crap.
Instead, sd_lavc.c and spudec.c (the two image sub decoders) always
output indexed/paletted images. For this purpose, add SUBBITMAP_INDEXED,
and convert the subs to RGBA in img_convert.c instead. If a VO is used
that supports the old OSD format only, the indexed bitmaps are converted
to the old OSD format by abusing spudec.c in a similar way sd_lavc.c
used to do.
The main reason why spudec.c is used is because the images must not only
be converted to the old format, but also properly scaled, cropped, and
aligned (the asm code in libvo/osd.c requires this alignment).
Remove support for the old format (packed variant) from the OpenGL VOs.
(The packed formats were how the actual OSD format was handled in some
GPU-driven VOs for a while.)
Remove all conversions from old to new formats. Now all subtitle
decoders and OSD renderers produce the new formats only.
Add an evil hack to convert the new format (scaled+indexed bitmaps) to
the old format. It creates a new spudec instance to convert images to
grayscale and to scale them. This is temporary for VOs which don't
support new OSD formats yet (vo_xv, vo_x11, vo_lavc).
Move sub-bitmap definitions from dec_sub.h to sub.h. While it's a bit
odd that OSD data structures are in a file named sub.h, it's definitely
way too strange to have them in a file about subtitle decoding. (Maybe
sub.h/.c and the sub/ directory should be split out and renamed "osd"
at a later point.)
Remove including ass_mp.h (and the libass headers) where possible.
Remove typedefs for mp_eosd_res and sub_bitmaps structs.
Store a mp_eosd_res struct in osd_state instead of just w/h. Note that
sbtitles might be rendered using different sizes/margins when filters
are involved (the subtitle renderer is not supposed to use the OSD res
directly, and the "dim" member removed in the previous commit is
something different).
Passing parameters from caller to subtitle renderer was done by
temporarily setting certain members in the osd_state struct (which for
all practical purposes are as good as global variables). This was the
only purpose of these members.
Rather than using such a messy way to pass parameter, put these into a
struct sub_render_params. The struct was already introduced in earlier
commits, and this commit just removes the parameter passing hack.
Before this commit, vf_vo.c and vf_ass.c were manually calling the
subtitle decoder to retrieve images to render. In particular, this
circumvented the sub-bitmap conversion & caching layer in sub.c.
Change this so that subtitle decoding isn't special anymore, and draws
all subtitles with the normal OSD drawing API.
This is also a step towards removing the need for vf_ass auto-insertion.
In fact, if auto-insertion would be disabled now, VOs with "old" OSD
rendering could still render ASS subtitles in monochrome, because
there is still ASS -> old-OSD bitmap conversion in the sub.c mechanism.
The code is written with the assumption that the subtitle rendering
filter (vf_ass) can render all subtitle formats. Since vf_ass knows the
ASS format only, rendering image subs (i.e. RGBA subs) with it simply
fails. This means that with vo_xv (vf_ass auto-inserted), image subs
wouldn't be rendered. Use a dumb hack to disable rendering subs with a
filter, if we detect that the subs are not in ASS format. (Trying to
render the subs first would probably result in purging the conversion
cache on every frame.)
VOs which could render the OSD in window size (as opposed to video size,
like vo_xv) and which could cache the OSD called this when the window
size changed. This was needed, because VOs used another OSD function to
check whether the OSD changed before passing the new window size to the
OSD code.
This was really just an artifact of OSD change detection, and now that
the affected VOs use the new OSD rendering API, it's done automatically.
This contains about the same code as bitmap_packer.c. eosd_packer.c was
added first, and then not merged for a year - then it was added as
bitmap_packer.c with slightly different and incompatible interface. Now
replacing eosd_packer.c with bitmap_packer.c is finally done. So much
wasted work...
Side effect: no direct support for old OSD format anymore. Instead,
sub.c converts sub-images in that format to the packed, alpha-inverted
version.
osd-color suboption is broken.
This was an extremely obscure setting, as it was used only with vo_gl
if its scaled-osd suboption was used. If you really want this, you can
set the desired ass-hinting value directly, and there will be literally
no loss in functionality.
Note that this didn't actually test whether the EOSD was scaled.
Basically, it only checked whether vo_gl had the scaled-osd suboption
set.
Useless. It complicated the code and caused flicker, and was useless
otherwise. The manpage describes this option as "should not normally
be used".
One possibly useful effect from the point of view of the user was that
vsync was disabled. You can do this with the --vsync option, or by
changing X/driver settings directly.
With this commit, the player will still use spudec.c (the "old" DVD sub
decoder), rather than ffmpeg. But it brings the changes needed to enable
this down to a single line change:
--- a/mplayer.c
+++ b/mplayer.c
@@ -1988,7 +1988,7 @@ static void reinit_subs(struct MPContext *mpctx)
#endif
vo_osd_changed(OSDTYPE_SUBTITLE);
} else if (track->stream) {
- if (mpctx->sh_sub->type == 'v')
+ if (mpctx->sh_sub->type == 'v' && false)
init_vo_spudec(mpctx);
else
sub_init(mpctx->sh_sub, mpctx->osd);
Also, copy the DVD resolution heuristics from spudec.c (from the
spudec_new_scaled() function). I'm not sure if this is correct or even
needed, but the sd_lavc codd explicitly reverted back to spudec with
code carrying this comment:
// Assume resolution heuristics only work for PGS and DVB
so it seems likely that the required heuristics were missing, and that
the spudec heuristics may make the DVD compatibility situation at least
as good as with spudec.
Note that it's unlikely that we enable sd_lavc for DVD subs by default,
as there are other problems in combination with direct DVD playback.
We are using libass for OSD rendering. One problem with that is that
libass has to be bug-compatible to VSFilter. This includes the setting
for the default RTL base direction. Neutral would be most reasonable,
but VSFilter assumes LTR.
This commit forces the default to neutral.
Unconfirmed whether this actually works as intended.
See the following libass commits:
9dbd12d shaper: allow font encoding -1 for neutral base direction
a80c45c shaper: always use LTR base direction by default
libass may always return a full change if no subtitle images are
rendered in some cases (empty tracks). Also, a full change despite empty
sub-images list may be reported on initialization. Avoid invoking odd
special cases in the VO code by always exiting early if the sub-image
list is empty.
Note that at least for OSD, the code in sub.c doesn't even send a
request VOCTRL_DRAW_EOSD if the image list is empty. But the subtitle
rendering code in vf_vo.c is independent from this (at least for now).
This allows vo_vdpau to render OSD directly, without the indirection
through the old OSD API, and without the additional conversions.
Remove support for the old OSD format. Only the mplayer DVD subtitle
decoder still generates this format. Although the new OSD interface does
support this format, remove it from vo_vdpau. It would be relatively
hard to support it in the EOSD code, as it requires two surfaces. (These
two surfaces are blended on top of each other to emulate the mplayer OSD
format.) The correct way to implement direct support for DVD subs would
consist of adding a paletted image format of some sort. But even sd_lavc
converts paletted subtitle images to RGBA, so doing something special
just for DVD subs is not worth it.
This means the frontend (sub.c) converts the subtitles to RGBA if it
detects that vo_vdpau does not support them natively.
The mplayer DVD sub decoder is the only remaining OSD image producer
that still requires the old mplayer OSD format (SUBBITMAP_OLD_PLANAR).
To make supporting this format optional in VOs, add a step that allows
converting these images to RGBA in case the VO doesn't have direct
support for it.
Note: the mplayer DVD sub decoder uses the old mplayer OSD format
(SUBBITMAP_OLD_PLANAR), which is assumed to use premultiplied alpha.
However, it seems DVDs allow only binary transparency, so the rendered
result will be the same.
Before this commit, the OSD was drawn using libass, but the resulting
bitmaps were converted to the internal mplayer OSD format. We want to
get rid of the old OSD format, because it's monochrome, and can't even
be rendered directly using modern video output methods (like with
OpenGL/Direct3D/VDPAU).
Change it so that VOs can get the ASS images directly, without
additional conversions. (This also has the consequence that the OSD can
render colors now.) Currently, this is vo_gl3 only. The other VOs still
use the old method. Also, the old OSD format is still used for all VOs
with DVD subtitles (spudec).
Rewrite sub.c. Remove all the awkward flags and bounding boxes and
change detection things. It turns out that much of that isn't needed.
Move code related to converting subtitle images to img_convert.c. (It
has to be noted that all of these conversions were already done before
in some places, and that the new code actually makes less use of them.)
This basically pushes the old OSD bitmaps via VOCTRL_DRAW_EOSD to the
VO, instead of using the old callback-based interface.
Future commits will change the code such that sub.c pushes images
rendered by libass directly, rather than converting them to the old
OSD format first.
One sub_bitmaps struct could contain either a libass ASS_Image list, or
a mplayer native list of sub-bitmaps. This caused code duplication in
vo_vdpau.c and bitmap_packer.c.
Avoid this by creating such a sub_bitmap array even with libass. This
basically copies the list and recreates it in mplayer's native format.
It gets rid of the code duplication, and will make implementing extended
subtitle and OSD rendering in other VOs easier.
Also do some cosmetic changes and other preparations for the following
commits.
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.
This changes the name of this project to mpv. Most user-visible mentions
of "MPlayer" and "mplayer" are changed to "mpv". The binary name and the
default config file location are changed as well.
The new default config file location is: ~/.mpv/
Remove etc/mplayer.desktop. Apparently this was for the MPlayer GUI,
which has been removed from mplayer2 ages ago.
We don't have a logo, and the MS Windows resource files sort-of require
one, so leave etc/mplayer.ico/.xpm as-is.
Remove the debian and rpm packaging scripts. These contained outdated
dependencies and likely were more harmful than useful. (Patches which
add working and well-tested packaging are welcome.)
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.
