From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id D472E4647A for ; Mon, 16 Oct 2023 21:24:00 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id E644168C9D5; Tue, 17 Oct 2023 00:23:57 +0300 (EEST) Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id EEF0D68C966 for ; Tue, 17 Oct 2023 00:23:51 +0300 (EEST) Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-40566f8a093so49235525e9.3 for ; Mon, 16 Oct 2023 14:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jkqxz-net.20230601.gappssmtp.com; s=20230601; t=1697491431; x=1698096231; darn=ffmpeg.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=puI0+bJNKDlCoddTYYFhewxdLEhFgM8PloOJBx0Y3eM=; b=VltL/LgNz0PtElFBAvsHA+cgRu5r3mSeJgfapVb3fDw/0dhPHuXzn8r3Fgg1or6zZK vt+SX3lwdRhPxHHKl0I4TbaPHMDGMD6NPGUHrdNjv2339TvuC8AnRlIqPaDS+7yOlyDB G3jWpVC2V1Pb1I/6TdDk4h/OG+gpRwp6NGox+qFNMXwv5/jPseyK1oJwfeIsZt9UA1UU eYtjPL5JNJZH+wSaLr1TSA0swb2TvIoUFDuqw8ufbYFT0tT0DRfObfejoPdVJKHiXLAi fXZPjy68qxFJLhalXXetd8AdXni1wERj2Qg7wYTdqhRsMQQ3yjxd/MOiWuaa5OM0HCdH Yniw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697491431; x=1698096231; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=puI0+bJNKDlCoddTYYFhewxdLEhFgM8PloOJBx0Y3eM=; b=QVUy1JzoUDQ7Xg6WRff0a2nKMN5Ad1gu97tHghBRDCe44DICTseliHaukMJGq3Qr/O xN/TqIPrAz7Plzb/8Eb8xcNXF36g9B5+yWqTIxdi/7pb+6WEntT7RZZfn4evlqBehXMF XRO/SqyjxfEzqyxbbRA/SiEmzwuxp2CS3OfbFhPShAZzlpD+QZjM//hJSpZ3BNymg0Xo dCTo34+8OeSkwkR8IGAG4DAZ3JglpgljaggyZIdGMVEVqE9aotP6EnkxsfISuMisR9uI ifL++kUHgdZZEqWwnrfRvRQt2fCsDFxIq99GZnnrSPymXvzq5Kpaizm7ixA7g+af2mp0 D0KQ== X-Gm-Message-State: AOJu0Yxky3xEahxOTr3z8caeGAuahuzfXEiR+isdkDChshkNGUln8l1x viA2slZcv+RgIlihijqa6GEB9LrW8obAVcDU6ds= X-Google-Smtp-Source: AGHT+IGrp+yhGkiPYz4ARZNt4vYQZcVTQYCvqDqRZ/JsJNMh4SvuOceMMhpGlPdtvdRgldwGzWOcaQ== X-Received: by 2002:a5d:54c6:0:b0:32d:88dd:419b with SMTP id x6-20020a5d54c6000000b0032d88dd419bmr539232wrv.35.1697491431154; Mon, 16 Oct 2023 14:23:51 -0700 (PDT) Received: from [192.168.0.15] (cpc92320-cmbg19-2-0-cust383.5-4.cable.virginm.net. [82.13.65.128]) by smtp.gmail.com with ESMTPSA id t6-20020a5d49c6000000b0032d72f48555sm175061wrs.36.2023.10.16.14.23.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Oct 2023 14:23:50 -0700 (PDT) Message-ID: <2315cfb6-7fed-4429-aebd-d958471898f9@jkqxz.net> Date: Mon, 16 Oct 2023 22:24:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20231016091402.7972-1-lucenticus@gmail.com> From: Mark Thompson In-Reply-To: <20231016091402.7972-1-lucenticus@gmail.com> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/amfenc: Fix for windows imprecise sleep 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 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 16/10/2023 10:13, Evgeny Pavlov wrote: > This commit reduces the sleep time on Windows to improve AMF encoding > performance on low resolution input videos. > This fix is for Windows only, because sleep() function isn't > very accurate on Windows OS. > > Fix for issue #10622 > > Signed-off-by: Evgeny Pavlov > --- > libavcodec/amfenc.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c > index 061859f85c..0c95465d6e 100644 > --- a/libavcodec/amfenc.c > +++ b/libavcodec/amfenc.c > @@ -770,7 +770,11 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket *avpkt) > if (query_output_data_flag == 0) { > if (res_resubmit == AMF_INPUT_FULL || ctx->delayed_drain || (ctx->eof && res_query != AMF_EOF) || (ctx->hwsurfaces_in_queue >= ctx->hwsurfaces_in_queue_max)) { > block_and_wait = 1; > +#ifdef _WIN32 > + av_usleep(0); //Sleep() is not precise on Windows OS. > +#else > av_usleep(1000); > +#endif > } > } > } while (block_and_wait); Wasting lots of power by spinning on a CPU core does not seem like a good answer to this problem. (I mean, presumably that is why Windows isn't honouring your request for a short sleep, because it wants timers to have larger gaps to avoid wasting power.) Why is there a sleep here at all, anyway? An API for hardware encoding should be providing a way for the caller to wait for an outstanding operation to complete. Thanks, - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".