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 78C4545565 for ; Wed, 1 Feb 2023 14:02:41 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id C8ADA68BE68; Wed, 1 Feb 2023 16:02:37 +0200 (EET) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id A50A968BE0C for ; Wed, 1 Feb 2023 16:02:31 +0200 (EET) Received: by mail-lf1-f47.google.com with SMTP id b3so29437862lfv.2 for ; Wed, 01 Feb 2023 06:02:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=q7jhZXWyhAA4UwK2UMzDT7A56FmLQbTkECNGCOho9KU=; b=TZOj53fV7hPrfUHlHVf2R0/Rc/Uy9OSiU17/m4K2zS/nZB2GpOrhNLlSPimGI8UCU/ ikZoW/8MFQiOxm1c6UD5i7xxYKQCg4Zzo02I8CfjiDz+7RWGQc/UIndQRLvSgarv5nXd 50p21SXbRB1sufXw/oGLOmMHuoBat2Ql6K6Q7EsMu+D+VNj4H4nU/Rh66WW/PaOt9yvM xXBcEEHIH411LRvvCExFmSxMtrrbyeeByXlPDkVpkzJ6Yq2cDEKulVUZ7gwBO9rpGgHK cSFUDdiQXBlMDCX7Ysdq2IXZO/Vm3gWkhIWN6Nw6QE5LIKnqihXgw7oSiY8xwt7RlWjv SvjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=q7jhZXWyhAA4UwK2UMzDT7A56FmLQbTkECNGCOho9KU=; b=3OBFotyoZ/FImebk4bUSd4Ynyi+TNd5JwtdkP2DzvmdJ4M911fYClU+JeCCssiKwOQ 5BVZRwDcJrvYc3lvDYuqHvhRdc94lwuGi+Ddo1sRGGtXkB3sJjKZcO9jSd0O/6yfPPyC L2hjfJVLGFeiGYJJeKUlgrKXbeE1kv+U8yyNjSCt60LZb6BC9gTrOH4PLKeCGjAvBLwQ LzAvyZl3mQdvVFsskSlzwrbm5keDsYM8FykL0BBASDTy/75OG9hDGD/6Sngg3Hp6CQ9O EvcApgQN9UTfx/avI4pu7lsS4Dbtt1CnoiwJ8YLIjzbhwbM3y7xRpY0bc+qeY/YCmQ3B Qe/g== X-Gm-Message-State: AO0yUKW2c34/zdWbYX6J156SAThEKWtiJtMrrcZ0wSyOZ0+mAbsbbr6C 1bmKB9+wI0qZnV3ZwqqxBwBwYmN8xbPRej2bHRnYBMYKN3g= X-Google-Smtp-Source: AK7set9F1hP/BDIIHvBDR5L3KrfQHko+j+vdsRwxeYeUi59aPsyApBfealfmXaNRw90T0xUZ7tYKtdVdXfAtMmYR/d8= X-Received: by 2002:a05:6512:2e2:b0:4d1:3e32:6417 with SMTP id m2-20020a05651202e200b004d13e326417mr449351lfq.61.1675260150147; Wed, 01 Feb 2023 06:02:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nuo Mi Date: Wed, 1 Feb 2023 22:02:18 +0800 Message-ID: To: FFmpeg development discussions and patches X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [FFmpeg-devel] Let us review and collebrate on vvc native decoder. 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 Sat, Jan 14, 2023 at 11:52 PM Ronald S. Bultje wrote: > Hi, > > On Sat, Jan 14, 2023 at 10:16 AM Nuo Mi wrote: > > > On Sat, Jan 14, 2023 at 10:28 PM Ronald S. Bultje > > > How come vvcdsp has only 8/10 bits/component code but vvcpred has > > 8/9/10/12 > > > bits/component code? > > > > I will remove it. > > > > Not sure how applicable this is, but for AV1 (dav1d), most high-bitdepth > (non-8 bits/component) code has the same container type requirements (e.g. > "fits in int16_t"), so we add a "limit" (analogous "bitdepth") argument to > relevant functions and then only have to implement it once for all non-8 > bits/component implementations. This is different from *_template.c > versions, because the binary size is actually significantly reduced. A > further advantage is that implementing hand-written arch-specific > implementations (asm) for one higher bitdepth automatically works for all. > Best of all: there's no runtime penalty. Maybe you want to consider that > for vvc also. (It's probably too late to fix ffh264/hevc/vp9.) > Hi Ronald, Before I go too far, could you help me review the current code? I hope the direction is right. https://github.com/ffvvc/FFmpeg/pull/35 I am adding highbd functions under the dsp functions. This will avoid bytefn propagating to callers. Current dav1d has 16 bytefn, some are really big, I guess it will double the code size for these functions. > > I can elaborate further if you're interested (maybe IRC?). The more complex > the codec gets (vvc > hevc > h264 > mpeg, and av1 > vp9 > vp8), the higher > the (binary) codesize gains from such an implementation choice. FFmpeg is > already huge so it's worth trying to trim its fat a bit. > > Ronald > _______________________________________________ > 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".