Reasons why you'd want this see manpage additions. Disabled by default,
because it would increase latency of live streams by default. (Or well,
at least it would be another problem when trying getting lower latency.)
This tried to be clever by waiting for a longer time each time the
buffer was underrunning, or shorter if it was getting better. I think
this was pretty weird behavior and makes no sense. If the user really
wants the stream to buffer longer, he/she/it can just pause the player
(the network caches will continue to be filled until they're full).
Every time I actually noticed this code triggering in my own use, I
didn't find it helpful. Apart from that it was pretty hard to test.
Some waiting is needed to avoid that the player just plays the available
data as fast as possible (to compensate for late frames and underrunning
audio). Just use a fixed wait time, which can now be controlled by the
new --cache-pause-wait option.
Don't drop the stream buffers, because the read call (that must have
been failing) might try to extend an existing read buffer in the first
place. Just move the messy seek logic to stream_lavf.c. (In theory,
stream_lavf should probably make libavformat connect at the correct
offset instead of using a seek to reconnect it again. This patch doesn't
fix it, but at least it's a good argument to have the messing with the
position not in the generic code.)
Also update the comment about avio not supporting reconnecting. It has
that feature now. Maybe we should use it, but only after it gets fixed.
Remove them from the big MPOpts struct and move them to their sub
structs. In the places where their fields are used, create a private
copy of the structs, instead of accessing the semi-deprecated global
option struct instance (mpv_global.opts) directly.
This actually makes accessing these options finally thread-safe. They
weren't even if they should have for years. (Including some potential
for undefined behavior when e.g. the OSD font was changed at runtime.)
This is mostly transparent. All options get moved around, but most users
of the options just need to access a different struct (changing sd.opts
to a different type changes a lot of uses, for example).
One thing which has to be considered and could cause potential
regressions is that the new option copies must be explicitly updated.
sub_update_opts() takes care of this for example.
Another thing is that writing to the option structs manually won't work,
because the changes won't be propagated to other copies. Apparently the
only affected case is the implementation of the sub-step command, which
tries to change sub_delay. Handle this one explicitly (osd_changed()
doesn't need to be called anymore, because changing the option triggers
UPDATE_OSD, and updates the OSD as a consequence). The way the option
value is propagated is rather hacky, but for now this will do.
It was split at least across osd.c and sd_ass.c/sd_lavc.c. sd_lavc.c
actually ignored most of the more obscure subtitle timing things.
There's no reason for this - just move it all to dec_sub.c (mostly from
sd_ass.c, because it has some of the most complex stuff).
Now timestamps are transformed as they enter or leave dec_sub.c.
There appear to have been some subtle mismatches about how subtitle
timestamps were transformed, e.g. sd_functions.accepts_packet didn't
apply the subtitle speed to the timestamp. This patch should fix them,
although it's not clear if they caused actual misbehavior.
The semantics of SD_CTRL_SUB_STEP are slightly changed, which is the
reason for the changes in command.c and sd_lavc.c.
Was only available with --demuxer-lavf-format=help and the demuxer
needed to be used for it to actually print the list.
This can be used in the future to check if 'dash' support was compiled
with FFmpeg so ytdl_hook can use it instead. For now, dashdec is too
rudimentary to be used right away.
The old code tried to make sure at all times to try to read a new
packet. Only once that was read, it tried to retrieve new video or audio
frames the decoder might already have decoded.
Change this to strictly read frames from the decoder until it signals
that it wants a new packet, and only then read and feed a new packet.
This is in theory nicer, follows the libavcodec recommended data flow,
and and reduces the minimum latency by 1 frame.
This merely requires switching the order in which those calls are done.
Normally, the decoder will return only 1 frame until a new packet is
required. If we would just feed it 1 packet, return DATA_AGAIN, and wait
until the next frame is decoded, we would run the playloop 1 time too
often for no reason (which is fine but might have some overhead). To
avoid this, try to read a frame again after possibly feeding a packet.
For this reason, move the feed/read code to its own functions each,
instead of merely moving the code.
The audio and video code for this particular thing is basically
duplicated. The idea is to unify them one day, so make the change to
both. (Doing this for video is the real motivation for this change, see
below.)
The video code change is slightly more complicated, because we have to
care about the framedrop counting (which is just a heuristic, but for
now considered better than nothing, and possibly considered required to
warn the user of framedrops happening - maybe).
Apparently this change helps with stalling streams on Android with the
mediacodec wrapper and mpeg2 decoder implementations which deinterlace on
decoding (and return 2 frames per packet).
Based on an idea and observations by tmm1.
Uses the EGL width/height by default when the user fails to set
the android-surface-width/android-surface-height options.
This means the vo-resize command is optional, and does not need to
be implemented on android devices which do not support rotation.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Now macosx_menubar.m and mpv.rc (win32) use the same copyright string.
(This is a bit roundabout, because mpv.rc can't use C constants. Also
the C code wants to avoid rebuilding real source files if only version.h
changed, so only version.c includes version.h.)
This seems to fix issues when building on windows where compiling mpv.rc
after a `waf clean` resulted in a failure because version.h was not
always present
Apparently some Intel drivers have a bug where copying from staging
buffers to constant buffers does not work. We used to keep a copy of the
buffer data in a staging buffer to enable partial constant buffer
updates. To work around this bug, keep the copy in talloc-allocated
system memory instead.
There doesn't seem to be any noticable performance difference from
keeping the copy in system memory. Our cbuffers are probably too small
for it to matter anyway.
See also: https://crbug.com/593024Fixes#5293
This reverts commit 9513165c99
and commit 4efe330efb.
I had changed --loop-file to interact with --start to work
the same way that --loop-playlist does. (That is, --loop-file
seeks to the --start time upon looping, not the beginning of
the file.) However, the consensus is that the old behavior is
preferred and the interaction with --loop-playlist is the one
that is incorrect.
In addition, this change introduced a bug in the interaction
between Quit-Watch-Later and --loop-file, where upon reaching
playback end it would seek to the resume timestamp, not the
start of the file.
As a result, this commit reverts that change.
The x264 hack requires reading the first video packet, which in turn we
handle with a hack in demux_mkv.c to get the packet without having to
add special crap to demux.c. Another useless MKV feature (which they
enabled by default at one point and which caused many demuxers to break
completely, only to disable it again when it was too late) conflicts
with this, because we actually pass a block as packet contents, instead
of after "decompression".
Fix this by calling demux_mkv_decode().
This fixes when resuming certain broken h264 files encoded by x264. See
FFmpeg commit 840b41b2a643fc8f0617c0370125a19c02c6b586 about the x264
bug itself.
Normally, the unregistered user data SEI (that contains the x264 version
string) is informational only. But libavcodec uses it to workaround a
x264 bug, which was recently fixed in both libavcodec and x264. The fact
that both encoder and decoder were buggy is the reason that it was not
found earlier, and there are apparently a lot of files around created by
the broken decoder. If libavcodec sees the SEI, this bug can be worked
around by using the old behavior.
If you resume a file with mpv (i.e. seeking when the file loads),
libavcodec never sees the first video packet. Consequently it has to
assume the file is not broken, and never applies the workaround,
resulting in garbage being played.
Fix this by always feeding the first video packet to the decoder on
init, and then flushing the codec (to avoid that an unwanted image is
output). Flushing the codec does not remove info such as the x264
version. We also abuse the fact that the first avcodec_send_packet()
always pushes the frame into the decoder (so we don't have to trigger
the decoder by requsting an output frame).
Technically, the user could just use --vd-lavc-o with the same result.
But I find it better to make this an explicit option, so we can document
the ups and downs, and also avoid setting it for non-h264.
This means that we now explicitly set an interval of 1. Although that
should be the EGL default, some drivers could possibly ignore this
(unconfirmed). In any case, this commit also allows disabling vsync, for
users who want it.
Crashed when no vdpau device was loaded. Also there was a mistake of not
setting p->ctx, which broke software surface input mode. This was not
found before, because p->ctx is not needed for anything else.
Fixes#5294.
Show total cache as well as demuxer cache separately.
This adjusts the presented values to be consistent with status line
and OSC modifications made in https://github.com/mpv-player/mpv/pull/5250
This commit introduces a new --oset-metadata key-value-list option,
allowing the user to specify output metadata when encoding
(eg. --oset-metadata=title="Hello",comment="World").
A second option --oremove-metadata is added to exclude existing metadata
from the output file (assuming --ocopy-metadata is enabled).
Not all output formats support all tags, but luckily libavcodec
simply discards unsupported keys.
--copy-metadata describes the result of the option better, (copying metadata
from the source file to the output file). Marks the old --no-ometadata
OPT_REMOVED with a suggestion for the new --no-ocopy-metadata.
A release has been made, so drop options deprecated for that release.
Also drop some options which have been deprecated a much longer time
before.
Also fix a typo in client-api-changes.rst.
The queue family index and the queue info index are not necessarily the
same, so we're forced to do a check based on the queue family index
itself.
Fixes#5049
