Instead of passing through double float timestamps opaquely, pass real
timestamps. Do so by always setting a valid timebase on the
AVCodecContext for audio and video decoding.
Specifically try not to round timestamps to a too coarse timebase, which
could round off small adjustments to timestamps (such as for start time
rebasing or demux_timeline). If the timebase is considered too coarse,
make it finer.
This gets rid of the need to do this specifically for some hardware
decoding wrapper. The old method of passing through double timestamps
was also a bit questionable. While libavcodec is not supposed to
interpret timestamps at all if no timebase is provided, it was
needlessly tricky. Also, it actually does compare them with
AV_NOPTS_VALUE. This change will probably also reduce confusion in the
future.
We don't support this anymore.
This tries to exit in a controlled way after command line options are
applied in order to honor logging options and, in case of libmpv, not to
kill the host. Not sure if it would be better to just vomit text to
stderr and call abort().
AVFormatContext.codec is deprecated now, and you're supposed to use
AVFormatContext.codecpar instead.
Handle this for all of the normal playback code.
Encoding mode isn't touched.
The old algorithm produced results which were not uniformly distributed,
i.e. some particular shuffles were preferred over others.
The new algorithm is an implementation of the Fisher-Yates shuffle which
is guaranteed to shuffle uniformly given a sufficiently uniform rand()
and ignoring potential floating-point errors.
Signed-off-by: wm4 <wm4@nowhere>
Completely pointless abominations that FFmpeg refuses to remove. They
are ancient, long deprecated API which we can't use anymore. They
confused users as well.
Pretend that they don't exist. Due to the way --vd works, they can't
even be forced anymore. The older hack which explicitly rejects these
can be dropped as well.
The goal is reducing log messups (which happen surprisingly often) by
buffering partial lines in mp_log. This is still not 100% reliable, but
better.
The extrabuffers for MSGL_STATUS and MSGL_STATS are not needed anymore,
because a separate mp_log instance can be used if problems really occur.
Also, give up, and replace the snprintf acrobatics with bstr.
mp_log.partial has a quite subtle problem wrt. talloc: talloc parents
can not be used, because there's no lock around the internal talloc
structures associated with mp_log. Thus it has to be freed manually,
even if this happens through a talloc destructor.
We want to add a prefix to the ffmpeg log message, so we called mp_msg
multiple times until now. But logging such partial lines is a race
condition, because there's only one internal mp_msg buffer, and no
external mp_msg locks.
Avoid this by building the message on a stack buffer.
I might make a mp_log-local partial line buffer, but even then av_log()
can be called from multiple threads, while targetting the same mp_log.
(Really, ffmpeg's log API needs to be fixed.)
Until now, a rather large stack buffer was used for this, and also a
static buffer in mp_log_root. The latter was added to buffer partial
lines, and the stack buffer was used only for MSGL_STATUS and MSGL_STATS
(I guess because these are the most likely/severe to clash with partial
line buffering).
Make the buffer in mp_log_root dynamically sized, so we don't get cut
off log lines if the text is excessively large. (The OpenGL extension
list dumped by vo_opengl is such an example.)
Since we still have to support partial line buffering (FFmpeg's log
callbacks leave no other choice), keep the stack buffer. But make it
smaller; there's no way all ~6KB are going to be needed in any
situation.
The complex filter support that will be added makes much more complex
use of libavfilter, and I'm not going to bother with adding hacks to
keep libavfilter optional.
Will be helpful for the coming filter support. I planned on merging
audio/video decoding, but this will have to wait a bit longer, so only
remove the duplicate status codes.
This covers source files which were added in mplayer2 and mpv times
only, and where all code is covered by LGPL relicensing agreements.
There are probably more files to which this applies, but I'm being
conservative here.
A file named ao_sdl.c exists in MPlayer too, but the mpv one is a
complete rewrite, and was added some time after the original ao_sdl.c
was removed. The same applies to vo_sdl.c, for which the SDL2 API is
radically different in addition (MPlayer supports SDL 1.2 only).
common.c contains only code written by me. But common.h is a strange
case: although it originally was named mp_common.h and exists in MPlayer
too, by now it contains only definitions written by uau and me. The
exceptions are the CONTROL_ defines - thus not changing the license of
common.h yet.
codec_tags.c contained once large tables generated from MPlayer's
codecs.conf, but all of these tables were removed.
From demux_playlist.c I'm removing a code fragment from someone who was
not asked; this probably could be done later (see commit 15dccc37).
misc.c is a bit complicated to reason about (it was split off mplayer.c
and thus contains random functions out of this file), but actually all
functions have been added post-MPlayer. Except get_relative_time(),
which was written by uau, but looks similar to 3 different versions of
something similar in each of the Unix/win32/OSX timer source files. I'm
not sure what that means in regards to copyright, so I've just moved it
into another still-GPL source file for now.
screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but
they're all gone.
Makes the next commit simpler. It's probably a bad idea to add more
fields to the global state, but on the other hand the client API state
is pretty much per-instance anyway. It also will help with things like
the proposed libmpv custom stream API.
mp_parse_escape() is used by the JSON parser in json.c, and JSON allows
escaping "/" (solidus).
Although it makes no sense, apparently Javascript traditionally allowed
that as escape sequence for working around issues with embedding
Javascript in HTML. (Or something like this must have been the history
of this issue.) Since it's valid in Javascript, it had to be valid in
JSON as well, and JSON explicitly specifies it as valid escape.
Fixes#2694.
If you do "mpv /bla/", and then branch out into sub-directories using
playlist navigation, and then used quit and watch later, then playing
the same directory did not resume from the previous point. This was
because resuming is based on the path hash, so a path prefix can't be
detected when resuming the parent directory.
Solve this by writing each path prefix when playing directories is
involved. (This includes all parent paths, so interestingly, "mpv /"
would also resume in the above example.)
Something like this was requested multiple times, and I want it too.
This fixes initial decoding of some samples. See #1341.
According to Libav devs, this should be considered a libavcodec bug, but
as it's hard to fix, here we go.
As the removed comment says, not copying this field may cause problems
on older libav* releases. See also commit 5f7de399.
Remove this, as newer FFmpeg releases are available. As of this commit,
use of mpv with FFmpeg 2.5.x and below, or Libav 11 and below is not
recommended, and may lead to random video decoding issues. (Although the
failure cases are apparently somewhat obscure.)
That just makes no sense, but seems to be a somewhat common user error.
The detection is not perfect. It's conceivable that EXT-X-... headers
are used in normal m3u playlists. After all, HLS playlists are by
definition a compatible extension to m3u playlists, as stupid as it
sounds.
Client API users can enable log output with mpv_request_log_messages().
But you can enable only a single log level. This is normally enough, but
the --msg-level option (which controls the terminal log level) provides
more flexibility. Due to internal complexity, it would be hard to
provide the same flexibility for each client API handle. But there's a
simple way to achieve basically the same thing: add an option that sends
log messages to the API handle, which would also be printed to the
terminal as by --msg-level.
The only change is that we don't disable this logic if the terminal is
disabled. Instead we check for this before the message is output, which
in theory can lower performance if messages are being spammed. It could
be handled with some more effort, but the gain would be negligible.
This happens with av_log(NULL, ...) calls. Drop the "?: " fallback
prefix, because it was confusing.
(Of course FFmpeg should not do this at all, but it's a very long way to
making the FFmpeg log callback sane.)
This is slightly "dangerous", because it could overwrite a log callback
another library has set, after we've set our own callback. But it's
probably still slightly better than leaving our own callback, which will
run the fallback code if no mpv instance is set. (Multiple mpv instances
sharing the same global state will safely avoid overwriting each other's
log callback.)
Note that we can't do much better, because the global state in FFmpeg is
obviously insane.
This provides a new method for enabling spdif passthrough. The old
method via --ad (--ad=spdif:ac3 etc.) is deprecated. The deprecated
method will probably stop working at some point.
This also supports PCM fallback. One caveat is that it will lose at
least 1 audio packet in doing so. (I don't care enough to prevent this.)
(This is named after the old S/PDIF connector, because it uses the same
underlying technology as far as the higher level protoco is concerned.
Also, the user should be renamed that passthrough is backwards.)
Right now, the default behavior is to pick the numerically lowest screen
ID that overlaps the window in any way - but this means that mpv will
decide to pick an ICC profile in a pretty arbitrary way even if the
window only overlaps another screen by a single pixel.
The new behavior is to query it based on the center of the window
instead.
This was traditionally needed to silence terminal output from errors
during command line parsing preparsing. Preparsing is done so that
options controlling the terminal and config files are parsed and applied
first, with a second command line parsing pass applying all other
options, _and_ printing error messages for the preparsed ones.
But the hack silencing log output during the preparse pass is actually
not needed anymore, since the terminal is enabled only after preparsing
is finished. update_logging() in main.c does this.
So as long as update_logging() is called before
m_config_preparse_command_line(), this will work.
This duplicates the logic which FFmpeg's libavcodec uses. The effects
are unknown, though it's somewhat clear that a single thread doesn't
necessarily saturate a single CPU.
(Eventually we should just let FFmpeg auto-init the thread count, but
for now I prefer it this way, so e.g. verbose mode will print the
thread count.)
It was possible to make the player play local files by putting rar://
links into remote playlists, and some other potentially unsafe things.
Redo the handling of it. Now the rar-redirector (the thing in
demux_playlist.c) sets disable_safety, which makes the player open any
playlist entries returned. This is fine, because it redirects to the
same file anyway (just with different selection/interpretation of the
contents). On the other hand, rar:// itself is now considered fully
unsafe, which means that it is ignored if found in normal playlists.
The code in main.c calls exit() explicitly, but the code is actually
easier to follow by simply exiting from main() instead. The exit() call
in av_log.c happens only on severely broken builds, so replace it with
abort().
(Shuts up rpmlint warnings.)
Make it accept "," as separator, instead of only ":". Do this by using
the key-value-list parser. Before this, the option was stored as a
string, with the option parser verifying that the option value as
correct. Now it's stored pre-parsed, although the log levels still
require separate verification and parsing-on-use to some degree (which
is why the msg-level option type doesn't go away).
Because the internal type changes, the client API "native" type also
changes. This could be prevented with some more effort, but I don't
think it's worth it - if MPV_FORMAT_STRING is used, it still works the
same, just with a different separator on read accesses.
