On Monday, 1 February 2021 8:03:28 ACDT Sergio M. Ammirata, Ph.D. wrote: > librist has an internal buffer limit of 10000 bytes (the > protocol has none). > > For writing, the data you give librist, will go out "as is" > to the network with some added protocol overhead bytes (28 > bytes without encryption enabled and 36 bytes with > encryption enabled). > > To avoid your data being fragmented because of network MTU, > you should really limit the write size to what you want > your IP packets to be. For mpegts, for example, 1316 is a > good number to keep the overall packet size below the > typical internet MTU size of 1500 (1400 to be safe). > > I suggest this "max" write size be a configurable setting > in ffmpeg so that a higher number can be used if you are > running it where the network supports jumbo packets.
If I can chime in as an experienced network designer/administrator, I concur with comments by Sergio and Marton. This should definitely be a configurable parameter for writing, with a default value of 1500 or less, and a maximum allowed value of 9216 (the highest jumbo frame MTU guaranteed to be supported by most modern networking equipment). The generally agreed (industry-wide) standard for jumbo packet MTU's is 9000 bytes, but most will support up to 9216. That does, however, depend on the maximum MTU configured by the network admins at any given location or organisation. Any packets larger than that must be fragmented by the network equipment, and that means CPU/Process switching all such packets rather than hardware switching, which adds to CPU and memory usage on the network kit and gets the network admins offside. The only time <1500 is really needed is for network links where tunnelling/ encapsulation is involved (e.g. VPN links using GRE, IPSec, IP-in-IP or some other encapsulation that results in a reduced MTU). In this case it should be able to be configured for values anywere from 1316 to 1422. Any network admin worth his salt will know how to check the maximum MTU for a given network path and advise the app owner to set the values accordingly. > > For reading, you can keep the 9964 number always. No harm in that, agreed. [...] -- ============================================================== Rodney Baker VK5ZTV rodney.ba...@iinet.net.au CCNA #CSCO12880208 ============================================================== _______________________________________________ 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".
