[FFmpeg-devel] [PATCH v2 1/4] frame: handle add side data with the same type

[Michael Niedermayer]

On Fri, Nov 01, 2019 at 06:16:38PM +0100, Marton Balint wrote:
> 
> 
> On Fri, 1 Nov 2019, "zhilizhao(赵志立)" wrote:
> 
> >
> >
> >>On Nov 1, 2019, at 8:13 PM, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> >>
> >>On Fri, Nov 1, 2019 at 1:03 PM <quinkblack at foxmail.com> wrote:
> >>>
> >>>From: Zhao Zhili <zhilizhao at tencent.com>
> >>>
> >>>---
> >>>libavutil/frame.c | 13 +++++++++++++
> >>>libavutil/frame.h |  4 ++++
> >>>2 files changed, 17 insertions(+)
> >>>
> >>
> >>I believe there have been some use-cases, especially around
> >>closed-captions, where multiple blocks of the same type have been
> >>used, somehow. Since this is really an API change, not sure its such a
> >>good idea.
> >
> >I guess it may be too late to change the behavior.
> 
> I am not sure, all our API around side data (get/remove) is based on the
> assumption that a single entry of a type exists. Also for packet/stream side
> data it is already assumed as far as I see. So at least for the sake of
> consistency it should be the same way. Maybe we should print a deprecation
> warning if something adds multiple side data of the same type. And later
> sometime it can be changed to actually replace the old side data.

In respect to adding side data when the same type already exists,
it may be more robust to error out in such a case instead of replacing.

Also we may handle deprecation in a type specific manner
In cases where a duplicated type makes semantically no sense and also doesnt
occur it could possibly be considered an error immedeatly
Only cases where it makes sense or does actually happen need a deprecation
period i think. That is if someone wants to implement this at such a
fine grained level ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20191103/ff9f8ca1/attachment.sig>