On 8/26/2019 5:20 PM, Michael Niedermayer wrote:
> On Mon, Aug 26, 2019 at 01:17:25PM -0300, 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.
>> + */
>
> ... exact duplicate of the previous one, except its timestamp and duration.
>
> maybe AV_FRAME_FLAG_DUPLICATE or AV_FRAME_FLAG_REPEATED would be clearer ?
It might, but i wanted to use the same name as the AVPacket flag defined
in avcodec.h. If duplicate or repeated is preferred then i'll change it.
I could also instead change the doxy to state it signals that the frame
is disposable in general and not just because it's a duplicate of a
previous one, even if for now that's the only usecase for it.
>
> thx
>
> [...]
>
>
> _______________________________________________
> 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".
>
_______________________________________________
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".
