| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I may (optionally) move decoding to a separate thread in a future
change. It's a bit attractive to move the entire decoder wrapper to
there, so if the demuxer has a new packet, it doesn't have to wake up
the main thread, and can directly wake up the decoder. (Although that's
bullshit, since there's a queue in between, and libavcodec's
multi-threaded decoding plays cross-threads ping pong with packets
anyway. On the other hand, the main thread would still have to shuffle
the packets around, so whatever, just seems like better design.)
As preparation, there shouldn't be any mutable state exposed by the
wrapper. But there's still a large number of corner-caseish crap, so
just use setters/getters for them. This recorder thing will inherently
not work, so it'll have to be disabled if threads are used.
This is a bit painful, but probably still the right thing. Like
speculatively pulling teeth.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was a hack that attempted to line up external audio tracks with
video. The problem is that if you do a keyframe seek backwards, video
will usually seek much farther back than audio (due to much higher
keyframe aka seek point distances). The hack somehow made seeking a 2
step process.
This existed in 4 different forms in the history of this code base, and
it was always very cumbersome. We mostly needed this for ytdl_hook (I
think?), which uses the 4th form, which is nicely confined to
demux_timeline and is unrelated to the "external" audio tracks in the
high level player.
Since this is (probably) not really widely needed anymore, get rid of
it. Better do this now, than when somehow rewriting all the seeking code
(which might happen in this decade or the next or so) and when it
wouldn't be easily revertable anymore in case we find we "really" need
it unlike expected.
There is no issue if hr-seeks are used. Also, you can still use edl
files to "bundle" multiple streams as if it was a single stream (this is
what ytdl_hook does now).
|
|
|
|
|
|
|
| |
The "seekbarkeyframes" option is now interpreted such if it's true, the
player default is used. Too lazy to make this a choice option or
whatever; the Lua option parser doesn't have support for that anyway.
Someone who cares can adjust this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Try to deal with various corner cases. But when I fix one thing, another
thing breaks. (And it's 50/50 whether I find the breakage immediately or
a few months later.) So results may vary.
The default for--hr-seek is changed to "default" (not creative enough to
find a better name). In this mode, audio seeking is exact if there is no
video, or if the video has only a single frame. This change is actually
pretty dumb, since audio frames are usually small enough that exact
seeking does not really add much. But it gets rid of some weird special
cases.
Internally, the most important change is that is_coverart and is_sparse
handling is merged. is_sparse was originally just a special case for
weird .ts streams that have the corresponding low-level flag set. The
idea is that they're pretty similar anyway, so this would reduce the
number of corner cases. But I'm not sure if this doesn't break the
original intended use case for it (I don't have a sample anyway).
This changes last-frame handling, and respects the duration of the last
frame only if audio is disabled. This is mostly "coincidental" due to
the need to make seeking past EOF trigger player exit, and is caused by
setting STATUS_EOF early. On the other hand, this might have been this
way before (see removed chunk close to it).
|
|
|
|
|
|
|
|
|
|
| |
This tries to fix #7206 (hr-seeking past EOF does not stop playback)
again. Commit 57fbc9cd76f7 should have fixed this, but trying it again
(using that git revision), it often did not work. Whatever the fuck.
So add another dumb special case that will break within weeks. Note that
the check in handle_eof() had no effect, since execute_queued_seek() is
called later, which cancels EOF in the same case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hr-seek past the last frame instantly enters EOF, which means
handle_playback_time() will not set playback_pts to the video PTS (as
all video frames are skipped), which leads to the playback time being
taken from the last seek target. This results in confusing behavior,
especially since the seek time will be clipped to the file duration for
display, but not for further relative seeks.
Obviously, the time should be set to the last video frame, so use the
last video frame as fallback if both audio and video have ended. Also,
since the same problem exists with audio-only playback, add a fallback
for audio PTS too. We don't know which was the "last" fragment of media
played (to decide whether to use the audio or video PTS as the
fallback), but it doesn't matter since the maximum works.
This could lead to some undesired effects. In particular the audio PTS
is basically a bad guess, and is for example not clipped against --end.
(But the ridiculous way audio syncing and clamping currently works, I'm
not going to touch that shit unless I rewrite it completely.) The cover
art case is slightly broken: using --keep-open with keyframe seeks will
result in 0 as playback PTS (the video PTS). OK, who cares, it got late.
Also casually get rid of last_vo_pts, since that barely made any sense
at all.
Fixes: #7487
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The seeking logic saves the last video frame it has seen (for example
for being able to seek to the last frame, or backstepping).
Unfortunately, the frame was fed back to the filtering pipeline in
situations when it shouldn't have. Then it's an out of order frame,
because it really saves the last _discarded_ frame.
For example, seeking to the end of a file with --keep-open, shift+up,
shift+down => invalid video pts warning due to saved_frame being fed
back.
Explicitly discard saved_frame when it's obviously not needed anymore.
The removed accesses to "r" are strictly speaking unrelated (just
const-propagating them).
|
|
|
|
| |
This just made it print a blank line.
|
|
|
|
|
|
|
|
|
| |
args->client was deallocated if the FDs were closed and nothing
referenced it (IPC socket codes detected the closed sockets and
asynchronously killed the mpv_handle in args->client). The problem was
that args->log depended on it, and was also destroyed.
Fix this by duplicating the mp_log.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The relatively recently added property update code has a race condition
when clients exit. It still tried to access mpv_handle during and after
it was destroyed.
The reason is that it unlocks the lock for the mpv_handle list (while
mpv_handle is locked), but nothing in mp_destroy_client() cares about
this case. The latter function locks mpv_handle only before/while it
makes sure all of its activity is coming to an end, such as asynchronous
requests, and property updates that are in progress. It did not include
the case when mp_client_send_property_changes() was still calling
send_client_property_changes() with mpv_handle locked.
Fix this by checking the mpv_handle.destroying field. This field can be
set only when mpv_handle is locked. While we're checking the lock, the
mpv_handle list is still locked, so at worst we might be at the point
before mp_destroy_client() locks the list again and finally destroys the
mpv_handle.
This is a hard to reproduce race condition which I spotted only once in
valgrind by chance, so the fix is unconfirmed.
|
| |
|
|
|
|
|
| |
Much more verbose, but on the other hand format_note is useless for the
alphabetic site with fragmented DASH streams.
|
|
|
|
|
| |
"format_note" normally contains a semi-informative description of the
format. But some extractors, confusingly, have it in the "format" field.
|
|
|
|
|
| |
E.g. soundcloud. While it still worked, not having the audio codec was
pretty annoying.
|
|
|
|
|
|
| |
This was obviously nonsense. In Lua 5.1 this appeared to work correctly,
but it really turned "\." into "." (making the pattern accept any
character). The proper way is using "%" for escaping.
|
|
|
|
| |
Well, didn't help much in the case I was interested it.
|
| |
|
|
|
|
| |
Should not be needed anymore. In fact, it's probably dangerous.
|
|
|
|
|
|
|
|
|
| |
In all_formats mode, we've ignored what --ytdl-format did so far, since
we've converted the full format list, instead of just the formats
selected by youtube-dl.
But we can easily restore --ytdl-format behavior: just mark the selected
tracks as default tracks.
|
|
|
|
|
| |
This was done for each media type, so muxed tracks had it twice, which
logged a dumb warning. Move it out of the per-media type loop.
|
|
|
|
|
| |
I think this is unnecessary, and at worst done by youtube-dl itself
(didn't check).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vbr and abr are the video and audio bitrates. Sometimes there is a weird
mix of any of them available, but in these cases, it's not good to fall
back to tbr if a specific track has no vbr/abr.
For example, the alphabetic site provides tbr only for the muxed
fallback stream, but using tbr would make the primitive mpv hls_bitrate
selection pick the compatibility stream for audio, because it appears to
have a higher bitrate than the other audio-only streams (because the
bitrate includes video). So we must not use tbr in this case.
On the other hand, formats coming from youtube-dl HLS master playlist
use will only have tbr set.
So as a heuristic, use the tbr only if it's the only bitrate available
in any track entry.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I don't think the skip_muxed option was overlay useful. While it was
nice to filter out the low quality muxed versions (as it happens on the
alphabetic site, I suspect it's compatibility stuff), it's not really
necessary, and just makes for another tricky and rarely used
configuration option. (This was different before muxed tracks were also
delay-loaded, and including the muxed versions slowed down loading.)
Add the force_all_formats option instead, which handles the HLS case.
Set it to true because they are also delay-loaded now, and don't slow
down startup as much.
|
|
|
|
|
|
| |
(Or if it's about HLS, just "muxed"/multiplexed streams.)
This only affects all_formats=yes,skip_muxed=no modes.
|
|
|
|
|
|
| |
If all streams were delay loaded, there was actually no duration present
at all in the EDL metadata. So the length was considered unknown by the
player frontend.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See manpage additions. We would have to extend delay_open to support
multiple sub-tracks (for audio and video), and we'd still don't know (?)
whether it might contain more than one stream each (thinking of HLS
master streams). And if it's a true interleaved file (such as a "normal"
mp4 file provided as fallback for more primitive players), we'd either
have to signal such "bundled" tracks, or waste bandwidth.
This restructures a lot. The if/else tree in add_single_video for format
selection was a bit annoying, so it's split into separate if blocks,
where it checks each time whether a URL was determined yet.
|
|
|
|
| |
It even has a typo.
|
|
|
|
| |
If available.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a "format" has both audio and video codec set, it might contain both
audio and video. all_format assumes that each format is just a quality
variant containing a single track.
This seems to happen with sites that provide a HLS master URL.
youtube-dl tends to "butcher" it, and the result isn't very ideal. I
guess HLS "renditions" simply don't map well to youtube-dl's output
format and what mpv expects. Playing master HLS directly is also less
than ideal, because of libavformat's stupid probing.
Fix this by not using the delay-opening mechanism if it appears like we
detected such a case. Add a metadata override to set the track titles to
"muxed-N", to indicate that they form a single unit. (Mostly helpful for
testing.)
|
|
|
|
|
| |
Shouldn't have any consequences. Probably makes the user-visible order
more stable.
|
|
|
|
| |
Because the --hls-bitrate option takes the same unit.
|
|
|
|
|
|
|
|
|
|
| |
This is just a more convenient way to start IPC client scripts per mpv
instance.
Does not work on Windows, although it could if the subprocess and IPC
parts are implemented (and I guess .exe/.bat suffixes are required).
Also untested whether it builds on Windows. A lot of other things are
untested too, so don't complain.
|
|
|
|
|
|
|
|
|
| |
Pretty worthless I guess. I only tested one site (and 2 videos), it's
somewhat likely that it will break with other sites. Even if you leave
the option disabled (the default).
Slightly related to #3548. This will allows you to use the bitrate
stream selection mechanism, that was added for HLS, with normal videos.
|
|
|
|
| |
Might be helpful for... whatever.
|
|
|
|
|
| |
Aka hls-bitrate. In turn, remove the demux_lavf.c hack, which made the
track title use this.
|
|
|
|
|
|
| |
Neither does it (directly) mess with filters, nor does it return a bool.
As noticed by a comment in #6333.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, filter_sdh was simply a function that was called by sd_ass
directly (if enabled).
I want to add another filter, so it's time to turn this into a somewhat
more general subtitle filtering infrastructure.
I pondered whether to reuse the audio/video filtering stuff - but better
not. Also, since subtitles are horrible and tend to refuse proper
abstraction, it's still messed into sd_ass, instead of working on the
dec_sub.c level. Actually mpv used to have subtitle "filters" and even
made subtitle converters part of it, but it was fairly horrible, so
don't do that again.
In addition, make runtime changes possible. Since this was supposed to
be a quick hack, I just decided to put all subtitle filter options into
a separate option group (=> simpler change notification), to manually
push the change through the playloop (like it was sort of before for OSD
options), and to recreate the sub filter chain completely in every
change. Should be good enough.
One strangeness is that due to prefetching and such, most subtitle
packets (or those some time ahead) are actually done filtering when we
change, so the user still needs to manually seek to actually refresh
everything. And since subtitle data is usually cached in ASS_Track (for
other terrible but user-friendly reasons), we also must clear the
subtitle data, but of course only on seek, since otherwise all subtitles
would just disappear. What a fucking mess, but such is life. We could
trigger a "refresh seek" to make this more automatic, but I don't feel
like it currently.
This is slightly inefficient (lots of allocations and copying), but I
decided that it doesn't matter. Could matter slightly for crazy ASS
subtitles that render with thousands of events.
Not very well tested. Still seems to work, but I didn't have many test
cases.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Uses the infrastructure added in the previous commits. This is
admittedly a bit weird (constructing EDL URLs and such). But on the
other hand, adding this as "first class" mechanism directly to the
sub-add command or so would increase weirdness and unexpected behavior
in other places, or at least that's what I think.
To reduce confusion, this goes through the effort of mapping the webvtt
codec, so it's shown "properly" in the codec list. Without this it would
show "null", but still work. In particular, any non-webvtt codecs should
still work if libavcodec supports it.
Not sure if I should remove the --all-subs hack from the code. But I
guess it does no harm.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A previous commit moved the underrun reporting to report_underruns(),
and called it from get_space(). One reason was that I worried about
printing a log message from a "realtime" callback, so I tried to move it
out of the way. (Though there's little justification other than a bad
feeling. While an older version of the pull code tried to avoid any
mutexes at all in the callback to accommodate "requirements" from APIs
like jackaudio, we gave up on that. Nobody has complained yet.)
Simplify this and move underrun reporting back to the callback. But
instead of printing the message from there, move the message into the
playloop. Change the message slightly, because ao->log is inaccessible,
and without the log prefix (e.g. "[ao/alsa]"), some context is missing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AOs can report audio underruns, but only ao_alsa and ao_sdl (???)
currently do so. If the AO was marked as not reporting it, the cache
state was used to determine whether playback was interrupted due to slow
input.
This caused problems in some cases, such as video with very low video
frame rate: when a new frame is displayed, a new frame has to be
decoded, and since there it's so much further into the file (long frame
durations), the cache gets into an underrun state for a short moment,
even though both audio and video are playing fine. Enlarging the audio
buffer didn't help.
Fix this by making all AOs report underruns. If the AO driver does not
report underruns, fall back to using the buffer state.
pull.c behavior is slightly changed. Pull AOs are normally intended to
be used by pseudo-realtime audio APIs that fetch an audio buffer from
the API user via callback. I think it makes no sense to consider a
buffer underflow not an underrun in any situation, since we return
silence to the reader. (OK, maybe the reader could check the return
value? But let's not go there as long as there's no implementation.)
Remove the flag from ao_sdl.c, since it just worked via the generic
mechanism. Make the redundant underrun message verbose only.
push.c seems to log a redundant underflow message when resuming (because
somehow ao_play_data() is called when there's still no new data in the
buffer). But since ao_alsa does its own underrun reporting, and I only
use ao_alsa, I don't really care.
Also in all my tests, there seemed to be a rather high delay until the
underflow was logged (with audio only). I have no idea why this happened
and didn't try to debug this, but there's probably something wrong
somewhere.
This commit may cause random regressions.
See: #7440
|
|
|
|
|
|
|
|
|
|
|
|
| |
As requested I guess. It behaves quite similar to the --loop* options.
Not quite happy with the idea that 1) the option is mutated on each
operation (but at least it's consistent with --loop* and doesn't require
more properties), and 2) the ab-loop command will do nothing once all
loop iterations are done. As a concession, the OSD shows something about
"disabled".
Fixes: #7360
|
|
|
|
|
| |
Also, add the function mp.get_script_directory() to let scripts know if
they're loaded as a directory and where.
|
|
|
|
|
|
|
|
|
| |
Directories inside ~~/scripts/ are now loaded as scripts, so don't use
it also for modules. Now there are no default module paths.
To compensate, we now try to run ~~/.init.js right after defaults.js,
so the user may extend the js init procedure via this script, e.g. for
adding default paths to mp.module_paths .
|
|
|
|
| |
Avoids an additional property access; see previous commit.
|
|
|
|
| |
Convenience; see following commit.
|
|
|
|
| |
Now keypad enter actually works.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While mpv normally uses the text a key produces (as opposed to physical
key mappings), this is different with the keypad. This is for the sake
of making it possible to distinguish between these keys and the normal
number keys on the left side of a full size keyboard.
There were complaints that the keypad doesn't interact with console.lua,
so manually map them. This ignores numlock (behaves as if it's always
on), and maps KP_DEC to "." (even though it's mapped to "," on some
keyboards). The /*-+ keys produce ASCII on mpv (at least with X11) as an
inexplicable inconsistency, so there are no mappings for these.
Fixes: #7431
|
|
|
|
|
| |
It was not meant to imply that screenshots are male. Female (and other)
screenshots are also welcome to this project.
|
|
|
|
|
|
| |