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.rheinha...@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
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".