From patchwork Tue Mar 21 12:37:28 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Martin_Storsj=C3=B6?= X-Patchwork-Id: 40750 Delivered-To: ffmpegpatchwork2@gmail.com Received: by 2002:a05:6a20:d046:b0:cd:afd7:272c with SMTP id hv6csp2546719pzb; Tue, 21 Mar 2023 05:37:40 -0700 (PDT) X-Google-Smtp-Source: AK7set9ceZLSPCMEFjk4PF56C+lhafqpp4fsmQBi/uMAScpiCxKKvj/comVeC51hYCJ3ZVsHDzpl X-Received: by 2002:aa7:dd44:0:b0:4fd:2346:7225 with SMTP id o4-20020aa7dd44000000b004fd23467225mr2727951edw.34.1679402259892; Tue, 21 Mar 2023 05:37:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679402259; cv=none; d=google.com; s=arc-20160816; b=MWj0tmF2DHrbxxqfo4ihohcj3kb/wUt+T283P5jLv1iPS1uahLoRZlKzFMxXqxqArB dsKnB0Z+eIEIoTJWJQz38X9N+TH0Jj8xqjWF1ZxnV/MUUVbrgmmkRdgW1t1yAV6elvPN 6vMj7dA9bvnp4046TDuF7OKgPYbf00dEwVhRmzxOfq4Tj6J7dwAdE3RC+rNZkFi7IUlP cuz4sKkFmAO87qUQW57XH8FKKSFovUFSFb50XQn/vPi9pT7+cQ/zDYoa9hYxcBoSGijp 6xZVq/9DSmK9tVyy7mlQyzgBgVNGwaR+r6n/yT9x8GCVMqgoTGFeVMbgjswIPP1UDFhn +SnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:content-transfer-encoding:reply-to:list-subscribe :list-help:list-post:list-archive:list-unsubscribe:list-id :precedence:subject:mime-version:message-id:date:to:from :dkim-signature:delivered-to; bh=3yoI53Xa1v5bk/Ion4mTwOla2k9sYf8SkAYCDwFqJ3k=; b=qd+oN6z4pI5Y8q1s10wV+s3m3Y78zW4M37/7zV+b5+ojZiKPwXWFgo15XHxuNf1wFQ JhALDvMjgxIl93kjC9eP4cR87GlNgIk2VcM6CGW+/nAMuV7UGyApkrEiGSrhk3UJ0OlU dj9joSDSch9r2AsLi5YHWeOG/F/S9ObYNOPQnOY6KUR9YxTum9RUvt6tAq3L3gdDJsLC 6yNCKr/7XIWvEaS3lHASrHlEIKlWGpF26300qQgGtndFKgwqY8fo0gHs72g66J9iNh9z Nw7zDebCFTgACHMzVv39uKNkyeMZQIH/QmH2IBkoY3I6GPKyGosI8q0vdawPEdOOgOiD ITBQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@martin-st.20210112.gappssmtp.com header.s=20210112 header.b=HMql7FpG; spf=pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) smtp.mailfrom=ffmpeg-devel-bounces@ffmpeg.org Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org. [79.124.17.100]) by mx.google.com with ESMTP id e9-20020a50fb89000000b004fe93335704si12761640edq.420.2023.03.21.05.37.39; Tue, 21 Mar 2023 05:37:39 -0700 (PDT) Received-SPF: pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) client-ip=79.124.17.100; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@martin-st.20210112.gappssmtp.com header.s=20210112 header.b=HMql7FpG; spf=pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) smtp.mailfrom=ffmpeg-devel-bounces@ffmpeg.org Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 1E5AA68C67D; Tue, 21 Mar 2023 14:37:37 +0200 (EET) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 6E38968C59C for ; Tue, 21 Mar 2023 14:37:31 +0200 (EET) Received: by mail-lj1-f169.google.com with SMTP id g18so15348988ljl.3 for ; Tue, 21 Mar 2023 05:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=martin-st.20210112.gappssmtp.com; s=20210112; t=1679402250; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:from:to:cc:subject:date:message-id:reply-to; bh=3G+En7D9shfO6h0uMykOlSJEndE05s1U4ugorJUedao=; b=HMql7FpGHwDPM7pRVFJmFR1ahRzrsubbm4Qhyv0OqcvneFdLsRTdhvF8qSvfz1EPJz xwPwolDVL8UHDRqgfvtjWx2rxi/I18xHhqzDXtrXxpkfGF29a2fkLR+AsCMJfWRNXf05 6GNygl8kGq3ojIQvT0o4L8m5C5gkXEAGRBpR8N7txlTRyoThOgkZrrq9cLpOA/DkrYd4 N2cNhFBuZQi8ON2l7H4CEZvKzG7BzTY/4+/Ezv57pQD3+0nWV6DKb/3al0G4K2dR50oh Z8MEBRCGGnJSjbbKBc2Prjo/gBrcWBPhHEMNoUxiyPHmsz0rQ5HwGQnUvL28BtBhF/Hq SLxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679402250; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3G+En7D9shfO6h0uMykOlSJEndE05s1U4ugorJUedao=; b=m3yNMsaCJD87LvS1Kk1aaYbwGK8bVUQbWQjHZYQH1cfTXxCt/x9dT+d4Lx1z/rhFeP dhXcddaew5vSMFXT0f1PTs/97M1V8j0/QHIqC2qg2F1snnTl1g6z5aK9tM9/4BSN3y54 4gK28YhOpA73cnpHPB8Hs8fIloGv6Z6MGT+ptODCzWOTMjnA/CqL2b712nUZavXJtyff w+dawnFxTHWbJU07Uxhmfyn0Hd0mTUBZJY/OHikiI+Kq7U3XC4SjVvgDdWsr6ne7CVI3 Kd83574ctgQ8TFEiJFY6UHJLoyHEBU6rMftB8+t2T4QaN6UrzXiBov5Wzk28ZOODoQ05 6NxQ== X-Gm-Message-State: AO0yUKUJAE8sf4lB96wgS9wfkeFpiWC0FylLb6R+mEPUMwRG5YF/IZPk 4VSweyHqoqQ74u96aKY4UxARz3GNKH4wl96Q48vcOg== X-Received: by 2002:a2e:b1d2:0:b0:29a:4a25:d961 with SMTP id e18-20020a2eb1d2000000b0029a4a25d961mr819399lja.45.1679402250583; Tue, 21 Mar 2023 05:37:30 -0700 (PDT) Received: from localhost (dsl-tkubng21-58c01c-243.dhcp.inet.fi. [88.192.28.243]) by smtp.gmail.com with ESMTPSA id g14-20020a19ee0e000000b004dc4c5149dasm2145309lfb.301.2023.03.21.05.37.30 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 21 Mar 2023 05:37:30 -0700 (PDT) From: =?utf-8?q?Martin_Storsj=C3=B6?= To: ffmpeg-devel@ffmpeg.org Date: Tue, 21 Mar 2023 14:37:28 +0200 Message-Id: <20230321123729.74124-1-martin@martin.st> X-Mailer: git-send-email 2.37.1 (Apple Git-137.1) MIME-Version: 1.0 Subject: [FFmpeg-devel] [PATCH 1/2] libavformat: Improve ff_configure_buffers_for_index for excessive deltas X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" X-TUID: YmIs2sIP1NAz Previously, the ff_configure_buffers_for_index function had upper sanity limits of 16 MB (1<<24) for buffer_size and 8 MB (1<<23) for short_seek_threshold. However, if the index analysis showed a need for even larger buffer sizes (for a really badly interleaved file), over the sanity limits, we previously didn't increase the buffer sizes at all. Instead, if the file shows a need for really large buffers and short_seek_threshold, just set them to the maximum sanity limit; while it might not be enough for all cases in the file, it might be enough for most of it. This can happen e.g. with a mov file with some tracks containing some samples that belong in the start of the file, at the end of the mdat, while the rest of the file is mostly reasonably interleaved; previously those samples caused the maximum pos_delta to skyrocket, skipping any buffer size enlargement. Signed-off-by: Martin Storsjö --- libavformat/seek.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libavformat/seek.c b/libavformat/seek.c index a236e285c0..818549dfef 100644 --- a/libavformat/seek.c +++ b/libavformat/seek.c @@ -220,7 +220,8 @@ void ff_configure_buffers_for_index(AVFormatContext *s, int64_t time_tolerance) pos_delta *= 2; ctx = ffiocontext(s->pb); /* XXX This could be adjusted depending on protocol*/ - if (s->pb->buffer_size < pos_delta && pos_delta < (1<<24)) { + pos_delta = FFMIN(pos_delta, 1<<24); + if (s->pb->buffer_size < pos_delta) { av_log(s, AV_LOG_VERBOSE, "Reconfiguring buffers to size %"PRId64"\n", pos_delta); /* realloc the buffer and the original data will be retained */ @@ -232,9 +233,8 @@ void ff_configure_buffers_for_index(AVFormatContext *s, int64_t time_tolerance) ctx->short_seek_threshold = FFMAX(ctx->short_seek_threshold, pos_delta/2); } - if (skip < (1<<23)) { - ctx->short_seek_threshold = FFMAX(ctx->short_seek_threshold, skip); - } + skip = FFMIN(skip, 1<<23); + ctx->short_seek_threshold = FFMAX(ctx->short_seek_threshold, skip); } int av_index_search_timestamp(AVStream *st, int64_t wanted_timestamp, int flags) From patchwork Tue Mar 21 12:37:29 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Martin_Storsj=C3=B6?= X-Patchwork-Id: 40751 Delivered-To: ffmpegpatchwork2@gmail.com Received: by 2002:a05:6a20:d046:b0:cd:afd7:272c with SMTP id hv6csp2546813pzb; Tue, 21 Mar 2023 05:37:48 -0700 (PDT) X-Google-Smtp-Source: AK7set/6RO9SW1D/O1DVlWP/rJueo1tcHlOuai09DXSaUyEVznmB7Ig2pmJJE7eAqE90fncawN2G X-Received: by 2002:a17:906:f8c2:b0:930:3916:df17 with SMTP id lh2-20020a170906f8c200b009303916df17mr2971975ejb.0.1679402268317; Tue, 21 Mar 2023 05:37:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679402268; cv=none; d=google.com; s=arc-20160816; b=MnQUv96QuMbxqlJ/4BlTbcIa/zqcY1kWCJG26cinpx4iF3DkGMPL/QQhvt+XkdSJIC w3snVyidL9lQWzbc7Pru48W6MDqxRLzqgi+4pyPHojbfnrsztz5NyVNrJSQfsn4lJXvl oDlHB/oWXEy9IOCzZLV1/70u7HKNGHcGCQ4iGFJw+5pSgDmxpOEXNOR2XqRm0ZaeCbHz 5j8hibE9grN7HkxSGI82GmXVSJZ1Z6INUp8sqI7fSH8TM+h5v9W6a5+Rg139gY4MpRf+ 1Kybo6KE6epNGELMXT3rXL7ynPaWbKvE/YgB03oM/CYQKIFnph9lI9E/smTjY7XX3JiU q4bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:content-transfer-encoding:reply-to:list-subscribe :list-help:list-post:list-archive:list-unsubscribe:list-id :precedence:subject:mime-version:references:in-reply-to:message-id :date:to:from:dkim-signature:delivered-to; bh=XSF5FqCpvoou/AfQnsmGc94766pk8vXse4h6BJOf/Hc=; b=L1OL62haC/yxgAInQoTFSBM4yDQRwLTPMehet5Br1K29eonYB0TOHbOt+FoTAoC5x9 X5Jcq4sLdh4P4RWgrnjJ5YQ+loxf+ii/mFBYqFld7UDpJajZ/zwxi2uHiotqhFSNBKEd sZLPcpwmT2QOGX6CqXubVRSZvteSmxW/d1lcPRjx348wZAapCZWIbddH8NzrFG4x13+b T7nR9ZW3UJKeMDj3DwrP6wWPg7T9aIYbUPZ+ou0f0UcMdnTLlK64WSZ5Y0IsR4y2wE+K ZX2R9zN5TWBXFQhVrIo3rNcnG+RXkfejKTcM1vgh9pzqUkNlqXyerZ35SHg27agsWJ5F NDEA== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@martin-st.20210112.gappssmtp.com header.s=20210112 header.b=fxnQ0YJc; spf=pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) smtp.mailfrom=ffmpeg-devel-bounces@ffmpeg.org Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org. [79.124.17.100]) by mx.google.com with ESMTP id s5-20020a170906960500b00930f5ecbd94si13153706ejx.346.2023.03.21.05.37.47; Tue, 21 Mar 2023 05:37:48 -0700 (PDT) Received-SPF: pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) client-ip=79.124.17.100; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@martin-st.20210112.gappssmtp.com header.s=20210112 header.b=fxnQ0YJc; spf=pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) smtp.mailfrom=ffmpeg-devel-bounces@ffmpeg.org Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2779468C68B; Tue, 21 Mar 2023 14:37:38 +0200 (EET) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 0C31D68C67A for ; Tue, 21 Mar 2023 14:37:32 +0200 (EET) Received: by mail-lf1-f47.google.com with SMTP id k37so5967013lfv.0 for ; Tue, 21 Mar 2023 05:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=martin-st.20210112.gappssmtp.com; s=20210112; t=1679402251; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:from:to:cc:subject:date:message-id :reply-to; bh=ZkxvFnMHZ8BJjnl6pVvRX6gu0RAXmBtTQJcyjvZPF7E=; b=fxnQ0YJcLivrISNJDmPGIwKI3WdLiG/niUg1oywuWt0i+xf81nkgoQd38vMSi0GWhK DWEa7rNqFYW7kqfLIiwXEk6zIQ6gOmPb4MMNK0jnzMhmHWraG1gtzuz/9OtBmupv5M2u oqEzi0yVaD4KO60nw5l7uG1dIrsz3P0shFCpC45Twu9JXv6WfyNUGP3I/JJ3BmlLLIZr z0zgBOSchgA6lzJHJUdmnLD1P88OJDF6LjfSH50NRO8AmrkIDh+L9TSAVzcYD5Ree4l3 Ilg8UakQe73j5lbz4lq7UOCqPPwUTM/r+RWkOi1YErqO5Cu1WzdT8euVROGylPffccSA 6seA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679402251; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZkxvFnMHZ8BJjnl6pVvRX6gu0RAXmBtTQJcyjvZPF7E=; b=k0y12BBKXAHqyRFpZrirW1iCdZnRg4aGE6twnFzXinj1Wf6torftIkcTOFqAjWJ0Hf LZ+O7i4McpZw2mp/a/lsTfjmCIeVjSK9DnKaF/QggFQtoRehnBLWqaWaP1PRcI9E7f+Y aymmNpzEFfrcvHiiiaiL8a7DE3nXI+A5jCDVtRqDRm6PlrAcWltSec33becEOYkrZ7xa tCgFBy9OZL4eaVNmTiuK8x2Hqm/xno/zVvMyMN1VwGkwzbnR3QO0nBHbMLgIzdH6jvPO p/FzInL45kvBwKhYuZ3HMXKf8KCLWrDwG17DW8yOOA3XHKktW8+cAtrjUX3nP0ae58Tw T6Dg== X-Gm-Message-State: AO0yUKV1pAyx+C09caGQsaiqIDn25bCFlX99yDX6CiesYi6E6LV3DPtQ IDKnwjKpybTp19t/3lS3G4FXNdnymdJ5hkHurHEBaQ== X-Received: by 2002:ac2:5231:0:b0:4e0:ee54:fa23 with SMTP id i17-20020ac25231000000b004e0ee54fa23mr769136lfl.8.1679402251203; Tue, 21 Mar 2023 05:37:31 -0700 (PDT) Received: from localhost (dsl-tkubng21-58c01c-243.dhcp.inet.fi. [88.192.28.243]) by smtp.gmail.com with ESMTPSA id r28-20020ac252bc000000b004e9cad1cd7csm1040471lfm.229.2023.03.21.05.37.30 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 21 Mar 2023 05:37:30 -0700 (PDT) From: =?utf-8?q?Martin_Storsj=C3=B6?= To: ffmpeg-devel@ffmpeg.org Date: Tue, 21 Mar 2023 14:37:29 +0200 Message-Id: <20230321123729.74124-2-martin@martin.st> X-Mailer: git-send-email 2.37.1 (Apple Git-137.1) In-Reply-To: <20230321123729.74124-1-martin@martin.st> References: <20230321123729.74124-1-martin@martin.st> MIME-Version: 1.0 Subject: [FFmpeg-devel] [PATCH 2/2] aviobuf: Avoid clearing the whole buffer in fill_buffer X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" X-TUID: 8VQYmg5BEaZO Normally, fill_buffer reads in one max_packet_size/IO_BUFFER_SIZE worth of data into the buffer, slowly filling the buffer until it is full. Previously, when the buffer was full, fill_buffer would start over from the start, effectively discarding all the previously buffered data. For files that are read linearly, the previous behaviour was fine. For files that exhibit some amount of nonlinear read patterns, especially mov files (where ff_configure_buffers_for_index increases the buffer size to accomodate for the nonlinear reading!) we would mostly be able to seek within the buffer - but whenever we've hit the maximum buffer size, we'd discard most of the buffer and start over with a very small buffer, so the next seek backwards would end up outside of the buffer. Keep one fourth of the buffered data, moving it to the start of the buffer, freeing the rest to be refilled with future data. For mov files with nonlinear read patterns, this almost entirely avoids doing seeks on the lower IO level, where we previously would end up doing seeks occasionally. Signed-off-by: Martin Storsjö --- I'm open to suggestions on whether 1/4 of the buffer is a reasonable amount to keep. It does of course incur some amount of overhead for well behaved linear files, but is a decent improvement for nonlinear mov files. Alternatively we could trigger this behaviour only after we've observed a couple seeks backwards? --- libavformat/aviobuf.c | 46 +++++++++++++++++++++++++++++++++++++------ 1 file changed, 40 insertions(+), 6 deletions(-) diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c index 4ad734a3c3..dfc3e77016 100644 --- a/libavformat/aviobuf.c +++ b/libavformat/aviobuf.c @@ -534,8 +534,7 @@ static void fill_buffer(AVIOContext *s) FFIOContext *const ctx = (FFIOContext *)s; int max_buffer_size = s->max_packet_size ? s->max_packet_size : IO_BUFFER_SIZE; - uint8_t *dst = s->buf_end - s->buffer + max_buffer_size <= s->buffer_size ? - s->buf_end : s->buffer; + uint8_t *dst = s->buf_end; int len = s->buffer_size - (dst - s->buffer); /* can't fill the buffer without read_packet, just set EOF if appropriate */ @@ -546,11 +545,46 @@ static void fill_buffer(AVIOContext *s) if (s->eof_reached) return; - if (s->update_checksum && dst == s->buffer) { - if (s->buf_end > s->checksum_ptr) + if (len < max_buffer_size && s->buffer_size > max_buffer_size) { + /* If the buffer is almost full and we're not trying to read + one whole buffer worth of data at once; keep some amount of + the currently buffered data, but move it to the start of the + buffer, to allow filling the buffer with more data. */ + int keep = (s->buf_end - s->buffer)/4; + int shift = s->buf_end - keep - s->buffer; + + if (s->update_checksum && s->checksum_ptr - s->buffer < shift) { + /* Checksum up to the buffer + shift position (that we're + shifting out of the buffer. */ s->checksum = s->update_checksum(s->checksum, s->checksum_ptr, - s->buf_end - s->checksum_ptr); - s->checksum_ptr = s->buffer; + s->buffer + shift - s->checksum_ptr); + } + + memmove(s->buffer, s->buf_end - keep, keep); + s->buf_end -= shift; + s->buf_ptr -= shift; + if (s->update_checksum) { + if (s->checksum_ptr - s->buffer < shift) + s->checksum_ptr = s->buffer; + else + s->checksum_ptr -= shift; + } + + dst = s->buf_end; + len = s->buffer_size - (dst - s->buffer); + } else if (len < max_buffer_size) { + /* If the buffer is full so we can't fit a whole write of max_buffer_size, + just restart the pointers from the start of the buffer. */ + dst = s->buffer; + len = s->buffer_size; + + if (s->update_checksum) { + /* Checksum all data that gets shifted out of the buffer. */ + if (s->buf_end > s->checksum_ptr) + s->checksum = s->update_checksum(s->checksum, s->checksum_ptr, + s->buf_end - s->checksum_ptr); + s->checksum_ptr = s->buffer; + } } /* make buffer smaller in case it ended up large after probing */