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 _______________________________________________ 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".