Should help with debugging, and might be slightly more userfriendly.
Note that this is called manually in multiple entry-points, instead of
the functions doing the actual work (like mp_remove_track()). This is
done so that exiting the player or calling the sub_reload command won't
print redundant in-between states.
During seeking, and there is momemtarily no new data available yet, the
player will display the seek target as current time. Clamp this time to
the known time range as implied by the start time and the duration of
the file.
This improves behavior especially when seeking in audio files, for which
this for some reason triggers rather often. There were some users
complaining about this.
This makes behavior worse for files with timestamp resets, or
incorrectly reported duration. (The latter is relatively common,
e.g. libavformat shortcomings, or incomplete files.)
This will change the format option to "bestaudio/best" instead of
passing the "-x" argument to yt-dl.
Prevents the video still being downloaded in the new mpv versions where
the yt-dl format is set to "best" by default.
This could make the player crash on exit if the "sub_reload" command was
used successfully. the reason was that the mpctx->sources array could
have dangling pointers to the unloaded demuxers.
Also fix a memory leak by actually always freeing the per-stream
subtitle decoders (which are a hack to make ordered chapters behave
better).
Fixes PNG cover art not showing up immediately (for example when running
with --pause).
libavformat exports embedded cover art as a single packet. For example,
a PNG attachment simply contains the PNG image, which can be sent to the
decoder. Normally you would expect that the PNG decoder would return 1
frame for 1 packet, without any delays. But this stopped working, and it
incurs a 1 frame delay.
This is perfectly legal (even if unexpected), so let our code feed the
decoder packets until we get something back. (In theory feeding the
packet instead of a real flush packet is still somewhat questionable.)
last_av_difference can be MP_NOPTS_VALUE under certain circumstances
(like no video timestamp yet). This triggered the desync message,
because fabs(MP_NOPTS_VALUE) is quite a large value. We don't want to
show a message in this situation.
The options don't change, but they're now declared and used privately by
demux_mkv.c. This also brings with it a minor refactor of the subpreroll
seek handling - merge the code from playloop.c into demux_mkv.c. The
change in demux.c is pretty much equivalent as well.
It's annoying and unnecessary. They can be manually loaded if really
needed (for things like previewing).
Also remove the #if. It was for suppressing warnings, and we don't need
to be so careful about this in the relatively obscure encoding mode.
Approximate time of video buffered in the demuxer, in seconds. Same as
`demuxer-cache-duration` but returns the last timestamp of bufferred
data in demuxer.
Signed-off-by: wm4 <wm4@nowhere>
This will be used in the following commit, which adds screenshot_raw.
The reasoning is that this will be better for binding scripting
languages.
One could special-case the screenshot_raw commit and define fixed
semantics for passing through a pointer using the current API, like
formatting a pointer as string. But that would be ridiculous and
unclean.
Remove the old implementation for these properties. It was never very
good, often returned very innaccurate values or just 0, and was static
even if the source was variable bitrate. Replace it with the
implementation of "packet-video-bitrate". Mark the "packet-..."
properties as deprecated. (The effective difference is different
formatting, and returning the raw value in bits instead of kilobits.)
Also extend the documentation a little.
It appears at least some decoders (sipr?) need the
AVCodecContext.bit_rate field set, so this one is still passed through.
It's entirely useless, especially now that vo.c handles screenshots in a
generic way, and requires no special VO support. There are some
potential weird use-cases, but actually I've never seen it being used.
The old behavior does not make too much sense after all. If you don't
want to file to be overwritten, the user can check this manually.
This is a change in behavior - let's hope nobody actually relied on it.
libavcodec makes it impossible to distinguish dropped frames (requested
with AVCodecContext.skip_frame), and cases when the decoder simply does
not return a frame by default (such as with VP9, which has invisible
reference frames).
This confuses users when decoding VP9 video. It's basically a cosmetic
issue, so just paint it over by ignoring them if framedropping is
disabled.
When playing cover art, it conceptually reaches EOF as soon as the image
was put on the VO, causing the EOF message to be repeated every time new
audio was decoded. Just silence the message.
Apparently the standard handles can be set to bogus values on XP. Use
GetFileType to check whether they refer to an actual file/pipe/etc. The
logic used by is_valid_handle() is now pretty similar to what the CRT
uses to check for valid stdio handles.
If mpv is started from Explorer or the Start Menu, it will have no
console and no standard IO handles. In this case, it's fairly safe to
enable the pseudo-gui profile.
Previously, mpv.exe used the --terminal option to decide whether to
attach to the parent process's console, which made it impossible to tell
whether mpv would attach to the console before the config files were
parsed. Instead, make mpv always attach to the console when launched
from the console wrapper (mpv.com) and never attach otherwise. This will
be useful for the next commit, which will use the presence of the
console to decide whether to use the pseudo-gui profile.
This change should also be an improvement in behavior. The old code
would attach to the parent process's console, regardless of whether it
was mpv.com or some other program like cmd.exe. This could be confusing,
since mpv.exe is marked as a Windows GUI program and shouldn't write
text to its parent process's console when launched directly. (See #768.)
Visual Studio does something similar with its devenv.com wrapper.
devenv.exe only attaches to the console when launched from devenv.com.
Add a platform-specific entry-point for Windows. This will allow some
platform-specific initialization to be added without the need for ugly
ifdeffery in main.c.
As an immediate advantage, mpv can now use a unicode entry-point and
convert the command line arguments to UTF-8 before passing them to
mpv_main, so osdep_preinit can be simplified a little bit.
Remove --keep-open. Switch to --idle=once. This effectively makes the
player quit after end of playback, but still shows the idle screen if it
was started with no files.
Starting the command line player with --no-terminal, the terminal was
sitll initialized. This happened because update_logging() used the
option value before the options were parsed. Fix by moving down the
initialization to before the point where it's actually needed.
When setting options like --no-video, ytdl_hook adds the "-x" argument
to youtube-dl, so that bandwith is saved by not downloading the video on
some sites.
The af_add() function has a problem: if the inserted filter returns
AF_DETACH during init, the function will have a dangling pointer. Until
now this was avoided by making sure none of the used filters actually
return AF_DETACH, but it's getting infeasible.
Solve this by requiring passing an unique label to af_add(), which is
then used instead of the pointer.
Only reinit filters if it's actually needed. This is also slightly
easier to understand: if you look at the code, it should now be more
obvious why a reinit is needed (hopefully).
Avoids a confusing message printed by the vdpau code when taking a
screenshot while using software decoding (because obviously GPU readback
won't work on normal in-memory video frames).
Use OPT_CHOICE_C() instead of the custom parser. The functionality is
pretty much equivalent.
(On a side note, it seems --video-stereo-mode can't be removed, because
it controls whether to "reduce" stereo video to mono, which is also the
default. In fact I'm not sure how this should be handled at all.)
This can be set to select a number of default settings that help mpv
pretend that it has a GUI.
I haven't decided yet whether I really want to use the profile mechanism
for this. There are a number of weird details that are not so easy to
handle with profiles, such as disabling pseudo-gui mode again (you can't
unset profiles directly). So this might change. But for now it will do.
There also should be a better way to store builtin profiles.
Unfortunately, the old crappy MPlayer config file parser needs on-disk
files, so just use a bunch of function calls for now.
It simply doesn't work, and is hard to make work. Lua 5.3 is a different
language from 5.1 and 5.2, and is different enough to make adding
support a major issue. Most importantly, 5.3 introduced integer types,
which completely mess up any code which deals with numbers.
I tried to make this a compile time check, but failed. Still at least
try to avoid selecting the 5.3 pkg-config package when the generic "lua"
name is used (why can't Lua upstream just provide an official .pc
file...). Maybe this actually covers all cases.
Fixes#1729 (kind of).
Remove the colorspace-related top-level options, add them to vf_format.
They are rather obscure and not needed often, so it's better to get them
out of the way. In particular, this gets rid of the semi-complicated
logic in command.c (most of which was needed for OSD display and the
direct feedback from the VO). It removes the duplicated color-related
name mappings.
This removes the ability to write the colormatrix and related
properties. Since filters can be changed at runtime, there's no loss of
functionality, except that you can't cycle automatically through the
color constants anymore (but who needs to do this).
This also changes the type of the mp_csp_names and related variables, so
they can directly be used with OPT_CHOICE. This probably ended up a bit
awkward, for the sake of not adding a new option type which would have
used the previous format.
It was already accidentally used unconditionally by command.c.
Apparently this worked well for us, so don't change anything about,
but should it be unavailable, fail at configure time instead of compile
time.
wm4
ChrisK2
robin
xylosper
Marcin Kurczewski
James Ross-Gowan
Sebastian Mayr
Niklas Haas