diff options
author | Andreas Rheinhardt <andreas.rheinhardt@outlook.com> | 2021-08-12 17:35:37 +0200 |
---|---|---|
committer | Andreas Rheinhardt <andreas.rheinhardt@outlook.com> | 2021-08-20 12:52:33 +0200 |
commit | d53d48c7993fe2e9ffcc4a638ebd2f4c5273c144 (patch) | |
tree | 198576c72a2f125c777cb6d197938b1c62b15993 /libavfilter/vf_dedot.c | |
parent | c83a7dd25fdf9636e7e5da3fad5e0d82035b9c86 (diff) | |
download | ffmpeg-d53d48c7993fe2e9ffcc4a638ebd2f4c5273c144.tar.gz |
fftools/cmdutils: Use avfilter_pad_count() for AVFilter's number of pads
Besides being nicer code this also has the advantage of not making
assumptions about the internal implementation: While it is documented
that the AVFilter.inputs and AVFilter.outputs arrays are terminated
by a zeroed sentinel, one is not allowed to infer that one can just
check avfilter_pad_get_name(padarray, i) to see whether one has reached
the sentinel:
It could be that the pointer to the string is contained
in a different structure than AVFilterPad that needs to be accessed
first: return pad->struct->string.
It could be that for small strings an internal buffer in
AVFilterPad is used (to avoid a relocation) whereas for longer strings
an external string is used; this is useful to avoid relocations:
return pad->string_ptr ? pad->string_ptr : pad->interal_string
Or it could be that the name has a default value:
return pad->name ? pad->name : "default"
(This actually made sense for us because the name of most of our
AVFilterPads is just "default"; doing so would save lots of relocations.)
The only thing one is allowed to infer from the existence of the
sentinel is that one is allowed to use avfilter_pad_count() to get
the number of pads. Therefore it is used.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Diffstat (limited to 'libavfilter/vf_dedot.c')
0 files changed, 0 insertions, 0 deletions