On Mon, 26 Aug 2019, James Almer wrote:

Used to signal frames that can be safely discarded without losing
any picture data, side data, or metadata other than timing info.

Signed-off-by: James Almer <jamr...@gmail.com>
---
This implements the "disposable frame" solution to allow library
users to drop duplicate frames before further processing if desired,
instead of forcing decoders to output vfr content when cfr is coded
in the bitstream.

doc/APIchanges      | 3 +++
libavutil/frame.h   | 5 +++++
libavutil/version.h | 2 +-
3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 682b67aa25..b28d702bae 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil:     2017-10-21

API changes, most recent first:

+2019-08-xx - xxxxxxxxxx - lavu 58.34.100 - avframe.h
+  Add AV_FRAME_FLAG_DISPOSABLE
+
2019-08-xx - xxxxxxxxxx - lavf 58.31.101 - avio.h
  4K limit removed from avio_printf.

diff --git a/libavutil/frame.h b/libavutil/frame.h
index 5d3231e7bb..e1bf8795d2 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -522,6 +522,11 @@ typedef struct AVFrame {
 * A flag to mark the frames which need to be decoded, but shouldn't be output.
 */
#define AV_FRAME_FLAG_DISCARD   (1 << 2)
+/**
+ * A flag to indicate frames that can be discarded by the encoder. I.e. frames
+ * that are an exact duplicate of the previous one.
+ */
+#define AV_FRAME_FLAG_DISPOSABLE    (1 << 3)

Such a flag has the problem that it is not really an attribute of a frame in itself, but of a frame of the frame chain. That can cause various issues: If the first frame is dropped, the next frame no longer becomes disposable.

For the issue we are trying to solve I feel that it is better if we create a video filter which checks the buffers (and side data and crop parameters) if they are the same and drops the frame. It also allows more granular control (or setting parameters, like making sure you get a frame every 1 second or so, which is common requirement even for VFR), plus it can work for existing cases without this flag implemented.

Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to