This adds cache as a possible path for mpv to internally pick
(~/.cache/mpv for non-darwin unix-like systems, the usual config
directory for everyone else). For gpu shader cache and icc cache,
controlling whether or not to write such files is done with the new
--gpu-shader-cache and --icc-cache options respectively. Additionally,
--cache-on-disk no longer requires explicitly setting the --cache-dir
option. The old options, --cache-dir, --gpu-shader-cache-dir, and
--icc-cache-dir simply set an override for the directory to save cache
files. If unset, then the cache is saved in XDG_CACHE_HOME.
A pain point for some users is the fact that watch_later is stored in
the ~/.config directory when it's really not configuration data. Roughly
2 years ago, XDG_STATE_DIR was added to the XDG Base Directory
Specification[0] and its description, user-specific state data, actually
perfectly matches what watch_later data is for. Let's go ahead and use
this directory as the default for watch_later. This change only affects
non-darwin unix-like systems (i.e. Linux, BSDs, etc.). The directory
doesn't move for anyone else.
Internally, quite a few things change with regards to the path
selection. If the platform in question does not have a statedir concept,
then the path selection will simply return "home" instead (old
behavior). Fixes#9147.
[0]: 4f2884e16d
They should not be modifying the argument, so clearly marking it
as const makes sure we don't do it in the future as well as allows
for read-only optimizations.
c784820454 introduced a bool option type
as a replacement for the flag type, but didn't actually transition and
remove the flag type because it would have been too much mundane work.
Previously, if log-file was set not via a CLI option (e.g. set via
mpv.conf or other config file, or set from a script init phase),
then meaningful early log messages were thrown away because the log
file name was unknown initially.
Such early log messages include the command line arguments, any
options set from mpv.conf, and possibly more.
Now we store up to 5000 early messages before the log file name is
known, and flush them once/if it becomes known, or destroy this
buffer once mpv init is complete.
The implementation is similar and adjacent, but not identical, to an
existing early log system for mpv clients which request a log buffer.
In debug mode the macro causes an assertion failure.
In release mode it works differently and tells the compiler that it can
assume the codepath will never execute. For this reason I was conversative
in replacing it, e.g. in mpv-internal code that exhausts all valid values
of an enum or when a condition is clear from directly preceding code.
So far there was no way to sync video to display and have audio sync to
video without changes in pitch.
With this option the audio does not get resampled (pitch change) and
instead the corrected audio speed is applied to audio filters.
This has been a long standing annoyance - ffmpeg is removing
sizeof(AVPacket) from the API which means you cannot stack-allocate
AVPacket anymore. However, that is something we take advantage of
because we use short-lived AVPackets to bridge from native mpv packets
in our main decoding paths.
We don't think that switching these to `av_packet_alloc` is desirable,
given the cost of heap allocation, so this change takes a different
approach - allocating a single packet in the relevant context and
reusing it over and over.
That's fairly straight-forward, with the main caveat being that
re-initialising the packet is unintuitive. There is no function that
does exactly what we need (what `av_init_packet` did). The closest is
`av_packet_unref`, which additionally frees buffers and side-data.
However, we don't copy those things - we just assign them in from our
own packet, so we have to explicitly clear the pointers before calling
`av_packet_unref`. But at least we can make a wrapper function for
that.
The weirdest part of the change is the handling of the vtt subtitle
conversion. This requires two packets, so I had to pre-allocate two in
the context struct. That sounds excessive, but if allocating the
primary packet is too expensive, then allocating the secondary one for
vtt subtitles must also be too expensive.
This change is not conditional as heap allocated AVPackets were
available for years and years before the deprecation.
Add xoshiro as a PRNG implementation instead of relying
on srand() and rand() from the C standard library. This,
in particular, lets us avoid platform-defined behavior with
respect to threading.
The video sync logic for mpv lies completely within its core at
essentially the highest layer of abstraction. The problem with this is
that it is impossible for VOs to know what video sync mode mpv is
currently using since it has no access to the opts. Because different
video sync modes completely changes how mpv's render loop operates, it's
reasonable that a VO may want to change how it renders based on the
current mode (see the next commit for an example).
Let's just move the video sync option to mp_vo_opts. MPContext, of
course, can still access the value of the option so it only requires
minor changes in player/video.c. Additionally, move the VS_IS_DISP
define from to player/core.h to common/common.h. All VOs already have
access to common/common.h, and there's no need for them to gain access
to everything that's in player/core.h.
FFmpeg recently split version.h into version.h and
version_major.h, and no longer automatically includes
version.h in avcodec.h (and the other libraries). This
should allow mpv to build against ffmpeg git master. See
FFmpeg/ffmpeg@f2da2e1458
These headers are not new, so their inclusion should not affect
backwards compatibility.
Though, only when the output format is matroska, to avoid muxing errors.
This is quite useful when the input has ASS subtitles, as they tend to
rely on embedded fonts.
I've looked and studied the flow in the recorder, and to my
understanding, the packet queue is moot after the initial sync, maybe
even then - but that's beyond me right now.
With the previous choice to mux trailing packets whatever the case, this
doesn't result in any new ill effects (and some missing packets at the
end is no big deal).
Notably, since we don't have to hold onto the packets after we get
muxing, we'll never run into any issues with veeery long GOPs filling up
our queue (resulting in dropped packets and much user chagrin).
For muxing, FFmpeg expects the FLAC extradata to be just the bare STREAMINFO,
and passing the full FLAC extradata (fLaC header and block size, with any
additional channel layout metadata) will result in malformed output, as
ffmpeg will simply prefix another fLaC header in front.
This can be considered to be a bug.
FFmpeg's own demuxers only store the STREAMINFO, hence the naivety, while
our common source of FLAC streams, the matroska demuxer, holds onto the
full extradata. It has been deemed preferable to adjust the extradata upon
muxing, instead of in the demuxer (ffmpeg's FLAC decoder knows to read
the full fLaC extradata).
This fixes muxing FLAC streams, meaning recorder.c or dump-cache.
In commit f7678575a5, wm4 chooses to mux
all remaining packets when mp_recorder_mark_discontinuity() is called and
adds a call to mux_packets(). However, it is called only after flush_packets(),
which clears the packets before they can be muxed out. This has no ill
effects per se - recordings end on keyframes, as before - but judging from
his commit message, the intention explicitly was to output the inter
frames, since long GOPs can mean several seconds of missing content from
the output. So, clear the stream packet queues only after the final mux.
Also, flushing can mean both discarding and committing. What a country!
Avoiding blindly copying the codec_tag between different formats allows
us to mux packets from, say, mpegts streams to matroska, making the
recorder (dump-cache) much more usable as unsupported codec_tags can
make the muxer reject the streams.
if log-file and really-quiet options were used together it could lead to
a completely empty log-file. this is unexpected because we need the
log-file option to work in all cases and produces at least a log of
verbosity -v -v. this is a regression of commit
a600d152d2
move the really quiet check back up, so it's set before the evaluation
of the actual log level, where check for log file, terminal, etc take
place.
If you encode to e.g. an audio-only format, then video is disabled
automatically. This also takes care of the very cryptic error message.
It says "[vo/lavc] codec for video not found". Sort of true, but
obscures the real problem if it's e.g. an audio-only format.
I don't see the point of this. Not doing it may defer an error to later.
That's OK? For now, it seems better to reduce the encoding internal API.
If someone can demonstrate that this is needed, I might reimplement it
in a different way.
This replaces the two buffers (ao_chain.ao_buffer in the core, and
buffer_state.buffers in the AO) with a single queue. Instead of having a
byte based buffer, the queue is simply a list of audio frames, as output
by the decoder. This should make dataflow simpler and reduce copying.
It also attempts to simplify fill_audio_out_buffers(), the function I
always hated most, because it's full of subtle and buggy logic.
Unfortunately, I got assaulted by corner cases, dumb features (attempt
at seamless looping, really?), and other crap, so it got pretty
complicated again. fill_audio_out_buffers() is still full of subtle and
buggy logic. Maybe it got worse. On the other hand, maybe there really
is some progress. Who knows.
Originally, the data flow parts was meant to be in f_output_chain, but
due to tricky interactions with the playloop code, it's now in the dummy
filter in audio.c.
At least this improves the way the audio PTS is passed to the encoder in
encoding mode. Now it attempts to pass frames directly, along with the
pts, which should minimize timestamp problems. But to be honest, encoder
mode is one big kludge that shouldn't exist in this way.
This commit should be considered pre-alpha code. There are lots of bugs
still hiding.
This simply printf()s a concatenation of the provided string and the
relevant escape sequences. No idea what exactly defines this escape
sequence (is it just a xterm thing that is now supported relatively
widely?), and this simply uses information provided on the linked github
issue.
Not much of an advantage over --term-status-msg, though at least this
can have a lower update frequency. Also I may consider setting a default
value, and then it shouldn't conflict with the status message.
Fixes: #1725
Sometimes it's helpful to override this for specific mp_log instances,
because in some specific circumstances you just want to suppress log
file noise you never want to see.
-1 is an allowed value (for suppressing MSGL_FATAL==0). It looks like
the libplacebo wrapper still does this wrong, so it will probably
trigger UB in some cases. I guess I don't care, though.
Add an infrastructure for collecting performance-related data, use it in
some places. Add rendering of them to stats.lua.
There were two main goals: minimal impact on the normal code and normal
playback. So all these stats_* function calls either happen only during
initialization, or return immediately if no stats collection is going
on. That's why it does this lazily adding of stats entries etc. (a first
iteration made each stats entry an API thing, instead of just a single
stats_ctx, but I thought that was getting too intrusive in the "normal"
code, even if everything gets worse inside of stats.c).
You could get most of this information from various profilers (including
the extremely primitive --dump-stats thing in mpv), but this makes it
easier to see the most important information at once (at least in
theory), partially because we know best about the context of various
things.
Not very happy with this. It's all pretty primitive and dumb. At this
point I just wanted to get over with it, without necessarily having to
revisit it later, but with having my stupid statistics.
Somehow the code feels terrible. There are a lot of meh decisions in
there that could be better or worse (but mostly could be better), and it
just sucks but it's also trivial and uninteresting and does the job. I
guess I hate programming. It's so tedious and the result is always shit.
Anyway, enjoy.
May or may not help when dealing with playlist loading in scripts. It's
supposed to help with the mean fact that loading a recursive playlist
will essentially edit the playlist behind the API user's back.
Looks like the recent change to this actually made it crash whenever
audio happened to be initialized first, due to not setting the
mux_stream field before the on_ready callback. Mess a way around this.
Also remove a stray unused variable from ao_lavc.c.
Should give a good deal more explicit control and insight over the
player state.
Some feel a bit pointless, and/or expose internal weirdness. However,
it's not like the existing weirdness didn't exist before, or can be made
go away. (In part, the weirdness is because certain in-between states
are visible. Hiding them would make things simpler, but less flexible.)
Maybe this actually gives users a better idea how the API _should_ look
like, too.
On a side note, this tries to really guarantee that mpctx->playing is
set between playback start/end. For that, the loadfile.c changes assume
that mpctx->playing is set (guaranteed by code above the change), and
that playing->filename is set (probably could never be false; was broken
before and actually would have crashed if that could ever happen; in any
case, also add an assert to playlist.c for this).
playlist_entry_to_index() now tolerates playlist_entrys that are not
part of the playlist. This is also needed for mpctx->playing.
Change all OPT_* macros such that they don't define the entire m_option
initializer, and instead expand only to a part of it, which sets certain
fields. This requires changing almost every option declaration, because
they all use these macros. A declaration now always starts with
{"name", ...
followed by designated initializers only (possibly wrapped in macros).
The OPT_* macros now initialize the .offset and .type fields only,
sometimes also .priv and others.
I think this change makes the option macros less tricky. The old code
had to stuff everything into macro arguments (and attempted to allow
setting arbitrary fields by letting the user pass designated
initializers in the vararg parts). Some of this was made messy due to
C99 and C11 not allowing 0-sized varargs with ',' removal. It's also
possible that this change is pointless, other than cosmetic preferences.
Not too happy about some things. For example, the OPT_CHOICE()
indentation I applied looks a bit ugly.
Much of this change was done with regex search&replace, but some places
required manual editing. In particular, code in "obscure" areas (which I
didn't include in compilation) might be broken now.
In wayland_common.c the author of some option declarations confused the
flags parameter with the default value (though the default value was
also properly set below). I fixed this with this change.
Libav seems rather dead: no release for 2 years, no new git commits in
master for almost a year (with one exception ~6 months ago). From what I
can tell, some developers resigned themselves to the horrifying idea to
post patches to ffmpeg-devel instead, while the rest of the developers
went on to greener pastures.
Libav was a better project than FFmpeg. Unfortunately, FFmpeg won,
because it managed to keep the name and website. Libav was pushed more
and more into obscurity: while there was initially a big push for Libav,
FFmpeg just remained "in place" and visible for most people. FFmpeg was
slowly draining all manpower and energy from Libav. A big part of this
was that FFmpeg stole code from Libav (regular merges of the entire
Libav git tree), making it some sort of Frankenstein mirror of Libav,
think decaying zombie with additional legs ("features") nailed to it.
"Stealing" surely is the wrong word; I'm just aping the language that
some of the FFmpeg members used to use. All that is in the past now, I'm
probably the only person left who is annoyed by this, and with this
commit I'm putting this decade long problem finally to an end. I just
thought I'd express my annoyance about this fucking shitshow one last
time.
The most intrusive change in this commit is the resample filter, which
originally used libavresample. Since the FFmpeg developer refused to
enable libavresample by default for drama reasons, and the API was
slightly different, so the filter used some big preprocessor mess to
make it compatible to libswresample. All that falls away now. The
simplification to the build system is also significant.
This is a central lock (that is to stay and has no reason to go away),
and it was simply made global. This reduces complexity when the original
MPlayer code was changed from single thread + global state to a context
handle.
Having the global lock was still a bit silly if there were multiple mpv
instances in the process, because it would make the instances wait for
each other for no reason. So move it to the per-instance context, which
is trivial enough.
The wakeup_log_file callback was still assuming that mp_msg_lock was
used to control the log file thread, but this changed while I was
writing this code, and forgot to update it. (It doesn't change any
state, which is untypical for condition variable usage. The state that
is changed is protected by another lock instead. But log_file_lock still
needs to be acquired to ensure the signal isn't sent while the thread is
right before the pthread_cond_wait() call, when the lock is held, but
the signal would still be lost.)
Because the buffer's wakeup callback now acquires the lock, the wakeup
callback must be called outside of the buffer lock, to keep the lock
order (log_file_lock > mp_log_buffer.lock). Fortunately, the wakeup
callback is immutable, or we would have needed another dumb leaf lock.
mp_msg_has_log_file() made a similar outdated assumption. But now access
to the log_file field is much trickier; just define that it's only to be
called from the thread that manages the msg state. (The calling code
could also just check whether the log-file option changed instead, but
currently that would be slightly more messy.)
Until now --log-file performed a blocking write to the log file, which
made any calling thread block for I/O. It even explicitly flushed after
every line (to make it tail-able, or to ensure a hard crash wouldn't
lose any of the output). This wasn't so good, because it could cause
real playback problems, which made it infeasible to enable it by
default.
Try to buffer it through a ring buffer and a thread. There's no other
choice but to use a thread, since async I/O on files is generally a big
and unportable pain. (We very much prefer portable pain.) Fortunately,
there's already a ring buffer (mp_log_buffer, normally for the client
API logging hook). This still involves some pretty messy locking. Give
each mp_log_buffer its own lock to make this easier.
This still makes calling threads block if the log buffer is full (unlike
with client API log buffers, which just drop messages). I don't want log
messages to get lost for this purpose. This also made locking pretty
complicated (without it, mp_log_buffer wouldn't have needed its own
lock). Maybe I'll remove this blocking again when it turns out to be
nonsense.
(We could avoid wasting an entire thread by "reusing" some other thread.
E.g. pick some otherwise not real time thread, and make it react to the
log buffer's wakeup callback. But let's not. It's complicated to abuse
random threads for this. It'd also raise locking complexity, because we
still want it to block on a full buffer.)
Although a linked list was ideal at first, there are cases where it
sucks, and became increasingly awkward (with the mpv command API
preferring integer indexes to access the list). In future, we probably
want to add more playlist-related functionality, so better change it to
an array now.
An array isn't always ideal either. Since playlist entries are still
separate objects (because in some cases you need a stable "iterator" to
it), but you still need to efficiently get the next/previous playlist
entry, there's a pl_index field, that needs to be maintained. E.g.
adding an entry at the start of the playlist => update the pl_index
field for all other entries. Well, it's not really worth to do something
more complicated to avoid these things.
This commit is probably buggy as shit. It's not like I bothered to test
everything. That's _your_ role.
mpv has a very weak and very annoying policy that determines whether a
playlist should be used or not. For example, if you play a remote
playlist, you usually don't want it to be able to read local filesystem
entries. (Although for a media player the impact is small I guess.)
It's weak and annoying as in that it does not prevent certain cases
which could be interpreted as bad in some cases, such as allowing
playlists on the local filesystem to reference remote URLs. It probably
barely makes sense, but we just want to exclude some other "definitely
not a good idea" things, all while playlists generally just work, so
whatever.
The policy is:
- from the command line anything is played
- local playlists can reference anything except "unsafe" streams
("unsafe" means special stream inputs like libavfilter graphs)
- remote playlists can reference only remote URLs
- things like "memory://" and archives are "transparent" to this
This commit does... something. It replaces the weird stream flags with a
slightly clearer "origin" value, which is now consequently passed down
and used everywhere. It fixes some deviations from the described policy.
I wanted to force archives to reference only content within them, but
this would probably have been more complicated (or required different
abstractions), and I'm too lazy to figure it out, so archives are now
"transparent" (playlists within archives behave the same outside).
There may be a lot of bugs in this.
This is unfortunately a very noisy commit because:
- every stream open call now needs to pass the origin
- so does every demuxer open call (=> params param. gets mandatory)
- most stream were changed to provide the "origin" value
- the origin value needed to be passed along in a lot of places
- I was too lazy to split the commit
Fixes: #7274
console.lua uses "terminal-default" logging, which is supposed to return
all messages logged to the terminal to the API. Internally, this is
translated to MP_LOG_BUFFER_MSGL_TERM, which is MSGL_MAX+1, because it's
not an actual log level (blame C for not having proper sum types or
something).
Unfortunately, this unintentionally raised the internal log level to
MSGL_MAX+1. It still functioned as intended, because log messages were
simply filtered at a "later" point. But it led to every message being
formatted even if not needed. More importantly, it made mp_msg_test()
pointless (code calls this to avoid logging in "expensive" cases and if
the messages would just get discarded). Also, this broke libplacebo
logging, because the code to map the log messages did not expect a level
higher than MSGL_MAX (mp_msg_level() returned MSGL_MAX+1 too).
Fix this by not letting the dummy level value be used as log level.
Messages at terminal log level will always make it to the inner log
message dispatcher function (i.e. mp_msg_va() will call
write_msg_to_buffers()), so log buffers which use the dummy log level
don't need to adjust the actual log level at all.
It did that because there was no other way. It used a lock-free ring
buffer, which does not support this. Use a "manual" ring buffer with
explicit locks instead, and drop messages from the start.
(We could have continued to use mp_ring, but it was already too late,
and although mp_ring is fine, using it for types other than bytes looked
awkward, and writing a ring buffer yet again seemed nicer. At least it's
not C++, where mp_ring would have been a template, and everything would
have looked like shit soup no matter what.)
In the referenced commit, I forgot about this part, and a client which
tried to use this was actually not woken up when needed.
(Also why the hell does the subject line of that commit say "removed"?)
Fixes: 8c2d73f112
As preparation for making repl.lua part of the core (maybe), add some
mechanisms which are supposed to improve its behavior.
Add a silent mode. Calling mpv_request_log_messages() with the log level
name prefixed with "silent:" will disable logging from the API user's
perspective. But it will keep the log buffer, and record new messages,
without returning them to the user. If logging is enabled again by
requesting the same log level without "silent:" prefix, the buffered log
messages are returned to the user at once. This is not documented,
because it's far too messy and special as that I'd want anyone to rely
on this behavior, but it will be perfectly fine for an internal script.
Another thing is that we record early startup messages. The goal is to
make the repl.lua script show option and config parsing file errors.
This works only with the special "terminal-default" log level.
In addition, reduce the "terminal-default" capacity to only 100 log
messages. If this is going to be enabled by default, it shouldn't use
too much resources.
Options marked with this flag were changed to strictly read-only after
initialization (mpv_initialize() in the client API, after option parsing
and config file loading with the CLI player).
This used to be necessary, because there was a single option struct that
could be accessed by multiple threads. For example, --config-dir sets
MPOpts.force_configdir, which was read whenever anything accessed the
mpv config dir (which could be on different threads, e.g. font
initialization tries to lookup fonts.conf from an arbitrary thread).
This isn't needed anymore, because threads now access these in a thread
safe way. In the case of --config-dir, the path is actually just copied
on init.
This M_OPT_FIXED mechanism is thus not strictly needed anymore. It still
prevents writing to some options that cannot take effect at runtime, but
even that can be dropped. In general, all mpv options can be changed any
time at runtime, even if they never take effect, and there's no need to
make an exception for a very low number of options. So just get rid of
it.
This is something relatively frequently needed, and there must be half a
dozen ad-hoc implementations in mpv. The next commit uses this, the
suspected duplicate implementations are hiding.
To be used in the next commit.
According to compiler explorer, __builtin_clz is very widely available,
and it barely makes sense to provide a fallback. clang also eats this
(and identifies at least as GCC 4). Actually, there's doubt that a fast
log2 implementation is needed at all (I guess UTF-8 parsing needs it,
but something UTF-8-specific would probably make it faster than using
log2). So the fallback is just something naive.
Before this commit, the status line used terminal control codes only if
stderr was a terminal. I'm not sure why this was done, and git blame
tracks it back to a huge commit by me, which changed all of the terminal
handling.
A user complained, so just stop treating this specially for no reason.
Fixes: #6617
mpv warned if the FFmpeg runtime library version was not exactly the
same as the build version. This seemed to cause frequent conflicts. At
this point, most mpv code probably adheres to the FFmpeg ABI rules, and
FFmpeg stopped breaking ABI "accidentally". Another source of problems
were mixed FFmpeg/Libav installations, something which nobody does
anymore. It's not "our" job to check and enforce ABI compatibility
either. So I guess this behavior can be removed.
OK, still check for incompatible libraries (according to FFmpeg
versioning rules), i.e. different major versions, or if the build
version is newer than the runtime version. For now.
The comment about ABI problems is still true. In particular, the
bytes_read field mentioned in the removed comment is still accessed, and
is still an ABI violation. Have fun.
Although this was sort of elegant, it just seems to complicate things
slightly. Originally, the API meant that you cache mp_recorder_sink
yourself (which would avoid the mess of passing an index around), but
that too seems slightly roundabout.
In a later change, I want to change the set of streams passed to
mp_recorder_create(), and then I'd have to keep track of the index for
each stream, which would suck. With this commit, I can just pass the
unambiguous sh_stream to it, and it will be guaranteed to match the
correct stream.
The disadvantages are barely worth discussing. It's a new linear search
per packet, but usually only 2 to 4 streams are active at a time. Also,
in theory a user could want to write 2 streams using the same sh_stream
(same metadata, just writing different packets or so), but in practice
this is never done.
This is the muxer used by all 3 stream recording features (why are there
so many?). It tried hard to avoid writing broken files. In particular,
it buffered packets until it new there was a keyframe packet (which, in
mpv's/FFmpeg's definition, mean seek points from which decoding can
resume), or final EOF. The danger that was probably considered here was
that due to video frame reordering, not muxing some trailing, missing
packets of a keyframe range could lead to broken decoding or skipped
frames, so better discard packets belonging to an incomplete range.
Sounds like a good idea so far.
Unfortunately, this will drop an entire keyframe range even if the
current packet run is complete and mp_recorder_mark_discontinuity() is
called, simply because recorder.c can not know that the next packet
would have been a keyframe.
It seems better to mux all packets to avoid losing valid data, even if
it means that sometimes packets/frames will be missing from the file. It
benefits especially the dump-cache command, which will call the function
to signal a discontinuity after every range. Before this commit, it
discarded the last packets, even if they were perfectly fine.
(An alternative solution for dump-cache would have been a second
discontinuity marker function, that communicates that the current packet
range is complete. But this commit's solution is simpler and overall
more robust, at the danger of producing more semi-broken files.)
This may make some of the complex buffering/waiting logic in recorder.c
pointless.
Untested (in this final form).
These macros explicitly honor MP_NOPTS_VALUE, instead of implicitly
relying on the fact that this value is the lowest allowed value.
In addition, this changes one case to use MP_NOPTS_VALUE instead of
INFINITY, also a cosmetic change.
I think I repeated this inline in some places (or maybe not), and some
experimental but discarded code used it. Add it anyway, maybe it'll be
useful. Or it'll give someone a chance to get a contribution into mpv by
removing an unused macro.
This commit rips out the entire mpv vulkan implementation in favor of
exposing lightweight wrappers on top of libplacebo instead, which
provides much of the same except in a more up-to-date and polished form.
This (finally) unifies the code base between mpv and libplacebo, which
is something I've been hoping to do for a long time.
Note: The ra_pl wrappers are abstract enough from the actual libplacebo
device type that we can in theory re-use them for other devices like
d3d11 or even opengl in the future, so I moved them to a separate
directory for the time being. However, the rest of the code is still
vulkan-specific, so I've kept the "vulkan" naming and file paths, rather
than introducing a new `--gpu-api` type. (Which would have been ended up
with significantly more code duplicaiton)
Plus, the code and functionality is similar enough that for most users
this should just be a straight-up drop-in replacement.
Note: This commit excludes some changes; specifically, the updates to
context_win and hwdec_cuda are deferred to separate commits for
authorship reasons.
--record-file is nice, but only sometimes. If you watch some sort of
livestream which you want to record, it's actually much nicer not to
record what you're currently "seeing", but anything you're receiving.
Since this function is called with packets on the stack, trying to free
them makes no sense. Instead, it should unref (which is what
`av_interleaved_write_frame` does anyway, rather than freeing).
Also, the calling code tried unreffing the packet a second time, even
after it was "freed" by the callee in the failure case - and after
ownership was taken over by `av_interleaved_write_frame` in the
successful case. Both of these cases were wrong.
This was always a legacy thing. Remove it by applying an orgy of
mp_get_config_group() calls, and sometimes m_config_cache_alloc() or
mp_read_option_raw().
win32 changes untested.
The path functions need to access the option that forces non-default
config directories. Just add it as a field to mpv_global - it seems
justified. The accessed options were always enforced as immutable after
init, so there's not much of a change.
Them being separate is just dumb. Replace them with a single
demux_free() function, and free its stream by default. Not freeing the
stream is only needed in 1 special case (demux_disc.c), use a special
flag to not free the stream in this case.
Don't allow it to freeze everything when loading a playlist from network
(although you definitely shouldn't do that, but whatever).
This also affects the really obscure --ordered-chapters-files option.
The --playlist option on the other hand has no choice but to freeze the
shit, because there's no concept of aborting the player during command
line parsing.
Until recently, ao_lavc and vo_lavc started encoding whenever the core
happened to send them data. Since audio and video are not initialized at
the same time, and the muxer was not necessarily opened when the first
encoder started to produce data, the resulting packets were put into a
queue. As soon as the muxer was opened, the queue was flushed.
Change this to make the core wait with sending data until all encoders
are initialized. This has the advantage that we don't need to queue up
the packets.
While I'm not sure whether it really works, at least it writes the pass1
log correctly now.
How 2-pass stat output is supposed to interact with the new decode API
is rather fishy. ffmpeg.c does the same, and before this change, the
log was not written on EOF (when at least libvpx actually outputs its
stats).
It was documented for --screenshot-template, but apparently never
implemented.
This value is not explicitly rounded, other than for printf() %f default
formatting (which rounds to 6 digits).
This means that a time of 4.5678 is displayed as "00:00:04.568" when the
format string is "%H:%M:%S.%T". Likewise, 59.99999 will be displayed as
"00:01:00.000". Before this change, the sub-ms times were just
truncated.
Requested by TheAMM.
AVFilterContext instances support some additional AVOptions over the
actual filter. This includes useful options like "threads". We didn't
support setting those for the "direct" wrapper (--vf=yadif:threads=1
failed). Change this. It requires setting options on the AVFilterContext
directly, except the code for positional parameters still needs to
access the actual filter's AVOptions.
The main change is that we wait with opening the muxer ("writing
headers") until we have data from all streams. This fixes race
conditions at init due to broken assumptions in the old code.
This also changes a lot of other stuff. I found and fixed a few API
violations (often things for which better mechanisms were invented, and
the old ones are not valid anymore). I try to get away from the public
mutex and shared fields in encode_lavc_context. For now it's still
needed for some timestamp-related fields, but most are gone. It also
removes some bad code duplication between audio and video paths.
Removes a good hunk of weird code.
This loses qscale "emulation", some logging, and the fact that duplicate
keys for values starting with +/- were added with AV_DICT_APPEND. I
don't assign those any importance, even if they are user-visible
changes.
The new M_OPT_ flag is just so that nothing weird happens for other
key-value options, which do not interpret a "help" key specially.
sfan5
Dudemanguy
Jan Ekström
Christoph Heinrich
Thomas Weißschuh
Avi Halachmi (:avih)
Philip Langdale
Leo Izen
TheAMM
der richter
wm4
ekisu
Niklas Haas
Anton Kindestam