On Tue, Aug 27, 2019 at 09:12:53AM +0200, Marton Balint wrote:
>
>
> 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. One disadvantage of this with the current ref counting system is that in codecs which do in place changes in a buffer. Keeping a reference to a frame means the decoder must copy the frame to get a new writable one to do changes in. Not keeping a ref avoids this. A method which detects duplicates without keeping a +1 reference on the previous frame would be better in this respect ... Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus
signature.asc
Description: PGP signature
_______________________________________________ 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".
