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 B39AB45DCE for ; Wed, 12 Jul 2023 13:21:42 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 3AB1368C4BC; Wed, 12 Jul 2023 16:21:40 +0300 (EEST) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 1508D68C4BC for ; Wed, 12 Jul 2023 16:21:34 +0300 (EEST) Received: by mail-ot1-f41.google.com with SMTP id 46e09a7af769-6b91ad1f9c1so4314648a34.3 for ; Wed, 12 Jul 2023 06:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689168092; x=1691760092; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=S87NJVGrEOgv1297M9L4LdAFeJwFimBuFr0qTyzJXHQ=; b=V1UlLtx5B2+708UiMZXMZ0K4XV3OT/ziXiiNZKHeZbyjrozp3aMe4c1UIw7hnLLkCN uD/GqFWEqz0ezaHn/NFt4iXSPcqpzG+rbT2Ywa0M8ahK+SMKVV1e9MlLUjxnE/hopdI4 dV7yO7T7Jf/p73D5534fwA+7VAqVqeHNNV9w1gR8yHwFeeIqP6F0cuu8aU0NLVzhLxYn osb6DTQ4TbYFlG2OjqIc6OsNjPS4ZOkle8iaqAYu1jovq14RG3bv06tSu2KinMIZ5/tu Ds4PEgKns2Z/yUX94VaVIC1QHKrHsHp7BtP1A+TehCF7KgX1TLGhvmhzn8aNmBqPnLxq RUkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689168092; x=1691760092; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=S87NJVGrEOgv1297M9L4LdAFeJwFimBuFr0qTyzJXHQ=; b=j17LKd6rPq9xhW3dlyqiEY2JaisJ8CPLGX62YMEGV/ajdRk5kV51yoH4vr+KVz5OQw JSF6sCjMgdaK0Xwj3gZ/6VWqkhe0yNry1caFVi+L5KNzJV64yCXCAC969uFu7FJkvphB bRyCKXml8RExQW2jz/x4137E48g/U727C1v91/6t5Bke8jsOKsyjZtzIM87B7w5nX9Gd fb/OtC09/QXcEp0IlnSx3nuZoNG0fja8comtMdpZBENPDm7hrwk0MJ+u85DlhmOXhyxg FRXMlFqmEUIx3AH7/352BR1UuZCH8LpjeRdGzKvcCw8f0WLzHtCHFNFQRghbmp4/aVOu OWHQ== X-Gm-Message-State: ABy/qLaQOioyeh8VTRQdOvRRpJMCbUNbL272Uia84ZJEdfYgmvx/u/33 g1YIufXojLAVRESgKc1U5CY2jiRUcus= X-Google-Smtp-Source: APBJJlG9B22+2Fge2jv3nOd2roDO4LVOmNYdT8QnVszn2vFWhbClq+GyM5mHRLbZAf8RnUpocv2AGQ== X-Received: by 2002:a05:6830:1e4e:b0:6b8:6851:b19 with SMTP id e14-20020a0568301e4e00b006b868510b19mr14838972otj.3.1689168091911; Wed, 12 Jul 2023 06:21:31 -0700 (PDT) Received: from [192.168.0.16] (host197.190-225-105.telecom.net.ar. [190.225.105.197]) by smtp.gmail.com with ESMTPSA id y17-20020a056830209100b006b95d86f4f3sm1915743otq.28.2023.07.12.06.21.30 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Jul 2023 06:21:31 -0700 (PDT) Message-ID: <5c3d0fdd-eae3-5e94-34d1-2d44a63c521f@gmail.com> Date: Wed, 12 Jul 2023 10:21:30 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20230709125746.8054-1-anton@khirnov.net> <3f5fae87-e165-b8c6-4270-bea88be187c4@gmail.com> <90db5f3d-d24f-3c13-ac17-90a540003438@gyani.pro> From: James Almer In-Reply-To: <90db5f3d-d24f-3c13-ac17-90a540003438@gyani.pro> Subject: Re: [FFmpeg-devel] [PATCH] lavc: deprecate AV_CODEC_FLAG_DROPCHANGED 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/12/2023 10:14 AM, Gyan Doshi wrote: > > > On 2023-07-12 06:12 pm, James Almer wrote: >> On 7/9/2023 9:57 AM, Anton Khirnov wrote: >>> This decoding flag makes decoders drop all frames after a parameter >>> change, but what exactly constitutes a parameter change is not well >>> defined and will typically depend on the exact use case. >>> This functionality then does not belong in libavcodec, but rather in >>> user code > > NAK. > > The applicable parameters are well defined as set by the implementation. The implementation defined its own interpretation of what constitutes a parameter change, yes, but callers may have their own interpretations too. The result is they either don't set this flag, or set it but still manually check every frame for other parameters. > They are whatever leads to a change in the size of the decoded frame > payload or the layout/semantics of the elemental unit in a decoded > frame, so width, height, pixel format, sample format/size, > interleaving..etc You give pixel format as an example, which would include a change from yuv to a yuvj pseudo format. What about decoders that export yuv + color_range mpeg and then yuv + color_range jpeg? This implementation will not consider that a parameter change, despite being practically the same scenario. Once the yuvj formats are removed, this will be true for all decoders. And suddenly starting to check for color_range would be a change in implementation here. This is definitely something that should be left to the caller. They get a frame out of the decoder, they decide if they want to drop it. > > Regards, > Gyan > > _______________________________________________ > 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". _______________________________________________ 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".