[FFmpeg-devel] [PATCH] libavformat: add librist protocol

[Rodney Baker]

On Tuesday, 2 February 2021 0:52:23 ACDT Nicolas George wrote:
> Sergio M. Ammirata, Ph.D. (12021-01-31):
> > 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).
> 
> Can you clarify something? Is this supposed to be a packet protocol or a
> stream protocol?
> 
> I.e., if the reader is waiting for 100 octets, and the writer sent 20
> then 30 then 40, will the reader get three reads of 20, 30, 40 or a
> single read of 20+30+40=90?
> 
> > 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).
> 
> It looks to me like reinventing the wheel that TCP had had years to make
> nicely round. Do we need to implement the Nagle algorithm?
> 
> Regards,

Nagle can introduce unwanted latency which is not desirable for real-time 
streaming. Mind you, tcp is inappropriate for real-time streaming anyway - 
that's what rtsp was invented for. I don't think Nagle belongs at app level 
anyway - it's a network stack function (that can be disabled with the 
TCP_NODELAY setting). 

Truth be told, the MTU should be (and is) controlled by the network stack too, 
but there's no reason to cause packet fragmentation (and the increased latency 
assocaited with packet fragmentation and reassembly) by deliberately 
configuring the app to generate packets larger than the largest possible MTU 
(but I don't really have a say in the matter - just providing advice based on 
hard-learned lessons and experience tuning networks where the largest 
bandwidth application - by orders of magnitude - is real-time streaming 
video). 

Regards,
Rodney.

-- 
==============================================================
Rodney Baker VK5ZTV
rodney.baker at iinet.net.au
CCNA #CSCO12880208
==============================================================