| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
I don't think the skip_muxed option was overlay useful. While it was
nice to filter out the low quality muxed versions (as it happens on the
alphabetic site, I suspect it's compatibility stuff), it's not really
necessary, and just makes for another tricky and rarely used
configuration option. (This was different before muxed tracks were also
delay-loaded, and including the muxed versions slowed down loading.)
Add the force_all_formats option instead, which handles the HLS case.
Set it to true because they are also delay-loaded now, and don't slow
down startup as much.
|
|
|
|
| |
Make it a proper list, instead of a paragraph soup.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, delay-loading was for files with single tracks only
(basically what DASH and HLS like to expose, so adaptive streaming and
codec selection becomes easier - for sites, not for us). But they also
provide some interleaved versions, probably for compatibility. Until
now, we were forced to eagerly load it (making startup slightly slower).
But there is not much missing. We just need a way to provide multiple
metadata entries, and use them to represent each track.
A side effect is now that the "track_meta" header can be used for normal
EDL files too.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See manpage additions. We would have to extend delay_open to support
multiple sub-tracks (for audio and video), and we'd still don't know (?)
whether it might contain more than one stream each (thinking of HLS
master streams). And if it's a true interleaved file (such as a "normal"
mp4 file provided as fallback for more primitive players), we'd either
have to signal such "bundled" tracks, or waste bandwidth.
This restructures a lot. The if/else tree in add_single_video for format
selection was a bit annoying, so it's split into separate if blocks,
where it checks each time whether a URL was determined yet.
|
|
|
|
|
| |
In particular, all_formats description split away the example section of
an unrelated option, so move that to its proper place.
|
|
|
|
|
|
|
|
|
|
| |
This is just a more convenient way to start IPC client scripts per mpv
instance.
Does not work on Windows, although it could if the subprocess and IPC
parts are implemented (and I guess .exe/.bat suffixes are required).
Also untested whether it builds on Windows. A lot of other things are
untested too, so don't complain.
|
|
|
|
|
|
|
|
|
| |
Pretty worthless I guess. I only tested one site (and 2 videos), it's
somewhat likely that it will break with other sites. Even if you leave
the option disabled (the default).
Slightly related to #3548. This will allows you to use the bitrate
stream selection mechanism, that was added for HLS, with normal videos.
|
|
|
|
| |
Might be helpful for... whatever.
|
|
|
|
| |
example config and default term-status-msg
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Works as ad-filter. I had some more plans, for example replacing
matching text with different text, but for now it's dropping matches
only. There's a big warning in the manpage that I might change
semantics. For example, I might turn it into a primitive sed.
In a sane world, you'd probably write a simple script that processes
downloaded subtitles before giving them to mpv, and avoid all this
complexity. But we don't live in a sane world, and the sooner you learn
this, the happier you will be. (But I also want to run this on muxed
subtitles.)
This is pretty straightforward. We use POSIX regexes, which are readily
available without additional pain or dependencies. This also means it's
(apparently) not available on win32 (MinGW). The regex list is because I
hate big monolithic regexes, and this makes it slightly better.
Very superficially tested.
|
|
|
|
|
|
| |
This renders incorrectly in the html output. I suspect you need one more
level here. Increase the indentation level. No other changes, other than
re-breaking some lines.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add something that will access an URL embedded in EDL only when the
track it corresponds to is actually selected. This is meant to help with
ytdl_hook.lua and to improve loading speeds.
In theory, all this stuff is available to any mpv user, but discourage
using it, as it's so specialized towards ytdl_hook.lua, that there's
danger we'll just break this once ytdl_hook.lua stops using it, or
similar.
Mostly untested.
|
|
|
|
| |
Well whatever.
|
|
|
|
|
|
|
| |
Normally, the first sub-stream is implicitly created. This change lets
the user use more orthogonal syntax, and use a new_stream header for
every sub-stream, instead of having to skip the header for the first
one.
|
|
|
|
|
|
|
|
|
|
|
| |
Add a mp_log context to the parse_edl() function, and report some
errors. Previously, this just told you that something was wrong. Add
some error reporting to make it slightly less evil.
Put all parameters in a list before processing them. This makes adding
parameters for special headers easier, and we can report parameters that
were not understood. (For "compatibility", which probably doesn't matter
at all, still don't count them as errors; as before.)
|
|
|
|
| |
Cut the arbitrary offset, and document what unit/timesource it uses.
|
|
|
|
|
|
|
| |
options.rst to clarify the option, some more text in mpv.rst to separate
out the compatibility stuff a little.
Fixes: #7461 (options.rst change only)
|
|
|
|
| |
Fixes: #7455
|
|
|
|
|
| |
This seems stable enough to use. Change the default, and remove it from
the sw-fast profile.
|
|
|
|
|
| |
Of course nobody will read this. I'm just putting it there so I can
blame users, who run into problems, for not having read it.
|
|
|
|
| |
Yes, this thing became vf_scale through the back door.
|
|
|
|
|
|
|
|
|
|
|
|
| |
As requested I guess. It behaves quite similar to the --loop* options.
Not quite happy with the idea that 1) the option is mutated on each
operation (but at least it's consistent with --loop* and doesn't require
more properties), and 2) the ab-loop command will do nothing once all
loop iterations are done. As a concession, the OSD shows something about
"disabled".
Fixes: #7360
|
|
|
|
|
|
| |
This is not really a changelog, but rather a list of potentially
breaking changes API- and normal users should be aware of, and to help
with migration from older mpv releases.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
this creates a default log for the last mpv run when started from the
bundle. that way one can get a log of what happened even after an issue
occurred. also add a menu entry under Help to show the current log, but
only when the bundle is used.
Fixes #7396
Fixes #2547
|
| |
|
|
|
|
|
| |
Also, add the function mp.get_script_directory() to let scripts know if
they're loaded as a directory and where.
|
|
|
|
|
|
|
|
|
| |
Directories inside ~~/scripts/ are now loaded as scripts, so don't use
it also for modules. Now there are no default module paths.
To compensate, we now try to run ~~/.init.js right after defaults.js,
so the user may extend the js init procedure via this script, e.g. for
adding default paths to mp.module_paths .
|
|
|
|
| |
Convenience; see following commit.
|
|
|
|
|
|
|
| |
As requested. I guess option name and manpage text could be better and
clearer.
Closes: #7442
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See #7435 and related for context.
Basically, it seems that while the original vsfilter processed subtitles
like with this option set to "yes", many current players (mpc-hc
default, vlc, probably most libass users) treat them like with "no". In
the linked issue, this makes rendering severely slower, and can consume
a lot of memory (or just overflow libass memory calculations). It seems
that changing this to "no" will lead to more good than bad, especially
because newer subtitles may be authored for the "no" behavior.
Most libass users seem to use "no" exactly because they do not call
ass_set_storage_size() at all. This API was needed because the scaling
of the subtitles depends on the video size (vsfilter bugs, or
something). In addition, it's my personal opinion that rendering should
not depend on the video at all, so I like setting the default of this to
"no".
|
|
|
|
| |
And add some clarifications/suggestions to the manpage.
|
|
|
|
|
| |
mpv actually used to be able to, from what I remember, but this was
changed for simplicity and because of problems with FFmpeg.
|
|
|
|
|
|
| |
And document the shit.
This uses code from commit bc1c024ae032e5b5c.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The intention is to provide a slightly nicer way to distribute scripts.
For example, you could put multiple source files into the directory, and
then import them from the actual script file (this is still
unimplemented).
At first I wanted to require a config file (because you need to know at
least which scripting backend it should use). This wouldn't have been
too hard (could have reused/abused the mpv config file parsing
mechanism, and I already had working code that was just 2 function
calls). But probably better to do this without new config files, because
it might become a pain in the distant future.
So this just probes for "main.lua", "main.js", etc., until an existing
file is found.
Another important change is that this skips all directory entries whose
name starts with ".". This automatically excludes the "." and ".."
special directories, and is probably useful to exclude random crap that
might be lying around in the directory (such as editor temporary files,
or OSX, in its usual hrmful, annoying, and idiotic modus operandi,
sharting all over any directories opened by "Finder").
Although the changelog mentions the docs, they're added only in a later
commit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This originally existed as a hack for weston. In certain scenarios, a
frame taking too long to render would cause vo_wayland_wait_frame to
timeout which would result in a ton of dropped frames. The naive
solution was to just to add a slight delay to the time value. If a
frame took too long, it would likely to fall under the timeout value and
all was well. This was exposed to the user since the default delay
(1000) was completely arbitrary.
However with presentation time, this doesn't appear to be neccesary.
Fresh frames that take longer than the display's refresh rate (16.666 ms
in most cases) behave well in Weston. In the other two main compositors
without presentation time (GNOME and Plasma), they also do not
experience any ill effects. It's better not to overcomplicate things, so
this "feature" can be removed now.
|
|
|
|
| |
was forgotten in commit 3275cd0
|
| |
|
|
|
|
|
|
| |
It's ridiculous that --script=something.dumb does not cause an error.
Make it error, and extend this behavior to the scripts/ sub-dir in the
mpv config dir.
|
|
|
|
|
|
|
|
|
|
|
| |
This "bundles" all OSD properties. It also makes some previously
Lua-only values available (Lua has mp.get_osd_margins(), unsure if
anything uses it).
The main intention is actually to allow retrieving all fields in an
"atomic" way. (Could introduce a mechanism on the level of the mpv
client API to do this, but doing ti ad-hoc all the time like this commit
is easier.)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Addresses dumb things like accidentally overwriting a media file with
e.g. "mpv --log-file test.mkv" (when the user thought that --log-file
was a flag option, when it actually takes a filename). This example will
now print an error. It still works with "-log-file overwritten.mkv", but
prints a warning.
Not sure if I'm being too careful or not "radical" enough. In any case,
both the syntax that stops working and the syntax that produces a
warning now have been discouraged and were called legacy for almost a
decade.
|
| |
|
|
|
|
|
|
| |
4a084c0df8fd8aaa66073839d97e544c3b6903e7 deprecated multiple -add items
with d3e3bd43074ddd8f4c8829a7454b9f855454f462 explicitly warning against
this usage.
|
|
|
|
|
|
|
|
| |
See manpage additions. The libarchive behavior mentioned in the last
paragraph there is technically unrelated, but makes this new option
mostly pointless.
See: #7182
|
|
|
|
|
| |
The text here has become somewhat outdated over the years, and it's
worth updating to reflect the current situation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the distant past, the cuviddec backed copy hwaccel could be
configured directly using lavc options. However, since that time,
we gained support for automatic hw ctx creation which ended up
bypassing the lavc options.
Rather than trying to find a way to pass those options again, a
better idea is to make the 'cuda-decode-device' option, used by
the interop hwaccels, work for the copy hwaccels too.
And that's pretty simple: we have to add a create function that
checks the option and passes it on to ffmpeg.
Note that this does require a slight re-jig to the configuration
flags, as we now have a scenario where we want to build with support
for the cuda copy hwaccels but not the interop ones. So we need
a distinct configuration flag for that combination.
Fixes #7295.
|
|
|
|
|
|
| |
Has a number of restrictions.
See: #2491, #7294
|
| |
|
|
|
|
|
| |
This file is only complete once it contains the entire mpv source code
in English form.
|
|
|
|
|
|
| |
Thought it might be useful to document some of these things, instead of
explaining them over and over again. But I can guarantee that nobody
will ever read all this. (Independent of its quality and completeness.)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add an "auto-safe" mode, mostly triggered by Ubuntu's nonsense to force
hwdec=vaapi in the global config file in their mpv package. But to be
honest it's probably something more people want.
This is implemented as explicit whitelist. On Windows, HEVC/Intel is
sometimes broken, but it's still whitelisted, and in theory we'd need a
detailed whitelist of device names etc. (like for example browsers tend
to do). On OSX, videotoolbox is a pretty bad choice, but unfortunately
the only one, so it's whitelisted too. There may be a larger number of
hwdec wrappers that work anyway, and I'm for example ignoring Android.
|
|
|
|
|
| |
The legacy mp.set_osd_ass(...) is still supported (but also still
undocumented) as a wrapper for the new mp.create_osd_overlay(...).
|
|
|
|
|
|
|
|
|
|
| |
A minority of users have expressed a dislike of hats, calling them
"cancer [that] don't belong in software" describing the people who add
them as "shitty circlejerks" and "chucklefuck."
While I personally disagree with those opinions, it's probably easier
to let them have it their way. For that reason this adds the option
`greenandgrumpy` to the osc, which allows users to disable the hat.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lua scripting has an undocumented mp.set_osd_ass() function, which is
used by osc.lua and console.lua. Apparently, 3rd party scripts also use
this. It's probably time to make this a public API.
The Lua implementation just bypassed the libmpv API. To make it usable
by any type of client, turn it into a command, "osd-overlay".
There's already a "overlay-add". Ignore it (although the manpage admits
guiltiness). I don't really want to deal with that old command. Its main
problem is that it uses global IDs, while I'd like to avoid that scripts
mess with each others overlays (whether that is accidentally or
intentionally). Maybe "overlay-add" can eventually be merged into
"osd-overlay", but I'm too lazy to do that now.
Scripting now uses the commands. There is a helper to manage OSD
overlays. The helper is very "thin"; I only want to force script authors
to use the ID allocation, which may help with putting multiple scripts
into a single .lua file without causing conflicts (basically, avoiding
singletons within a script's environment). The old set_osd_ass() is
emulated with the new API.
The JS scripting wrapper also provides a set_osd_ass() function, which
calls internal mpv API. Comment that part (to keep it compiling), but
I'm leaving it to @avih to finish the change.
|
|
|
|
| |
(OK, maybe a bit redundant, since vo=xv breaks a lot of stuff.)
|
|
|
|
|
| |
This is conceptually outdated and should not exist. This affects Lua
scripting and JSON IPC too.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that 00af718a made the lua read_options behavior much more similar
to the js behavior, the main difference was that lua does not re-read
the config file at on_update (but it does re-apply its stored content)
while js did re-read it.
Now the js on_update also does not re-read the config file and instead
applies its stored original content.
This is slightly hacky by adding an undocumented optional 4th argument
to read_options which allows overriding the config file content.
|
|
|
|
|
|
|
|
| |