diff mbox series

[FFmpeg-devel,2/3,v2] avcodec: add an AVCodecContext flag to export PRFT side data on demand

Message ID 20200210182646.17593-2-jamrial@gmail.com
State New
Headers show
Series [FFmpeg-devel,1/3,v2] avcodec: add an AVCodecContext field to signal types of packet, frame, and coded stream side data to export
Related show

Checks

Context Check Description
andriy/ffmpeg-patchwork pending
andriy/ffmpeg-patchwork success Applied patch
andriy/ffmpeg-patchwork success Configure finished
andriy/ffmpeg-patchwork success Make finished
andriy/ffmpeg-patchwork success Make fate finished

Commit Message

James Almer Feb. 10, 2020, 6:26 p.m. UTC
Signed-off-by: James Almer <jamrial@gmail.com>
---
 libavcodec/avcodec.h       | 8 +++++++-
 libavcodec/options_table.h | 1 +
 2 files changed, 8 insertions(+), 1 deletion(-)

Comments

Derek Buitenhuis Feb. 19, 2020, 3:21 p.m. UTC | #1
On 10/02/2020 18:26, James Almer wrote:
>      /**
> -     * Producer Reference Time data corresponding to the AVProducerReferenceTime struct.
> +     * Producer Reference Time data corresponding to the AVProducerReferenceTime struct
> +     * exported by some encoders (on demand through the prft flag set in the AVCodecContext
> +     * export_side_data field).
>       */
>      AV_PKT_DATA_PRFT,

Isn't this (and the x264 change) a behavior change, and thus an API/ABI break?

- Derek
James Almer Feb. 19, 2020, 4:42 p.m. UTC | #2
On 2/19/2020 12:21 PM, Derek Buitenhuis wrote:
> On 10/02/2020 18:26, James Almer wrote:
>>      /**
>> -     * Producer Reference Time data corresponding to the AVProducerReferenceTime struct.
>> +     * Producer Reference Time data corresponding to the AVProducerReferenceTime struct
>> +     * exported by some encoders (on demand through the prft flag set in the AVCodecContext
>> +     * export_side_data field).
>>       */
>>      AV_PKT_DATA_PRFT,
> 
> Isn't this (and the x264 change) a behavior change, and thus an API/ABI break?

This flag and the x264 addition are both about a month old, and not
present in any release, so no.

> 
> - Derek
> _______________________________________________
> 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".
>
Derek Buitenhuis Feb. 19, 2020, 5:58 p.m. UTC | #3
On 19/02/2020 16:42, James Almer wrote:
> This flag and the x264 addition are both about a month old, and not
> present in any release, so no.

I see.

Aside: Do we have an actual written policy on after what amount of time
we consider it an API/ABI break? I always thought master was also supposed
to be stable within reason.

- Derek
Andreas Rheinhardt Feb. 19, 2020, 6:01 p.m. UTC | #4
Derek Buitenhuis:
> On 19/02/2020 16:42, James Almer wrote:
>> This flag and the x264 addition are both about a month old, and not
>> present in any release, so no.
> 
> I see.
> 
> Aside: Do we have an actual written policy on after what amount of time
> we consider it an API/ABI break? I always thought master was also supposed
> to be stable within reason.
> 
doc/APIchanges:
"Never assume the API of libav* to be stable unless at least 1 month
has passed since the last major version increase or the API was added."

- Andreas
James Almer Feb. 19, 2020, 6:01 p.m. UTC | #5
On 2/19/2020 2:58 PM, Derek Buitenhuis wrote:
> On 19/02/2020 16:42, James Almer wrote:
>> This flag and the x264 addition are both about a month old, and not
>> present in any release, so no.
> 
> I see.
> 
> Aside: Do we have an actual written policy on after what amount of time
> we consider it an API/ABI break? I always thought master was also supposed
> to be stable within reason.
> 
> - Derek

