ffmpeg | branch: release/3.4 | Jan Ekström <jee...@gmail.com> | Wed May 13 00:27:58 2020 +0300| [895f67bbed4360ffbf507b0cfb2c98b3e17a7266] | committer: Jan Ekström
avformat/tls_schannel: always decrypt all received data The dec_buf seems to be properly managed between read calls, and we have no logic to decrypt before attempting socket I/O. Thus - until now - such data would not be decrypted in case of connections such as HTTP keep-alive, as the recv call would always get executed first, block until rw_timeout, and then get retried by retry_transfer_wrapper. Thus - if data is received - decrypt all of it right away. This way it is available for the following requests in case they can be satisfied with it. (cherry picked from commit 39977fff20048f1798a95c593d6034a0e73ebbe5) > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=895f67bbed4360ffbf507b0cfb2c98b3e17a7266 --- libavformat/tls_schannel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/tls_schannel.c b/libavformat/tls_schannel.c index 1c65c25441..7718681495 100644 --- a/libavformat/tls_schannel.c +++ b/libavformat/tls_schannel.c @@ -422,7 +422,7 @@ static int tls_read(URLContext *h, uint8_t *buf, int len) c->enc_buf_offset += ret; } - while (c->enc_buf_offset > 0 && sspi_ret == SEC_E_OK && c->dec_buf_offset < len) { + while (c->enc_buf_offset > 0 && sspi_ret == SEC_E_OK) { /* input buffer */ init_sec_buffer(&inbuf[0], SECBUFFER_DATA, c->enc_buf, c->enc_buf_offset); _______________________________________________ ffmpeg-cvslog mailing list ffmpeg-cvslog@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-cvslog To unsubscribe, visit link above, or email ffmpeg-cvslog-requ...@ffmpeg.org with subject "unsubscribe".
