>On 11/15/17, 10:32 AM, "Aman Gupta" <ffm...@tmm1.net> wrote:
>
>From: Aman Gupta <a...@tmm1.net>
>
>Signed-off-by: Aman Gupta <a...@tmm1.net>
>---
> libavformat/http.c | 1 +
> libavformat/tls.c  | 1 +
> 2 files changed, 2 insertions(+)

Again, do want to hardcode tcp_nodelay at http and tls level? Because there 
could be other muxers 
that send data in very small chunks where setting this option would actually 
increase the tcp overhead
severely for such use-cases.

I thought it would be better if the http plugin exposed this as an option and 
hls or dash muxers enable it, 
after we make sure that the relevant TS and MOV muxers used in hls and dash 
plugins writes data as 
big chunks(atleast one frame at a time or some kind of size limit). I think 
movenc already handles it with
dynbuf avio and pushes it only at the end of the segment. But same can’t be 
said about the mpd file or
m3u8 file posts. I think we need to examine the tcpdump logs(or wireshark) to 
make sure that the number
of tcp packets doesn’t increase unexpectedly after this change. 

I am only saying this from muxer point of view. Similarly, we need think from 
demuxer point of view and
make sure that enabling this doesn’t add any unnecessary tcp overhead there as 
well.

My suggestion is to add tcp_nodelay as an option for http and tls and push this 
change.
Later we can modify the hls and dash plugins separately to enable this 
optimization.

Thanks and regards,
Karthick

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to