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 7D8C745D4D for ; Fri, 7 Apr 2023 07:22:47 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B0C9E68AA0F; Fri, 7 Apr 2023 10:22:44 +0300 (EEST) Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id EB77D689B45 for ; Fri, 7 Apr 2023 10:22:37 +0300 (EEST) Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-54bfa5e698eso115988067b3.13 for ; Fri, 07 Apr 2023 00:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=davyandbeth-com.20210112.gappssmtp.com; s=20210112; t=1680852156; h=content-transfer-encoding:content-language:to:subject:from :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=Z1i+sukKfwu3F8HM/il1uXaNxgNRFlAueyhED75SKpY=; b=QT0FiIYNULWqaUqMeD45eec9SQHFLLEU4l+jRVB3As3LOktKnn1Xi7PlbvnPAP12OE gNIythNlkKhvwyd1VqohaUi7YF1CYArqGwIY3WH3TAMZCSClpNDVxpvrCzrQSFxC9Lhy BaSGXLu7c8CKgQborYhOKyIGg2G919tTdU067Ejv3Hh12yXrZqleclsgLInqlrrJoHCh W6HwTQAsp/pP+X9JXQwns6f/wkkOpYNHDh3+eVpbndITRnkSdj7LEhfLzSHnqKjGoWDz 4buNDWnxqXsTAN+VKJOKnlo5RvaPrDrZrt3AWLy9MjuDpvZF1jj/9qpkPzxsdQy4mUL4 Rmiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680852156; h=content-transfer-encoding:content-language:to:subject:from :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=Z1i+sukKfwu3F8HM/il1uXaNxgNRFlAueyhED75SKpY=; b=cMAu2D7V+1xIZYUKU5L/HkE/QyRdUP3sk0PV62rKgDeqGPbfOlrfQvgRg6swNhvF4T OPy3ZoY94L8HhVs2a9DvKbr/2sX+7vFDJHvcvTR83m7AS1fnDEJt423biHMp+W5lyBqn Rfg/6d70Uqtrv6DpYwSGM2JjuQooNPev0y8aC11QAhNB8Dg47ExJXlbCuyHnnxfdyZ8X daDyanJu6MQ+QhHK7avb6SvHtJujnc8KIbCk1jpVTE+wnJpgSMZISctnWwCz3YZGLCxC 0hPcUjFQkAYZXARPkdWpiUVU+hw8fKmfNxAUF/sOIHttFHQh1VsTTPZMVdSch/Ns3g+G y2Ng== X-Gm-Message-State: AAQBX9cR5Ycm+vTV1jxJ1R3+p6ekIcE+vLuno7vpjt34NYRbYp+itK51 ln+7ejAXBh+hpPSheDTIa1V2eeVjAMwORlHl0RONFA== X-Google-Smtp-Source: AKy350YpInf5HOsSwb3qcQNqaF/XuPi6+S/goDeApwYgKAaD4aoA4qzgki0pexwvcgh3xjEXE7I5eA== X-Received: by 2002:a81:658a:0:b0:54c:c7b:a0ec with SMTP id z132-20020a81658a000000b0054c0c7ba0ecmr936079ywb.49.1680852155812; Fri, 07 Apr 2023 00:22:35 -0700 (PDT) Received: from [192.168.1.92] ([68.249.219.17]) by smtp.googlemail.com with ESMTPSA id 145-20020a810b97000000b0054601bc6ce2sm842575ywl.118.2023.04.07.00.22.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 Apr 2023 00:22:35 -0700 (PDT) Message-ID: <04dc9ccd-33e9-eee4-07ec-77ef301842ac@davyandbeth.com> Date: Fri, 7 Apr 2023 02:22:35 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 From: Davy Durham To: ffmpeg-devel@ffmpeg.org Content-Language: en-US Subject: [FFmpeg-devel] [PATCH] fftools/ffmpeg: sleep more efficiently when using -re or -readrate 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: When the ffmpeg cli tool is given a read rate (i.e. -re or -readrate), the read function is called repeatedly but which may return EAGAIN if it should be called again later. How much later is not indicated and the trancode loop just sleeps for 10ms and tries again. On the next try it may get EGAIN again and this adds up to wasted CPU. For example, conversions of audio files show about a 15-20% higher CPU usage than necessary, when compared to running without a read rate. This patch introduces InputFile::next_read_time which is computed on the way out of the read function, ifile_get_packet(), when it returns EAGAIN. Before sleeping, the transcoding loop now consults this value to determine how long it should sleep rather than blindly sleeping 10ms. Running ffmpeg under the 'time' command shows an improved real+sys time after this change, and these savings improve further if one specifies a larger pkt size to the demuxer (e.g. -max_size for .wav, -raw_packet_size for raw, etc.) since the system is able to sleep longer (and now accurately) each iteration. Signed-off-by: Davy Durham --- fftools/ffmpeg.c | 22 +++++++++++++++++----- fftools/ffmpeg.h | 1 + fftools/ffmpeg_demux.c | 9 ++++++--- 3 files changed, 24 insertions(+), 8 deletions(-) diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c index 438bee8fef..42bb14556e 100644 --- a/fftools/ffmpeg.c +++ b/fftools/ffmpeg.c @@ -3633,13 +3633,25 @@ static int got_eagain(void) return 0; } -static void reset_eagain(void) +/* returns the earliest delay in microseconds after which all inputs should be read again */ +static int64_t reset_eagain(void) { + int64_t now = av_gettime_relative(); + int64_t d, min_next_read_time = now + 1000000; /* start 1 sec from now */ int i; - for (i = 0; i < nb_input_files; i++) - input_files[i]->eagain = 0; + for (i = 0; i < nb_input_files; i++) { + InputFile* f = input_files[i]; + if (f->eagain) { + f->eagain = 0; + min_next_read_time = FFMIN(min_next_read_time, f->next_read_time); + f->next_read_time = 0; + } + } for (OutputStream *ost = ost_iter(NULL); ost; ost = ost_iter(ost)) ost->unavailable = 0; + + d = min_next_read_time - now; + return d > 0 ? d : 0; } static void decode_flush(InputFile *ifile) @@ -3929,8 +3941,8 @@ static int transcode_step(void) ost = choose_output(); if (!ost) { if (got_eagain()) { - reset_eagain(); - av_usleep(10000); + int64_t delay = reset_eagain(); + av_usleep(delay); return 0; } av_log(NULL, AV_LOG_VERBOSE, "No more inputs to read from, finishing.\n"); diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h index 823218e214..c2d279f163 100644 --- a/fftools/ffmpeg.h +++ b/fftools/ffmpeg.h @@ -452,6 +452,7 @@ typedef struct InputFile { AVFormatContext *ctx; int eof_reached; /* true if eof reached */ int eagain; /* true if last read attempt returned EAGAIN */ + int64_t next_read_time; /* if eagain, this is the av_gettime_relative() value after which we should read again */ int64_t input_ts_offset; int input_sync_ref; /** diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c index db05ddb8e9..b3fdbe0c9e 100644 --- a/fftools/ffmpeg_demux.c +++ b/fftools/ffmpeg_demux.c @@ -453,15 +453,18 @@ int ifile_get_packet(InputFile *f, AVPacket **pkt) (f->start_time != AV_NOPTS_VALUE ? f->start_time : 0) ); float scale = f->rate_emu ? 1.0 : f->readrate; + int64_t now = av_gettime_relative(); for (i = 0; i < f->nb_streams; i++) { InputStream *ist = f->streams[i]; - int64_t stream_ts_offset, pts, now; + int64_t stream_ts_offset, pts, now_adj; if (!ist->nb_packets || (ist->decoding_needed && !ist->got_output)) continue; stream_ts_offset = FFMAX(ist->first_dts != AV_NOPTS_VALUE ? ist->first_dts : 0, file_start); pts = av_rescale(ist->dts, 1000000, AV_TIME_BASE); - now = (av_gettime_relative() - ist->start) * scale + stream_ts_offset; - if (pts > now) + now_adj = (now - ist->start) * scale + stream_ts_offset; + if (pts > now_adj) { + f->next_read_time = now + (pts - now_adj); return AVERROR(EAGAIN); + } } } -- 2.25.1 _______________________________________________ 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".