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 C526848EA1 for ; Mon, 29 Jan 2024 18:49:59 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 25FF868D235; Mon, 29 Jan 2024 20:49:57 +0200 (EET) Received: from haasn.dev (haasn.dev [78.46.187.166]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9383168D1E1 for ; Mon, 29 Jan 2024 20:49:50 +0200 (EET) Received: from haasn.dev (unknown [10.30.0.2]) by haasn.dev (Postfix) with ESMTP id 04EBB49C91 for ; Mon, 29 Jan 2024 19:49:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=haasn.xyz; s=mail; t=1706554190; bh=W2Xn4+zRpniORIym/ehkIbA8dtUfkbplF8POiwsjDAs=; h=Date:From:To:Subject:In-Reply-To:References:From; b=ve+WuHh+YuTtuBmf9h2n33zYeMmgbwm1BZEGBttXgm75CEVIyFmk6DO/7l8ceEy4Y cJ4peweOzu1eN4e32q3xuYM3QQw0luH3AWNRg/iZW29mzGA/gRW1BC/7IgmAo6PMcH 7xejtLpCoVjf1oqGzQqWQHiSVHiA7N30c+GWQkz0= Date: Mon, 29 Jan 2024 19:49:49 +0100 Message-ID: <20240129194949.GB11235@haasn.xyz> From: Niklas Haas To: ffmpeg-devel@ffmpeg.org In-Reply-To: <20240129031943.GR1833374@pb2> References: <20231231214948.CD436411659@natalya.videolan.org> <20240129031943.GR1833374@pb2> MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] vf_scale: use colorspace negotiation API 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 Mon, 29 Jan 2024 04:19:43 +0100 Michael Niedermayer wrote: > On Sun, Dec 31, 2023 at 09:49:47PM +0000, Niklas Haas wrote: > > ffmpeg | branch: master | Niklas Haas | Tue Oct 31 13:52:53 2023 +0100| [45e09a30419cc2a7251e72689142e021ecdfe6d9] | committer: Niklas Haas > > > > vf_scale: use colorspace negotiation API > > > > This filter will always accept any input format, even if the user sets > > a specific in_range/in_color_matrix. This is to preserve status quo with > > current behavior, where passing a specific in_color_matrix merely > > overrides the incoming frames' attributes. (Use `vf_format` to force > > a specific input range) > > > > Because changing colorspace and color_range now requires reconfiguring > > the link, we can lift sws_setColorspaceDetails out of scale_frame and > > into config_props. (This will also get re-called if the input frame > > properties change) > > > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=45e09a30419cc2a7251e72689142e021ecdfe6d9 > > --- > > > > libavfilter/vf_scale.c | 188 +++++++++++++++++++++++++++---------------------- > > 1 file changed, 103 insertions(+), 85 deletions(-) > > This seems to remove metadata > > ./ffmpeg -f lavfi -i color=black -pix_fmt yuv422p10le -bitexact -vframes 1 -f framecrc - > > Stream #0:0: Video: rawvideo (Y3[10][10] / 0xA0A3359), yuv422p10le(tv, progressive), 320x240 [SAR 1:1 DAR 4:3], q=2-31, 38400 kb/s, 25 fps, 25 tbn > vs > Stream #0:0: Video: rawvideo (Y3[10][10] / 0xA0A3359), yuv422p10le(progressive), 320x240 [SAR 1:1 DAR 4:3], q=2-31, 38400 kb/s, 25 fps, 25 tbn > > > when its stored in a file, it results in a different output, example: > ./ffmpeg -f lavfi -i color=black -pix_fmt yuv422p10le -bitexact -vframes 1 -c:v ffv1 -level 3 -y ffv1-lavf-black-4636-new.mkv > > > I have not investigated what is correct, but i would think "no range information" > would seem worse than whatever the correct is Looking at this quickly, what is happening here is not that vf_scale is stripping metadata, it's that vf_scale used to *add* default metadata after a pixel format conversion - even though it did not touch the pixel range, and the incoming frames were untagged. This was arguably a bug. The new behavior is actually less surprising here - the vsrc generates untagged frames, so vf_scale preserves them being untagged. (Observe -vf showinfo,format=yuv422p10le,showinfo before vs after patch) In any case, the *proper* fix here would be to make vsrc_testsrc aware of the colorspace negotiation API. Ideally, it should switch from ff_draw_init to ff_draw_init2, and use the negotiated YUV colorspace and range. (pal(75|100)bars are also bugged) _______________________________________________ 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".