Use codec names instead of FourCCs to identify codecs. Rewrite how
codecs are selected and initialized. Now each decoder exports a list
of decoders (and the codec it supports) via add_decoders(). The order
matters, and the first decoder for a given decoder is preferred over
the other decoders. E.g. all ad_mpg123 decoders are preferred over
ad_lavc, because it comes first in the mpcodecs_ad_drivers array.
Likewise, decoders within ad_lavc that are enumerated first by
libavcodec (using av_codec_next()) are preferred. (This is actually
critical to select h264 software decoding by default instead of vdpau.
libavcodec and ffmpeg/avconv use the same method to select decoders by
default, so we hope this is sane.)
The codec names follow libavcodec's codec names as defined by
AVCodecDescriptor.name (see libavcodec/codec_desc.c). Some decoders
have names different from the canonical codec name. The AVCodecDescriptor
API is relatively new, so we need a compatibility layer for older
libavcodec versions for codec names that are referenced internally,
and which are different from the decoder name. (Add a configure check
for that, because checking versions is getting way too messy.)
demux/codec_tags.c is generated from the former codecs.conf (minus
"special" decoders like vdpau, and excluding the mappings that are the
same as the mappings libavformat's exported RIFF tables). It contains
all the mappings from FourCCs to codec name. This is needed for
demux_mkv, demux_mpg, demux_avi and demux_asf. demux_lavf will set the
codec as determined by libavformat, while the other demuxers have to do
this on their own, using the mp_set_audio/video_codec_from_tag()
functions. Note that the sh_audio/video->format members don't uniquely
identify the codec anymore, and sh->codec takes over this role.
Replace the --ac/--vc/--afm/--vfm with new --vd/--ad options, which
provide cover the functionality of the removed switched.
Note: there's no CODECS_FLAG_FLIP flag anymore. This means some obscure
container/video combinations (e.g. the sample Film_200_zygo_pro.mov)
are played flipped. ffplay/avplay doesn't handle this properly either,
so we don't care and blame ffmeg/libav instead.
This could write .edl files in MPlayer's format. Support for playing
these files has been removed from mplayer2 quite a while ago. (mplayer2
can play its own, "new" .edl format, but does not support writing it.)
Since this is a rather obscure functionality, and it's not really clear
how it should behave (e.g. what should it do if a new file is played),
and wasn't all that great to begin with (what if you made a mistake?
the "edl_mark" command sucks for editing), get rid of it.
Suggestions how to reimplement this in a nicer way are welcome. If it's
just about retrieving timecodes, this in input.conf will do:
KEY print_text "position: ${=time-pos}"
sub_remove remove an external subtitle track, for whatever this may be
needed.
sub_reload removes and re-adds an external subtitle track.
Also rename sub_load to sub_add, because that seems to be more in line
with sub_remove.
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".
"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.
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.
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.
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.
wm4