On 08.01.25 08:35, Marth64 wrote:
As it’s effectively controlling the value of the Range header, this is also
something one can do with curl’s -r switch or -headers on the http protocol
handler now. So I think it’s reasonable to make it available as an option.
I would not necessarily brand it as a hack in the commit message since
there could be legitimate use cases as well when tuning for network
performance, etc.
Unfortunately if users want to use it to circumvent throttling or frustrate
upstream servers that is a risk already with the options currently
available (overriding custom headers including Range, aggressive retry
policies, etc.)
I think it’s ok. I would maybe call it -max_range_size or similar instead
since the size of the request isn’t changing but rather we are asking the
server to provide a differently sized chunk.
Hi,
if I'll change it to anything then maybe max_requested_size, but
max_range_size seems less clear to me because that it does this through
the range header is not relevant to the user, its effect is, which is
that FFmpeg requests less data per sent request.
I'd rather get some technical feedback on the implementation from
someone though, I don't think FFmpeg does any kind of connection pooling
so if there are two concurrent streams being fetched from it probably
re-establishes the keep-open connection each time as the host may change
between them.
Thoughts?
Thank you.
_______________________________________________
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".
