[FFmpeg-cvslog] avformat/tls_schannel: immediately return decrypted data if available

Jan Ekström git at videolan.org
Fri Sep 4 21:15:03 EEST 2020


ffmpeg | branch: release/3.2 | Jan Ekström <jeebjp at gmail.com> | Wed May 13 00:31:03 2020 +0300| [cb772c3597b8b69e57b84b08b25b882dbbdf59fe] | committer: Jan Ekström

avformat/tls_schannel: immediately return decrypted data if available

Until now, we would have only attempted to utilize already decrypted
data if it was enough to fill the size of buffer requested, that could
very well be up to 32 kilobytes.

With keep-alive connections this would just lead to recv blocking
until rw_timeout had been reached, as the connection would not be
officially closed after each transfer. This would also lead to a
loop, as such timed out I/O request would just be attempted again.

By just returning the available decrypted data, keep-alive based
connectivity such as HLS playback is fixed with schannel.

(cherry picked from commit 6f8826e4aaddf1ee6cf3f333ed0e392a748382fe)

> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=cb772c3597b8b69e57b84b08b25b882dbbdf59fe
---

 libavformat/tls_schannel.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavformat/tls_schannel.c b/libavformat/tls_schannel.c
index b0ce6b88fa..db6d0b8dc0 100644
--- a/libavformat/tls_schannel.c
+++ b/libavformat/tls_schannel.c
@@ -392,7 +392,12 @@ static int tls_read(URLContext *h, uint8_t *buf, int len)
     int size, ret;
     int min_enc_buf_size = len + SCHANNEL_FREE_BUFFER_SIZE;
 
-    if (len <= c->dec_buf_offset)
+    /* If we have some left-over data from previous network activity,
+     * return it first in case it is enough. It may contain
+     * data that is required to know whether this connection
+     * is still required or not, esp. in case of HTTP keep-alive
+     * connections. */
+    if (c->dec_buf_offset > 0)
         goto cleanup;
 
     if (c->sspi_close_notify)



More information about the ffmpeg-cvslog mailing list