The formats API deals with lists of channel layouts, sample rates,
pixel formats and sample formats. These lists are refcounted in a way in
which the list structure itself contains pointers to all of its owners.
Furthermore, it is possible for a list to be not owned by anyone yet;
this status is temporary until the list has been attached to an owner.
Adding an owner to a list involves reallocating the list's list of
owners and can therefore fail.
In order to reduce the amount of checks and cleanup code for the users
of this API, the API is supposed to be lenient when faced with input
lists that are NULL and it is supposed to clean up if adding an owner
to a list fails, so that a simple use case like
list = ff_make_format_list(foo_fmts);
if ((ret = ff_formats_ref(list, &ctx->inputs[0]->out_formats)) < 0)
return ret;
needn't check whether list could be successfully allocated
(ff_formats_ref() return AVERROR(ENOMEM) if it couldn't) and it also
needn't free list if ff_formats_ref() couldn't add an owner for it.
But the cleaning up after itself was broken. The root cause was that
the refcount was decremented during unreferencing whether or not the
element to be unreferenced was actually an owner of the list or not.
This means that if the above sample code is continued by
if ((ret = ff_formats_ref(list, &ctx->inputs[1]->out_formats)) < 0)
return ret;
and that if an error happens at the second ff_formats_ref() call, the
automatic cleaning of list will decrement the refcount from 1 (the sole
owner of list at this moment is ctx->input[0]->out_formats) to 0 and so
the list will be freed; yet ctx->input[0]->out_formats still points to
the list and this will lead to a double free/use-after-free when
ctx->input[0] is freed later.
Presumably in order to work around such an issue, commit
93afb338a4 restricted unreferencing to
lists with owners. This does not solve the root cause (the above example
is not fixed by this) at all, but it solves some crashs.
This commit fixes the API: The list's refcount is only decremented if
an owner is removed from the list of owners and not if the
unref-function is called with a pointer that is not among the owners of
the list. Furtermore, the requirement for the list to have owners is
dropped.
This implies that if the first call to ff_formats_ref() in the above
example fails, the refcount which is initially zero during unreferencing
is not modified, so that the list will be freed automatically in said
call to ff_formats_ref() as every list whose refcount reaches zero is.
If on the other hand, the second call to ff_formats_ref() is the first
to fail, the refcount would stay at one during the automatic
unreferencing in ff_formats_ref(). The list would later be freed when
its last (and in this case sole) owner (namely
ctx->inputs[0]->out_formats) gets unreferenced.
The issues described here for ff_formats_ref() also affected the other
functions of this API. E.g. ff_add_format() failed to clean up after
itself if adding an entry to an already existing list failed (the case
of a freshly allocated list was handled specially and this commit also
removes said code). E.g. ff_all_formats() inherited the flaw.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The query_formats function of the channelmap filter tries to allocate
a list of channel layouts which on success are attached to more permanent
objects (an AVFilterLink) for storage afterwards. If attaching succeeds,
the link becomes one of the common owners (in this case, the only owner)
of the list. Yet if the list has been successfully attached to the link
and an error happens lateron, the list was manually freed, which is wrong,
because it is owned by its link so that the link's pointer to the list will
become dangling and there will be a double-free/use-after-free when the link
is later cleaned up automatically.
This commit fixes this by removing the custom freeing code; this will
temporarily add a leaking codepath (if attaching the list fails, the list
will leak), but this will be fixed soon by making sure that an
AVFilterChannelLayouts without owner will be automatically freed when
attaching it to an AVFilterLink fails.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The query_formats function of the alphamerge filter tries to allocate
two lists of formats which on success are attached to more permanent
objects (AVFilterLinks) for storage afterwards. If attaching a list
to an AVFilterLink succeeds, the link becomes one of the owners of
the list. Yet if attaching a list to one of its links succeeds and
an error happens lateron, both lists were manually freed, which is wrong
if the list is already owned by one or more links; these links' pointers
to their lists will become dangling and there will be a double-free/use-
after-free when these links are cleaned up automatically.
This commit fixes this by removing the custom freeing code; this will
temporarily add a leaking codepath (if attaching a list not already
owned by a link to a link fails, the list will leak), but this will
be fixed soon by making sure that an AVFilterFormats without owner will
be automatically freed when attaching it to an AVFilterLink fails.
At most one list leaks because as of this commit a new list is only
allocated after the old list has been successfully attached to a link.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The query_formats function of the overlay filter tries to allocate
two lists (only one in a special case) of formats which on success
are attached to more permanent objects (AVFilterLinks) for storage
afterwards. If attaching a list to an AVFilterLink succeeds, it is
in turn owned by the AVFilterLink (or more exactly, the AVFilterLink
becomes one of the common owners of the list). Yet if attaching a list
to one of its links succeeds and an error happens lateron, both lists
were manually freed, whic is wrong if the list is already owned by one
or more links; these links' pointers to their lists will become dangling
and there will be a double-free/use-after-free when these links are
cleaned up automatically.
This commit fixes this by removing the custom freeing code; this will
temporarily add a leaking codepath (if attaching a list not already
owned by a link to a link fails, the list will leak), but this will
be fixed soon by making sure that an AVFilterFormats without owner will
be automatically freed when attaching it to an AVFilterLink fails.
Notice that at most one list leaks because a new list is only allocated
after the old list has been successfully attached to a link.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The query_formats function of the remap filter tries to allocate
two lists of formats which on success are attached to more permanent objects
(AVFilterLinks) for storage afterwards. If attaching a list to an
AVFilterLink succeeds, it is in turn owned by the AVFilterLink (or more
exactly, the AVFilterLink becomes one of the common owners of the list).
Yet if attaching a list to one of its links succeeds and an error happens
lateron, both lists were manually freed, which means that is wrong if the
list is already owned by one or more links; these links' pointers to
their lists will become dangling and there will be a double-free/use-after-
free when these links are cleaned up automatically.
This commit fixes this by removing the custom free code; this will
temporarily add a leaking codepath (if attaching a list not already
owned by a link to a link fails, the list will leak), but this will
be fixed soon by making sure that an AVFilterFormats without owner will
be automatically freed when attaching it to an AVFilterLink fails.
Notice at most one list leaks because a new list is only allocated
after the old list has been successfully attached to a link.
Reviewed-by: Nicolas George <george@nsup.org>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The query_formats function of the showpalette filter tries to allocate
two lists of formats which on success are attached to more permanent objects
(AVFilterLinks) for storage afterwards. If attaching a list to an
AVFilterLink succeeds, the link becomes one (in this case the only one)
of the owners of the list. Yet if attaching the first list to its link
succeeds and attaching the second list fails, both lists were manually
freed, which means that the first link's pointer to the first list
becomes dangling and there will be a double-free when the first link is
cleaned up automatically.
This commit fixes this by removing the custom free code; this will
temporarily add a leaking codepath (if attaching a list to a link fails,
the list will leak), but this will be fixed shortly by making sure that
an AVFilterFormats without owner will be automatically freed when
attaching it to an AVFilterLink fails. Notice at most one list leaks
because as of this commit a new list is only allocated after the old list
has been successfully attached to a link.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The query_formats function of the amix filter tries to allocate a list
of channel layouts which are attached to more permanent objects
(an AVFilter's links) for storage afterwards on success. If attaching
a list to a link succeeds, the link becomes one of the common owners
of the list. Yet if a list has been successfully attached to links (or if
there were no links to attach it to in which case
ff_set_common_channel_layouts() already frees the list) and an error
happens lateron, the list was manually freed, which is wrong, because
the list has either already been freed or it is owned by its links in
which case these links' pointers to their list will become dangling and
there will be double-frees/uses-after-free when these links are cleaned
up automatically.
This commit fixes this by removing the custom freeing code; this is made
possible by using the list in ff_set_common_channel_layouts() directly
after its allocation (without anything that can fail in between).
Notice that ff_set_common_channel_layouts() is buggy itself which can
lead to double-frees on error. This is not fixed in this commit.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Replace using ff_add_format() repeatedly by a single call to
ff_make_format_list(). (Right now this also fixes a memleak: If the
first ff_add_format() succeeds and a subsequent call fails, the list
leaks.)
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The vpp_qsv's query_formats function allocated two AVFilterFormats,
before storing them permanently. If storing the first of them fails,
the function simply returns and the second leaks. This has been fixed by
only allocating the second AVFilterFormats structure after the first one
has been successfully stored.
Fixes Coverity issue #1422231.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The paletteuse's query_formats function allocated three AVFilterFormats
before storing them permanently. If allocating one of them failed, the
three AVFilterFormats structures would be freed with av_freep() which
does not free separately allocated subelements (namely the formats
array) which leak.
Furthermore, if storing one of the first two fails, the function simply
returns and the ones not yet stored leak.
These leaks have been fixed by only creating a new AVFilterFormats after
the last one has already been permanently stored. Furthermore, it is
enough to check whether the elements have been properly stored as
ff_formats_ref() by design returns AVERROR(ENOMEM) if it is provided a
NULL AVFilterFormats *.
Fixes Coverity issues #1270818 and #1270819.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Parsing labeled outputs involves a check for an already known match
(a labeled input with the same name) to pair them together. If yes,
it is attempted to create a link between the two filters; in this case
the AVFilterInOuts have fulfilled their purpose and are freed. Yet if
creating the link fails, these AVFilterInOuts have up until now not been
freed, although they had already been removed from their respective lists
(which means that they are not freed automatically). In other words:
They leak. This commit fixes this.
This fixes ticket #7084. Said ticket contains an example program to
reproduce a leak. It can also be reproduced with ffmpeg alone, e.g. with
the complex filters "[0]null[1],[2]anull[0]" or with "[0]abitscope[0]".
All of these three examples involve media type mismatches which make it
impossible to create the links. The bug could also be triggered by other
means, e.g. failure to allocate the necessary AVFilterLink.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The AVFilterInOuts normally get freed in init_output_filter() when
the corresponding streams get created; yet if an error happens before
one reaches said point, they leak. Therefore this commit makes
ffmpeg_cleanup free them, too.
Fixes ticket #8267.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
parse_filter() did not check the return value of av_get_token() for
success; in case name (the name of a filter) was NULL, one got a
segfault in av_strlcpy() (called from create_filter()).
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This happened in parse_link_name() if there was a '[' without matching
']'. While this is not undefined behaviour (pointer arithmetic one
beyond the end of an array works fine as long as there are no accesses),
it is potentially dangerous. It currently isn't (all callers of
parse_link_name() treat this as an error and don't access the string any
more), but making sure that this will never cause trouble in the future
seems nevertheless worthwhile.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
parse_inputs() uses a temporary linked list to parse the labeled inputs
of a filter; said linked list owns its elements (and their names). On
success, the list of unlabeled inputs is appened to the end of the list
of labeled inputs and the new list is returned; yet on failures, nothing
frees the already existing elements of the temporary linked list, leading
to a leak.
This can be triggered by e.g. using '-vf [v][' in the FFmpeg
command-line tool.
This leak seems to exist since 4e781c25b7.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Currently if the frame buffers are full, the frame is unrefed and
dropped. Instead buffer the frame so that it is enqueued in the
next v4l2_receive_packet() call. The behavior was observed on
DragonBoard 410c.
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Check the return value of sscanf as it can return -1(EOF), for example
when the first char in the line is 0x00
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ffmpeg documentation says the NUT container supports SubStation Alpha
This brings actual functionality in line with documentation.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The dvbsubtest_filter.ts sample is a filtered version of the Videolan
sample database (samples/sub/dvbsub/dvbsubtest.ts) using Project X. It
originates from ticket #8844.
The write_colr flag has been marked as experimental for over 5 years.
It should be safe to enable its behavior by default as follows:
- Write the colr atom by default for mp4/mov if any of the following:
- The primaries/trc/matrix are all specified, OR
- There is an ICC profile, OR
- The user specified +write_colr
- Keep the write_colr flag for situations where the user wants to
write the colr atom even if the color info is unspecified (e.g.,
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259334.html)
This fixes https://trac.ffmpeg.org/ticket/7961
Signed-off-by: Michael Bradshaw <mjbshaw@google.com>
This commit removes ff_parse_sample_format(), ff_parse_time_base() and
ff_query_formats_all_layouts() from libavfilter/formats.c. All of these
functions were completely unused. ff_parse_time_base() has not been used
at all since it had been added in 3448404a707b6e236a2ffa7b0453b3300de41b7b;
the last caller of ff_parse_sample_format has been removed in commit
d1c49bcae9. And the one and only caller of
ff_query_formats_all_layouts() (the asyncts filter) has been removed in
commit a8fe8d6b4a.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_planar_sample_fmts_array is unused (and was unused since it was added
in 4d4098da00) and therefore this commit
removes it; ff_packed_sample_fmts_array meanwhile is used only once (in
the amerge filter) and therefore it has been moved to this place.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
dnn_execute_layer_avg_pool() contains the following line:
assert(avgpool_params->padding_method = VALID);
This statement contains an assignment where obviously a comparison was
intended. Furthermore, *avgpool_params is const, so that the attempted
assignment leads to a compilation failure if asserts are enabled
(i.e. if DEBUG is defined which leads libavutil/internal.h to not define
NDEBUG). Moreover, the enumeration constant VALID actually has the value 0,
so that the assert would be triggered if a compiler compiles this with
asserts enabled. Finally, the statement uses assert() directly instead
of av_assert*().
All these errors have been fixed.
Thanks to ubitux for providing a FATE-box [1] where DEBUG is defined.
[1]: http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-ddebug
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Guo, Yejun <yejun.guo@intel.com>
In a function body, a redundant ; is just a null statement that does
nothing. Yet outside a function body, a superfluous ';' like one that
exists if one adds a ';' immediately after a function body's closing
brace is actually invalid C that compilers happen to accept. Yet when
compiled in -pedantic mode, both GCC as well as Clang emit warnings for
this like "ISO C does not allow extra ‘;’ outside of a function
[-Wpedantic]".
The scenario described above existed in vf_overlay.c as a result of
macro expansion. This commit fixes it.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
