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 _______________________________________________ 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".
