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 5C68A488FB for ; Fri, 22 Mar 2024 09:41:23 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B4C9468D5A8; Fri, 22 Mar 2024 11:41:20 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id C9AFC68D59A for ; Fri, 22 Mar 2024 11:41:14 +0200 (EET) Authentication-Results: mail0.khirnov.net; dkim=pass (2048-bit key; unprotected) header.d=khirnov.net header.i=@khirnov.net header.a=rsa-sha256 header.s=mail header.b=JIzp7pr1; dkim-atps=neutral Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 8542B240DAC; Fri, 22 Mar 2024 10:41:14 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id 0dbI_1kpVJ84; Fri, 22 Mar 2024 10:41:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=khirnov.net; s=mail; t=1711100473; bh=ZYn4iMgDcVePHzkQpUjgZtifXAfk24e4Wxp4uVsB/YI=; h=Subject:From:To:Cc:In-Reply-To:References:Date:From; b=JIzp7pr1N6dGqGSMKIkzl9vANaLdeU4+0i8zsPrmKikBwP1f7vcIFyQbSxkoi0ZNm j415qNXxj2BdS57mmXjHJIOO3wd3WpwpShJ34rohAzzJhlk16mUhP4/xWS7Hz4Qba4 c78cW91/M0RGKynCQpR0xGD0ItgnjNLPBNDRUZYRBrErecf8TRL67gjMbrrhO8tmrh h/m9ksAJ+lyr33fwszgEWybN1dZMNEwPwXJAu52CY8Hy+hPn8HsbktYNYL5HMNgLGl 9GYdH33smczRBD2bWYdA63X1a9bkrtviK0j05GmvwdiGIAGgbq3QrxSD0iyjkAr0tr +LjL937vCsiBg== Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id E0A1C2404AF; Fri, 22 Mar 2024 10:41:13 +0100 (CET) Received: by lain.khirnov.net (Postfix, from userid 1000) id BD3201601B9; Fri, 22 Mar 2024 10:41:13 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: <20240321131132.GB15980@haasn.xyz> References: <20240319191642.95217-1-ffmpeg@haasn.xyz> <171101621793.7287.2859730890037554804@lain.khirnov.net> <20240321131132.GB15980@haasn.xyz> Mail-Followup-To: FFmpeg development discussions and patches , Niklas Haas Date: Fri, 22 Mar 2024 10:41:13 +0100 Message-ID: <171110047375.7287.3672479821689972140@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 1/4] fftools/ffmpeg_enc: strip DOVI config record for AV1 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 Cc: Niklas Haas 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: Quoting Niklas Haas (2024-03-21 13:11:32) > On Thu, 21 Mar 2024 11:16:57 +0100 Anton Khirnov wrote: > > Quoting Niklas Haas (2024-03-19 20:16:39) > > > From: Niklas Haas > > > > > > AV1 streams don't use configuration records, so delete them when > > > encoding to AV1. Ideally this would be, as the comment suggests, handled > > > at the frame-level (and stripped by the av1 encoder), but given the > > > status quo of copying the packet-level data here directly, we should > > > definitely make an effort to strip it. > > > --- > > > fftools/ffmpeg_enc.c | 25 ++++++++++++++----------- > > > 1 file changed, 14 insertions(+), 11 deletions(-) > > > > I'm very much not a fan of having codec-specific code in ffmpeg CLI. It > > implies that every single caller must now be aware of this > > (undocumented?) interaction of this specific side data with this > > specific codec ID. > > Note: This is an existing bug, not introduced by this series. This > series just makes it obvious. The status quo is that, beacuse of this > logic in ffmpeg_enc.c, we incorrectly forward dolby vision configuration > records when transcoding to AV1. I know pretty much nothing about dolby vision, so could you please explain why precisely is this incorrect? And at what point in the transcoding chain does the side data become invalid? > Or, indeed, when transcoding to *any* format - since current FFmpeg also > does not propagate dolby vision RPUs, we generate broken files pretty > much always when transcoding dolby vision. So we definitely need to > strip the metadata from the stream muxer *somewhere*. Where else comes > to mind? > > This also gets into another topic I wanted to touch on, which is that > the presence of dynamic dolby vision metadata currently hinders the > ability of libavfilter to treat the video primaries/gamma as > a negotiable colorspace property (the way it is done currently for YUV > matrix/range). This is because when interpreted as such, DV metadata > fundamentally changes the colorspace of the incoming video stream. > Ideally we would like some way to negotiate DV metadata on the > query_formats() level. > > Ideally, we'd want something like AVCOL_SPC_DOLBYVISION, but we can't > easily introduce that without breaking ISO/IEC 23091 compatibility.. In principle it could be yet another negotiated field, could it not? You just added a bunch of those recently, what's another one? -- Anton Khirnov _______________________________________________ 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".