| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
I can't see much value in them. Just specify the size manually.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| | |
|
| |
|
|
|
| |
In addition to disabling the OSD bar physically, also add some fallbacks
to OSD text in places the OSD bar would have been used.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
FreeBSD actually supports V4L2, and V4L2 supports this chip. Also,
this chip is from 1997. Farewell.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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}"
|
| |
|
|
|
|
|
| |
Add missing documentation for --quvi-format switch.
Fix description how hw decoding is enabled. The old way currently still
works, but is deprecated.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
These options might be useful sometimes, but they are not that
important, and work with vf_sub only. Make them vf_sub sub-options.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Unfortunately, these do not fix the man page indent issue.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
The --zoom option has been removed, and is always active.
|
| |
|
|
|
|
| |
The typo in options.rst was introduced in a54088.
--hardframedrop mentioned in mpv.rst has been merged with --framedrop.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 ad |
