If a card supports both DVB-T/T2 or DVB-S/S2, channels.conf.{sat,ter}
was always interpreted as DVB-T2 / DVB-S2 before this change.
After this change, using channels.conf.{sat1,ter1} will enforce
interpretation as DVB-S/T.
The superior VDR channel config format is still the recommended solution
for such cards as it allows to specify the delivery system variant per
channel, but enforcing T2/S2 for cards supporting it whenever the zap
format is used does not seem reasonable.
fd4e3af740 originally started installing
it, and we've been doing it ever since then. The value of having all of
these encoding profiles predefined by default is pretty dubious since a
lot of them are pretty old ('MP4 for Nokia N900' being a shining
example) and mpv is not really a good encoding tool anyways. Let's treat
it like the other conf files in etc and install it in the data directory
for reference. If someone really uses these, they can copy the file over
locally to their mpv config directory and it'll still work fine.
Reword this paragraph making it clear that as long as a and a-b are not
bound, the a-b-c binding works even if b is bound.
The 4-key limit for sequences was raised to 16 by a5dbf34094, because
MP_MAX_KEY_DOWN is used for both the number of keys that can be held
down and for the key history size. Just remove the related sentence
since you're never going to need sequences longer than 16 keys.
This commit is based on incorrect information, see previous commit.
It also deletes the correct information the prefetch starts when the
current file is fully load.
The commit also misunderstood the comment about m3u8 urls. It refers to
the prefetching of file data inside the m3u8 stream manifest data, which
has nothing to do with mpv playlists when the m3u8 urls are opened as one
stream by ffmpeg.
The original comment was not very clear about this, so add more details
about this.
This reverts commit d4bf179e78.
The decision was based on incorrect assumption that this option
"only opens a connection to the next file, and the cache of the next
video starts empty", a prequisite of the assumption that this option
has no major drawbacks, including incurring unwanted network traffic.
The assumption can be proven incorrect by testing with networked files
in playlist. With log level set to debug, the following lines are shown
after the next file is prefetched, while monitoring of network traffic
shows constant network traffic after the currect file cache reading
reaches EOF, which triggers prefetching:
[cplayer] Opening done: <url to prefetched file>
[lavf] select track 0
[lavf] select track 1
[lavf] EOF reached.
[ffmpeg] AVIOContext: Statistics: 37139315 bytes read, 0 seeks
It is clear that saying "there is nothing to prefetch after the first
frame" is a complete lie: in fact, it fetches the whole file to the
demuxer cache, according to the demuxer cache settings. And when the next
file plays, it also starts with full cache rather than "an empty cache".
In fact, what this option really does is written in
556e204a11: --prefetch-playlist calls
demux_start_prefetch() which does the same thing as the
--demuxer-cache-wait option:
"Before starting playback, read data until either the end of the file was
reached, or the demuxer cache has reached maximum capacity."
This is exactly what is happening with the testing. This option will indeed
cause large amount of unwanted network traffic - a concern raised in the
discussion concerning this option.
Revert this commit since it's based on incorrect assumption, and subsequent
incorrect conclusions derived from it in the subsequent discussions.
This reverts commit 978b219889.
Make Ctrl+y copy the input line to the clipboard, or the currently
selected item in the menu.
The vi key to copy is used because Ctrl+c is already bound.
Alternative bindings are:
Ctrl+x to cut, but this also clears the line.
Ctrl+shift+c like in terminals, but this is harder to press, and this
commit works differently from terminals anyway since you don't manually
highlight characters, it just copies the whole line.
Alt+w, the emacs copy binding, but unless you use emacs this is weird
and unfamiliar.
I'd rather not argue about which is better so go back to status quo,
users can use the more sensible option of "simple" if it doesn't break
anything (which it won't).
Using simple has benefits of growing memory usage slower and much faster
OSD rendering when complex isn't needed.
Simple breaks rendering complex glyphs like Material font icons
Fixes: https://github.com/tomasklaen/uosc/issues/1086
Fixes: f24611980c ("sub/osd: add osd-shaper and set it to simple by default")
case_sensitive originally only affected Tab completion. It defaulted to
yes outside of Windows just to emulate the bad defaults of bash and zsh
(not fish, which has better defaults and defaults to case-insensitive
completion). This was already silly, but then it affected the fuzzy
autocompletion and case-sensitive fuzzy completion is even more silly.
And since 0b3cc3a167, it accidentally stopped affecting even that,
because the completion via script message never checked for the option.
Nobody even noticed this, meaning that nobody was relying on fuzzy
autocompletion being case-sensitive.
Just make case_sensitive only affect the new exact search, and make it
default to no on all platforms. Though IMO the search could just always
be case-insensitive.
Allow matching items exactly instead of fuzzily when prefixing the
search with ' (like in fzf) or with
--script-opt=console-exact_match=yes.
This is mainly useful to filter history entries chronologically.
You can also specify multiple search terms delimited by spaces. But '
makes every term an exact match, unlike fzf where you need to place it
before every word, since we can't hook into fzy's algorithm.
Closes#14587.
Disables perf graphs from stats.lua. They are relatively expensive to
render, causes a lot of memory to be used for caches which are never
reused because graph is rarely the same. And most importantly those
graphs are not that useful beyond quick visual inspection of jitter.
Can be enable in script-opt if needed. Cache graph is left enabled,
because it shows if cache readhead grows or not nicely.
This is a change in default for libass with harfbuzz enabled, previously
it would choose the best available shaper.
Harfbuzz isn't really needed for mpv's OSD and it comes with a
significant performance penalty, so use simple instead
Oliver Freyermuth