[FFmpeg-devel] [PATCH v2 1/2] avformat: Redo cleanup of demuxer upon read_header() failure

Michael Niedermayer michael at niedermayer.cc
Mon Jul 20 21:53:57 EEST 2020


On Sun, Jul 19, 2020 at 10:47:54PM +0200, Andreas Rheinhardt wrote:
> If reading the header fails, the demuxer's read_close() function (if
> existing) is not called automatically; instead several demuxers call it
> via "goto fail" in read_header().
> 
> This commit intends to change this by adding a flag to AVInputFormat
> that can be used to set on a per-AVInputFormat basis whether read_close()
> should be called generically after an error during read_header().
> 
> The flag controlling this behaviour needs to be added because it might
> be unsafe to call read_close() generally (e.g. this might lead to
> read_close() being called twice and this might e.g. lead to double-frees
> if av_free() is used instead of av_freep(); or a size field has not
> been reset after freeing the elements (see the mov demuxer for an
> example of this)). Yet the intention is to check and fix all demuxers
> and make the flag redundant in the medium run.
> 
> The flag itself is non-public (it resides in libavformat/internal.h),
> but it has been added to the ordinary (i.e. public) flags field of
> AVInputFormat, because there is no field for internal flags and adding
> one is not possible, because libavdevice also defines AVInputFormats
> and so there is the possibility that a newer libavformat is used
> together with an older libavdevice that would then lack the new field
> for internal flags. When it has become redundant, it can be removed again
> at the next major version bump.
> 
> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt at gmail.com>
> ---
> This is an updated version of my initial patch [1]. I have also rebased
> the whole set of patches following it (with the exception of the w3c
> patch in the next patch they no longer fix a memleak; instead they now
> only set the flag and remove the manual calls to read_close). Should I
> resend the other patches, too?
> 
> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/258830.html
> 
>  libavformat/internal.h |  6 ++++++
>  libavformat/utils.c    | 11 +++++++++--
>  2 files changed, 15 insertions(+), 2 deletions(-)

LGTM

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200720/29fe5f1a/attachment.sig>


More information about the ffmpeg-devel mailing list