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: 84de84bFixes: #12825
The previous commit was already a big improvement, but it was still
somewhat slow on the lua interpreter. By wrapping the table at the top
we loose the consistent placement of items while resizing (at least as
long as the column count didn't change), but we avoid taking all the
off screen items into account.
The fewer items fit on screen the faster this becomes.
Showing all properties was terribly slow.
Instead of starting at one row and increasing the row count until it
fits, the column count can be increased until it doesn't fit anymore.
That alone already reduces the required iterations, but from the column
count an upper and lower bound for the row count can be calculated.
For large tables this dramatically reduces the amount of iterations.
So far completing something like `${some-pro}` with the cursor between
`o}` would result in `${some-property}}`. Adding that superfluous `}` can
be avoided by checking if it's already in the string after the cursor.
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. de6eace6e9
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.
This would cause mpv to, in some very specific scenarios, have a
negative vsync_offset after seeking which would result in mpv requesting
a pts before the first frame to libplacebo.
Fix it by setting it to 0 when we reset state, such as after seeking.
Fixes: https://github.com/mpv-player/mpv/issues/12813
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.
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.
For whatever reason, some of the lua code (particularly the osc and
ytdl_hook) is full of a bunch of stuff like if (foo), if not (foo ==
nil), etc. The parenthesis aren't needed in lua and actually just look
weird since nobody actually writes lua like this. You can see most of
the other conditionals are written normally. So cleanup the style to
match when the parenthesis clearly aren't doing anything. Not directly
related, but also add some spaces on a few math operations while we're
at it.
This avoids a "Redefined local `options`" LSP warning in
list_option_list() after the previous commit. It still works, but
reusing names for local variables is error-prone.
Previously, the av sync change calculation was only done if the
audio_status was STATUS_PLAYING, but there is at least one or two more
states where this should be done. player/audio is capable of adding
delay if the state is anything besides STATUS_EOF. This means that while
calling adjust_sync, the delay value could have changed from the audio
side of the equation from the previous playloop, and it doesn't
necessarily mean that the current audio_status is STATUS_PLAYING either.
So the old code would technically skip this case. In practice, this is
just one frame so it hardly matters, but it should be taken into
account. For example, STATUS_READY is definitely possible here in
adjust_sync. I'm not sure if it's actually possible for STATUS_SYNCING
to happen but the audio code can change add delay with that status, so
it doesn't hurt. STATUS_DRAINING is probably not relevant, but again
include it to mirror the audio code logic. Of course, STATUS_EOF is
obviously a no-no since that means no audio at all, so we return from
there. I didn't take hard measurements or anything, but this does seem
to result in slightly smaller av sync fluctuations on discontinuities
(like seeking) which makes sense because we're now making an additional
correction that wasn't previously done.
Another change is to always try adjust_sync as long as the frame_time is
nonzero. The old logic only did this if the video_status was playing or
greater, but it is possible to get new frames with a different PTS that
do not have that status. The audio is still playing so logically it
should be adjusted as well. Again, this happens for just one frame, so
it doesn't really matter in practice but it should make more sense. A
zero frame_time is skipped since that would mean the pts did not advance
and the previous playloop should have done the adjustment for that time
already.
3038e578af recently changed the logic here
so it wouldn't trigger on still images, but after thinking about the
code here some more, I don't believe it's needed at all. Doing an ao
reset when you flip the video track is very disruptive and not really
desirable at all. Since the ao no longer adds bogus delay values while
the video is off, there should be no need to do a full reset for syncing
reasons. The delay value will be zero, so we can let the audio just play
normally and let the video code do its thing. There is one slight trick
here however. When using a display sync mode, part of the syncing code
will try to update the audio and video playback speed. This can cause an
audio underrun if we're just turning the video back one. An easy way to
avoid most of these is to not update the speed if we are in the
STATUS_SYNCING state for video. This isn't quite perfect and underruns
are still possible, but it actually seems to depend on the AO. e.g. I
couldn't trigger an underrun with alsa but I could with pipewire. In any
case, the audio artifact here is much less noticeable than doing a full
ao reset, so it's still an improvement.
ytdl lists thumbnails in ascending order according to height/preference.
all_formats=yes adds formats from best to worst, so the same should also
be done for thumbnails.
yt-dlp has a preference field for it's thumbnails, and not all of it's
listed thumbnails have fields with their dimensions.
Therefore prefere the preference field when available and fall back to
height if it's not.
I'd like some names to be more descriptive, but to work with 15 chars
limit we have to make some sacrifice.
Also because of the limit, remove the `mpv/` prefix and prioritize
actuall thread name.
dac977193c changed adding delay to only
when the video is playing but this isn't correct. The video frames
adjust themselves based on the audio, so if we still have audio
processing while the video itself happens to be in some non-playing
state (such as STATUS_READY), the delay still needs to be taken into
account. The correct thing to check is to make sure that it is not
STATUS_EOF. STATUS_EOF covers the case where we have still image, and of
course no video at all is STATUS_EOF. So having a massive bogus delay
value is still avoided.
The MPV_LEAK_REPORT environment variable was previously read in order to
determine whether or not to enable memory reporting for javascript
scripts. This is kind of weird and deviates from the norm of exposing an
option to the user. So let's just add --js-memory-report and disable it
by default instead.
The point of the mpctx->delay field is for calculating a/v sync and
adjusting the frame timings appropriately. However, the frame_time was
always subtracted from mpctx->delay regardless of the audio status. This
meant that for a video with no audio, every single frame had a
subtraction with nothing ever added to it meaning that you get massive
negative delay times. For weird videos where the audio starts way later,
the massive delay leads to the VO sleeping for basically about as long
as the video was previously playing without audio. This results in
nothing being rendered during that brief period of time and just overall
badness. When using display-sync, it happens to work since the video
doesn't adjust itself based on audio and it renders anyway.
The fix is to simply not touch mpctx->delay in player/video.c unless
there's actually audio playing. This is what the rest of the code
already does aside from setting it to 0 on resets or EOFs. Move the
calculation into adjust_sync after the audio status check. It works
exactly the same as before except that we don't constantly subtract
bogus values when there's no audio playing. The reverse situation in
player/audio.c also has the same issue. For something that is only
audio, mpctx->delay is always added to but nothing will ever subtract
from it. It's not really clear if this particular version could ever
cause a real bug, but logically it needs to be guarded in the same way.
The field here should only be updated if the video is actually playing.
Fixes#12025.
Kacper Michajłow
Guido Cella
Dudemanguy
Christoph Heinrich
llyyr
Eva