| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
Instead of having reselect_demux_streams() look at all streams, make it
look at the current stream that is being enabled/disabled.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_Of course_ the previous commit broke --force-window behavior (like it
does every single time I touch it).
vo_has_frame() gets cleared after a seek, so e.g. stopping playback of a
file and going to the next by keeping the seek key down will enter a
short moment without video at the end of the first file, which will set
the stalled_video variable to true. Prevent it by using the indication
whether the window was properly created (which is probably exactly what
we want here).
This function is also responsible for destroying the window when needed,
and obviously we should never do that while video is active. (This is
the actual bug, although the other change in this commit already hides
the common breakage it caused.)
|
|
|
|
|
| |
If a video track is selected, but no video is decoded from it (mostly
with broken files), then create the window anyway.
|
|
|
|
|
| |
This is the unfortunate video timer; it's already reset when it actually
matters (after video was prepared and before video is actually started).
|
|
|
|
|
| |
No need for this crazy loop anymore, and we can simply enable it for
each demuxer when it's opened.
|
|
|
|
|
|
|
| |
It was just dead code.
Also fixes the stream-open-filename property, which is supposed to be
read-only if a file was already opened.
|
|
|
|
|
|
| |
Some oddity that is not needed anymore. The only thing which still
referenced them was avoiding loading external files more than once,
which is now prevented by checking the list of tracks instead.
|
|
|
|
|
|
| |
Accidental leftover from commit ae55896f. (This seek ised to be done
with ordered chapters, and was accidentally changed to always being
done.)
|
| |
|
|
|
|
|
| |
Preparation for the timeline rewrite. The codec will be able to change,
the stream header not.
|
|
|
|
| |
This is always the same value.
|
|
|
|
| |
(Limited usefulness.)
|
|
|
|
|
|
|
|
|
| |
When playback of a video ends, and the next file has no video at all (no
cover art or anything), then the window must be cleared.
This also resizes the window forcibly, which is by design.
Fixes #2825.
|
|
|
|
| |
It signalled failure instead.
|
|
|
|
|
|
|
|
| |
Especially useful to see what video formats are involved on the various
filter links.
I suspect this function is not available on Libav, so add necessary
ifdeffery preemptively.
|
|
|
|
| |
Fixes CID 1350055 and CID 1350054.
|
|
|
|
|
|
| |
Fixes CID 1350058.
(Still looks like this might be valid C, in some fucked up way.)
|
| |
|
|
|
|
| |
Also improve the error message for the missing label case.
|
|
|
|
|
|
|
|
| |
It would make somewhat sense for libcs which don't implement locales at
all, such as Bionic.
Beyond that, setlocale() is specified that it can return NULL, and we
shouldn't crash if that happens.
|
|
|
|
| |
Caused by the recent refactoring for complex filters.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately I see no better solution.
The refresh seek is skipped if the amount of buffered audio is not
overly huge.
Unfortunately softvol af_volume insertion still can cause this issue,
because it's outside of the normal dynamic filter chain changing code.
Move the video refresh call to reinit_video_filters() to make it more
uniform along with the audio code.
|
|
|
|
| |
Mostly intended for use with --lavfi-complex.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was dumb. Could make it burn 100% CPU and not exit at the end.
(Because it would retry as instructed, instead of terminating playback.)
It also needs to consider EOF as waiting for input. lavfi_process() will
decide if it's really EOF, or if further input might come in the future.
Without this, it'd would think that it does not need to wait for input,
i.e. that new input will be available immediately.
(Not so fond of the duplication of subtle logic.)
|
|
|
|
| |
The code for decoding the initial frame has to handle this explicitly.
|
|
|
|
| |
Now it's used for initialization only for audio and video.
|
|
|
|
|
|
| |
It doesn't provide this function. The code is not really designed to
work without it, so it will probably mess up big time, but at least
make it compile again.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See --lavfi-complex option.
This is still quite rough. There's no support for dynamic configuration
of any kind. There are probably corner cases where playback might freeze
or burn 100% CPU (due to dataflow problems when interaction with
libavfilter).
Future possible plans might include:
- freely switch tracks by providing some sort of default track graph
label
- automatically enabling audio visualization
- automatically mix audio or stack video when multiple tracks are
selected at once (similar to how multiple sub tracks can be selected)
|
|
|
|
| |
Preparation.
|
|
|
|
|
|
| |
track can't be NLUL at this point, so the if is redundant. Remove it and
unindent the block. Also, make the function check whether the track is
selected at all, which makes it safer and idempotent.
|
|
|
|
|
| |
The main reason for changing the fullscreen default is that not doing it
would change the vo_rpi default behavior with the previous commit.
|
|
|
|
|
|
| |
Apparently useful for window embedding.
Fixes #2750.
|
|
|
|
|
|
|
| |
For bitmap subs, implement it properly. For libass, you need newest git
master.
Fixes #2791.
|
|
|
|
|
|
| |
Also remove the unused function argument.
Fixes #2784.
|
|
|
|
|
| |
Basically, just make it append " (original)" if the original aspect
ratio is selected.
|
|
|
|
| |
Don't mind me.
|
|
|
|
| |
Slightly better.
|
|
|
|
|
|
| |
Will be helpful for the coming filter support. I planned on merging
audio/video decoding, but this will have to wait a bit longer, so only
remove the duplicate status codes.
|
|
|
|
|
|
|
|
|
| |
Let's fix broken samples with questionable heuristic without real
reasoning. Until this gets fixed properly, this is a good compromise,
though. A proper fix would properly resync audio and video without
brutally resetting the decoders, but on the other hand not doing the
brutal reset would cause issues in other obscure corner cases such
resyncing might cause.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code is tricky because it has to wakeup the mainloop to make
progressing during syncing audio, but also has to avoid waking it up
when it's not needed. Failure to do so either burns CPU by not ever
going to sleep, or causes apparent "freezes" by going to sleep (and it
will continue if the mainloop is woken up e.g. due to user input).
In this case, simply starting A/V playback with --start=5 and removing
an unrelated wakeup in osd.c can trigger such a "freeze". The unrelated
wakeup did hide this bug, nonetheless it's a bug.
(Can't wait to rewrite this shitty audio resync code. And it's all my
fault.)
|
|
|
|
|
|
|
| |
We just need to provide an entrypoint for it, and move the main init
code to a separate function. This gets rid of the messy video chain full
reinit in command.c, which completely destroyed and recreated the video
state for the purpose of mid-stream hw/sw switching.
|
|
|
|
|
|
| |
These changes don't make too much sense without context, but are
preparation for later. Then the audio_src/video_src fields will be
actually be NULL under circumstances.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this commit, reinit_audio_chain() did 2 things: create all the
management data structures and initialize the decoder, and handling lazy
filter/output init (as well as dealing with format changes). For the
second purpose, it could be called multiple times (even though it wasn't
really idempotent). This was pretty weird, so make them separate
functions. The new function is actually idempotent too.
It also turns out the reinit functions don't have to call themselves
recursively for the spdif PCM fallback.
|
|
|
|
| |
Reduces the dependency of the filter/output code on the decoder.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Regression caused by commit 3b95dd47. Also see commit 4c25b000. We can
either use video_next_pts and add "delay", or we just use video_pts. Any
other combination breaks. The reason why the assumption that delay==0 at
this point was wrong exactly because after displaying the first video
frame (usually done before audio resync) a new frame might be "added"
immediately, resulting in a new video_next_pts and "delay", which will
still amount to video_pts.
Fixes #2770. (The reason why display-sync was blamed in this issue is
because enabling display-sync in the options forces a prefetch by 2
instead of 1 frames for seeks/playback restart, which triggers the
issue, even if display-sync is not actually enabled. In this case,
display-sync is never enabled because the frames have a unusually high
frame duration. This is also what exposed the initial desync issue.)
|
|
|
|
|
|
| |
If cover art is re-enabled during playback, the covert art picture
(which has pts==0) will be discarded. Add another corner case to
the list.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This seems generally easier when using libmpv (and was already requested
and implemented before: see commit 327a779a; it was reverted some time
later).
With the weird internal logic we have to deal with, in particular the
--softvol=no case (using system volume), and using the audio API's mixer
(--softvol=auto on some systems), we still can't avoid all glitches and
corner cases that complicate this issue so much. The API user is either
recommended to use --softvol=yes or auto, or to watch the new
mixer-active property, and assume the volume/mute properties have
significant values if the mixer is active.
Remaining glitches:
- changing the volume/mute properties has no effect if no internal mixer
is used (--softvol=no) and the mixer is not active; the actual mixer
controls do not change, only the property values
- --volume/--mute do not have an effect on the volume/mute properties
before mixer initialization (the options strictly are only applied
during mixer init)
- volume-max is 100 while the mixer is not active
|
|
|
|
|
| |
Resync newly switched video streams to the current playback position.
(Normal seeks will reset playback_pts to NOPTS.)
|
|
|
|
|
|
|
|
|
| |
With the format left untouched, this would just try to reinit with a
spdif format again.
We're not clearing the format in reset_audio_state() so the audio chain
can be recreated any time without having to wait for a frame to be
decoded.
|
| |
|