On Thu, Jun 11, 2020 at 12:51:44PM -0300, James Almer wrote: > On 6/11/2020 12:39 PM, Andreas Rheinhardt wrote: > > lance.lmw...@gmail.com: > >> On Wed, Jun 10, 2020 at 07:43:11AM +0800, lance.lmw...@gmail.com wrote: > >>> From: Limin Wang <lance.lmw...@gmail.com> > >>> > >>> Signed-off-by: Limin Wang <lance.lmw...@gmail.com> > >>> --- > >>> rebase with master only, I'll apply the patchset in two days if no > >>> objection. > >>> > >>> doc/APIchanges | 3 +++ > >>> libavutil/frame.c | 1 + > >>> libavutil/frame.h | 8 ++++++++ > >>> libavutil/version.h | 2 +- > >>> 4 files changed, 13 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/doc/APIchanges b/doc/APIchanges > >>> index 70579df..08cdbda 100644 > >>> --- a/doc/APIchanges > >>> +++ b/doc/APIchanges > >>> @@ -15,6 +15,9 @@ libavutil: 2017-10-21 > >>> > >>> API changes, most recent first: > >>> > >>> +2020-06-xx - xxxxxxxxxx - lavu 56.53.100 - frame.h > >>> + Add AV_FRAME_DATA_SEI_UNREGISTERED. > >>> + > >>> 2020-06-05 - ec39c2276a - lavu 56.50.100 - buffer.h > >>> Passing NULL as alloc argument to av_buffer_pool_init2() is now > >>> allowed. > >>> > >>> diff --git a/libavutil/frame.c b/libavutil/frame.c > >>> index 2e952ed..9884eae 100644 > >>> --- a/libavutil/frame.c > >>> +++ b/libavutil/frame.c > >>> @@ -851,6 +851,7 @@ const char *av_frame_side_data_name(enum > >>> AVFrameSideDataType type) > >>> case AV_FRAME_DATA_DYNAMIC_HDR_PLUS: return "HDR Dynamic Metadata > >>> SMPTE2094-40 (HDR10+)"; > >>> case AV_FRAME_DATA_REGIONS_OF_INTEREST: return "Regions Of Interest"; > >>> case AV_FRAME_DATA_VIDEO_ENC_PARAMS: return "Video > >>> encoding parameters"; > >>> + case AV_FRAME_DATA_SEI_UNREGISTERED: return "H.26[45] > >>> User Data Unregistered SEI message"; > >>> } > >>> return NULL; > >>> } > >>> diff --git a/libavutil/frame.h b/libavutil/frame.h > >>> index fc67db0..3fb8c56 100644 > >>> --- a/libavutil/frame.h > >>> +++ b/libavutil/frame.h > >>> @@ -184,6 +184,14 @@ enum AVFrameSideDataType { > >>> * Encoding parameters for a video frame, as described by > >>> AVVideoEncParams. > >>> */ > >>> AV_FRAME_DATA_VIDEO_ENC_PARAMS, > >>> + > >>> + /** > >>> + * User data unregistered metadata associated with a video frame. > >>> + * This is the H.26[45] UDU SEI message, and shouldn't be used for > >>> any other purpose > >>> + * The data is stored as uint8_t in AVFrameSideData.data which is 16 > >>> bytes of > >>> + * uuid_iso_iec_11578 followed by AVFrameSideData.size - 16 bytes of > >>> user_data_payload_byte. > >>> + */ > >>> + AV_FRAME_DATA_SEI_UNREGISTERED, > >>> }; > >>> > >>> enum AVActiveFormatDescription { > >>> diff --git a/libavutil/version.h b/libavutil/version.h > >>> index 652e1e9..e75e625 100644 > >>> --- a/libavutil/version.h > >>> +++ b/libavutil/version.h > >>> @@ -79,7 +79,7 @@ > >>> */ > >>> > >>> #define LIBAVUTIL_VERSION_MAJOR 56 > >>> -#define LIBAVUTIL_VERSION_MINOR 52 > >>> +#define LIBAVUTIL_VERSION_MINOR 53 > >>> #define LIBAVUTIL_VERSION_MICRO 100 > >> > >> will apply this patch to avoid conflict every time. > >> > > You should not have done so given that the other patches are not > > finished yet and given that you yourself suggested zero-terminating the > > buffer (which the pushed version does not demand). > > > > And avoiding merge conflicts is a bad rationale for pushing early anyway > > > (a better solution would be to only add the changes to APIchanges and > > version.h directly before you push). > > That is the correct solution, not just a better one. > > If this design is not finished, it shouldn't have been pushed at all. > Fortunately it was done after 4.3 was branched, so not much of an issue > if changed as required in a timely manner, but please refrain from > pushing API changes before they are accepted.
Thanks for the solution and comments, sorry I didn't think enough yet, good lesson to learn. > > > > >> > >>> > >>> #define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \ > >>> -- > >>> 1.8.3.1 > >>> > >> > > > > _______________________________________________ > > 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". -- Thanks, Limin Wang _______________________________________________ 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".