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 E62D544BF7 for ; Fri, 9 Dec 2022 13:48:53 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id A9F1868BCE0; Fri, 9 Dec 2022 15:48:50 +0200 (EET) Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id D704968BCAF for ; Fri, 9 Dec 2022 15:48:43 +0200 (EET) Received: by mail-pg1-f181.google.com with SMTP id 82so3597464pgc.0 for ; Fri, 09 Dec 2022 05:48:43 -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=fFpM0Rl27L0pxD5hoEsXcjSVUWWGfOoLFXGsV+M6NnY=; b=dpzpUDUJAHMrD7YzIAc//NgfU4XnBwbt0Grm9h5arJAn1pCXq9vM70+OLZYcCQOizE sYNHqknrcxDoCu8A+L3RN1PgMPex+u4WIrjamGMCVYNEBYR0ggkg5pipMGKmx6Umq28+ 3Mh/2mJBscQLZNpNbCWEeaTFuPMOoWO4WGuRjGx2HmmKmwGh/8xqQrQ/dsFZ7L1iV1kW 66UdSOI5zjvhACWSHHVUM3ox28CJN2n4wiuQLtcRVQTsShITQOwFTf6Q1Ibn4T8K/ELI B32m/eBcLrAA7JCtWW00cDIU9w1og8cLxlMxOeWDMY9g/Pe5oG28fmQYHEXXhaOg7TRc rXig== 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=fFpM0Rl27L0pxD5hoEsXcjSVUWWGfOoLFXGsV+M6NnY=; b=QBRwrcZEc9KejM9x5UqKwXjeooYMVN1eEukU0cbM7c3bfaxXggWReqarkWq5/wwWZ+ YFkDI+ykHIjzY7+rTgpm5h18MeZKuUAkzpo6EQxJCoUlj4iTIDiSGD1BryqtGw0pFQiM TPyVgZNVkKPfY6y4p8skPagYGJ/A3a1AYsFJlZXcW7/GZzaXvtht3gozESQqT4fvgnwC oBGt1jlHqgmCO9eHmplR8G/7H8/rLfPzvXs7E4Cc/Ix6jzcthzF5CxVy50uYDshu7B0i ttufKlyRrvVYcQoLYedWf+35DQvuRfkl4UB4E6ZhMOAIRSu9Cp6/8SxgrnjNt87PYx1H HNTQ== X-Gm-Message-State: ANoB5pmElI/F4c1Lvf8z9fdymhBpgcskAUg6uF/kMCGWZve0WIJn/pbC vej3blFhE/fkDno9/AUaX5fUfTBReRwdEV8MO1cEnvBwLgY= X-Google-Smtp-Source: AA0mqf6WW7aaztRDQqHwlKXjsr4g9ayvHnuL6Og5DtHwnG5/Z8bSDeCH+0I1g0hYP4GGbeLJFk0XIA+eqVlVERSyKX8= X-Received: by 2002:a63:1e49:0:b0:46b:1590:2625 with SMTP id p9-20020a631e49000000b0046b15902625mr67168904pgm.569.1670593721540; Fri, 09 Dec 2022 05:48:41 -0800 (PST) MIME-Version: 1.0 References: <20221209124941.GB66771@haasn.xyz> <20221209134526.GB119445@haasn.xyz> In-Reply-To: <20221209134526.GB119445@haasn.xyz> From: "Diederick C. Niehorster" Date: Fri, 9 Dec 2022 14:48:24 +0100 Message-ID: To: FFmpeg development discussions and patches X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [FFmpeg-devel] Towards YUVJ removal 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 Fri, Dec 9, 2022 at 1:45 PM Niklas Haas wrote: > Oh, you are right. So that presents an alternative to 4 - rather than an > encoder flag, we can tie the auto-conversion in fftools to be tied to > the strict_std_compliance check. > > I will try implementing this approach, it may be the best compromise in > that it presents a clear upgrade path that doesn't break the common > case. > > That said, there still is an encoder that has this problem: "amv". > Currently, this only advertises YUVJ, but after YUVJ removal, it would > be treated equivalently to mjpeg when `strict_std_compliance` is enabled. > > But given that this is a less common format, I think, such a regression > would not be as big a concern. (And we can still special-case it in > fftools, if we want to) > As a user of the API, I do not think hacking fftools is the way to go. I vote option 3, filter negotiation also takes color_range (etc) info into account, and auto-inserts a scale where needed. But that is only half the solution, and actually not the important part. If i have a frame source and another sink that both have declared pixel formats, i can easily check whether conversion needs to happen at all, and if so, just set up an empty filter chain and have it auto-insert the required scale filter (super!). Now i would have to also be able to: 1. have settings in the filter context (i guess) for color_range, etc, and corresponding syntax for the args argument of avfilter_graph_create_filter() and/or corresponding options to set, so that filter input and output sides can be provided with correct info 2. query my sink for what it actually provides (a bunch more functions ala av_buffersink_get_format() are needed to get color_range, etc) I probably don't oversee the problem, so may be missing more that needs to be done, or be off the mark here. I also agree with Henrik that a way to query encoders for what they support besides formats is critical, and that this should ideally be context-senstive (so you can set certain options, and then query what remains of supported pix_fmts, color_range, etc). All the best, Dee _______________________________________________ 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".