The wait_start was about POLLING_TIME larger which leads to timeout
100ms late than the option setting.
---
libavformat/network.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/libavformat/network.c b/libavformat/network.c
index 0f5a575f77..7a9a4be5bb 100644
--- a/libavformat/network.c
+++ b/libavformat/network.c
@@ -78,7 +78,10 @@ int ff_network_wait_fd(int fd, int write)
int ff_network_wait_fd_timeout(int fd, int write, int64_t timeout,
AVIOInterruptCB *int_cb)
{
int ret;
- int64_t wait_start = 0;
+ int64_t wait_start;
+
+ if (timeout > 0)
+ wait_start = av_gettime_relative();
I think we intentionally wanted to avoid calling gettime on the fast path.
while (1) {
if (ff_check_interrupt(int_cb))
@@ -86,12 +89,8 @@ int ff_network_wait_fd_timeout(int fd, int write, int64_t
timeout, AVIOInterrupt
ret = ff_network_wait_fd(fd, write);
if (ret != AVERROR(EAGAIN))
return ret;
- if (timeout > 0) {
- if (!wait_start)
- wait_start = av_gettime_relative();
Why not simply wait_start = av_gettime_relative() - POLLING_TIME? It seems
to achieve the same result.
Thanks,
Marton
- else if (av_gettime_relative() - wait_start > timeout)
- return AVERROR(ETIMEDOUT);
- }
+ if (timeout > 0 && (av_gettime_relative() - wait_start > timeout))
+ return AVERROR(ETIMEDOUT);
}
}
--
2.28.0
_______________________________________________
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".
_______________________________________________
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".
