| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Tends to be somewhat glitchy if subtitles are enabled, and you enable
and disable tracks.
On error, this will disable --lavfi-complex, which will result in
whatever behavior.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 0e0b87b6f3297 fixed that dropped packets did not trigger further
work correctly. But it also made trivial --lavfi-complex freeze. The
reason is that the meaning if DATA_AGAIN was overloaded: the decoders
meant that they should be called again, while lavfi.c meant that other
outputs needed to be checked again. Rename the latter meaning to
DATA_STARVE, which means that the current input will deliver no more
data, until "other" work has been done (like reading other outputs, or
feeding input).
The decoders never return DATA_STARVE, because they don't get input from
the player core (instead, they get it from the demuxer directly, which
is why they still can return DATA_WAIT).
Also document the DATA_* semantics in the enum.
Fixes #4746.
|
|
|
|
|
| |
The function ignores AVBufferSrcParameters.channel_layout. Set it
manually using the API.
|
|
|
|
|
|
| |
Not so important by itself, but important for when we replace the vf
libavfilter wrapper with the common implementation. (Which will
hopefully happen, but not too soon.)
|
|
|
|
|
| |
It's nice that you don't have to create a parameter string anymore, but
the rest sure is complicated as hell.
|
|
|
|
|
|
|
|
|
|
| |
Preparation for enabling hw filters. mp_image_params can't have an
AVHWFramesContext reference (because it can't hold any allocations, and
isn't meant to hold "active" data in the first place.
So just use a mp_image. It has all real data removed, because that would
essentially leak 1 frame once the decoder or renderer don't need it
anymore.
|
|
|
|
|
|
|
|
|
|
|
| |
The AVFrame in the tmp_frame field was never actually deallocated.
Since this AVFrame holds data temporarily only, and is unreferenced
immediately after use, there is actually no need to make it per-pad, so
simplify it a bit.
(There's also no real value in caching this tmp_frame at all, but I
guess it makes the control flow slightly simpler.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we have a disconnected output, read data only passively (and don't
cause input to be written). Otherwise, we're in danger of making
libavfilter queue too many frames on other outputs which are connected
to the same input, but don't read as quickly.
Also don't set pad->output_needed in this specific case, because it
would nonsensically make lavfi_process() return true, even if nothing is
going on.
This commit breaks if there is a simple filter chain with a connected
input, but a disconnected output, like
--lavfi-complex='[aid1] copy [ao]'
and the audio output didn't initialize correctly. This will eventually
starve video as the audio packet queue get full (it will print a
warning, and then assume video EOF and exit).
But whatever.
Probably fixes #4118.
|
|
|
|
|
|
|
| |
As a positive side-effect, this also errors out gracefully for the
extremely unlikely but possible case certain builtin filters are not
available. (This could happen only with crippled libavfilter builds that
can't be used by anything using its public API.)
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Also improve the error message for the missing label case.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
|
|
| |
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)
|