| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently VOCTRL are completely unusable for frequent data query. Since
the HDR parameter addition to video-params, the parameters can change
each frame. In which case observe on those parameter would be triggered
constantly. The problem is that quering those parameters involves VOCTRL
which in turn involves whole render cycle of delay.
Instead update VO params on each draw_frame. This requires changes to VO
reconfiguration condition, but in practice it should only be triggered
when image size or data layout changes. In other cases it will be
handled internal by VO driver.
I'm not quite happy with this solution, but don't see better one without
changing observe/notify logic significantly. There is no good way
currently to handle VOCTRL that are constantly queried.
This adds unfortunate synchronization of player command with VO thread,
but there is not way around that and if too frequent queries of this
param becomes a problem we can thing of other solutions.
Changes the way to get data from VO driver added by a98c5328dc
Fixes: 84de84b
Fixes: #12825
|
|
|
|
|
| |
Without this, changing the vo at runtime with --force-window --idle
would kill the vo.
|
|
|
|
| |
Fixes: 73fbe09a49d3ed00c6e19fdcc658802f28974ae2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the sub seek code path, there was an arbitrary small offset added to
the pts before the seek. However when seeking backwards, the offset was
an additional subtraction. de6eace6e984be3cd2515e9be6362a0cf04b7457
added this logic 10 years ago and perhaps it made sense then, but the
additional subtraction when seeking backwards causes the subtitle seek
to go too far to the previous subtitle if the durations overlap. This
should always be an addition to work correctly. Additionally, the sub
stepping code path also could use this offset for the same reason
(duration overlaps). However, it is only applicable to sd_ass not
sd_lavc. sd_lavc has step_sub support but on a sample it didn't even
work anyway. Perhaps it only works for certain kinds of subtitles
(patches welcome).
Anyways instead of keeping this offset as a magic number, we can define
it in sd.h which is handy for this. For sd_ass, we add the offset when
sub stepping, and the offset is always added for sub seeking like it was
before. Update the comment to be a little more relevant to what actually
happens today. Fixes #11445.
|
|
|
|
| |
It contains metadata that may change per frame.
|
|
|
|
|
|
|
|
| |
This commit replaces all uses of sig_peak and maps all HDR metadata.
Form notable changes mixed usage of maxCLL and max_luma is resolved and
not always max_luma is used which makes vo_gpu and vo_gpu_next behave
the same way.
|
|
|
|
|
| |
It is now included in video-out-params and was never released in stable
version, so we can safely remove it.
|
|
|
|
|
| |
Note this commit does not change all uses of sig-peak, this is for
future refactoring.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change essentially removes mp_thread_self() and instead add
mp_thread_id to track threads and have ability to query current thread
id during runtime.
This will be useful for upcoming win32 implementation, where accessing
thread handle is different than on pthreads. Greatly reduces complexity.
Otherweis locked map of tid <-> handle is required which is completely
unnecessary for all mpv use-cases.
Note that this is the mp_thread_id, not to confuse with system tid. For
example on threads-posix implementation it is simply pthread_t.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
UPDATE_SUB_HARD causes all of the ass objects to reset in order to apply
the new style. UPDATE_SUB_FILT doesn't actually reset the sd, but it
should in order to update the actual filters so that was added here.
Doing this causes the current subtitle to be dropped. In the paused
cause, this concidentally works because command.c forces a video refresh
which then reloads the subtitle essentially. But while playing, the
subtitle will be dropped and you won't get anything until the next one
appears.
Instead of using video refreshes, what we can do is just always save the
last two subtitle packets in a cache and redecode them if needed. This
is much easier and also allows us to get rid of all the video refresh
logic in command.c. Fixes #12386.
|
|
|
|
|
|
|
|
|
| |
C standard says that `= {0}` activates and initializes first member of
union. We expect whole union to be zeroed, it is used as default value.
Initialize union with one zeroed default instance to ensure proper init.
Fixes: #12711
|
|
|
|
|
|
|
|
| |
To avoid switching to scientific notation. Apparently it is "jarring"
for some users.
This preserves status quo from before 9dddfc4f where pretty printer were
truncated to 3 decimal places.
|
|
|
|
|
|
|
| |
The whole mess with setting the option value explictly and saving the
old stop_play value only needs to happen if we're at the end of file.
Doing it in general is unneccessary and breaks other things.
Fixes #12424.
|
|
|
|
|
|
|
|
| |
Use "%.7g" to show 7 significant digits. Removes the trailing zeros, and
in general makes it more readable, than fixed 3 decimal digits.
For avsync use "%+.2g" to add plus sign, similar to display-sync
values.
|
|
|
|
| |
fps property was not renamed in events.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was wrongly assuming that playlist_path is always set for the
current playlist entry, but it's only set when a file was added by
expanding a playlist.
The crash in playlist_get_first_in_next_playlist can be reproduced with
mpv foo.mkv foo.zip, playlist-next, playlist-prev,
playlist-next-playlist. You need to run playlist-next, playlist-prev
first because foo.zip's playlist_path is NULL until you do that, which
makes playlist_get_first_in_next_playlist return immediately.
The crash in cmd_playlist_next_prev_playlist can be replicated with mpv
--loop-playlist foo.zip foo.mkv, running playlist-next until foo.mkv,
and playlist-play-next. Again, you need to open foo.zip first or its
playlist_path is NULL which skips running strcmp(entry->playlist_path,
mpctx->playlist->current->playlist_path).
Fixes https://github.com/mpv-player/mpv/issues/12495#issuecomment-1760968608
|
|
|
|
|
| |
This is weird. The caller should be responsible for converting the value
if desired. Move the conversion to player/command.c instead.
|
|
|
|
|
|
|
|
|
|
|
|
| |
playlist-prev-playlist goes to the beginning of the previous playlist
because this seems more useful and symmetrical to
playlist-next-playlist. It does not go to the beginning when the current
playlist-path starts with the previous playlist-path, e.g. with mpv
--loop-playlist foo/, which expands to foo/{1..9}.zip, the current
playlist path foo/1.zip beings with the playlist-path foo/ of {2..9}.zip
and thus playlist-prev-playlist goes to 9.zip rather than to 2.zip.
Closes #12495.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fbe154831a8addfc18a4f81e1c4b9284c31acace added a new VOCTRL to signal
when the OSD changed for gpu-next's handling of subtitles, but this is
both not necessary and actually incomplete. The VOCTRL would signal OSD
changes, but not all subtitle changes (like selecting another
non-external sub track for example). VOCTRL_OSD_CHANGED was used to
increment p->osd_sync which would then redraw the blended subtitles if
the player was paused.
But there's already a VOCTRL_PAUSE and VOCTRL_RESUME. Plus, the
sub_bitmap_list object will have items in it if it changed in any way,
so we don't need the VOCTRL_OSD_CHANGED method at all. That can be
removed.
The check that fp->osd_sync < p->osd_sync stays in place since that's an
optimization while the video is playing, but we also check the pause
state as well since the VO can know this. If we're paused, then always
do update_overlays since core must be signalling a redraw to us if we
get a draw_frame call here. Additionally in update_overlays itself, the
p->osd_sync counter is incremented if we have any items since the frame
signature will need that. As for the actual bug that is fixed, changing
subtitle tracks while paused with blended subtitles now correctly works.
Previously, it was never updated so the old subtitle stayed there
forever until you deselected it (since VOCTRL_OSD_CHANGED triggered
there).
Also include some cosmetic code fixes that were noticed.
|
|
|
|
|
|
| |
e277fadd60350caad1fc31e92a5076692e61dcc9 originally added this but it
never actually did anything in the function... wm4 probably changed his
mind but forget to delete it so just remove it here.
|
|
|
|
| |
fixes: #11180
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When seeking chapters, `last_chapter_seek` acts as a projection of
what the current chapter will be once mpv has a chance to seek to it.
This allows for more accurate results from the `chapter` property.
It works by comparing the projection to the actual current chapter
and returning the larger of the two indexes, but this only works when
seeking forward.
If we want it to work for both forward and backward chapter seeking,
we can instead use a boolean called `last_chapter_flag`, which gets
switched on when a chapter seek request is made, and then
switched off when the seek has been performed.
We should also check to ensure that we don't allow the chapter index
to be set to -1 unless there is a span of time between the very
beginning of the track and the start of the first chapter.
Since the new approach to resetting `last_chapter_seek` no longer
depends on `last_chapter_pts`, that member variable can be removed.
|
|
|
|
|
|
|
| |
Evidently I was wrong and mpv only actually warns once on deprecation
(playlist-pos nor display-fps did not and warned every time, but those
were outliers apparently). Someone complained so just hack it into
command_ctx for now.
|
|
|
|
| |
user-data is simply better.
|
|
|
|
|
|
| |
No wonder wm4 wanted to get rid of this. This option requires touching a
bunch of crap in the core player code. --stream-record works perfectly
fine and is a lot nicer so there's no need for this to exist anymore.
|
|
|
|
|
|
|
|
|
| |
e9e93b4dbe748cd341a6fbea355e6ba013ada81b added a warning about writing
the same value to the playlist-pos property that in the future it would
stop restarting playback. Instead, you should use the
playlist-play-index command for that. Well go ahead and drop the old
deprecated behavior now and do what wm4 wanted this to do: just ignore
if the same value is written again.
|
|
|
|
|
|
|
|
| |
drop-frame-count and vo-drop-frame-count are ancient and have no reason
to exist anymore. The other change is that support for writing to
display-fps has been removed, and the property is strictly read-only
now. 3a2dc8b22e9f947c9cd3a91445b0731b8df1d798 is what deprecated it with
a warning to users, so we can remove it without much trouble.
|
| |
|
| |
|
|
|
|
|
|
| |
Setting `--video-crop=0x0+0+0` applies full frame crop, ignoring the
container one. Setting --video-crop=0 disables manual crop and restores
container one if it is available.
|
| |
|
| |
|
|
|
|
|
|
| |
Just cropping by VO that works with hwdec.
Fixes: #12222
|
|
|
|
| |
4 years is enough of deprecation period.
|
| |
|
|
|
|
|
|
| |
Since we no longer have the auto choice, this is always exactly equal to
the value of the option (sub-forced-events-only). Remove the property
and alias it.
|
|
|
|
|
|
|
|
| |
The old name is pretty bad and users mistakenly think it has something
to do with selecting forced subtitles (that would be
--subs-fallback-forced). Instead of giving it such a generic name, make
it clearer that this has to do specifically with forced sub events
which is only relevant for a small minority of subtitles.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First of all, this never worked. Or if it ever did, it was in some
select few scenarios. c9474dc9ed6172a5f17f66f4b7d367da6b077909 is what
originally added support for the auto choice. However, that commit
worked by propagating a value to a fake option used internally. This
shouldn't have ever worked because the underlying m_config_cache was
never updated so the value shouldn't have been preserved when accessed
in sd_lavc. And indeed with some testing, the value there is always 0
unsurprisingly.
This was later rewritten in ba7cc071068f4f57ae354e77f64552712fda6855
along with a lot of other sub changes, but with that, it was still
mostly broken. The reason is because one of the key parts of having to
hit this logic (prefer_forced) required `--no-subs-with-matching-audio`
to be set. If the audio language matches the subtitle language (the
requirement also excludes forced subs), the option makes no subtitle
selection in the first place so pick->forced_only_def is not set to true
and nothing even happens. Another way around this would be to attempt to
change your OS language (like with the LANG environment variable) so
that the subtitle track gets selected but then audio_matches mistakenly
becomes false because it compares the OS language to the audio language
which then make preferred_forced 0, so nothing happens. I don't think
there's a scenario where pick->forced_only_def is actually set to true
(thus meaning `auto` is useless), but maybe someone could contrive
something very strange. Regardless, it's definitely not something even
remotely common.
fbe8f9919428a7ed24a61899bfd85bbb7680e389 changed track selection again
but didn't consider this particular case. The net result is that DVD/PGS
subs become equivalent to --sub-forced-only being yes, so this a change
in behavior and probably not a good one. Note that I wasn't able to
actually observe any difference in a PGS sample. It still displayed
subtitles fine but that sample probably didn't have the right flags to
hit the sub-forced-only logic.
Anyways, the auto feature is extremely questionable at best and in my
view, not actually worth it. It is meant to be used with
`--no-subs-with-matching-audio` to display forced pictures in subtitle
tracks that are not marked as forced, but that contradicts that
particular option's purpose and description in the manual (secretly
selecting a track under certain conditions even though it says not to).
Instead of trying to shove all this logic into select_default_track
which is already insanely complicated as it is, recognize that this is a
trivial lua script. If you absolutely want to turn --sub-forced-only on
under these certain conditions (DVD/PGS subtitles, matching audio and
subtitle languages, etc.), just look at the current-tracks property and
do your thing. The very, very niche behavior that this option tried to
accomplish basically never worked, no user even knows what this option
does, and well it's just not worth supporting in core mpv code. Drop
all this code for sanity's sake and change --sub-forced-only back to a
bool.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--audio-file-auto, --cover-art-auto, and --sub-auto all work by using an
internally hardcoded list that determine what file extensions get
recognized. This is fine and people periodically update it, but we can
actually expose this as a stringlist option instead. This way users can
add or remove any file extension for any type. For the most part, this
is pretty pretty easy and involves making sub_exts, etc. the defaults
for the new options (--audio-file-auto-exts, --cover-art-auto-exts, and
--sub-auto-exts). There's actually one slight complication however. The
input code uses mp_might_be_subtitle_file which guesses if the file drag
and dropped file is a subtitle. The input ctx has no access to mpctx so
we have to be clever here.
For this, the trick is to recognize that we can leverage the
m_option_change_callback. We add a new flag, UPDATE_SUB_EXTS, which
fires when the player starts up. Then in the callback, we can set the
value of sub_exts in external_files to opts->sub_auto_exts. Whenever the
option updates, the callback is fired again and sub_exts updates. That
way mp_might_be_subtitle_file can just operate off of this global
variable instead of trying to mess with the core mpv state directly.
Fixes #12000.
|
|
|
|
|
|
|
|
|
|
|
|
| |
A bit of a long standing pain with scripting is that when opening a file
that gets interpreted as a playlist (like an m3u), the original path of
the file gets thrown away later. Workarounds basically consist of
getting the filename before mpv expands the path, but that's not really
reliable. Instead of throwing it away, save the original playlist path
by copying to the playlist entries when applicable (demuxer playlist and
the playlist option). Then expose these as properties: playlist-path for
the currently playing entry and playlist/N/playlist-path for each
specific entry. Closes #8508, #7605.
|
|
|
|
|
|
|
|
| |
mpv makes this option an integer, but the underlying ass API actually
accepts doubles. From some testing, there is no meaningful precision
difference between float or double (it seems to go in roughly 0.05
steps), so just make it a float. sd_lavc also can handle non-integer
values here. Closes #11583.
|
|
|
|
| |
With pretty printed aspect ratio and related format.
|
|
|
|
|
|
|
|
|
|
|
| |
When printing the name of the video track on the OSC, mpv almost always
prefixes it with "unknown". This is referring to the language tag which
essentially nobody ever does for the video track since it doesn't make
any sense. Instead of putting unknown when there's no language, just
make it an empty string instead. "Unknown" confuses can confuse users
here and practically nobody would guess that it's referring to language.
We still will print the language for a video track in case someone out
there really does tag it, but that should be rare.
|
|
|
|
|
| |
Now actually matches the documentation (was an empty string not null).
Fixes #11464.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is pretty obscure but if you screw around with the play-dir option
to essentially create a ping-pong loop; mpv will get hit by an assertion
error. What's happening here is that changing the play-dir always
requires a seek. This is handled in player/command along with the other
runtime option changes. However, queue_seek can actually clear the value
of mpctx->stop_play if the file is ending. So while loadfile is
terminating playback and the play-dir gets changed, the value of
mpctx->stop_play gets cleared because of seek. This then hits that
assertion later when mpv tries to finish the file.
The fix is to just add some weird logic to play-dir in player/command.
We have to be sure that mpctx->play_dir matches the new direction
immediately when we get the change so explictly set it here and don't
wait for it later. Secondly, keep the old value of mpctx->stop_play
before the seek and restore it afterwards. This ensures that termination
still happens cleanly and allows the ping-pong loop to work. Fixes #10782
|
|
|
|
|
|
| |
1df0a42a8cb12005311f6a03f3a1c4329c798f8c changed aspect-ratio from
floats to doubles, but forgot to change this function for
pretty-printing them as fractions for the video-aspect-override property
|
|
|
|
|
|
|
| |
The only user of these APIs was ao_pipewire and the logic there got
converted so drop the now dead code.
This reverts commit 3167a77aa38b |