Re: [FFmpeg-devel] [PATCH v2 1/3] avformat/avformat: Deprecate AVFMT_ALLOW_FLUSH

[Andreas Rheinhardt <andreas.rheinhardt@outlook.com>]

Martin Storsjö:
> On Tue, 26 Sep 2023, Andreas Rheinhardt wrote:
> 
>> Martin Storsjö:
>>> On Tue, 26 Sep 2023, Anton Khirnov wrote:
>>>
>>>> Quoting Andreas Rheinhardt (2023-09-26 01:54:30)
>>>>> It is of no value to the user, because every muxer can always
>>>>> be flushed with a NULL packet. As its documentation shows
>>>>> ("If not set, the muxer will not receive a NULL packet in
>>>>> the write_packet function") it is actually an internal flag
>>>>> that has been publically exposed because there was no internal
>>>>> flags field for output formats for a long time. But now there is
>>>>> and so use it by replacing the public flag with a private one.
>>>>
>>>> Is there any value for the callers in knowing whether flushing is a
>>>> no-op or actually does something?
>>>
>>> Hypthetically, in theory, I guess one could make a case for that. But
>>> most of the codepaths where one use this anyway, one is pretty closely
>>> tied to the specific muxer one is using (usually mov/mp4 or maybe mkv),
>>> so in practice I don't think that's needed.
>>>
>>> I don't remember there being a specific demand for that back when this
>>> was added, it was only a case of us not having internal flags at the
>>> time.
>>>
>>
>> So if we had them back then, you would not have made the flag public?
> 
> Exactly; if we have had private muxer flags at the time, I would
> probably not have made this a public flag.
> 
> So I think this patch is fine.
> 

Ok, will push this on October 3 then unless there are objections.

- 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-request@ffmpeg.org with subject "unsubscribe".