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 9CE3C44FE2 for ; Tue, 14 Feb 2023 18:37:12 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 1605A68B85C; Tue, 14 Feb 2023 20:37:09 +0200 (EET) Received: from btbn.de (btbn.de [136.243.74.85]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 0EF9A6802E3 for ; Tue, 14 Feb 2023 20:37:03 +0200 (EET) Received: from [authenticated] by btbn.de (Postfix) with ESMTPSA id 2B6DF3B8FFD for ; Tue, 14 Feb 2023 19:37:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rothenpieler.org; s=mail; t=1676399822; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dsG2asDGJti0112UZS2ZrEu0+bZ/qElqs3zNAunvku0=; b=FY9cASbadOpj23Vsdwgsvfb8CEn+elcppDJuazNATEMODpmW/N0lBXA/2d6uReHq0yU8DP 4gaUZn1CVQvrNgoDeJYVeAdxoVKPC6TTlesvI/eecLtPnxHud17gp/5/NmRTNA2JnR3fIr S/HNqttn7QuDwMinTh3uU1488x53+k1vcHelbFfbSSSdmfdzM4oyOVbgWawQP4gOXly+tt Sa7gGu2P15sIfCXWc/uQ0iuSvhXLEluHhmrsaL+xWcqr2Ojd39mzcV4Mycaz/EbECzFI0X tc5GHcNa6EV6+ndwtbuNsft8ULmeATzqWMnZZ5lIyVwp3pv1Ks6w803s2zs7Tw== Message-ID: Date: Tue, 14 Feb 2023 19:37:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: From: Timo Rothenpieler In-Reply-To: Subject: Re: [FFmpeg-devel] Proposed change to NVDEC ulNumOutputSurfaces initialization 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 14.02.2023 18:27, Miller, Adrian wrote: > > Hi, > > I'm considering a proposing a change to libavcodec/nvdec.c but wanted to run it by you first as I'm new to FFmpeg development to make sure I've gotten things right (this is not a patch). > > We use the NVDEC decoder as part of our live transcoder. This means that new decoders may be spun up to accommodate switching sources but the frames_ctx->initial_pool_size is calculated based on values from the source's initial SPS and the decoder's "extra_hw_frames" option, so it's possible that a new source will result in an SPS+extra_hw_frames value greater than the max supported by the NVDEC decoder, 32. > > The current behavior is to return if the NVDEC decoder fails to initialize and return a warning (nvdec.c:413). I'm sure this is fine in the interactive use case where the user can simply provide a smaller value for extra_hw_frames and try again. In the unattended case this isn't possible, and our application fails. > > I was thinking something along the lines of in nvdec.c to handle this case: > > - params.ulNumDecodeSurfaces = frames_ctx->initial_pool_size; > - params.ulNumOutputSurfaces = frames_ctx->initial_pool_size; > + const int kMaxSurfaces = 32; > + params.ulNumDecodeSurfaces = (frames_ctx->initial_pool_size <= kMaxSurfaces) ? frames_ctx->initial_pool_size : kMaxSurfaces; > + params.ulNumOutputSurfaces = params.ulNumDecodeSurfaces; > + if (frames_ctx->initial_pool_size > kMaxSurfaces) { > + av_log(avctx, AV_LOG_WARNING, "Requested %d decode surfaces, which is more than %d. Condifuring decoder with %d surfaces.\n", > + (int)frames_ctx->initial_pool_size, kMaxSurfaces, (int)params.ulNumDecodeSurfaces); > + } > > Plus, probably rewording the original warning that handles the case where the decoder still fails. > > Thoughts? If this seems like a reasonable approach I'll put together a formal patch email after going through the rest of your submission process and the stuff I have to do for my employer. Something like that seems reasonable enough to me for sure. Better than running into a failure right away. Make sure to limit the number of threads in your setup. Those are the main source for extra surfaces, specially on systems with high CPU/thread numbers. If all you do is hwdecode/process/encode, you can safely just set the threads value to two and call it a day, and you'll then likely never run into the limit again. _______________________________________________ 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".