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

[Marton Balint <cus@passwd.hu>]

On Fri, 14 Mar 2025, Zhao Zhili wrote:

>
>
>> On Mar 14, 2025, at 04:03, Marton Balint <cus@passwd.hu> wrote:
>> 
>> 
>> On Thu, 13 Mar 2025, Zhao Zhili wrote:
>> 
>>> From: Zhao Zhili <zhilizhao@tencent.com>
>>> 
>>> Optimizing memory footprint in memory-constrained systems.
>>> 
>>> Signed-off-by: Zhao Zhili <zhilizhao@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@ffmpeg.org
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>> 
>>> To unsubscribe, visit link above, or email
>>> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>>> 
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org <mailto:ffmpeg-devel@ffmpeg.org>
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-request@ffmpeg.org <mailto:ffmpeg-devel-request@ffmpeg.org> with subject "unsubscribe".
>
> _______________________________________________
> 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".
_______________________________________________
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".