On Fri, Nov 3, 2017 at 4:10 AM, Jeyapal, Karthick <kjeya...@akamai.com> wrote:
> >On 11/3/17, 2:18 PM, "Nicolas George" <geo...@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. > I recently implemented keepalive support in the hls demuxer, and have been using it with a lot of success. See my patchset: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/217353.html Aman > > Or if anybody proposes a better approach, I am willing to consider that as > well. > > >Regards, > > > >-- > > Nicolas George > > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
