[FFmpeg-devel] [PATCH 2/4] libavformat/tcp: Added an option to reuse sockets
ffmpeg at tmm1.net
Fri Nov 3 18:06:59 EET 2017
On Fri, Nov 3, 2017 at 4:10 AM, Jeyapal, Karthick <kjeyapal at akamai.com>
> >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
> 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
> could be thought of as an implementation level detail to improve
> For example, android HTTP APIs reuse the sockets internally to improve
> without affecting the abstraction.
> >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
> - 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.
I recently implemented keepalive support in the hls demuxer, and have been
using it with a lot of success. See my patchset:
> Or if anybody proposes a better approach, I am willing to consider that as
> > Nicolas George
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel