[FFmpeg-devel] [PATCH] avformat/avio: Add max_pkt_size option

[Marton Balint]

On Fri, 14 Mar 2025, Zhao Zhili wrote:

>
>
>> On Mar 14, 2025, at 04:03, Marton Balint <cus at passwd.hu> wrote:
>> 
>> 
>> On Thu, 13 Mar 2025, Zhao Zhili wrote:
>> 
>>> From: Zhao Zhili <zhilizhao at tencent.com>
>>> 
>>> Optimizing memory footprint in memory-constrained systems.
>>> 
>>> Signed-off-by: Zhao Zhili <zhilizhao at tencent.com>
>>> ---
>>> libavformat/avio.c    | 2 ++
>>> libavformat/version.h | 2 +-
>>> 2 files changed, 3 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/libavformat/avio.c b/libavformat/avio.c
>>> index d109f3adff..e1b959ed73 100644
>>> --- a/libavformat/avio.c
>>> +++ b/libavformat/avio.c
>>> @@ -61,6 +61,8 @@ static const AVOption options[] = {
>>>    {"protocol_whitelist", "List of protocols that are allowed to be used", OFFSET(protocol_whitelist), AV_OPT_TYPE_STRING, { .str = NULL },  0, 0, D },
>>>    {"protocol_blacklist", "List of protocols that are not allowed to be used", OFFSET(protocol_blacklist), AV_OPT_TYPE_STRING, { .str = NULL },  0, 0, D },
>>>    {"rw_timeout", "Timeout for IO operations (in microseconds)", offsetof(URLContext, rw_timeout), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, AV_OPT_FLAG_ENCODING_PARAM | AV_OPT_FLAG_DECODING_PARAM },
>>> +    {"max_pkt_size", "Default maximum packet size in bytes, could be overwritten by particular protocol",
>>> +            offsetof(URLContext, max_packet_size), AV_OPT_TYPE_INT, { .i64 = IO_BUFFER_SIZE }, 0, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM | AV_OPT_FLAG_DECODING_PARAM },
>>>    { NULL }
>>> };
>> 
>> 
>> This feels super confusing. A *max_packet_size* option which might not do anything at all depending on the protocol the user is using, and which the user might override with the protocol specific *pkt_size* option if it exists. So I'd rather not expose ->max_pkt_size like that.
>
> rw_timeout has the same issue, it’s still useful for users.

And it is confusing for the users when the -timeout option can/should be 
used and when -rw_timeout. Not to mention which one is in miliseconds, 
nanoseconds or seconds.

In general it is not nice from the users point of view that some options 
are allowed to be set when they are not actually supported, and the user 
have no feedback about it, that is why I'd rather go for the protocol 
specific options. And also since protocols are controlling this right now 
anyway.

>
> The patch is for 
>
> https://ffmpeg.org/pipermail/ffmpeg-devel/2025-March/341114.html

Yeah, I saw that, and to be honest, it is a bit suprising to me that 32k 
for IO buffer is too big for something that actually runs ffmpeg/avformat 
(which allocates a lot more RAM than that). So probably it would be nice 
to hear a bit more about the use case.

>
> We can add pkt_size for more protocols, but it sounds weird for tcp
> with pkt_size option.

You are right, pkt_size (or max_pkt_size) is not the right name for this. 
For example max_pkt_size conflicts with mpegts "max_pkt_size" option.

>
> Use can change AVIOContext::max_packet_size directly. I’m not sure
> if it’s better or valid.

AVIOContext struct unfortunately does not sepearte public and private 
fields, so there is no clear boundary...

Regards,
Marton

>
>> 
>> Regards,
>> Marton
>> 
>> 
>>> 
>>> diff --git a/libavformat/version.h b/libavformat/version.h
>>> index 6ffdf61b43..e1ab967f5b 100644
>>> --- a/libavformat/version.h
>>> +++ b/libavformat/version.h
>>> @@ -32,7 +32,7 @@
>>> #include "version_major.h"
>>> 
>>> #define LIBAVFORMAT_VERSION_MINOR   9
>>> -#define LIBAVFORMAT_VERSION_MICRO 107
>>> +#define LIBAVFORMAT_VERSION_MICRO 108
>>> 
>>> #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
>>>                                               LIBAVFORMAT_VERSION_MINOR, \
>>> -- 
>>> 2.46.0
>>> 
>>> _______________________________________________
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel at ffmpeg.org
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>> 
>>> To unsubscribe, visit link above, or email
>>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>>> 
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org <mailto:ffmpeg-devel at ffmpeg.org>
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-request at ffmpeg.org <mailto:ffmpeg-devel-request at ffmpeg.org> with subject "unsubscribe".
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".