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 D1D3F47027 for ; Tue, 25 Jul 2023 11:41:48 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 8C9EC68C8DC; Tue, 25 Jul 2023 14:41:45 +0300 (EEST) Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id DB63068C8C6 for ; Tue, 25 Jul 2023 14:41:39 +0300 (EEST) Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-31759e6a4a1so1951808f8f.3 for ; Tue, 25 Jul 2023 04:41:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kynesim-co-uk.20221208.gappssmtp.com; s=20221208; t=1690285299; x=1690890099; h=content-transfer-encoding:mime-version:user-agent:in-reply-to :references:message-id:date:subject:to:from:from:to:cc:subject:date :message-id:reply-to; bh=EAbx5IwxvNdsAsyBPQQyBhP4c7pp7mnyLSopeVT1UgI=; b=IbZbyNnkS24QRuB3WxPEYxDdLH5xMXD5nJM4wY9iVcLYECZg1I3zS3BAUKfdOeE5tt xqYBq2qXalaX/7qCa8pHgPWF9cyO3e1b33PThkyCoToYKqnaAVx9KOtavPxKcCAnAWy4 lXiHsWxWVI6ou7sTiq8paNC4wyjqMY8jinFdRkoMyL+BDQq2+e2HVdgq7bZt/Pv/rKEE 2dSDHaJcjlO/CKbooDPRKQV91ZTY6PYv+SHKjshyHiF7WHUBJgzKq1i9oPeAgOoCuFJH VMGX+A951UoHZGQCMUGscy6UUpOr4CR5YhtTQXdBbYFfhqU7mg+0I//DvYYmybvvb3zI lQKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690285299; x=1690890099; h=content-transfer-encoding:mime-version:user-agent:in-reply-to :references:message-id:date:subject:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=EAbx5IwxvNdsAsyBPQQyBhP4c7pp7mnyLSopeVT1UgI=; b=NMhvbIIrG0o29HbQz8U3ed3o7jcfKxnksZhhTu23JrRuEkVP9uOgObKS0fUkC/kVLy W/xFuaNSQBF3o/hJWerxcFn5LmfDPHciTN7OiGH+OqAtnl77uUD3QNs/5mk1duGbFcsp Oid+hLmV36JC2/laIx49MOmA/s1GkQG9ZsdGRt1k4eXdsHZKmqGm46uwOWoZ1UMw9vGM WqU08ae1miCkurSJsvooc0MsKxrIN+kObvmU3w58/Wp4CQ3n5gZ25bg61Ltc3dQjJQ5t ehJSSA7R3ZTduE0o+hL6TLzAFOYSHPrsFvy+B3g709GczSTysLipvyns3ynP2W5T7YXh gZAw== X-Gm-Message-State: ABy/qLYT0XzNAiK6exEk7NoR4B6XpCSxkB2F5k+rGHVzRa+KOWXTY1aH IWrarcQi5r2FV+WJcUPuvYqZk1aG5klF+Vkt/rc= X-Google-Smtp-Source: APBJJlFqZ/EyvQUzNM8L8/bOJaLMzuRgu//uSUVDnYfM1+SQ+1+52nNTvgJPoVy1Mrpq2eIe4zX48w== X-Received: by 2002:a05:6000:128c:b0:313:f548:25b9 with SMTP id f12-20020a056000128c00b00313f54825b9mr7035669wrx.40.1690285299039; Tue, 25 Jul 2023 04:41:39 -0700 (PDT) Received: from CTHALPA.outer.uphall.net (cpc1-cmbg20-2-0-cust759.5-4.cable.virginm.net. [86.21.218.248]) by smtp.gmail.com with ESMTPSA id f12-20020adfe90c000000b0031758e7ba6dsm8336600wrm.40.2023.07.25.04.41.38 for (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Tue, 25 Jul 2023 04:41:38 -0700 (PDT) From: John Cox To: FFmpeg development discussions and patches Date: Tue, 25 Jul 2023 12:41:38 +0100 Message-ID: <9obvbi9pb7edh81bll4vpa1dfos75rg3eu@4ax.com> References: <20230722170357.964313-1-jc@kynesim.co.uk> <20230722170357.964313-2-jc@kynesim.co.uk> <48dc91a8-5da0-d074-386d-4a095651afaa@gmail.com> <6288c203-38eb-7135-10d7-7f893545b8fd@gmail.com> <0ea5bd3d-4e6c-cd83-fe69-58e17e7e59e1@gmail.com> In-Reply-To: <0ea5bd3d-4e6c-cd83-fe69-58e17e7e59e1@gmail.com> User-Agent: ForteAgent/8.00.32.1272 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH v3 1/1] avfilter/buffersink: Add video frame allocation callback 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Sun, 23 Jul 2023 17:04:55 -0300, you wrote: >On 7/23/2023 4:40 PM, Paul B Mahol wrote: >> On Sun, Jul 23, 2023 at 9:26?PM Nicolas George wrote: >> >>> James Almer (12023-07-23): >>>> What about when FF_FILTER_FLAG_HWFRAME_AWARE filters are present in the >>>> graph? hw_frames_ctx from AVFilterLink can't be accessed from outside >>> lavfi. >>>> Is vf_hwdownload meant to be added to the graph before buffersink? >>> >>> I do not know how hardware acceleration works at all. (The tidbits of >>> discussion I catch left me the impression all of it is very badly >>> designed, but I have low confidence in that impression.) If this API >>> only works with filters that output software frames, it is already very >>> useful. >>> >> >> Patch is only marginally useful: >> >> - missing audio support > >Trivially added if needed and when needed. alloc_cb is a union that can >get a new callback typedef field for audio. Now added in v4 >> - missing full internal buffers allocation replacement support > >What is the benefit of supporting a custom allocator for all filters in >the chain? Internally, it's already using a very optimized buffer pool. >The caller only cares about how what they get out of buffersink is >allocated. A case was made that you might want to tweak the number of buffers in the pool, but I remain to be convinced that the substantial extra complexity of trying to do this is worth it. >> - missing/untested hardware acceleration support > >This however i agree about. We need to know how it will behave in this >scenario. How does buffersink currently handle things when the previous >filter in the chain propagates hardware frames? It just delivers them to the user The case that this code was written for and I suspect pretty much the only case it will be used for is where the user wants the frame in a special buffer that it can pass directly to display or other hardware and doesn't want the overhead of copying. Assuming that to be the case then there are two possibilities if the final filter stage produces hardware frames: a) The frames are in the right sort of h/w buffer in which case no custom allocator is wanted - code unused b) they need copying / conversion to the right sort of buffer - again custom allocation doesn't help So given that I could do the same as what avcodec ff_getbuffer does and if there is an existing h/w frame allocator then the user function isn't called. Would that be OK? If not then I'd like some constructive suggestions as to what exactly would be OK please. Regards JC >> >>> Regards, >>> >>> -- >>> Nicolas George >>> _______________________________________________ >>> 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". >>> >> _______________________________________________ >> 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". >_______________________________________________ >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". _______________________________________________ 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".