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 E245B43B72 for ; Tue, 19 Jul 2022 18:13:42 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2210468B70B; Tue, 19 Jul 2022 21:13:39 +0300 (EEST) Received: from mail-oo1-f44.google.com (mail-oo1-f44.google.com [209.85.161.44]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id D279368B43B for ; Tue, 19 Jul 2022 21:13:32 +0300 (EEST) Received: by mail-oo1-f44.google.com with SMTP id q207-20020a4a33d8000000b0043572da7bdfso2993480ooq.9 for ; Tue, 19 Jul 2022 11:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=u3s4t/eVnYcRZs6rqTjw0Jo0Bjru0oI6bAYP4Y5NckU=; b=alALOCsS7Xb3D5neDyYcfdAFKUK6mUHt+M8utaGli3sB8evZZtRnkI6WrEyKH+PuFc IFjO4i7dr+cdZyMIPqW2wT4qLPv9X35u5pXNAVqysQCr96dwCa4tDqwXd8X/Wi3hZan2 i4WwJbvPzg7xxZlyziCOMPxMuuMyR4NOBccxFZGjlujIvhbce/zLeMXuOsNlCVJ5x5ZW W6hEO3tiZWtJv0eScuTpvc9W4Box4IZRE8xn5xR7nQQ9c6Kue1HVHMAYWeOhDQwq2aDN RJxY6NZIhLHJlg9AnKBHHGDyFWIC9yN3oLeIosd8lr/R0AX6XT857jv8lKJvbTqjdqrJ lL/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=u3s4t/eVnYcRZs6rqTjw0Jo0Bjru0oI6bAYP4Y5NckU=; b=kglPcJZUQW9X+L+HcOHNpAJ0RJS1vwyHPGzfU2I31ppTWZKFPK+kGLsStTp4TZzR8D VPXB4P0abtbiMjXL3cBoSagnfo842Yd8hpm+Hjw/DYizSb5X3X05URBaXpiSJX9utoTh ct4nTks0oSI6rdiDws6V8vdTpKS+S7jHPdw06dHs7hoclayh7R1WlYdiLLojBmn07/5Y wO3ysqiEJcX8gRdGu8RZJEkGyl6nnwvh8oOt1GAms0OyNTZ0RaNrPVRcl7CFH2pwhdhf oXGqDSFL39GDnIuTLXHZUVoyv7C0OTYo/MuZ/HyPRZGd9FHABjd7exXWEvdrUQr85vOE u2og== X-Gm-Message-State: AJIora/Tn01Yo9HzuxgMqV5+CRpktDNaNTjEcaeh6qjI0XSnXed6rxfe KgqTrZOxsMqjxslz9cEMvNBFwLfgS8nU2Q== X-Google-Smtp-Source: AGRyM1vugmewJkUoMN5PkKf8Xl8f0OotrXECvfynKcIEgl4cjBSg8W8Qhcdbyx62dRzCSwj3h4fe3w== X-Received: by 2002:a05:6820:16aa:b0:435:acba:37ef with SMTP id bc42-20020a05682016aa00b00435acba37efmr1804224oob.69.1658254410706; Tue, 19 Jul 2022 11:13:30 -0700 (PDT) Received: from [192.168.0.11] ([186.136.131.204]) by smtp.gmail.com with ESMTPSA id r12-20020a056830120c00b00616dfd2c859sm6425142otp.59.2022.07.19.11.13.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Jul 2022 11:13:29 -0700 (PDT) Message-ID: Date: Tue, 19 Jul 2022 15:13:27 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20220717192700.1077-4-anton@khirnov.net> <20220719124711.25500-1-anton@khirnov.net> <165823546515.15564.594189075971384302@lain.khirnov.net> From: James Almer In-Reply-To: <165823546515.15564.594189075971384302@lain.khirnov.net> Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/libx264: support AV_CODEC_CAP_ENCODER_RECON_FRAME 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 7/19/2022 9:57 AM, Anton Khirnov wrote: > Quoting James Almer (2022-07-19 14:51:13) >> If this is only >= 122, what will pic_out above contain in older versions? > > IIUC it won't do deblocking, so the reconstructed frame won't be exactly > as decoded. That kinda defeats the purpose, and is also inconsistent. Maybe we can signal somehow at the API level that the reconstructed frame is not fully done? Or making the kind of reconstruction the user requests explicit, like having the recon_frame AVOption be an enum in AVCodecContext with defined values like full_recon (hard requirement), partial_recon (soft requirement, may still return full recon if that's all the encoder can generate), etc, instead of simply a flag for avctx->flags? Or just disabling it for libx264 this old so output/behavior is consistent across all encoders regardless of version and the API remains as simple as possible. _______________________________________________ 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".