| Message ID | 20200210182646.17593-2-jamrial@gmail.com |
|---|---|
| State | Accepted |
| 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 | expand |
| Context | Check | Description |
|---|---|---|
| andriy/ffmpeg-patchwork | success | Make fate finished |
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
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". >
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
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
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.
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.
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
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.
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 --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},
Signed-off-by: James Almer <jamrial@gmail.com> --- libavcodec/avcodec.h | 8 +++++++- libavcodec/options_table.h | 1 + 2 files changed, 8 insertions(+), 1 deletion(-)