[FFmpeg-devel] [PATCH] lavf/rtmp: Add option to set TCP_NODELAY for rtmp

[Thilo Borgmann]

Hi,

Am 09.06.21 um 12:41 schrieb Nicolas George:
> Thilo Borgman (12021-06-09):
>> $subject seems to be useful depending on the network.
> 
> It looks premature. TCP_NODELAY should only ever used when the network
> code already takes care of writing data in a single system call. This is
> not what happens in ff_rtmp_packet_write() (libavformat/rtmppkt.c): the
> header is written separately.
> 
> Before allowing this option, this piece of code needs to be rewritten to
> reduce system calls.

I'm sorry for a repeated mistake... I remember having asked s.o. in the past to give me feedback about a patch off-list and had been told to ask on the list for everyone to benefit from an elaborate answer. Same thing happened again - now I want it on the list myself as it iterates the discussion. Since Nicolas is sharing his thought here anyway, I dare not to ask him before quoting:


> Thilo Borgman (12021-06-09):
>> thanks for looking at it!
>> Ok let's try, I'm looking at libavformat/rtmppkt.c:377 ff.
>>
>> If I understand you correctly, we might generate the whole output in an
>> extra buffer and then calling ffurl_write() only once on that buffer. Not?
> 
> The ideal solution would be to be able to provide several buffers all at
> once, like writev(). But we do not have this, so buffering would be the
> next best thing.
> 
>> Before I get into implementing this and blindly send it, I wonder if it is
>> worth to have 3 sys calls less for the need to have a new buffer & copy over
>> from header & pkt..?
>>
>> Maybe I just missed something?
> 
> In terms of CPU use, it would bear benchmarking, but it is usually
> considered that an extra buffer copy is better than an extra system
> call. So that is already that.
> 
> But in this case, we are not concerned about CPU use but about network
> overhead and latency. The sockets API flushes after all system calls, we
> can do nothing about it (portably).
> 
> But now that I think on it some more, I realize it would not be
> reasonable to ask for this change. It would be isolated and
> inconsistent: the same issue certainly happens for many network
> protocols.
> 
> What we need is infrastructure to do that properly. Since I have started
> really thinking on making avio callbacks-based, it should give us an
> infrastructure.
> 
> So, for now, I would say: no objection to the option, but please add a
> comment in the code and in the documentation that it is not yet optimal.

Will do before push, thank you!

-Thilo