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 4F5ED4A1B4 for ; Mon, 22 Apr 2024 21:04:00 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 7FC8068D388; Tue, 23 Apr 2024 00:03:57 +0300 (EEST) Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id BAD1668D0E0 for ; Tue, 23 Apr 2024 00:03:51 +0300 (EEST) Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-5721ec47305so197244a12.0 for ; Mon, 22 Apr 2024 14:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ltnglobal-com.20230601.gappssmtp.com; s=20230601; t=1713819830; x=1714424630; darn=ffmpeg.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=wndi5Wc4efvAKAltLHU4JjiWR6nzKYniKzRhK0Oezo0=; b=3dOXIVurUe0U02sx7BbO7eE6xDPzpuh6arvCy/L9bGXimMNoO3ZminHNPKnHdLl39c kVElOEev4HctDBxCVB154pb4EkoL1pGGPSjQLjLUZ0YDLYV/iBAXuhTtas2iGzuW1EUx wSfiaqEX5d46hGAjFSZMOMphd6jwBGD0FIrreyuuhUMyU/RMyg3Kyatr2MRL69pC/cVU suxzqgi9e+LGQUGeRBI3O2IlpRxOubk0rIYTzlYF2kR1/P4i4IwPbKhEqQOZPuaf+LKJ s9tjbUVfSELcgen1l/4/c/lCzqwViY2CBsrfEojxET2vdP0bz0Jj1ndF7h8igSNagMbA SK5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713819830; x=1714424630; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=wndi5Wc4efvAKAltLHU4JjiWR6nzKYniKzRhK0Oezo0=; b=iOQ8R/Q6JdB/VExDgdr4DS1QumelhMaUZFF6Sc9WCCKk6omnz4r85JvdqltgSXeUga CWDL/FJO67jx3WNm7fkD19cXPMenUrhbfaxmJxicntxCv5A+MQvS/YnmKeZkOYfvE0Br O4Vke/by0U+t+i9b+bfQ87J1kv/9uDYERkCFgfY5ByHHhvvrq3vq5KXuFjVc1bbozdkO 5JjUp6qjAv/wfKFxz6IsQ/A/0gmyc3Z9g1libUYj0KpItjGNrCwljSiyaj9K9DuncBm0 +jLyTml4k4mnY9J4DAraG2GegZ6+gOazDV6RAW+H+ReopAdWgP7qQRn0nmGYMIljca6V To8A== X-Gm-Message-State: AOJu0YxiW4yOGWvQXGucQWuV+tJXkXm1qlVFnMMXS1+AboF+EaaGkIGe u6sEsQwsp6ZT4s9GKMgT2V5KsoOgSVMwKxqSrNMvWUN1VbFQLlg1rvQ3gAIlbWQuVjnXwU6uiv5 s1sTUeEu6FZsS1HFQnxrJ4ZA7Y9XQ/rnCC4q3sXXMv2o8OLbDA1I= X-Google-Smtp-Source: AGHT+IHD8VoJce8JsORQmaxC6Py6Dejfybs8gipG3+q3GtxDSP6vsDegxBdWqjBgHpV7mS1BGmvV6qdA6EOJ69tNOAw= X-Received: by 2002:a50:8a89:0:b0:56e:2f39:c5d2 with SMTP id j9-20020a508a89000000b0056e2f39c5d2mr7065176edj.7.1713819830343; Mon, 22 Apr 2024 14:03:50 -0700 (PDT) MIME-Version: 1.0 From: Devin Heitmueller Date: Mon, 22 Apr 2024 17:03:39 -0400 Message-ID: To: FFmpeg development discussions and patches Subject: [FFmpeg-devel] Inconsistent usage of AVFieldOrder values 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: Hello, I suspect this topic has been visited a number of times over the years, but I figured I should re-raise it. In the compressed domain, field ordering is represented by the AVFieldOrder enumeration. Among the interlaced possibilities, you've got four combinations: AV_FIELD_TT, AV_FIELD_BB, AV_FIELD_TB, AV_FIELD_BT. The last two characters indicate the coding and display order respectively. Only a subset of these possible values are able to be represented in ffmpeg's AVFrame facility (specifically AV_FIELD_TT and AV_FIELD_TB). This is because interlaced AVFrames are always represented as interleaved with top field coded first, and the AV_FRAME_FLAG_TOP_FIELD_FIRST flag (previously the top_field_first member) is used to dictate the display order. I'm not proposing we make any change to this behavior at this time. I'm seeing use cases (including within the ffmpeg tree) where I suspect the developer is misunderstanding the meaning of these values, and I want to solicit feedback on whether patches would be accepted to correct such usage, even if it results in breaking applications that expect the incorrect values. For example, the decklink input module (libavdevice/decklink_dec.cpp) sets the values on the v210 packets to either AV_FIELD_TT or AV_FIELD_BB depending on whether the display order is top field first or bottom field first. While the AV_FIELD_TT values is correct, the use of AV_FIELD_BB is incorrect since all frames delivered by the driver are always coded as top-field-first (i.e. interlaced frames with a display order of bottom first should be AV_FIELD_TB). I'm seeing numerous cases such as the above, in decoders and encoders, libavformat/libavdevice modules, as well as in third party applications. I guess my question is: if I submit patches which fix such cases where I find them, will they be rejected because they are a change in behavior and might very well break existing applications that expect the incorrect values? I would like the libraries to report the correct values in a consistent manner, but I recognize this may cause some breakage in existing applications. Thoughts? Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmueller@ltnglobal.com _______________________________________________ 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".