[FFmpeg-devel] [PATCH 2/4] libavformat/tcp: Added an option to reuse sockets

[Jeyapal, Karthick]

>On 11/3/17, 2:18 PM, "Nicolas George" <george at nsup.org> wrote:

>I strongly oppose this: we do not want new global state.
I also agree. I am open to suggestions, and I would be happy re-implement this feature without new global state.

>Also, I am very doubtful about the feature itself. It is public, and as
>such should be usable for many uses, but I do not see it useful for
>anything but patches 3 and 4. 
Well beyond patch 3 and 4, this feature is usable for HLS player, DASH player and DASH encoder. 
Any other segmented streaming standard would also benefit from this feature.
With internet streaming having moved towards segmented streaming standards, I would think this feature is very useful.
Right now, the performance of hlsenc, dashenc etc., suffers terribly for http output with lower segment sizes.
Also, this feature could be extended for HTTPS/TLS connections as well.

>Furthermore, it is a break of abstraction,
>sockets lose their simple and clear API, they are not really closed when
>they are closed, etc.
Technically it doesn’t break any abstraction. Internally reusing socket connections,
could be thought of as an implementation level detail to improve performance. 
For example, android HTTP APIs reuse the sockets internally to improve performance
without affecting the abstraction.
https://developer.android.com/reference/java/net/HttpURLConnection.html
 
>If you are trying to implement keepalive HTTP for HLS, then most of the
>code should be in http.c and hls*.c, not tcp.c.
That’s a very good point. I had also thought in similar lines. Here is an 
approach that I could think of. 
- Open just one http connection from hlsenc.c
- Somehow call http_shutdown instead of http_close during end of segments/file
- For opening a new segment/file hlsenc calls http_write (with relevant http headers 
composed by hlsenc) instead of a fresh http_open
If ffmpeg maintainers agree to the above approach, I am willing to implement it 
that way. 

Or if anybody proposes a better approach, I am willing to consider that as well.

>Regards,
>
>-- 
>  Nicolas George