On Wed, May 13, 2020 at 12:35 AM Jan Ekström <jee...@gmail.com> wrote: > > 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. > --- > 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 4f0badcb8d..7a8842e7fe 100644 > --- a/libavformat/tls_schannel.c > +++ b/libavformat/tls_schannel.c > @@ -424,7 +424,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); > > -- > 2.26.2
LGTM. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".