Up until now, an AVFilter's lists of input and output AVFilterPads
were terminated by a sentinel and the only way to get the length
of these lists was by using avfilter_pad_count(). This has two
drawbacks: first, sizeof(AVFilterPad) is not negligible
(i.e. 64B on 64bit systems); second, getting the size involves
a function call instead of just reading the data.
This commit therefore changes this. The sentinels are removed and new
private fields nb_inputs and nb_outputs are added to AVFilter that
contain the number of elements of the respective AVFilterPad array.
Given that AVFilter.(in|out)puts are the only arrays of zero-terminated
AVFilterPads an API user has access to (AVFilterContext.(in|out)put_pads
are not zero-terminated and they already have a size field) the argument
to avfilter_pad_count() is always one of these lists, so it just has to
find the filter the list belongs to and read said number. This is slower
than before, but a replacement function that just reads the internal numbers
that users are expected to switch to will be added soon; and furthermore,
avfilter_pad_count() is probably never called in hot loops anyway.
This saves about 49KiB from the binary; notice that these sentinels are
not in .bss despite being zeroed: they are in .data.rel.ro due to the
non-sentinels.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible now that the next-API is gone.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
ff_filter_frame() always frees the frame in case of error, so we don't
need to free the frame after ff_filter_frame() fails.
Fix CID 1457230.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
!(c->pix_fmt != AV_PIX_FMT_NONE || c->got_format_from_params)
equals
(c->pix_fmt == AV_PIX_FMT_NONE) && !c->got_format_from_params
1. When (c->pix_fmt == AV_PIX_FMT_NONE) is true, got_format_from_params is
always false, the flag doesn't contribute to the result.
2. When the first part is false, the second part doesn't matter, the flag
doesn't contribute to the result.
The result only depends on c->pix_fmt.
The timestamp of the changed input frame as well as its relevant
properties can be examined by the user. Only applicable when
reinit_filter is disabled on the input stream.
This reverts commit 04aa09c4bc
and reintroduces 0ff5567a30 that
was temporarily reverted due to minor regressions.
It also reverts e5bce8b4ce that fixed FATE refs.
The fate-ffm change is caused by field_order now being set
on the output format because the first frame arrives earlier.
The fate-mxf change is assumed to be the same.
When setting the channel layout directly using AVBufferSrcParameters
the channel layout was correctly set however the init function still
expected the old string format to set the number of channels (when it
hadn't already been specified).
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
A lot of changes happen at the same time:
- Add a framequeue fifo to AVFilterLink.
- split AVFilterLink.status into status_in and status_out: requires
changes to the few filters and programs that use it directly
(f_interleave, split, filtfmts).
- Add a field ready to AVFilterContext, marking when the filter is ready
and its activation priority.
- Add flags to mark blocked links.
- Change ff_filter_frame() to enqueue the frame.
- Change all filtering functions to update the ready field and the
blocked flags.
- Update ff_filter_graph_run_once() to use the ready field.
- buffersrc: always push the frame immediately.
It makes more sense to not claim anything about the SAR if we don't know
anything. No changes in the FATE tests, since this is what avconv ends
up doing anyway.
Many of the functions from avfilter/formats can return errors, usually AVERROR(ENOMEM).
This propagates the return values.
All of these were found by using av_warn_unused_result, demonstrating its utility.
Tested with FATE. I am least sure of the changes to avfilter/filtergraph,
since I don't know what/how reduce_format is intended to behave and how it should
react to errors.
Fixes: CID 1325680, 1325679, 1325678.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Previous version Reviewed-by: Nicolas George <george@nsup.org>
Previous version Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Previously it was partly only added to central functions called
internally, however if GCC would inline these into the public fuction, the
alignment attribute would not take effect.
Instead, add it to all public entry points to avoid these problems.
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously it was partly only added to central functions called
internally, however if GCC would inline these into the public fuction, the
alignment attribute would not take effect.
Instead, add it to all public entry points to avoid these problems.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The functions which actually drive the filter graph by pushing
frames through it need to ensure an aligned stack for SIMD functions.
This fixes a crash in YADIF filter when using a mingw build in a MSVC
application.
Signed-off-by: Martin Storsjö <martin@martin.st>
The line was lost during the AVFrame transition.
It causes programs relying on the failed requests count,
especially ffmpeg, to add frames to the wrong input.
Fix trac ticket #2467.
Andreas Rheinhardt
James Almer
Jun Zhao
Zhao Zhili
Andreas Rheinhardt
Nicolas George
Gyan Doshi
Jun Zhao
Paul B Mahol
Muhammad Faiz
Vittorio Giovara
Rostislav Pehlivanov
Anton Khirnov
Nicolas George
Ganesh Ajjanagadde
Hendrik Leppkes
Federico Tomassetti
Michael Niedermayer
Federico Tomassetti
Clément Bœsch
Lukasz Marek
Stefano Sabatini
Diego Biurrun