summaryrefslogtreecommitdiffstats
path: root/player/lavfi.c
Commit message (Collapse)AuthorAgeFilesLines
* lavfi: temporary workaround for FFmpeg av_buffersrc_parameters_set() bugwm42017-02-221-0/+9
| | | | | The function ignores AVBufferSrcParameters.channel_layout. Set it manually using the API.
* lavfi: support hwdec filters for --lavfi-complexwm42017-02-201-0/+18
| | | | | | 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.)
* lavfi: use AVBufferSrcParameterswm42017-02-201-23/+34
| | | | | It's nice that you don't have to create a parameter string anymore, but the rest sure is complicated as hell.
* lavfi: use mp_image to store the filter pad formatwm42017-02-201-16/+19
| | | | | | | | | | 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.
* lavfi: fix minor memory leakwm42017-02-131-9/+11
| | | | | | | | | | | 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.)
* lavfi: cosmetics: more consistent variable namingwm42017-02-091-3/+3
|
* lavfi: slightly better disconnected output handlingwm42017-02-081-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* lavfi: shut up false positive compiler warningswm42016-04-261-2/+8
| | | | | | | 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.)
* lavfi: dump the filter graphwm42016-02-121-0/+13
| | | | | | | | 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.
* lavfi: stop playback on some unrecoverable situationswm42016-02-101-1/+3
| | | | Also improve the error message for the missing label case.
* lavfi: fix EOF casewm42016-02-061-3/+4
| | | | | | | | | | | | 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.)
* lavfi: fix build on Libavwm42016-02-051-0/+2
| | | | | | 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.
* player: add complex filter graph supportwm42016-02-051-0/+722
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)