On Fri, 14 Mar 2025, Zhao Zhili wrote:
On Mar 14, 2025, at 04:03, Marton Balint <c...@passwd.hu> wrote: On Thu, 13 Mar 2025, Zhao Zhili wrote:From: Zhao Zhili <zhiliz...@tencent.com> Optimizing memory footprint in memory-constrained systems. Signed-off-by: Zhao Zhili <zhiliz...@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 forhttps://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, Martondiff --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-requ...@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-requ...@ffmpeg.org <mailto:ffmpeg-devel-requ...@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-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
