[FFmpeg-devel] [PATCH 04/21] avformat: Redo cleanup of demuxer upon read_header() failure

[Andreas Rheinhardt]

Andreas Rheinhardt:
> James Almer:
>> On 3/22/2020 12:47 AM, 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 has been 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() instead of av_freep() is used; 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 has been added to a new internal field of AVInputFormat,
>>> flags_internal. When it has become redundant, it can be removed again
>>> at the next major version bump.
>>
>> Fields considered not public (And thus added below the relevant notice
>> in the struct) can be added and removed at any time. So this sentence is
>> not needed.
>>
> This field is not public, but I thought that the fact that libavdevice
> also defines AVInputFormats makes this de-facto avpriv. Isn't it allowed
> to use a newer libavdevice together with an older libavformat? Imagine
> your libavdevice to be so new that the field has already been removed,
> yet the libavformat being so old that it still checks for the field.
> That would not go well.
> (If I am right then this gives the task of checking and adapting all the
> demuxers a certain urgency to be finished before the next major bump.)
> 
I reconsidered this and I think I got it exactly wrong: libavdevice is
linked against libavformat, not the other way around. Therefore one can
swap the libavformat against a newer one, but one is not allowed to
update libavdevice without also updating libavformat. (This presumes
that the usual rules apply in this scenario; I haven't seen any
exception documented for the special case of the heavily interwoven
libavdevice and libavformat, so I guess there is none.)

This means that adding new fields to AVInputFormat (and using them) is
not possible, because said AVInputFormat might come from an older
version of libavdevice and might therefore not have these fields.

This means that my proposal has to be modified. flags_internal is not
feasible (unless one uses a version check for. One could use a not
publically documented flag of the normal flags.

This also means that this flag can not be enabled by default (and
therefore removed) before the next major version bump. E.g. the alsa
input device seems to be incompatible with automatically running its
read_close function after failure of reading the header (the current
error handling closes a snd_pcm_t, but doesn't reset the pointer to NULL).

- Andreas