The internal stereo3d filter was removed due to being GPL only, and due
to being a mess that somehow used libavfilter's filter. Without this
filter, it's hard to remove our internal stereo3d image attribute, so
even using libavfilter's stereo3d filter would not work too well (unless
someone fixes it and makes it able to use AVFrame metadata, which we
then could mirror in mp_image).
This was never well thought-through anyway, so just drop it. I think
some "downsampling" support would still make sense, maybe that can be
readded later.
Now using libavfilter filters directly.
The rotation case is a bit lazy, because it uses the slow vf_rotate
filter in all cases, instead of using special filters for 90° step
rotations.
Apparently a relatively widespread convention, and almost as strict as
the old "exact" semantics. (So it's not going to auto load radically
unrelated files.)
There has been no new developments or agreements, but I was uncertain
about the copyright status of them. Thus this part of code was marked as
being potentially GPL, and was not built in LGPL mode. Now I've taken a
close look again, and decided that these can be relicensed using the
existing relicensing agreements.
OSD level 3 was introduced in commit 8d190244, with the author being
unreachable. As I decided in commit 6ddd95fd, OSD level 3 itself can
be kept, but the "osd" command had to go, and the "rendering" of OSD
level 3 (the HAVE_GPL code in osd.c) was uncertain. But the code for
this was rewritten: instead of duplicating the time/percent formatting
code, it was changed to use common code, and some weird extra logic was
removed. The code inside of the "if" is exactly the same as the code
that formats the OSD status line (covered by LGPL relicensing).
The current commands for adding/removing sub/audio tracks more or less
originated from commit 2f376d1b39, with the author being unreachable.
But the original code was very different, mostly due to MPlayer's
incredibly messy handling of subtitles in general. Nothing of this
remains in the current code. Even the command declarations were
rewritten. The commands (as seen from the user side) are rather similar
in naming and semantics, but we don't consider this copyrightable. So it
doesn't look like anything copyrightable is left.
The add/cycle commands were more or less based on step_property,
introduced in commit 7a71da01d6, with the patch author disagreeing with
the LGPL relicensing. But all code original to the patch has been
replaced in later mpv changes, and the original code was mostly copied
from MP_CMD_SET_PROPERTY anyway. The underlying property interface was
completely changed, the error handling was redone, and all of this is
very similar to the changes that were done on SET_PROPERTY. The command
declarations are completely different in the first place, because the
semantic change from step to add/cycle. The commit also seems to have
been co-authored by reimar to some degree. He also had the idea to
change the original patch from making the command modify a specific
property to making it generic.
(The error message line, especially with its %g formatting, might
contain some level of originality, so change that just to be sure.
This commit Copies and adapts the error message for SET_PROPERTY.)
Although I'm a bit on the fence with all the above things, it really
doesn't look like there's anything substantial that would cause issues.
I thus claim that there is no problem with changing the license to LGPL
for the above things. It's probably still slightly below the standard
that was usually applied in the code relicensing in mpv, but probably
still far above to the usual in open source relicensing (and above
commercial standards as well, if you look what certain tech giants do).
Always display the duration as "unknown" if the duration is known. Also
fix that at least demux_lavf reported unknown duration as 0 (fix by
setting the default to unknown in demux.c).
Remove the dumb _u formatter function, and use a different approach to
avoiding displaying "unknown" as playback time on playback start (set
last_seek_pts for that).
Even though only 1 seek range is supported at the time.
Other than preparation for possibly future features, the main gain is
actually that we finally separate the reporting for the buffering, and
the seek ranges. These can be subtly different, so it's good to have a
clear separation.
This commit also fixes that the ts_reader wasn't rebased to the start
time, which could make the player show "???" for buffered cache amount
in some .ts files and others (especially at the end, when ts_reader
could become higher than ts_max). It also fixes writing the cache-end
field in the demuxer-cache-state property: it checked ts_start against
NOPTS, which makes no sense.
ts_start was never used (except for the bug mentioned above), so get rid
of it completely. This also makes it convenient to move the segment
check for last_ts to the demux_add_packet() function.
Even if the demuxer cache does not multiple ranges yet. This is to
reduce the pain should caching of multiple ranges ever be implemented.
Also change it from the sub properties stuff to return a mpv_node
directly, which is less roundabout. Sub-property access won't work
anymore, though.
Remove the seekable-start/-end fields as well, as they're redundant with
the ranges.
All this would normally be considered an API change, but since it's been
only a few days with no known users, change it immediately.
This adds some node.c helpers as well, as the code would be too damn
fugly otherwise.
Seems like most code dealing with this was for setting it in redundant
cases. Now SEEK_BACKWARD is redundant, and SEEK_FORWARD is the odd one
out.
Also fix that SEEK_FORWARD was not correctly unset in try_seek_cache().
In demux_mkv_seek(), make the arbitrary decision that a video stream is
not required for the subtitle prefetch logic to be active. We might want
subtitles with long duration even with audio only playback, or if the
file is used as external subtitle.
This improves upon the previous commit, and partially rewrites it (and
other code). It does:
- disable the seeking within cache by default, and add an option to
control it
- mess with the buffer estimation reporting code, which will most likely
lead to funny regressions even if the new features are not enabled
- add a back buffer to the packet cache
- enhance the seek code so you can seek into the back buffer
- unnecessarily change a bunch of other stuff for no reason
- fuck up everything and vomit ponies and rainbows
This should actually be pretty usable. One thing we should add are some
properties to report the proper buffer state. Then the OSC could show a
nice buffer range. Also configuration of the buffers could be made
simpler. Once this has been tested enough, it can be enabled by default,
and might replace the stream cache's byte ringbuffer.
In addition it may or may not be possible to keep other buffer ranges
when seeking outside of the current range, but that would be much more
complex.
This was phased out, and was used only by vdpau by now. Drop the
mechanism and the vdpau special code, which means screenshots won't
include the vf_vdpaupp processing anymore. (I don't care enough about
vdpau, it's on its way out.)
Signed-off-by: wm4 <wm4@nowhere>
Rename --stats to --load-stats-overlay and add an entry to options.rst
over the original commit.
Signed-off-by: wm4 <wm4@nowhere>
Previously multiple timers were used to realize oneshot, toggling
(redrawing) and page keybindings. The oneshot case in particular also
relied on mp.osd_message to display text only for a given duration.
This was changed to only use one timer in total now. Because now each
case has a defined "start" and "end" point (including oneshot)
mp.set_osd_ass() can be used to print stats as well. This is currently
optional and has to be activated using the config option
persistent_overlay=true.
One shortcoming: oneshot and toggling are mutual exclusive right now.
Previously you could enter toggling while oneshot stats were shown,
this is not possible anymore to reduce the number of cases to be
considered. This can be added later on if desired.
It used a bad heuristic that got even worse/less reliable with recent
changes in mpv. In fact, it's not reliable at all.
Watch out for dropped frames instead. That's a useful indicator.
Previously I could trigger a bug with intense button mashing, however,
was unable to reproduce it and therefore debug it.
This change now seems to be resilient against button mashing, let's hope
it really is.
Please note that the latest version of this script needs a very recent
version of mpv (from yesterday, to be precise, see the readme).
For older versions, please go to "releases".
HOW IT WORKS:
While the stats are visible (i.e. text is printed to the OSD) a
subsequent click on a numeric key (1, 2, ...) will display the
corresponding "page".
This works no matter if the stats are toggled or just shown as a single
invocation. In case of a single invocation, the newly displayed page
will be shown for the full duration again.
The selected page will be remembered (not persistantly though).
So far, only 3 pages are available.
1: the default page, stats as they used to be
2: extensive VO performance stats (to be redesigned/changed soon)
3: dummy
In the future, many more pages are possible.
Implementation is likely to change again (functionality will stay
the same). A new timer had to be introduced to remove the forced
keybindings in the oneshot case. The toggle case can remove them without
a timer. Ensuring that each mode won't remove timers of the other mode
didn't really turn out neat.
Therefore, I intend to change this again, maybe by merging the
oneshot case into the toggle case.
Due to the large amount of per-pass data, the function takes a parameter
indicating whether or not to print a simplified view instead.
The overall intent is to print the simplified view for now, but supposed
printing the full view on a dedicated "tab" (or extra view type), and as
such, `o.print_perfdata_passes` will go away again. I've only introduced
it for now so users can play around with this functionality if they want
to, until Argon- gets around to implementing stats "tabs".
