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 CA51948D9C for ; Sun, 25 Feb 2024 19:50:57 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2DB9968C74E; Sun, 25 Feb 2024 21:50:49 +0200 (EET) Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id AB25368C733 for ; Sun, 25 Feb 2024 21:50:42 +0200 (EET) Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4129e8bc6c8so9253135e9.2 for ; Sun, 25 Feb 2024 11:50:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jkqxz-net.20230601.gappssmtp.com; s=20230601; t=1708890642; x=1709495442; darn=ffmpeg.org; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=PWu1bh+XHlTa54X6qEjF+tEwpqIEeN+8LsL+/2EREZI=; b=2y+wMnsG8gJ/7C1+Rqd3lR9ja0aE7vodq6L6jiIQGjsA4QdBjEryk7ZWF3Ja0fHNo5 sSLIL1+bNewyxtmFKO6SPInkWQlcYVAVV6HMJenuqYx+WlYOpMXGW/t5bF8F4KL3mEwl kzn5UdwouHFAgm1fQ2txUNPgiPBsp2hfhgQumTm1E9Y3bM0VF+TWJy5KLmNdY7BH2H5o ir4lqL3FnF/e9ZgJjEA2DA/5TGuKFoKcud+3TXUnixB27AzGW/PqceqGwM4wMSbZ1NTZ D/E6F3Cc7tacBGBMEMRwJk+mxObKZy8lJaek8wkQC9OP4ki22cP/5FDKulcMX1LMQxwN 6RPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708890642; x=1709495442; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=PWu1bh+XHlTa54X6qEjF+tEwpqIEeN+8LsL+/2EREZI=; b=msc0kKyhZu+AA8A0HNUnyqocjUwZLgHKIwo1EEiVyROf+REz0IswmditUls8xxkOuY R/pixe/hrdqhg5M3raRHhSg+5gcQHjXV7lFTGMIMgHEB2hZMLtSHNOoBPdWVp3d/KNsJ jxXIpGPuvu0cRlJWK6YKMTxqoNbO2gSOjmHiSyl66ZCyKiXNA3HCYieBPzWocgEwtYFG SQ5G9gjZ+8d+gOKLe2bahjiF7wZhA4ZivWgHIVP1jGMR8rMZxGQ7IlN8BJxUt7RtEaON M3Fk//9vLoZ6pEcsbbFXDMvjxjM/HPqbZhfp4bKA3HoOo6AQ1BPyVYxgTzvagX3529SB VS4w== X-Gm-Message-State: AOJu0YzbIrj7Bl/J7PMjDV0TJ7305dxJu+Pqtr2mvfcrIcV1+jQbK5ek nCEcIKyi1bMU4VJsRf6zu5zTTU0fTJYw0NLemvNnryAubsqJgYnkXwZwpdWynSqi23+/TruMd3j J X-Google-Smtp-Source: AGHT+IFzQQj6ApKwFst4LhuMp1bJUD68A/QEsdW0NBD4DXHeljxTFeKcmI2Mh6mjv/DNWzRrV3g81A== X-Received: by 2002:a05:600c:5489:b0:412:9db6:3e0e with SMTP id iv9-20020a05600c548900b004129db63e0emr2822475wmb.0.1708890641955; Sun, 25 Feb 2024 11:50:41 -0800 (PST) Received: from [192.168.0.15] (cpc92302-cmbg19-2-0-cust1183.5-4.cable.virginm.net. [82.1.212.160]) by smtp.gmail.com with ESMTPSA id d16-20020a05600c34d000b004129e8af6absm5305969wmq.33.2024.02.25.11.50.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 25 Feb 2024 11:50:41 -0800 (PST) Message-ID: <817dc1ea-495e-4c7f-8615-264e755ff6bd@jkqxz.net> Date: Sun, 25 Feb 2024 19:51:10 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: FFmpeg development discussions and patches From: Mark Thompson Subject: [FFmpeg-devel] [PATCH] lavfi/vaapi: Don't use fixed-size frame pools 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: Since e0da916b8f5b079a4865eef7f64863f50785463d the ffmpeg utility has held multiple frames output by the filter graph in internal queues without telling the filter which created the frames that it is going to do so. This broke many VAAPI filter->encode cases because a fixed-size frame pool is used in each filter; this avoids the problem by changing VAAPI filtering to always use a dynamically-sized pool. (Note that other cases with fixed-size pools my still be broken, since the ffmpeg utility is still lying to libavfilter by not setting extra_hw_frames.) Fixed-size frame pool support remains in the decoder, where it may still be needed for compatibility. --- On 08/02/2024 04:15, Xiang, Haihao wrote: > Is there any comment or concern about adding a quirk for workable drivers ? We > may use a dynamic frame pool in vaapi decoders and filters for workable drivers > only. > > Note since commit e0da916b, a command below doesn't work with the current fixed > frame pool used in vaapi filters. > > $ ffmpeg -hwaccel_output_format vaapi -hwaccel vaapi -i input.mp4 -vf > 'scale_vaapi=w=720:h=480' -c:v hevc_vaapi -f null - > [...] > [vf#0:0 @ 0x562847b01050] Error while filtering: Cannot allocate memory > [vf#0:0 @ 0x562847b01050] Task finished with error code: -12 (Cannot allocate > memory) > [vf#0:0 @ 0x562847b01050] Terminating thread with return code -12 (Cannot > allocate memory) > [...] Having thought about this more carefully: There is plenty of decoder hardware out there which effectively has one address register for the reference frames and therefore requires them in array form. VAAPI originally enforced this, but more recent drivers avoid requiring it by various methods (updated hardware or dual output). It is still required by DXVA/D3D11, where the restriction is enforced directly and can't be avoided. Filters do not have the same problem with reference frames since none of the current forms read back in their own outputs, and therefore the restriction on array textures for output frames doesn't really make sense for them. The one possible case I can see which could plausibly be relevant are filters with temporal inputs (the deinterlacer), but the inputs could always be allocated freely so this doesn't really change anything. Hence these two changes: * , which fixes the ffmpeg utility to set extra_hw_frames properly to account for frames stored in queues. * This patch, which removes the fixed-size pools for VAAPI filtering. I believe this fixes all of the VAAPI problem cases (and also DXVA/D3D11 at the same time). Any thoughts? Thanks, - Mark libavfilter/vaapi_vpp.c | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/libavfilter/vaapi_vpp.c b/libavfilter/vaapi_vpp.c index 59961bfa4a..19e7fdae97 100644 --- a/libavfilter/vaapi_vpp.c +++ b/libavfilter/vaapi_vpp.c @@ -104,7 +104,6 @@ int ff_vaapi_vpp_config_output(AVFilterLink *outlink) AVVAAPIHWConfig *hwconfig = NULL; AVHWFramesConstraints *constraints = NULL; AVHWFramesContext *output_frames; - AVVAAPIFramesContext *va_frames; VAStatus vas; int err, i; @@ -203,9 +202,9 @@ int ff_vaapi_vpp_config_output(AVFilterLink *outlink) output_frames->width = ctx->output_width; output_frames->height = ctx->output_height; - output_frames->initial_pool_size = 4; + output_frames->initial_pool_size = 0; - err = ff_filter_init_hw_frames(avctx, outlink, 10); + err = ff_filter_init_hw_frames(avctx, outlink, 0); if (err < 0) goto fail; @@ -216,14 +215,10 @@ int ff_vaapi_vpp_config_output(AVFilterLink *outlink) goto fail; } - va_frames = output_frames->hwctx; - av_assert0(ctx->va_context == VA_INVALID_ID); vas = vaCreateContext(ctx->hwctx->display, ctx->va_config, ctx->output_width, ctx->output_height, - VA_PROGRESSIVE, - va_frames->surface_ids, va_frames->nb_surfaces, - &ctx->va_context); + VA_PROGRESSIVE, NULL, 0, &ctx->va_context); if (vas != VA_STATUS_SUCCESS) { av_log(avctx, AV_LOG_ERROR, "Failed to create processing pipeline " "context: %d (%s).\n", vas, vaErrorStr(vas)); -- 2.43.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-request@ffmpeg.org with subject "unsubscribe".