A month or two should be ok, IMO. But as far as written things go, i
think we've only ever defined a volatile/unstable period of a month or
so after a major bump.
Anton Khirnov Feb. 20, 2020, 8:49 a.m. UTC | #6
Quoting James Almer (2020-02-19 17:42:24)
> On 2/19/2020 12:21 PM, Derek Buitenhuis wrote:
> > On 10/02/2020 18:26, James Almer wrote:
> >>      /**
> >> -     * Producer Reference Time data corresponding to the AVProducerReferenceTime struct.
> >> +     * Producer Reference Time data corresponding to the AVProducerReferenceTime struct
> >> +     * exported by some encoders (on demand through the prft flag set in the AVCodecContext
> >> +     * export_side_data field).
> >>       */
> >>      AV_PKT_DATA_PRFT,
> > 
> > Isn't this (and the x264 change) a behavior change, and thus an API/ABI break?
> 
> This flag and the x264 addition are both about a month old, and not
> present in any release, so no.

Well, technically yes. Master is supposed to be stable. But I suppose
we can be less strict for exact behavior of specific encoders, that has
never been particularly strongly specified.
Derek Buitenhuis Feb. 20, 2020, 2:30 p.m. UTC | #7
On 20/02/2020 08:49, Anton Khirnov wrote:
> Well, technically yes. Master is supposed to be stable. But I suppose
> we can be less strict for exact behavior of specific encoders, that has
> never been particularly strongly specified.

Changing what a type of side data means is not encoder specific, however.

- Derek
Anton Khirnov Feb. 20, 2020, 2:35 p.m. UTC | #8
Quoting Derek Buitenhuis (2020-02-20 15:30:41)
> On 20/02/2020 08:49, Anton Khirnov wrote:
> > Well, technically yes. Master is supposed to be stable. But I suppose
> > we can be less strict for exact behavior of specific encoders, that has
> > never been particularly strongly specified.
> 
> Changing what a type of side data means is not encoder specific, however.

???
IIUC the change is merely that PRFT is exported on demand rather than
always.
Derek Buitenhuis Feb. 20, 2020, 2:44 p.m. UTC | #9
On 20/02/2020 14:35, Anton Khirnov wrote:
> IIUC the change is merely that PRFT is exported on demand rather than
> always.

Uhhhhhhhhh I got this patch set mixed up with the 2-3 other patch sets involving side data types.

Please disregard.

- Derek
diff mbox series

Patch

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 1280a7ffe2..7a40fa12b5 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1106,6 +1106,10 @@  typedef struct RcOverride{
  * Export motion vectors through frame side data
  */
 #define AV_CODEC_EXPORT_DATA_MVS         (1 << 0)
+/**
+ * Export Producer Reference Time through packet side data
+ */
+#define AV_CODEC_EXPORT_DATA_PRFT        (1 << 1)
 
 /**
  * Pan Scan area.
@@ -1426,7 +1430,9 @@  enum AVPacketSideDataType {
     AV_PKT_DATA_AFD,
 
     /**
-     * Producer Reference Time data corresponding to the AVProducerReferenceTime struct.
+     * Producer Reference Time data corresponding to the AVProducerReferenceTime struct
+     * exported by some encoders (on demand through the prft flag set in the AVCodecContext
+     * export_side_data field).
      */
     AV_PKT_DATA_PRFT,
 
diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index 3f278d5c68..3265889b8e 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_table.h
@@ -80,6 +80,7 @@  static const AVOption avcodec_options[] = {
 {"ass_ro_flush_noop", "do not reset ASS ReadOrder field on flush", 0, AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG2_RO_FLUSH_NOOP}, INT_MIN, INT_MAX, S|D, "flags2"},
 {"export_side_data", "Export metadata as side data", OFFSET(export_side_data), AV_OPT_TYPE_FLAGS, {.i64 = DEFAULT}, 0, UINT_MAX, A|V|S|D|E, "export_side_data"},
 {"mvs", "export motion vectors through frame side data", 0, AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_EXPORT_DATA_MVS}, INT_MIN, INT_MAX, V|D, "export_side_data"},
+{"prft", "export Producer Reference Time through packet side data", 0, AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_EXPORT_DATA_PRFT}, INT_MIN, INT_MAX, A|V|S|E, "export_side_data"},
 {"time_base", NULL, OFFSET(time_base), AV_OPT_TYPE_RATIONAL, {.dbl = 0}, 0, INT_MAX},
 {"g", "set the group of picture (GOP) size", OFFSET(gop_size), AV_OPT_TYPE_INT, {.i64 = 12 }, INT_MIN, INT_MAX, V|E},
 {"ar", "set audio sampling rate (in Hz)", OFFSET(sample_rate), AV_OPT_TYPE_INT, {.i64 = DEFAULT }, 0, INT_MAX, A|D|E},