On Fri, 20 Nov 2020, Jan Ekström wrote:
On Fri, Nov 13, 2020 at 12:17 AM Martin Storsjö <mar...@martin.st> wrote:
When the check was added (in 3668701f9600, in 2015), some IO
functions returned 0 on EOF (in particular, the TCP protocol
did, but the TLS protocol returned AVERROR_EOF). Since
0e1f771d2200d in 2017, the TCP protocol also returns AVERROR_EOF
instead of 0, making the check for premature end never have the
intended effect.
---
libavformat/http.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index 3d25d652d3..2d24c00e18 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -1436,7 +1436,8 @@ static int http_buf_read(URLContext *h, uint8_t *buf, int
size)
if ((!s->willclose || s->chunksize == UINT64_MAX) && s->off >=
target_end)
return AVERROR_EOF;
len = ffurl_read(s->hd, buf, size);
- if (!len && (!s->willclose || s->chunksize == UINT64_MAX) && s->off <
target_end) {
+ if ((!len || len == AVERROR_EOF) &&
+ (!s->willclose || s->chunksize == UINT64_MAX) && s->off <
target_end) {
av_log(h, AV_LOG_ERROR,
"Stream ends prematurely at %"PRIu64", should be
%"PRIu64"\n",
s->off, target_end
--
2.24.3 (Apple Git-128)
Change-wise should be OK. Empty or EOF with not enough read leading to
AVERROR(EIO), former being already current behavior.
That said, if this error case always was only regarding EOF use cases
we might want to check the case in ticket 4039 - if simplifying the
check to EOF only still has it work as expected. But that I think is a
separate check/change.
Thanks for having a look, will push this one soon then.
Yeah, removing the check for !len might be fine when/if
FF_API_OLD_AVIO_EOF_0 gets disabled.
// Martin
_______________________________________________
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".
