Apr 30, 2021, 22:29 by c...@passwd.hu:
>
>
> On Fri, 30 Apr 2021, Lynne wrote:
>
>> Apr 30, 2021, 13:34 by br...@frogmouth.net:
>>
>>> Signed-off-by: Brad Hards <br...@frogmouth.net>
>>> ---
>>> libavutil/frame.c | 31 +++++++++++++++++++++++++++++++
>>> libavutil/frame.h | 23 +++++++++++++++++++++++
>>> 2 files changed, 54 insertions(+)
>>>
>>> diff --git a/libavutil/frame.c b/libavutil/frame.c
>>> index 2ec59b44b1..9f9953c2b4 100644
>>> --- a/libavutil/frame.c
>>> +++ b/libavutil/frame.c
>>> @@ -625,6 +625,37 @@ AVFrameSideData *av_frame_get_side_data(const AVFrame
>>> *frame,
>>> return NULL;
>>> }
>>>
>>> +AVFrameSideData *av_frame_get_side_data_n(const AVFrame *frame,
>>> + enum AVFrameSideDataType type,
>>> + const int side_data_instance)
>>> +{
>>> + int i;
>>> + int n = 0;
>>> +
>>> + for (i = 0; i < frame->nb_side_data; i++) {
>>> + if (frame->side_data[i]->type == type) {
>>> + if (n == side_data_instance) {
>>> + return frame->side_data[i];
>>> + } else {
>>> + n++;
>>> + }
>>> + }
>>> + }
>>> + return NULL;
>>> +}
>>>
>>
>> _follow_the_code_style_
>> We have a document! We have thousands of lines of code already written with
>> it!
>> We do not add brackets on one-line statements, and we allow for (int loops.
>>
>
> The developer docs also says that FFmpeg does not force an indentation style
> on developers. So strictly speaking patch authors are not obligated to follow
> the general practice if they don't want to.
>
I already said what I had to say about this, so I'm just going to say "no" and
end it at that.
Unless you too agree that asterisk symbols look so much like insects we should
definitely have a MUL() macro, then we can talk.
> If we want to provide an API for getting multiple frame side data of the same
> type, then I think the more natural thing to do is extending the existing
> function, e.g.: "av_frame_get_side_data2(frame, type, prev)"
> This way the user can use the extended version (iterator-style) if having
> multiple side data makes sense, and the original version if it does not.
>
I could agree with that, though I'd still prefer a type-less
av_frame_get_side_data_next(frame, prev).
_______________________________________________
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".
