Apparently useful for dumping DVD. Could also be used to rip streams
with libquvi and such, but for that there are better tools. Actually
I doubt there aren't better tools to dump DVDs, but whatever, this was
a feature request, so I don't need a good reason.
This adds Mission Control fullscreen functionality to mpv. Since this doesn't
play well with many of mpv's features disable it by default. Users can activate
this feature by using `--native-fs` when starting mpv.
Fixes#34
A "watch later" command is now mapped to Shift+Q. This quits the player
and stores the playback state in a config file in ~/.mpv/watch_later/.
When calling the player with the same file again, playback is resumed
at that time position.
It's also possible to make mpv save playback state always on quit with
the --save-position-on-quit option. Likewise, resuming can be disabled
with the --no-resume-playback option.
This also attempts to save some playback parameters, like fullscreen
state or track selection. This will unconditionally override config
settings and command line options (which is probably not what you would
expect, but in general nobody will really care about this). Some things
are not backed up, because that would cause various problems. Additional
subtitle files, video filters, etc. are not stored because that would be
too hard and fragile. Volume/mute state are not stored because it would
mess up if the system mixer is used, or if the system mixer was
readjusted in the meantime.
Basically, the tradeoff between perfect state restoration and
complexity/fragility makes it not worth to attempt to implement
it perfectly, even if the result is a little bit inconsistent.
These require bleeding edge libass (latest git version), and will be
ignored otherwise.
I'm not sure about the blur factor and scaling. The ASS/VSFilter
semantics for blur scaling are a bad mess. Might require further
investigation.
Anything this option did has been removed in the preceding 3 commits.
Note that even though these options sounded like a good idea (like
setting accuracy vs. speed tradeoffs), they were not really properly
implemented.
This option can be used to selectively reset settings when playing the
next file in the playlist (i.e. restore mplayer and mplayer2 behavior).
Might remove this option again should it turn out that nobody uses it.
Makes sure that seeking to a given time position shows the subtitle at
that position. This can fail if the subtitle packet is not close enough
to the seek target. Always enabled for hr-seeks, and can be manually
enabled for normal seeks with --mkv-subtitle-preroll.
This helps displaying subtitles correctly with ordered chapters. When
switching ordered chapter segments, a seek is performed. If the subtitle
is timed slightly before the start of the segment, it normally won't be
demuxed. This is a problem with all seeks, but in this case normal
playback is affected. Since switching segments always uses hr-seeks,
the code added by this commit is always active in this situation.
If no subtitles are selected or the subtitles come from an external
file, the demuxer should behave exactly as before this commit.
The OSX part of the Apple Remote was unmaintained for a long time and was not
working anymore. I tried to update the cookies to what the current versions of
OS X expect without much luck. I decided to remove it since Apple is not
including the IR receiver anymore in new hardware and it's clear that wifi
based remotes are the way to go.
A third party iOS app should be used in it's place. In the future we could look
into having a dedicated iOS Remote Control app like VLC and XBMC do.
The Linux side (`appleir.c`) was relatively tidy but it looks like LIRC can be
configured to work with any version of Apple Remote [1] and is more maintained.
[1] LIRC Apple Remote configs: http://lirc.sourceforge.net/remotes/apple/
Drawing the bar with vector drawings (instead with characters from the
OSD font) offers more flexibility and looks better. This also adds
chapter marks to the OSD bar, which are visible as small triangles on
the top and bottom inner border of the bar.
Change the default position of the OSD bar below the center of the
screen. This is less annoying than putting the bar directly into the
center of the view, where it obscures the video. The new position is
not quite on the bottom of the screen to avoid collisions with
subtitles.
The old centered position can be forced with ``--osd-bar-align-y=0``.
Also make it possible to change the OSD bar width/height with the new
--osd-bar-w and --osd-bar-h options.
It's possible that the new OSD bar renders much slower than the old
one. There are two reasons for this: 1. the character based bar
allowed libass to cache each character, while the vector drawing forces
it to redraw every time the bar position changes. 2., the bar position
is updated at a much higher granularity (the bar position is passed
along as float instead of as integer in the range 0-100, so the bar
will be updated on every single video frame).
This way it's possible to retrieve correct information about video, like
actual width/height, which in general are available only after at least
one frame has been sent to the video output, such as dwidth/dheight.
mpv_identify.sh becomes a bit slower, because we let it decode enough
audio and video to fill the audio buffers and to send one frame to the
video output. Also, --playing-msg isn't shown anymore with --frames=0
(could be fixed by special-casing it, should this break any use cases).
Note that in some corner cases, like when the demuxer for some reason
returns lots of audio packets but no video packets at the start, but
video actually starts later, the --playing-msg will still be output
before video starts.
This has the same (useless) definition as frame stepping in audio-only
mode: one frame means one playloop iteration. (It's relatively useless,
because one playloop iteration has a random duration. But it makes
--frames=1 work, which is useful again.)
Latest nvidia drivers ignore the application setting, so this switch
makes even less sense than before. It's still possible to control this
with VO specific suboptions.
The spdif decoder was hardcoded to assume that the spdif output is
capable of accepting high (>1.5Mbps) bitrates. While this is true
for modern HDMI spdif interfaces, the original coax/toslink system
cannot deal with this and will fail to work.
This patch adds an option --dtshd which can be enabled if you use
a DTS-capable receiver behind a HDMI link.
This allowed making the player switch the monitor video mode when
creating the video window. This was a questionable feature, and with
today's LCD screens certainly not useful anymore. Switching to a random
video mode (going by video width/height) doesn't sound too useful
either.
I'm not sure about the win32 implementation, but the X part had several
bugs. Even in mplayer-svn (where x11_common.c hasn't been receiving any
larger changes for a long time), this code is buggy and doesn't do the
right thing anyway. (And what the hell _did_ it do when using multiple
physical monitors?)
If you really want this, write a shell script that calls xrandr before
and after calling mpv.
vo_sdl still can do mode switching, because SDL has native support for
it, and using it is trivial. Add a new sub-option for this.
The --wid switch (for embedding the player into other applications)
didn't create a new window, and instead tried to use the window that
was passed via --wid directly. This made the code more complex, caused
strange X errors (mpv and host application fighting for exclusive X
resources), and actually could cause issues if the --wid window wasn't
created with the X Visual needed for OpenGL.
Always create a window instead. This makes it always possible to embed
the player into foreign windows. --geometry doesn't work anymore - the
controlling application should always create a new window to place the
player inside it, and can control the video window by moving and
resizing this window.
w32_common.c actually did this right, and always creates a new window.
You can just use --wid=0 if you really want this.
This only worked/works for X11, and even then it might interact badly
with most desktop environments. All the option did was setting --wid to
0, and the property did nothing.
For all suboptions, "flat" options were available by separating the
parent option and the sub option with ":", e.g. "--rawvideo:w=123". Drop
this syntax and use "-" as separator. This means even suboptions are
available as normal options now, e.g. "--rawvideo-w=123". The old syntax
doesn't work anymore.
Note that this is completely separate from actual suboptions. For
example, "-rawvideo w=123:h=123" still works. (Not that this syntax is
worth supporting, but it's needed anyway, for for other things like vf
and vo suboptions.)
As a consequence of this change, we also have to add new "no-" prefixed
options for flag suboptions, so that "--no-input-default-bindings"
works. ("--input-no-default-bindings" also works as a consequence of
allowing "-input no-default-bindings" - they are handled by the same
underlying option.)
For --input, always use the full syntax in the manpage. There exist
suboptions other than --input (like --tv, --rawvideo, etc.), but since
they might be handled differently in the future, don't touch these yet.
M_OPT_PREFIXED becomes the default, so remove it. As a minor unrelated
cleanup, get rid of M_OPT_MERGE too and use the OPT_SUBSTRUCT() macro in
some places.
Unrelated: remove the duplicated --tv:buffersize option, fix a typo in
changes.rst.
`--fs-screen` allows to decide what display to go fullscreen into. The
semantics of `--screen` changed and now it is only used to select the windowed
display when starting the application.
This is useful for people using mpv with an external TV. They will start
windowed on their laptop's screen and switch to fullscreen on the TV.
@wm4 worked on the x11 and w32 parts of the code. All is squashed in one
commit for history clarity.
Being able to insert newline characters ("\n") is useful for
--osd-status-msg, and possibly also for anything that prints to the
terminal. Espcially --term-osd-esc looks relatively useless without
being able to specify escapes.
Maybe parsing escapes should happen during command line / config parsing
instead (for all options).
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.
Simplify --no-config and make it a normal flag option, and doesn't take
an argument anymore. You can get the same behavior by using --no-config
and then --include to explicitly load a certain config file.
Make --no-config work for input.conf as well. Make it so that
--input:conf=file still works in this case. As a technically unrelated
change, the file argument now works as one would expect, instead of
making it relatively to "~/.mpv/". This makes for simpler code and
easier to understand option semantics. We can also print better error
messages.
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}"
The "http:" protocol has been switched to use ffmpeg's HTTP
implementation some time ago. One problem with this was that many HTTP
specific options stopped working, because they were obviously
implemented for the internal HTTP implementation only.
Add the missing things. Note that many options will work for ffmpeg
only, as Libav's HTTP implementation is missing these. They will
silently be ignored on Libav.
Some options we can't fix:
--ipv4-only-proxy, --prefer-ipv4, --prefer-ipv6
As far as I can see, not even libavformat internals distinguish
between ipv4 and ipv6.
--user, --passwd
ffmpeg probably supports specifying these in the URL directly.
-x/-y were rather useless and obscure. The only use I can see is
forcing a specific aspect ratio without having to calculate the aspect
ratio float value (although --aspect takes values of the form w:h).
This can be also done with --geometry and --no-keepaspect. There was
also a comment that -x/-y is useful for -vm, although I don't see how
this is useful as it still messes up aspect ratio.
-xy is mostly obsolete. It does two things: a) set the window width to
a pixel value, b) scale the window size by a factor. a) is already done
by --autofit (--autofit=num does exactly the same thing as --xy=num, if
num >= 8). b) is not all that useful, so we just drop that
functionality.
--autofit=WxH sets the window size to a maximum width and/or height,
without changing the window's aspect ratio.
--autofit-larger=WxH does the same, but only if the video size is
actually larger than the window size that would result when using
the --autofit=WxH option with the same arguments.
Now all numbers in the --geometry specification can take percentages.
Rewrite the parsing of --geometry, because adjusting the sscanf() mess
would require adding all the combinations of using and not using %. As
a side effect, using % and pixel values can be freely mixed.
Keep the aspect if only one of width or height is set. This is more
useful in general.
Note: there is one semantic change: --geometry=num used to mean setting
the window X position, but now it means setting the window width.
Apparently this was a mplayer-specific feature (not part of standard X
geometry specifications), and it doesn't look like an overly useful
feature, so we are fine with breaking it.
In general, the new parsing should still adhere to standard X geometry
specification (as used by XParseGeometry()).
The video filter chain traditionally used FourCCs for pixel formats.
This was recently changed, but some parts of the manpage were not
updated properly. Now there are two rypes of options: some which take
a FourCC (as used with raw video formats), and some which take a
symbolic format identifier (as used in the video filter chain).
I realize that it's harder to specify FourCC for RGB formats now (TV
stuff may need RGB). They use non-printable characters as part of the
FourCC, and have to be specified as hexadecimal numbers (instead of
a symbolic identifier). Because I can't be bothered to find out what
these numbers are for the respective formats, just remove the old
pseudo-FourCCs from the documentation.
This printed per-frame statistics into a file, like bitrate or frame
type. Not very useful and accesses obscure AVCodecContext fields
(danger of deprecation/breakage), so get rid of it.
This was a "broken misfeature" according to Libav developers. It wasn't
implemented for modern codecs (like h264), and has been removed from
Libav a while ago (the AVCodecContext field has been marked as
deprecated and its value is ignored). FFmpeg still supports it, but
isn't much useful due to aforementioned reasons.
Remove the code to enable it.
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
Deprecate the hardware specific video codec entries (like ffh264vdpau).
Replace them with the --hwdec switch, which requests that a specific
hardware decoding API should be used. The codecs.conf entries will be
removed at a later time, but for now they are useful for testing and
compatibility.
Instead of --vc=ffh264vdpau, --hwdec=vdpau should be used.
Add a fallback if hardware decoding fails. Most hardware decoders
(including vdpau) support only a subset of h264, and having such a
fallback is supposed to enable a better user experience.
Slices allowed filtering or drawing video in horizontal bands or
blocks. This allowed working on the video in smaller units. In theory,
this could bring a performance win by lowering cache pressure, as you
didn't have to keep the whole video frame in cache while filtering,
only the slice.
In practice, the slice code path was barely used for the following
reasons:
- Multithreaded decoding with ffmpeg didn't use slices. The ffmpeg
slice callback was disabled, because it can be called from another
thread, and the mplayer video chain is not thread-safe.
- There was nothing that would turn "full" images into appropriate
slices, so slices were rarely used.
- Most filters didn't actually support slices.
On the other hand, supporting slices lead to code duplication and more
complex code in general. I made some experiments and didn't find any
actual measurable performance improvements when using slices. Even
ffmpeg removed slices based filtering from libavfilter in favor of
simpler code.
The most broken thing about the slices code path is that slices can't
be queued, like it is done for images in vo.c.
This is simpler and more useful. We could add a new switch for the old
functionality, but that would probably be more confusing than helpful.
When passing only a single file to the command line, this commit
shouldn't change behavior.
(Classic mplayer provided both features by duplicating the loop
functionality in the "playtree".)
Setting some subtitle options may lead to incorrect rendering of complex
ASS subtitle scripts, such as displaced signs or visual artifacts. The
user should be made aware that this can happen.
In theory, libass could make using some of these options relatively
safe, but it doesn't.
Note that there are potentially much more options that could in theory
break subtitle rendering, but add a warning only to the most fragile
ones.
Before this commit, the --osd-* options (like --osd-font-size etc.)
configured both the OSD and subtitle font. Make them separate, and add
--sub-text-* options (like --sub-text-size etc.). Now --osd-* affects
the OSD font only, and --sub-text-* unstyled text subtitles only.
They were more or less grouped by usefulness, but since everything
else in the manpage is sorted alphabetically, it's better to be
consistent and sort these options as well.
Commit c02f25 switched the "http://" protocol to use ffmpeg's HTTP
implementation (stream_lavf.c), instead of the mplayer internal one
(http.c). Unfortunately, it turns out that there are some network
related options that are not respected by stream_lavf.c, and
consequently do not work anymore for "http://" URLs. This might be
fixed later. Mark them as deprecated for now, as it might take
arbitrarily long until this is taken care of.
ffmpeg pretends that image attachments (such as contained in ID3v2
metadata) are video streams. It injects the attached pictures as packets
into the packet stream received with av_read_frame().
Add the --audio-display option to allow configuring whether attached
pictures should be displayed. The default behavior doesn't change
(images are displayed).
Identify video streams, that are actually image attachments, with "[P]"
in the terminal output.
Modify the default stream selection such that real video streams are
preferred over attached pictures. (This is just for robustness; I do not
know of any samples where images are added before actual video streams
and could lead to bad default stream selection with the old code.)
libavformat wants to read a full ~400KB of data to determine whether
it's really AAC. This causes slow startup with AAC web radio streams [1]
(possible due to a broken initial packet). There are similar issues
with other file formats.
Make the probe "score" (libavformat's mechanism for testing file
formats) configurable with the -lavfdtops:probescore option. This allows
lowering the amount of data read on probing. If the probe score is below
the probescore option value, demux_lavf will try to get a higher score
by feeding more data to libavformat, until the required score or the
max. probe size is reached.
Remove the lavf_preferred demuxer entry. This had a purpose in
mplayer-svn, but now there doesn't seem to be any good reason for it
to exist. Make sure that our native "good" demuxers are above
demux_lavf in demuxer_list[] instead (so that they are preferred).
[1] http://lr2mp0.latvijasradio.lv:8000
ffmpeg recently added a demuxer that can read vobsubs (pairs of .sub and
.idx files). Get rid of the internal vobsub reader, and use the ffmpeg
demuxer instead.
Sneak in an unrelated manpage change (autosub default).
Remove the options --utf8 and --unicode which had no effect any more
(what they once did should be doable with --subcp). The only use of
corresponding variables left in code was subreader.c code using
sub_utf8 as a flag indicating whether iconv conversion was active.
Change the code to test the existence of iconv context instead.
Conflicts:
DOCS/man/en/options.rst
core/cfg-mplayer.h
sub/sub.c
sub/sub.h
sub/subreader.c
Merged from mplayer2 commit ea7311.
Note: --unicode was already removed
When the cache fill status goes below a certain threshold, automatically
pause the player. When the cache is filled again, unpause again.
This is intended to help with streaming from http. It's better to pause
a while, rather than exposing extremely crappy behavior when packet
reads during decoding block the entire player.
In theory, we should try to increase the cache if underruns happen too
often. Unfortunately, changing the cache implementation would be very
hard, because it's insane code (forks, uses shared memory and "volatile"
etc.). So for now, this just reduces the frequency of the stuttering if
the network is absolutely too slow to play the stream in realtime.
MPlayer/mplayer2 still show DVD subtitles in gray. Depending on who you
ask, this can be considered a bug or a feature. Include rendering in
gray as explicit feature, so the user can decide what is better.
This affects all indexed sub bitmaps entering the OSD rendering path.
Currently, this means all image subs are affected by this option, but
nothing else.
Apparently the -spugauss option was popular. The code originally
implementing this is gone (scaler stuff in spudec.c). Reimplement it
using libswscale to scale and blur image subtitles if the --sub-gauss
option is set.
The code does some rather lazy padding to allow the blur to spread
pixels past the original image bounding box. (This problem exists with
normal bilinear scaling too, but is barely noticable.)
Technically, this doesn't just blur subtitles, but anything RGBA (or
indexed) that enters the OSD rendering path. But only image subtitles
produce these OSD formats currently, so no explicit check is done to
prevent blurring in other cases.
Make more aspects of the OSD font customizable. This also affects the
font used for unstyled subtitles (such as SRT), or when using the
--no-ass option. This adds back some customizability that was lost with
commit 74e7a1 (osd: use libass for OSD rendering).
Removed options:
--ass-border-color
--ass-color
--font
--subfont
--subfont-text-scale
Added options:
--osd-color
--osd-border
--osd-back-color
--osd-shadow-color
--osd-font
--osd-font-size
--osd-border-size
--osd-margin-x
--osd-margin-y
--osd-shadow-offset
--osd-spacing
--sub-scale
The font size is now specified in pixels as it would be rendered on a
window with a height of 720 pixels. OSD and subtitles are always scaled
with the window height, so specifying or expecting an absolute font
size doesn't make sense.
Such scaled pixel units are used to specify font border etc. as well.
(Note: the font size is directly passed to libass. How the fonts are
actually rasterized is outside of our control, but in theory ASS font
sizes map to "script" pixels and then are scaled to screen size.)
The default settings should be about the same, with slight difference
due to rounding to the new scales.
The OSD and subtitle fonts are not separately configurable. It has
limited use and would double the number of newly added options, which
would be more confusing than helpful. It could be easily added later,
should the need arise.
Other small details that change:
- ASS_Style.Encoding is not set to -1 for subs anymore
(assuming subs use VSFilter direction in -no-ass mode too)
- use a different WrapStyle for OSD
- ASS forced styles are not applied to OSD
The --start and --end switch now accept a chapter number. The chapter
number is prefixed with '#', e.g. "--start=#2" jumps to chapter 2.
The chapter support might be able to replace --chapter completely, but
for now I am not sure how well this works out with e.g. DVDs and BDs,
and a separate --chapter option is useful interface-wise.
(This was supposed to be added in 51503a, but apparently the fixup
commit adding it was lost in a rebase. This might also be the reason
for the mess-up fixed in 394285.)
Enable autoprobing for demux_mf, so that image files can be directly
displayed with e.g. "mpv file.jpg --pause". (The --pause switch is
needed to prevent the window from closing immediately.)
Since demux_mf doesn't have any real file format probing and goes by
file extension only, move the demuxer down the demuxer list to ensure
it's checked last. (ffmpeg's demux_mf equivalent, "image2", probes by
file extensions too, and there doesn't seem to be anything that can
probe typical image file formats from binary data.)
Remove the --mf "w" and "h" suboptions. Don't pass the width/height to
the video stream header. Both of these are useless, because the decoder
reads the real image size at a later point from the file headers.
Remove setting the BITMAPINFOHEADER as well, as vd_lavc doesn't need
this.
Enable --correct-pts by default. This fixes displaying a single image
with vo_vdpau (as mentioned by uau).
Keep around a pointer to the sh_video stream header instead of
accessing demuxer->video->sh_video. Fixes a crash when deselecting the
video track.
Note that the format probing is incorrect when opening images from HTTP
locations. File extensions don't have to match the actual file format.
A correct implementation would require to check the MIME type, or to
probe the binary data correctly.
The --keep-open option causes mpv not to close the current file.
Instead, it will pause, and allow the user to seek around. When
seeking beyond the end of the file, mpv does a precise seek back to
the previous last known position that produced video output.
In some corner cases, mpv might not be able to produce video output at
all, despite having created a VO. (Possibly when only 1 frame could be
decoded, but the video filter chain queues frames. Then a VO would be
created, without sending an actual video frame to the VO.) In these
cases, the VO window will not redraw, not even OSD.
Based on a patch by coax [1].
[1] http://devel.mplayer2.org/ticket/210#comment:4
"--autosub-match" is close to "--autosub", and reflects what this
option does slightly better. Replace the magic number option values
with choices:
--sub-fuzziness=0 becomes --autosub-match=exact
--sub-fuzziness=1 becomes --autosub-match=fuzzy
--sub-fuzziness=2 becomes --autosub-match=all
Rename the -ss option to -start, and -endpos to -length. Add a -end
option. The -end option always specifies an absolute end time, as
opposed to -endpos/-length.
All these options (--start, --end, --length) now accept relative times.
Percent positions (e.g. "--start=30%") are interpreted as fractions of
the file duration. Negative times (e.g. "--start=-1:00) are interpreted
relative to the end of the file. Chapters (e.g. "--start=#3") yield the
chapter's time position.
The chapter support might be able to replace --chapter completely, but
for now I am not sure how well this works out with e.g. DVDs and BDs,
and a separate --chapter option is useful interface-wise.
Remove the code that attempted to read cookie files from well-known
browser locations. This code was written for ancient browsers, and only
knew about Mozilla and Netscape. While it's possible that these browsers
are still alive and still use the same config locations and cookie file
formats, the only Mozilla-based browser that still matters is Firefox.
Firefox uses a sqlite database for cookies, located in a slightly
different config path.
Just remove this code.
The -zoom option enabled scaling with vo_x11. Remove the -zoom option,
and make its behavior default. Since vo_x11 has to use libswscale for
colorspace conversion anyway, which doesn't do actual extra scaling when
vo_x11 is run in windowed mode, there should be no speed difference with
this change.
The code removed from vf_scale attempted to scale the video to d_width/
d_height, which matters for anamorphic video and the --xy option only.
vo_x11 can handle these natively. The only case for which the removed
vf_scale code could matter is encoding with vo_lavc, but since that
didn't set VOFLAG_SWSCALE, nothing actually changes.
The -ni option does something with the AVI demuxer only.
Also fix misleading error messages when the packet queue overflows (it
suggests using -ni, which in the typical case of playing NI AVI files
will not work, as demux_lavf is used by default).
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.
wm4
Paul B Mahol
Stefano Pigozzi
reimar
Wessel Dankers
Uoti Urpala
Rudolf Polzer