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 C820C49DFC for ; Mon, 11 Mar 2024 22:31:48 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 3B13768D0AD; Tue, 12 Mar 2024 00:31:45 +0200 (EET) Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 0609168CC0A for ; Tue, 12 Mar 2024 00:31:39 +0200 (EET) Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-1dd10a37d68so41622255ad.2 for ; Mon, 11 Mar 2024 15:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jkqxz-net.20230601.gappssmtp.com; s=20230601; t=1710196297; x=1710801097; darn=ffmpeg.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=8bonOweZmogGYxtyObRVlwYeWgKLk9S3oKWYZ3ljZJ4=; b=iE/IfVFB4zUSBiODaWs/ElN1OtOsUXZvyecMxDhwchRx++bgIMKkYFSwaz+1yCz+CV 0aDDt0OURlBhtqcqwClKrDMI7QAfq/ZWXyNYYHXM+82b4dvyS0QrRBCqG3incZadq3RC 5ldIxhlUpDi8Ikf9f3PSyaC37PMjkbv+XdbeG9mTfbk6GFaYL+Twi87fBXvKzqufDeuO eCxTDy3IYO5C5PSPYDk60KHzncs6bPKtR3nD+GPunXmH8DtmffNW95zwluIjNtnPcgrL IBwSfOS9sjj7veElKlG14IjEUqqEn7PXEn49XgYLmB8R288QiFfcWd7hZpRCcJTwmXZw 3c5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710196297; x=1710801097; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8bonOweZmogGYxtyObRVlwYeWgKLk9S3oKWYZ3ljZJ4=; b=bm8UtxAfhmxaO0YUYdpkfkjs8A8vNjRgE1Zo5kmLE2AF3frluUX/yfSeJr8ZciBrw3 41ME1TCdz4CAA7xEs1ANXYdpMVw56E0rnCTyYsDoa0ArAmfwRV6ihw/noBpk+6GyDii8 dsXjC8n6espYDeYCp58Zsao8nme97cmWju5Xb+IYFhWs+G0ognePFyAnIFXvZPjebkbI xk6aUe+0LURU1XebJg+3mVDI27rJ0wAD5EiXCZQT3ChGJkkXrHR6pWyDe6V7dHIpkAcs 5lyYJMpruwdxGM9IA3RHjTjukfxNYQCWIcaM906sHHmLE1XgAyo8Y3989deOaW2Mq9Mp GKUw== X-Gm-Message-State: AOJu0Yw6tNWzkZJTFeVC4syKVMPaMyCl29jOFiiXPqNUDQLBdeKHOIm3 qX50K2iOsehUafVjErvANBwCrKWjVso5Xl92UzxgLA8XuUJ+m+WowxY/raa+sP0kcWhvgOkhszu 6 X-Google-Smtp-Source: AGHT+IFyIYv1ZQLHAZmcElgsJUd9unwftydaODG8Sb3fMokmHXJC8LdmrRdDUfC74/b+hYcA/OOw1w== X-Received: by 2002:a17:903:22c5:b0:1d8:f072:ec9f with SMTP id y5-20020a17090322c500b001d8f072ec9fmr10756873plg.28.1710196296758; Mon, 11 Mar 2024 15:31:36 -0700 (PDT) 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 w13-20020a170902d3cd00b001dd707d5fe6sm5232387plb.158.2024.03.11.15.31.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Mar 2024 15:31:36 -0700 (PDT) Message-ID: <5e4a4e4f-f346-45a2-843d-a1a3b0562307@jkqxz.net> Date: Mon, 11 Mar 2024 22:32:01 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: ffmpeg-devel@ffmpeg.org References: <20240308132108.28337-1-ffmpeg@haasn.xyz> <186f152d-122a-4400-b941-526c986d0c56@gmail.com> <20240308144417.GB30572@haasn.xyz> Content-Language: en-US From: Mark Thompson In-Reply-To: <20240308144417.GB30572@haasn.xyz> Subject: Re: [FFmpeg-devel] [PATCH v2 1/4] avcodec/aom_film_grain: add AOM film grain synthesis 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 08/03/2024 13:44, Niklas Haas wrote: > On Fri, 08 Mar 2024 10:31:28 -0300 James Almer wrote: >> On 3/8/2024 10:21 AM, Niklas Haas wrote: >>> From: Niklas Haas >>> >>> Implementation copied wholesale from dav1d, sans SIMD, under permissive >>> license. This implementation was extensively verified to be bit-exact, >>> so it serves as a much better starting point than trying to re-engineer >>> this from scratch for no reason. (I also authored the original >>> implementation in dav1d, so any "clean room" implementation would end up >>> looking much the same, anyway) >>> >>> The notable changes I had to make while adapting this from the dav1d >>> code-base to the FFmpeg codebase include: >>> >>> - reordering variable declarations to avoid triggering warnings >>> - replacing several inline helpers by avutil equivalents >>> - changing code that accesses frame metadata >>> - replacing raw plane copying logic by av_image_copy_plane >>> >>> Apart from this, the implementation is basically unmodified. >> >> Do we want this to be public? Both as a struct and the decoding functions. >> It could be used by libavfilter or even outside our libraries. The hevc >> decoder would export the relevant T.35 SEI in the new struct if told to >> not apply fg, like we already do in av1. > > I'm not sure if the AFGS1 struct itself needs to be public, since it is > largely just a codec-internal wrapper for multiple param sets (for > scalable codecs). This is not correct. Along with scalable cases, the multiple param sets are to support applying film grain at the display resolution after scaling, providing a better result than upscaling the grain applied at the decode resolution. For example, you could have a scalable stream with operating points of 1920x1080, 1280x720 and 640x360. The AFGS1 metadata associated with the stream would then have film grain parameters for those three resolutions, plus perhaps 2560x1440 and 3840x2160. In the ideal case you then pick the operating point for decode based on your available bandwidth and decode capabilities, and the resolution for film grain application based on the display. The decode happens without any film grain, the clean video is upscaled, and then the film grain is applied immediately before display. A current conforming AV1 implementation which only supports applying film grain as part of the decode process can do so and produce a conforming result, but the quality may not be as good as the ideal case because the presence of noise will affect the upscale quality and also the grain itself will be scaled in a way which may not look correct. I'm not sure what the best way to expose this is. For a player application an option to select the intended display resolution and then export an AV1 film grain side data as it is now is sufficient, but that doesn't really work in an application like ffmpeg where the target resolution isn't directly known. (Also note that a transcode can carry the AFGS1 message from the source to the output without ever touching it, as long as the target resolution satisfies the requirement on the coded resolution being available in the param sets. It seems desirable to support this possibility.) Thanks, - Mark _______________________________________________ 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".