Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect for object detection
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: 2021年3月1日 12:50
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect
> for object detection
>
> Guo, Yejun:
> > Signed-off-by: Guo, Yejun
> > ---
> > configure | 1 +
> > doc/filters.texi | 40 +++
> > libavfilter/Makefile | 1 +
> > libavfilter/allfilters.c | 1 +
> > libavfilter/dnn/dnn_backend_openvino.c | 12 +
> > libavfilter/dnn_filter_common.c| 7 +
> > libavfilter/dnn_filter_common.h| 1 +
> > libavfilter/dnn_interface.h| 6 +-
> > libavfilter/vf_dnn_detect.c| 462
> +
> > 9 files changed, 529 insertions(+), 2 deletions(-) create mode
> > b/libavfilter/dnn_interface.h index d3a0c58a61..90a08129f4 100644
> > --- a/libavfilter/dnn_interface.h
> > +++ b/libavfilter/dnn_interface.h
> > @@ -63,6 +63,8 @@ typedef struct DNNData{
> > DNNColorOrder order;
> > } DNNData;
> >
> > +typedef int (*PRE_POST_PROC)(AVFrame *frame, DNNData *model,
> > +AVFilterContext *filter_ctx);
>
> Why uppercase? It is a typedef, not a macro.
will change to CamelCase, thanks.
>
> > +
> > typedef struct DNNModel{
> > // Stores model that can be different for different backends.
> > void *model;
> > @@ -80,10 +82,10 @@ typedef struct DNNModel{
> > const char *output_name, int
> *output_width, int *output_height);
> > // set the pre process to transfer data from AVFrame to DNNData
> > // the default implementation within DNN is used if it is not provided
> by the filter
> > -int (*pre_proc)(AVFrame *frame_in, DNNData *model_input,
> AVFilterContext *filter_ctx);
> > +PRE_POST_PROC pre_proc;
> > // set the post process to transfer data from DNNData to AVFrame
> > // the default implementation within DNN is used if it is not provided
> by the filter
> > -int (*post_proc)(AVFrame *frame_out, DNNData *model_output,
> AVFilterContext *filter_ctx);
> > +PRE_POST_PROC post_proc;
>
> Spurious change.
sorry, not quite understand this comment. It is used for code refine.
Maybe I need to let it in a separate patch.
>
> > } DNNModel;
> >
> > +
> > +frame->private_ref = av_buffer_alloc(sizeof(*header) + sizeof(*bbox) *
> nb_bbox);
> > +if (!frame->private_ref) {
> > +av_log(filter_ctx, AV_LOG_ERROR, "failed to allocate buffer for %d
> bboxes\n", nb_bbox);
> > +return AVERROR(ENOMEM);;
>
> Double ;
thanks, will remove it.
>
> > +}
> > +
> > +header = (BoundingBoxHeader *)frame->private_ref->data;
> > +strncpy(header->source, ctx->dnnctx.model_filename,
> sizeof(header->source));
> > +header->source[sizeof(header->source) - 1] = '\0';
> > +header->bbox_size = sizeof(*bbox);
> > +
> > +bbox = (BoundingBox *)(header + 1);
>
> This does not guarantee proper alignment. You could use a flexible array
> member for that.
The memory layout of frame->private_ref->data is:
sizeof(*header) + sizeof(*bbox) + sizeof(*bbox) + ...
I think 'header + 1' goes correctly to the first bbox. thanks.
> > +
> > +label = av_strdup(buf);
> > +if (!label) {
> > +av_log(context, AV_LOG_ERROR, "failed to allocate memory
> for label %s\n", buf);
> > +fclose(file);
> > +free_detect_labels(ctx);
> > +return AVERROR(ENOMEM);
> > +}
> > +
> > +if (av_dynarray_add_nofree(&ctx->labels, &ctx->label_count, label)
> < 0) {
> > +av_log(context, AV_LOG_ERROR, "failed to do
> av_dynarray_add\n");
> > +fclose(file);
> > +free_detect_labels(ctx);
>
> 1. You are leaking label here.
> 2. You are repeating yourself with the cleanup code.
> 3. When you return an error in a filter's init function, the filter's uninit
> function
> is called automatically. In this case this means that free_detect_labels is
> called
> twice which is not only wasteful, but
> harmful: You are freeing ctx->labels (and all labels contained in it) in the
> first
> run, but you are not resetting the number of labels. If
> ctx->label_count is > 0, there will be a segfault when
> free_detect_labels is called the second time.
good catch, will free label, remove the duplicate calling, and also reset
ctx->label_count.
> 4. Return the error code.
> (5. I consider your use of av_log for every error to be excessive.)
not quite understand this one, thanks.
>
> > +return AVERROR(ENOMEM);
> > +}
> > +}
> > +
> > +fclose(file);
> > +return 0;
> > +}
> > +
___
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".
Re: [FFmpeg-devel] [PATCH 2/3] libavformat/hls: add support for decryption of HLS streams in MPEG-TS format protected using SAMPLE-AES encryption
On Mon, Mar 1, 2021 at 11:30 AM Steven Liu wrote:
>
>
>
> > 2021年3月1日 下午12:55，Nachiket Tarate 写道：
> >
> > This is an updated version of the patch in which I have added the check. If
> > the segments are in Fragmented MP4 format, HLS demuxer quits by giving an
> > error message:
> >
> > "SAMPLE-AES encryption is not supported for fragmented MP4 format yet”
> I don’t think is a good resolution for SAMPLE-AES encryption and decryption.
> You should support that if you want support SAMPLE-AES in hls,
> because SAMPLE-AES not only support in MPEG-TS, but also support fragment mp4.
> Whatever, if you only support mpegts en[de]cryption, it should be a half part
> patch.
Two completely different technologies/specifications have been used
for SAMPLE-AES encryption of HLS streams in MPEG-TS and fragmented MP4
formats.
Fragmented MP4 media segments are encrypted using the 'cbcs' scheme of
Common Encryption [CENC]:
https://www.iso.org/standard/68042.html
Encryption of other media segment formats such as MPEG-TS or external
audio tracks containing H.264, AAC, AC-3 and Enhanced AC-3 media
streams is described in the Apple's HTTP Live Streaming (HLS) Sample
Encryption specifications:
https://developer.apple.com/library/ios/documentation/AudioVideo/Conceptual/HLS_Sample_Encryption
This patch implements the later specifications and enables decryption
of media segments in MPEG-TS, AAC, AC-3 and Enhanced AC-3 formats. So
I think we should merge this patch right now.
In future, we will add support for CENC or see how can we use existing
things from MOV demuxer.
Best Regards,
Nachiket Tarate
> >
> > Best Regards,
> > Nachiket Tarate
> >
> > On Mon, Mar 1, 2021 at 10:13 AM Steven Liu wrote:
> >
> >>
> >>
> >>> 2021年3月1日 下午12:35，Nachiket Tarate 写道：
> >>>
> >>> @Steven Liu
> >>>
> >>> Can we merge this patch ?
> >> I’m waiting update patch for fragment mp4 encryption.
> >> After new version of the patchset I will test and review.
> >>>
> >>> Best Regards,
> >>> Nachiket Tarate
> >>>
> >>> On Wed, Feb 24, 2021 at 4:44 PM Nachiket Tarate <
> >>> nachiket.program...@gmail.com> wrote:
> >>>
> Apple HTTP Live Streaming Sample Encryption:
>
>
>
> >> https://developer.apple.com/library/ios/documentation/AudioVideo/Conceptual/HLS_Sample_Encryption
>
> Signed-off-by: Nachiket Tarate
> ---
> libavformat/Makefile | 2 +-
> libavformat/hls.c| 105 --
> libavformat/hls_sample_aes.c | 391 +++
> libavformat/hls_sample_aes.h | 66 ++
> libavformat/mpegts.c | 12 ++
> 5 files changed, 562 insertions(+), 14 deletions(-)
> create mode 100644 libavformat/hls_sample_aes.c
> create mode 100644 libavformat/hls_sample_aes.h
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index fcb39ce133..62627d50a6 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -236,7 +236,7 @@ OBJS-$(CONFIG_HCOM_DEMUXER) += hcom.o
> pcm.o
> OBJS-$(CONFIG_HDS_MUXER) += hdsenc.o
> OBJS-$(CONFIG_HEVC_DEMUXER) += hevcdec.o rawdec.o
> OBJS-$(CONFIG_HEVC_MUXER)+= rawenc.o
> -OBJS-$(CONFIG_HLS_DEMUXER) += hls.o
> +OBJS-$(CONFIG_HLS_DEMUXER) += hls.o hls_sample_aes.o
> OBJS-$(CONFIG_HLS_MUXER) += hlsenc.o hlsplaylist.o avc.o
> OBJS-$(CONFIG_HNM_DEMUXER) += hnm.o
> OBJS-$(CONFIG_ICO_DEMUXER) += icodec.o
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index af2468ad9b..3cb3853c79 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -2,6 +2,7 @@
> * Apple HTTP Live Streaming demuxer
> * Copyright (c) 2010 Martin Storsjo
> * Copyright (c) 2013 Anssi Hannula
> + * Copyright (c) 2021 Nachiket Tarate
> *
> * This file is part of FFmpeg.
> *
> @@ -39,6 +40,8 @@
> #include "avio_internal.h"
> #include "id3v2.h"
>
> +#include "hls_sample_aes.h"
> +
> #define INITIAL_BUFFER_SIZE 32768
>
> #define MAX_FIELD_LEN 64
> @@ -145,6 +148,10 @@ struct playlist {
> int id3_changed; /* ID3 tag data has changed at some point */
> ID3v2ExtraMeta *id3_deferred_extra; /* stored here until subdemuxer
> is opened */
>
> +/* Used in case of SAMPLE-AES encryption method */
> +HLSAudioSetupInfo audio_setup_info;
> +HLSCryptoContext crypto_ctx;
> +
> int64_t seek_timestamp;
> int seek_flags;
> int seek_stream_index; /* into subdemuxer stream array */
> @@ -266,6 +273,8 @@ static void free_playlist_list(HLSContext *c)
> pls->ctx->pb = NULL;
> avformat_close_input(&pls->ctx);
> }
> +if (pls->crypto_ctx.aes_ctx)
> + av_free(pls->crypto_ctx.aes
[FFmpeg-devel] [PATCH] mjpegdec: handle lowres with AVID cropping
---
libavcodec/mjpegdec.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 79c7d6e6cf..20f310fd70 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -445,16 +445,16 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
if (ret < 0)
return ret;
+if ((s->avctx->codec_tag == MKTAG('A', 'V', 'R', 'n') ||
+ s->avctx->codec_tag == MKTAG('A', 'V', 'D', 'J')) &&
+s->orig_height < height)
+s->avctx->height = AV_CEIL_RSHIFT(s->orig_height,
s->avctx->lowres);
+
s->first_picture = 0;
} else {
size_change = 0;
}
-if ((s->avctx->codec_tag == MKTAG('A', 'V', 'R', 'n') ||
- s->avctx->codec_tag == MKTAG('A', 'V', 'D', 'J')) &&
-s->orig_height < s->avctx->height)
-s->avctx->height = s->orig_height;
-
if (s->avctx->codec_id == AV_CODEC_ID_SMVJPEG) {
s->avctx->height = s->avctx->coded_height / s->smv_frames_per_jpeg;
if (s->avctx->height <= 0)
@@ -2863,8 +2863,8 @@ the_end:
if ((avctx->codec_tag == MKTAG('A', 'V', 'R', 'n') ||
avctx->codec_tag == MKTAG('A', 'V', 'D', 'J')) &&
avctx->coded_height > s->orig_height) {
-frame->height = avctx->coded_height;
-frame->crop_top = frame->height - s->orig_height;
+frame->height = AV_CEIL_RSHIFT(avctx->coded_height, avctx->lowres);
+frame->crop_top = frame->height - avctx->height;
}
ret = 0;
--
2.30.0
___
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".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec: add SGA PCM decoder
will apply this set soon. ___ 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".
Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect for object detection
Guo, Yejun:
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Andreas Rheinhardt
>> Sent: 2021年3月1日 12:50
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect
>> for object detection
>>
>> Guo, Yejun:
>>> Signed-off-by: Guo, Yejun
>>> ---
>>> configure | 1 +
>>> doc/filters.texi | 40 +++
>>> libavfilter/Makefile | 1 +
>>> libavfilter/allfilters.c | 1 +
>>> libavfilter/dnn/dnn_backend_openvino.c | 12 +
>>> libavfilter/dnn_filter_common.c| 7 +
>>> libavfilter/dnn_filter_common.h| 1 +
>>> libavfilter/dnn_interface.h| 6 +-
>>> libavfilter/vf_dnn_detect.c| 462
>> +
>>> 9 files changed, 529 insertions(+), 2 deletions(-) create mode
>
>>> b/libavfilter/dnn_interface.h index d3a0c58a61..90a08129f4 100644
>>> --- a/libavfilter/dnn_interface.h
>>> +++ b/libavfilter/dnn_interface.h
>>> @@ -63,6 +63,8 @@ typedef struct DNNData{
>>> DNNColorOrder order;
>>> } DNNData;
>>>
>>> +typedef int (*PRE_POST_PROC)(AVFrame *frame, DNNData *model,
>>> +AVFilterContext *filter_ctx);
>>
>> Why uppercase? It is a typedef, not a macro.
>
> will change to CamelCase, thanks.
>
>>
>>> +
>>> typedef struct DNNModel{
>>> // Stores model that can be different for different backends.
>>> void *model;
>>> @@ -80,10 +82,10 @@ typedef struct DNNModel{
>>> const char *output_name, int
>> *output_width, int *output_height);
>>> // set the pre process to transfer data from AVFrame to DNNData
>>> // the default implementation within DNN is used if it is not provided
>> by the filter
>>> -int (*pre_proc)(AVFrame *frame_in, DNNData *model_input,
>> AVFilterContext *filter_ctx);
>>> +PRE_POST_PROC pre_proc;
>>> // set the post process to transfer data from DNNData to AVFrame
>>> // the default implementation within DNN is used if it is not provided
>> by the filter
>>> -int (*post_proc)(AVFrame *frame_out, DNNData *model_output,
>> AVFilterContext *filter_ctx);
>>> +PRE_POST_PROC post_proc;
>>
>> Spurious change.
>
> sorry, not quite understand this comment. It is used for code refine.
> Maybe I need to let it in a separate patch.
>
>>
>>> } DNNModel;
>>>
>>> +
>>> +frame->private_ref = av_buffer_alloc(sizeof(*header) + sizeof(*bbox) *
>> nb_bbox);
>>> +if (!frame->private_ref) {
>>> +av_log(filter_ctx, AV_LOG_ERROR, "failed to allocate buffer for %d
>> bboxes\n", nb_bbox);
>>> +return AVERROR(ENOMEM);;
>>
>> Double ;
>
> thanks, will remove it.
>
>>
>>> +}
>>> +
>>> +header = (BoundingBoxHeader *)frame->private_ref->data;
>>> +strncpy(header->source, ctx->dnnctx.model_filename,
>> sizeof(header->source));
>>> +header->source[sizeof(header->source) - 1] = '\0';
>>> +header->bbox_size = sizeof(*bbox);
>>> +
>>> +bbox = (BoundingBox *)(header + 1);
>>
>> This does not guarantee proper alignment. You could use a flexible array
>> member for that.
>
> The memory layout of frame->private_ref->data is:
> sizeof(*header) + sizeof(*bbox) + sizeof(*bbox) + ...
>
> I think 'header + 1' goes correctly to the first bbox. thanks.
>
header + 1 points to the position where another BoundingBoxHeader would
be if header were an array of BoundingBoxHeaders (i.e. it points
sizeof(BoundingBoxHeader) bytes after header). So this guarantees that
there is no overlap between your header and your actual boxes, but this
does not guarantee proper alignment. This will be a problem on platforms
where int is 64bit and requires eight byte alignment (unlikely) or if
you add something that requires alignment of eight bytes (like a 64bit
integer or a pointer on a 64bit system) to BoundingBox.
>>> +
>>> +label = av_strdup(buf);
>>> +if (!label) {
>>> +av_log(context, AV_LOG_ERROR, "failed to allocate memory
>> for label %s\n", buf);
>>> +fclose(file);
>>> +free_detect_labels(ctx);
>>> +return AVERROR(ENOMEM);
>>> +}
>>> +
>>> +if (av_dynarray_add_nofree(&ctx->labels, &ctx->label_count, label)
>> < 0) {
>>> +av_log(context, AV_LOG_ERROR, "failed to do
>> av_dynarray_add\n");
>>> +fclose(file);
>>> +free_detect_labels(ctx);
>>
>> 1. You are leaking label here.
>> 2. You are repeating yourself with the cleanup code.
>> 3. When you return an error in a filter's init function, the filter's uninit
>> function
>> is called automatically. In this case this means that free_detect_labels is
>> called
>> twice which is not only wasteful, but
>> harmful: You are freeing ctx->labels (and all labels contained in it) in the
>> first
>> run, but you are not resetting the number of labels. If
>> ctx->label_count is > 0, there will be a segfault when
>> free_detect_labels is called the sec
Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect for object detection
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: 2021年3月1日 16:31
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect
> for object detection
>
> Guo, Yejun:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel On Behalf Of
> >> Andreas Rheinhardt
> >> Sent: 2021年3月1日 12:50
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter
> >> dnn_detect for object detection
> >>
> >> Guo, Yejun:
> >>> Signed-off-by: Guo, Yejun
> >>> ---
> >>> configure | 1 +
> >>> doc/filters.texi | 40 +++
> >>> libavfilter/Makefile | 1 +
> >>> libavfilter/allfilters.c | 1 +
> >>> libavfilter/dnn/dnn_backend_openvino.c | 12 +
> >>> libavfilter/dnn_filter_common.c| 7 +
> >>> libavfilter/dnn_filter_common.h| 1 +
> >>> libavfilter/dnn_interface.h| 6 +-
> >>> libavfilter/vf_dnn_detect.c| 462
> >> +
> >>> 9 files changed, 529 insertions(+), 2 deletions(-) create mode
> >
> >>> b/libavfilter/dnn_interface.h index d3a0c58a61..90a08129f4 100644
> >>> --- a/libavfilter/dnn_interface.h
> >>> +++ b/libavfilter/dnn_interface.h
> >>> @@ -63,6 +63,8 @@ typedef struct DNNData{
> >>> DNNColorOrder order;
> >>> } DNNData;
> >>>
> >>> +typedef int (*PRE_POST_PROC)(AVFrame *frame, DNNData *model,
> >>> +AVFilterContext *filter_ctx);
> >>
> >> Why uppercase? It is a typedef, not a macro.
> >
> > will change to CamelCase, thanks.
> >
> >>
> >>> +
> >>> typedef struct DNNModel{
> >>> // Stores model that can be different for different backends.
> >>> void *model;
> >>> @@ -80,10 +82,10 @@ typedef struct DNNModel{
> >>> const char *output_name, int
> >> *output_width, int *output_height);
> >>> // set the pre process to transfer data from AVFrame to DNNData
> >>> // the default implementation within DNN is used if it is not
> >>> provided
> >> by the filter
> >>> -int (*pre_proc)(AVFrame *frame_in, DNNData *model_input,
> >> AVFilterContext *filter_ctx);
> >>> +PRE_POST_PROC pre_proc;
> >>> // set the post process to transfer data from DNNData to AVFrame
> >>> // the default implementation within DNN is used if it is not
> >>> provided
> >> by the filter
> >>> -int (*post_proc)(AVFrame *frame_out, DNNData *model_output,
> >> AVFilterContext *filter_ctx);
> >>> +PRE_POST_PROC post_proc;
> >>
> >> Spurious change.
> >
> > sorry, not quite understand this comment. It is used for code refine.
> > Maybe I need to let it in a separate patch.
> >
> >>
> >>> } DNNModel;
> >>>
> >>> +
> >>> +frame->private_ref = av_buffer_alloc(sizeof(*header) +
> >>> + sizeof(*bbox) *
> >> nb_bbox);
> >>> +if (!frame->private_ref) {
> >>> +av_log(filter_ctx, AV_LOG_ERROR, "failed to allocate buffer
> >>> + for %d
> >> bboxes\n", nb_bbox);
> >>> +return AVERROR(ENOMEM);;
> >>
> >> Double ;
> >
> > thanks, will remove it.
> >
> >>
> >>> +}
> >>> +
> >>> +header = (BoundingBoxHeader *)frame->private_ref->data;
> >>> +strncpy(header->source, ctx->dnnctx.model_filename,
> >> sizeof(header->source));
> >>> +header->source[sizeof(header->source) - 1] = '\0';
> >>> +header->bbox_size = sizeof(*bbox);
> >>> +
> >>> +bbox = (BoundingBox *)(header + 1);
> >>
> >> This does not guarantee proper alignment. You could use a flexible
> >> array member for that.
> >
> > The memory layout of frame->private_ref->data is:
> > sizeof(*header) + sizeof(*bbox) + sizeof(*bbox) + ...
> >
> > I think 'header + 1' goes correctly to the first bbox. thanks.
> >
>
> header + 1 points to the position where another BoundingBoxHeader would be
> if header were an array of BoundingBoxHeaders (i.e. it points
> sizeof(BoundingBoxHeader) bytes after header). So this guarantees that there
> is
> no overlap between your header and your actual boxes, but this does not
> guarantee proper alignment. This will be a problem on platforms where int is
> 64bit and requires eight byte alignment (unlikely) or if you add something
> that
> requires alignment of eight bytes (like a 64bit integer or a pointer on a
> 64bit
> system) to BoundingBox.
got the point, thanks. Will add 'BoundingBox bboxes[0]' at the end of struct
BoundingBoxHeader.
>
> >>> +
> >>> +label = av_strdup(buf);
> >>> +if (!label) {
> >>> +av_log(context, AV_LOG_ERROR, "failed to allocate
> >>> + memory
> >> for label %s\n", buf);
> >>> +fclose(file);
> >>> +free_detect_labels(ctx);
> >>> +return AVERROR(ENOMEM);
> >>> +}
> >>> +
> >>> +if (av_dynarray_add_nofree(&ctx->labels, &ctx->label_count,
> >>> + label)
> >> < 0) {
> >>> +av_log(context, AV_LOG_ERROR, "failed to do
> >> av_dynarray_add\n");
>
Re: [FFmpeg-devel] [PATCH V3 1/5] libavdevice/v4l2.c: fix build warning for [-Wformat-truncation=]
Guo, Yejun (12021-03-01): > thanks for the advice, we might don't disable it, because the disabling will > no longer > remind the developers of this issue existing, this is another comment. thanks. What "issue"? The only issue here is a useless warning. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect for object detection
Guo, Yejun:
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Andreas Rheinhardt
>> Sent: 2021年3月1日 16:31
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect
>> for object detection
>>
>> Guo, Yejun:
>>>
>>>
-Original Message-
From: ffmpeg-devel On Behalf Of
Andreas Rheinhardt
Sent: 2021年3月1日 12:50
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter
dnn_detect for object detection
Guo, Yejun:
> Signed-off-by: Guo, Yejun
> ---
> configure | 1 +
> doc/filters.texi | 40 +++
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/dnn/dnn_backend_openvino.c | 12 +
> libavfilter/dnn_filter_common.c| 7 +
> libavfilter/dnn_filter_common.h| 1 +
> libavfilter/dnn_interface.h| 6 +-
> libavfilter/vf_dnn_detect.c| 462
+
> 9 files changed, 529 insertions(+), 2 deletions(-) create mode
>>>
> b/libavfilter/dnn_interface.h index d3a0c58a61..90a08129f4 100644
> --- a/libavfilter/dnn_interface.h
> +++ b/libavfilter/dnn_interface.h
> @@ -63,6 +63,8 @@ typedef struct DNNData{
> DNNColorOrder order;
> } DNNData;
>
> +typedef int (*PRE_POST_PROC)(AVFrame *frame, DNNData *model,
> +AVFilterContext *filter_ctx);
Why uppercase? It is a typedef, not a macro.
>>>
>>> will change to CamelCase, thanks.
>>>
> +
> typedef struct DNNModel{
> // Stores model that can be different for different backends.
> void *model;
> @@ -80,10 +82,10 @@ typedef struct DNNModel{
> const char *output_name, int
*output_width, int *output_height);
> // set the pre process to transfer data from AVFrame to DNNData
> // the default implementation within DNN is used if it is not
> provided
by the filter
> -int (*pre_proc)(AVFrame *frame_in, DNNData *model_input,
AVFilterContext *filter_ctx);
> +PRE_POST_PROC pre_proc;
> // set the post process to transfer data from DNNData to AVFrame
> // the default implementation within DNN is used if it is not
> provided
by the filter
> -int (*post_proc)(AVFrame *frame_out, DNNData *model_output,
AVFilterContext *filter_ctx);
> +PRE_POST_PROC post_proc;
Spurious change.
>>>
>>> sorry, not quite understand this comment. It is used for code refine.
>>> Maybe I need to let it in a separate patch.
>>>
> } DNNModel;
>
> +
> +frame->private_ref = av_buffer_alloc(sizeof(*header) +
> + sizeof(*bbox) *
nb_bbox);
> +if (!frame->private_ref) {
> +av_log(filter_ctx, AV_LOG_ERROR, "failed to allocate buffer
> + for %d
bboxes\n", nb_bbox);
> +return AVERROR(ENOMEM);;
Double ;
>>>
>>> thanks, will remove it.
>>>
> +}
> +
> +header = (BoundingBoxHeader *)frame->private_ref->data;
> +strncpy(header->source, ctx->dnnctx.model_filename,
sizeof(header->source));
> +header->source[sizeof(header->source) - 1] = '\0';
> +header->bbox_size = sizeof(*bbox);
> +
> +bbox = (BoundingBox *)(header + 1);
This does not guarantee proper alignment. You could use a flexible
array member for that.
>>>
>>> The memory layout of frame->private_ref->data is:
>>> sizeof(*header) + sizeof(*bbox) + sizeof(*bbox) + ...
>>>
>>> I think 'header + 1' goes correctly to the first bbox. thanks.
>>>
>>
>> header + 1 points to the position where another BoundingBoxHeader would be
>> if header were an array of BoundingBoxHeaders (i.e. it points
>> sizeof(BoundingBoxHeader) bytes after header). So this guarantees that there
>> is
>> no overlap between your header and your actual boxes, but this does not
>> guarantee proper alignment. This will be a problem on platforms where int is
>> 64bit and requires eight byte alignment (unlikely) or if you add something
>> that
>> requires alignment of eight bytes (like a 64bit integer or a pointer on a
>> 64bit
>> system) to BoundingBox.
>
> got the point, thanks. Will add 'BoundingBox bboxes[0]' at the end of struct
> BoundingBoxHeader.
>
An array with zero elements is not allowed in ISO C (see 6.7.6.2 1 in
C11 or 6.7.5.2 1 in C99), although many compilers support it.
>>
> +
> +label = av_strdup(buf);
> +if (!label) {
> +av_log(context, AV_LOG_ERROR, "failed to allocate
> + memory
for label %s\n", buf);
> +fclose(file);
> +free_detect_labels(ctx);
> +return AVERROR(ENOMEM);
> +}
> +
> +i
Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect for object detection
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: 2021年3月1日 20:13
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect
> for object detection
>
> Guo, Yejun:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel On Behalf Of
> >> Andreas Rheinhardt
> >> Sent: 2021年3月1日 16:31
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter
> >> dnn_detect for object detection
> >>
> >> Guo, Yejun:
> >>>
> >>>
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: 2021年3月1日 12:50
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter
> dnn_detect for object detection
>
> Guo, Yejun:
> > Signed-off-by: Guo, Yejun
> > ---
> > configure | 1 +
> > doc/filters.texi | 40 +++
> > libavfilter/Makefile | 1 +
> > libavfilter/allfilters.c | 1 +
> > libavfilter/dnn/dnn_backend_openvino.c | 12 +
> > libavfilter/dnn_filter_common.c| 7 +
> > libavfilter/dnn_filter_common.h| 1 +
> > libavfilter/dnn_interface.h| 6 +-
> > libavfilter/vf_dnn_detect.c| 462
> +
> > 9 files changed, 529 insertions(+), 2 deletions(-) create mode
> >>>
> > b/libavfilter/dnn_interface.h index d3a0c58a61..90a08129f4 100644
> > --- a/libavfilter/dnn_interface.h
> > +++ b/libavfilter/dnn_interface.h
> > @@ -63,6 +63,8 @@ typedef struct DNNData{
> > DNNColorOrder order;
> > } DNNData;
> >
> > +typedef int (*PRE_POST_PROC)(AVFrame *frame, DNNData *model,
> > +AVFilterContext *filter_ctx);
>
> Why uppercase? It is a typedef, not a macro.
> >>>
> >>> will change to CamelCase, thanks.
> >>>
>
> > +
> > typedef struct DNNModel{
> > // Stores model that can be different for different backends.
> > void *model;
> > @@ -80,10 +82,10 @@ typedef struct DNNModel{
> > const char *output_name, int
> *output_width, int *output_height);
> > // set the pre process to transfer data from AVFrame to DNNData
> > // the default implementation within DNN is used if it is not
> > provided
> by the filter
> > -int (*pre_proc)(AVFrame *frame_in, DNNData *model_input,
> AVFilterContext *filter_ctx);
> > +PRE_POST_PROC pre_proc;
> > // set the post process to transfer data from DNNData to
> AVFrame
> > // the default implementation within DNN is used if it is not
> > provided
> by the filter
> > -int (*post_proc)(AVFrame *frame_out, DNNData *model_output,
> AVFilterContext *filter_ctx);
> > +PRE_POST_PROC post_proc;
>
> Spurious change.
> >>>
> >>> sorry, not quite understand this comment. It is used for code refine.
> >>> Maybe I need to let it in a separate patch.
> >>>
>
> > } DNNModel;
> >
> > +
> > +frame->private_ref = av_buffer_alloc(sizeof(*header) +
> > + sizeof(*bbox) *
> nb_bbox);
> > +if (!frame->private_ref) {
> > +av_log(filter_ctx, AV_LOG_ERROR, "failed to allocate
> > + buffer for %d
> bboxes\n", nb_bbox);
> > +return AVERROR(ENOMEM);;
>
> Double ;
> >>>
> >>> thanks, will remove it.
> >>>
>
> > +}
> > +
> > +header = (BoundingBoxHeader *)frame->private_ref->data;
> > +strncpy(header->source, ctx->dnnctx.model_filename,
> sizeof(header->source));
> > +header->source[sizeof(header->source) - 1] = '\0';
> > +header->bbox_size = sizeof(*bbox);
> > +
> > +bbox = (BoundingBox *)(header + 1);
>
> This does not guarantee proper alignment. You could use a flexible
> array member for that.
> >>>
> >>> The memory layout of frame->private_ref->data is:
> >>> sizeof(*header) + sizeof(*bbox) + sizeof(*bbox) + ...
> >>>
> >>> I think 'header + 1' goes correctly to the first bbox. thanks.
> >>>
> >>
> >> header + 1 points to the position where another BoundingBoxHeader
> >> would be if header were an array of BoundingBoxHeaders (i.e. it
> >> points
> >> sizeof(BoundingBoxHeader) bytes after header). So this guarantees
> >> that there is no overlap between your header and your actual boxes,
> >> but this does not guarantee proper alignment. This will be a problem
> >> on platforms where int is 64bit and requires eight byte alignment
> >> (unlikely) or if you add something that requires alignment of eight
> >> bytes (like a 64bit integer or a pointer on a 64bit
> >> system) to BoundingBox.
> >
> > got the point, thanks. Will add 'BoundingBox bboxes[0]' at the end of struct
> BoundingBoxHe
Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect for object detection
Guo, Yejun:
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Andreas Rheinhardt
>> Sent: 2021年3月1日 20:13
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect
>> for object detection
>>
>> Guo, Yejun:
>>>
>>>
-Original Message-
From: ffmpeg-devel On Behalf Of
Andreas Rheinhardt
Sent: 2021年3月1日 16:31
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter
dnn_detect for object detection
Guo, Yejun:
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Andreas Rheinhardt
>> Sent: 2021年3月1日 12:50
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter
>> dnn_detect for object detection
>>
>> Guo, Yejun:
>>> Signed-off-by: Guo, Yejun
>>> ---
>>> configure | 1 +
>>> doc/filters.texi | 40 +++
>>> libavfilter/Makefile | 1 +
>>> libavfilter/allfilters.c | 1 +
>>> libavfilter/dnn/dnn_backend_openvino.c | 12 +
>>> libavfilter/dnn_filter_common.c| 7 +
>>> libavfilter/dnn_filter_common.h| 1 +
>>> libavfilter/dnn_interface.h| 6 +-
>>> libavfilter/vf_dnn_detect.c| 462
>> +
>>> 9 files changed, 529 insertions(+), 2 deletions(-) create mode
>
>>> b/libavfilter/dnn_interface.h index d3a0c58a61..90a08129f4 100644
>>> --- a/libavfilter/dnn_interface.h
>>> +++ b/libavfilter/dnn_interface.h
>>> @@ -63,6 +63,8 @@ typedef struct DNNData{
>>> DNNColorOrder order;
>>> } DNNData;
>>>
>>> +typedef int (*PRE_POST_PROC)(AVFrame *frame, DNNData *model,
>>> +AVFilterContext *filter_ctx);
>>
>> Why uppercase? It is a typedef, not a macro.
>
> will change to CamelCase, thanks.
>
>>
>>> +
>>> typedef struct DNNModel{
>>> // Stores model that can be different for different backends.
>>> void *model;
>>> @@ -80,10 +82,10 @@ typedef struct DNNModel{
>>> const char *output_name, int
>> *output_width, int *output_height);
>>> // set the pre process to transfer data from AVFrame to DNNData
>>> // the default implementation within DNN is used if it is not
>>> provided
>> by the filter
>>> -int (*pre_proc)(AVFrame *frame_in, DNNData *model_input,
>> AVFilterContext *filter_ctx);
>>> +PRE_POST_PROC pre_proc;
>>> // set the post process to transfer data from DNNData to
>> AVFrame
>>> // the default implementation within DNN is used if it is not
>>> provided
>> by the filter
>>> -int (*post_proc)(AVFrame *frame_out, DNNData *model_output,
>> AVFilterContext *filter_ctx);
>>> +PRE_POST_PROC post_proc;
>>
>> Spurious change.
>
> sorry, not quite understand this comment. It is used for code refine.
> Maybe I need to let it in a separate patch.
>
>>
>>> } DNNModel;
>>>
>>> +
>>> +frame->private_ref = av_buffer_alloc(sizeof(*header) +
>>> + sizeof(*bbox) *
>> nb_bbox);
>>> +if (!frame->private_ref) {
>>> +av_log(filter_ctx, AV_LOG_ERROR, "failed to allocate
>>> + buffer for %d
>> bboxes\n", nb_bbox);
>>> +return AVERROR(ENOMEM);;
>>
>> Double ;
>
> thanks, will remove it.
>
>>
>>> +}
>>> +
>>> +header = (BoundingBoxHeader *)frame->private_ref->data;
>>> +strncpy(header->source, ctx->dnnctx.model_filename,
>> sizeof(header->source));
>>> +header->source[sizeof(header->source) - 1] = '\0';
>>> +header->bbox_size = sizeof(*bbox);
>>> +
>>> +bbox = (BoundingBox *)(header + 1);
>>
>> This does not guarantee proper alignment. You could use a flexible
>> array member for that.
>
> The memory layout of frame->private_ref->data is:
> sizeof(*header) + sizeof(*bbox) + sizeof(*bbox) + ...
>
> I think 'header + 1' goes correctly to the first bbox. thanks.
>
header + 1 points to the position where another BoundingBoxHeader
would be if header were an array of BoundingBoxHeaders (i.e. it
points
sizeof(BoundingBoxHeader) bytes after header). So this guarantees
that there is no overlap between your header and your actual boxes,
but this does not guarantee proper alignment. This will be a problem
on platforms where int is 64bit and requires eight byte alignment
(unlikely) or if you add something that requires alignment of eight
bytes (like a 64bit integer or a pointer on a 64bit
system) to BoundingBox.
>>>
>>> got the point, thanks. Will add 'BoundingBox bboxes[0]' at the end
Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect for object detection
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: 2021年3月1日 20:24
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect
> for object detection
>
> Guo, Yejun:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel On Behalf Of
> >> Andreas Rheinhardt
> >> Sent: 2021年3月1日 20:13
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter
> >> dnn_detect
> >> for object detection
> >>
> >> Guo, Yejun:
> >>>
> >>>
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: 2021年3月1日 16:31
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter
> dnn_detect for object detection
>
> Guo, Yejun:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel On Behalf Of
> >> Andreas Rheinhardt
> >> Sent: 2021年3月1日 12:50
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter
> >> dnn_detect for object detection
> >>
> >> Guo, Yejun:
> >>> Signed-off-by: Guo, Yejun
> >>> ---
> >>> configure | 1 +
> >>> doc/filters.texi | 40 +++
> >>> libavfilter/Makefile | 1 +
> >>> libavfilter/allfilters.c | 1 +
> >>> libavfilter/dnn/dnn_backend_openvino.c | 12 +
> >>> libavfilter/dnn_filter_common.c| 7 +
> >>> libavfilter/dnn_filter_common.h| 1 +
> >>> libavfilter/dnn_interface.h| 6 +-
> >>> libavfilter/vf_dnn_detect.c| 462
> >> +
> >>> 9 files changed, 529 insertions(+), 2 deletions(-) create mode
> >
> >>> b/libavfilter/dnn_interface.h index d3a0c58a61..90a08129f4 100644
> >>> --- a/libavfilter/dnn_interface.h
> >>> +++ b/libavfilter/dnn_interface.h
> >>> @@ -63,6 +63,8 @@ typedef struct DNNData{
> >>> DNNColorOrder order;
> >>> } DNNData;
> >>>
> >>> +typedef int (*PRE_POST_PROC)(AVFrame *frame, DNNData *model,
> >>> +AVFilterContext *filter_ctx);
> >>
> >> Why uppercase? It is a typedef, not a macro.
> >
> > will change to CamelCase, thanks.
> >
> >>
> >>> +
> >>> typedef struct DNNModel{
> >>> // Stores model that can be different for different backends.
> >>> void *model;
> >>> @@ -80,10 +82,10 @@ typedef struct DNNModel{
> >>> const char *output_name, int
> >> *output_width, int *output_height);
> >>> // set the pre process to transfer data from AVFrame to
> DNNData
> >>> // the default implementation within DNN is used if it is not
> >>> provided
> >> by the filter
> >>> -int (*pre_proc)(AVFrame *frame_in, DNNData *model_input,
> >> AVFilterContext *filter_ctx);
> >>> +PRE_POST_PROC pre_proc;
> >>> // set the post process to transfer data from DNNData to
> >> AVFrame
> >>> // the default implementation within DNN is used if it is not
> >>> provided
> >> by the filter
> >>> -int (*post_proc)(AVFrame *frame_out, DNNData
> *model_output,
> >> AVFilterContext *filter_ctx);
> >>> +PRE_POST_PROC post_proc;
> >>
> >> Spurious change.
> >
> > sorry, not quite understand this comment. It is used for code refine.
> > Maybe I need to let it in a separate patch.
> >
> >>
> >>> } DNNModel;
> >>>
> >>> +
> >>> +frame->private_ref = av_buffer_alloc(sizeof(*header) +
> >>> + sizeof(*bbox) *
> >> nb_bbox);
> >>> +if (!frame->private_ref) {
> >>> +av_log(filter_ctx, AV_LOG_ERROR, "failed to allocate
> >>> + buffer for %d
> >> bboxes\n", nb_bbox);
> >>> +return AVERROR(ENOMEM);;
> >>
> >> Double ;
> >
> > thanks, will remove it.
> >
> >>
> >>> +}
> >>> +
> >>> +header = (BoundingBoxHeader *)frame->private_ref->data;
> >>> +strncpy(header->source, ctx->dnnctx.model_filename,
> >> sizeof(header->source));
> >>> +header->source[sizeof(header->source) - 1] = '\0';
> >>> +header->bbox_size = sizeof(*bbox);
> >>> +
> >>> +bbox = (BoundingBox *)(header + 1);
> >>
> >> This does not guarantee proper alignment. You could use a flexible
> >> array member for that.
> >
> > The memory layout of frame->private_ref->data is:
> > sizeof(*header) + sizeof(*bbox) + sizeof(*bbox) + ...
> >
> > I think 'header + 1' goes correctly to the first bbox. thanks.
> >
>
> header + 1 points to the position where another BoundingBoxHeader
> would be if header were an array of BoundingBoxHeaders (i.e. it
> points
>
Re: [FFmpeg-devel] [PATCH] lavc/alsdec: Add NEON optimizations
Hi Thilo,
On Sun, 28 Feb 2021, Thilo Borgmann wrote:
it's my first attempt to do some assembly, it might still includes some dont's
of the asm world...
Tested with gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Speed-wise, it sees a drop for small prediction orders until around 10 or 11.
Well, the maximum prediction order is 1023.
I therefore checked with the "real-world" samples from the fate-suite, which
suggests low prediction orders are non-dominant:
pred_order = {7..17}, gain: 23%
als_reconstruct_all_c: 26645.2
als_reconstruct_all_neon: 20635.2
This is the combination that the patch actually tests by default, if I
read the code correctly - right?
You didn't write what CPU you tested this on - do note that the actual
peformance of the assembly is pretty heavily dependent on the CPU.
I get roughly similar numbers if I build with GCC:
Cortex A53 A72 A73
als_reconstruct_all_c: 107708.2 44044.5 57427.7
als_reconstruct_all_neon: 78895.7 38464.7 34065.5
However - if I build with Clang, where vectorization isn't disabled by
configure, the C code beats the handwritten assembly:
Cortex A53
als_reconstruct_all_c:69145.7
als_reconstruct_all_neon: 78895.7
Even if I only test order 17, the C code still is faster. So clearly we
can do better - if nothing else, we could copy the assembly code that
Clang outputs :-)
First a couple technical details about the patch...
new file mode 100644
index 00..130b1a615e
--- /dev/null
+++ b/libavcodec/aarch64/alsdsp_init_aarch64.c
@@ -0,0 +1,35 @@
+
+#include "config.h"
+
+#include "libavutil/aarch64/cpu.h"
+#include "libavcodec/alsdsp.h"
+
+void ff_alsdsp_reconstruct_all_neon(int32_t *samples, int32_t *samples_end,
int32_t *coeffs, unsigned int opt_order);
Nit: Long line?
diff --git a/libavcodec/aarch64/alsdsp_neon.S b/libavcodec/aarch64/alsdsp_neon.S
new file mode 100644
index 00..fe95eaf843
--- /dev/null
+++ b/libavcodec/aarch64/alsdsp_neon.S
@@ -0,0 +1,155 @@
+
+#include "libavutil/aarch64/asm.S"
+#include "neon.S"
+
+//void ff_alsdsp_reconstruct_all_neon(int32_t *samples, int32_t *samples_end,
int32_t *coeffs, unsigned int opt_order);
+// x0: int32_t *samples
+// x1: int32_t *samples_end
+// x2: int32_t *coeffs
+// w3: unsigned int opt_order
+function ff_alsdsp_reconstruct_all_neon, export = 1
Write the named macro argument without extra spaces, i.e. "export=1".
Otherwise this breaks building with gas-preprocessor
+sub sp, sp, #128
Please align instructions and operands in the same way as in other sources.
Also for the operands, I'd recommend aligning the columns according to
the max width for each operand. E.g. like this:
lsl x3, x3, #32
neg x3, x3, lsr #32
lsl x10, x3, #2
That way the columns line up nicely regardless of which registers are
used. And for vector register operands, align them so that the max
sized register (v16.16b) would fit. For things that deviate from the
regular form (e.g. loads/stores etc) just align things so it looks
pretty.
+st1 {v8.4s - v11.4s}, [sp], #64
+st1 {v12.4s - v15.4s}, [sp], #64
You aren't using registers v16-v31 at all. You could use those and
avoid using v8-v15, to avoid needing to back up and restore these
registers.
+// avoid 32-bit clubber from register
Nit: The common spelling is "clobber"
+lsl x3, x3, #32
+neg x3, x3, lsr #32
There's normally no need to do such manual cleanup of the
argument that might have junk in the upper half. If you
really need to, you can fix it by doing "uxtl x3, w3" or
"sxtl x3, w3", but in most cases you can avoid it by just
making sure to refer to the register as w3 instead of x3
the first time you use it. If you do a write to a register
in the form wN instead of xN, it will implicitly clear the
upper half, so you could use the xN form after that. That
doesn't work quite as easily here when you want to have it
fully negated though.
But e.g. with something like this, it works just fine:
neg w3, w3
lsl w10, w3, #2
// Sign extension when used with a 64 bit register
add x4, x0, w10, sxtw
add x5, x2, w10, sxtw
mov w6, w3
// All other uses use w6 instead of x6 etc.
+// x10 counts the bytes left to read, set to 4 * -opt_order
+lsl x10, x3, #2
+
+// loop x0 .. x1
+1: cmp x0, x1
+b.eq4f
+
+// samples - opt_order, coeffs - opt_order
+add x4, x0, x10
+add x5, x2, x10
+// reset local counter: count -opt_order .. 0
+mov x6, x3
+
+// reset local acc
+moviv8.2d, #0
+moviv9.2d, #0
+moviv10.2d, #0
+moviv11.2d, #0
+moviv12.2d, #0
+moviv13.2d, #0
+moviv14.2d, #0
+moviv15.2d, #0
+
+// loop over 16 samples while >= 16 more to read
+adds
[FFmpeg-devel] [PATCH] libavformat/movenc: Support encryption of H265 stream in AnnexB format
Add an ability to accept H265 AnnexB stream at encryption
similar to how its done for H264 AnnexB stream.
Steps to test:
1. Create h265 test files - mp4 and h265 AnnexB streams:
ffmpeg -f lavfi -i testsrc=duration=10:size=640x480:rate=30 -c:v hevc
input_h265.mp4
ffmpeg -f lavfi -i testsrc=duration=10:size=640x480:rate=30 -c:v hevc -bsf:v
hevc_mp4toannexb input_h265.h265
2. Encrypt and decrypt files. Put appropriate input file name here:
input_h265.mp4 or input_h265.h265
ffmpeg -i input_h265.h265 -vcodec copy -acodec copy -encryption_scheme
cenc-aes-ctr \
-encryption_key -encryption_kid
\
encrypted_h265.mp4
ffplay -i encrypted_h265.mp4 -decryption_key
Signed-off-by: Vadym Bezdushnyi
---
libavformat/movenc.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 545b0885ae..0433968cd2 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -5685,7 +5685,15 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket
*pkt)
return ret;
avio_write(pb, reformatted_data, size);
} else {
-size = ff_hevc_annexb2mp4(pb, pkt->data, pkt->size, 0, NULL);
+if (trk->cenc.aes_ctr) {
+size = ff_mov_cenc_avc_parse_nal_units(&trk->cenc, pb,
pkt->data, size);
+if (size < 0) {
+ret = size;
+goto err;
+}
+} else {
+size = ff_hevc_annexb2mp4(pb, pkt->data, pkt->size, 0, NULL);
+}
}
} else if (par->codec_id == AV_CODEC_ID_AV1) {
if (trk->hint_track >= 0 && trk->hint_track < mov->nb_streams) {
@@ -5727,6 +5735,9 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
if (par->codec_id == AV_CODEC_ID_H264 && par->extradata_size > 4) {
int nal_size_length = (par->extradata[4] & 0x3) + 1;
ret = ff_mov_cenc_avc_write_nal_units(s, &trk->cenc,
nal_size_length, pb, pkt->data, size);
+} else if(par->codec_id == AV_CODEC_ID_HEVC && par->extradata_size
> 21) {
+int nal_size_length = (par->extradata[21] & 0x3) + 1;
+ret = ff_mov_cenc_avc_write_nal_units(s, &trk->cenc,
nal_size_length, pb, pkt->data, size);
} else {
ret = ff_mov_cenc_write_packet(&trk->cenc, pb, pkt->data,
size);
}
@@ -6711,7 +6722,8 @@ static int mov_init(AVFormatContext *s)
if (mov->encryption_scheme == MOV_ENC_CENC_AES_CTR) {
ret = ff_mov_cenc_init(&track->cenc, mov->encryption_key,
-track->par->codec_id == AV_CODEC_ID_H264, s->flags &
AVFMT_FLAG_BITEXACT);
+(track->par->codec_id == AV_CODEC_ID_H264 ||
track->par->codec_id == AV_CODEC_ID_HEVC),
+s->flags & AVFMT_FLAG_BITEXACT);
if (ret)
return ret;
}
--
2.30.0
___
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] [PATCH V4 1/4] libavfilter/bbox.h: add BoundingBoxHeader and BoundingBox
They will be used for filters such as detect and classify.
Signed-off-by: Guo, Yejun
---
libavfilter/bbox.h | 53 ++
1 file changed, 53 insertions(+)
diff --git a/libavfilter/bbox.h b/libavfilter/bbox.h
index 116158d59e..ead14417cc 100644
--- a/libavfilter/bbox.h
+++ b/libavfilter/bbox.h
@@ -22,6 +22,59 @@
#define AVFILTER_BBOX_H
#include
+#include "libavutil/rational.h"
+
+typedef struct BoundingBox {
+/**
+ * Distance in pixels from the top edge of the frame to top
+ * and bottom, and from the left edge of the frame to left and
+ * right, defining the bounding box.
+ */
+int top;
+int left;
+int bottom;
+int right;
+
+#define BBOX_LABEL_NAME_MAX_LENGTH 32
+
+/**
+ * Detect result with confidence
+ */
+char detect_label[BBOX_LABEL_NAME_MAX_LENGTH+1];
+AVRational detect_confidence;
+
+/**
+ * At most 4 classifications based on the detected bounding box.
+ * For example, we can get max 4 different attributes with 4 different
+ * DNN models on one bounding box.
+ * classify_count is zero if no classification.
+ */
+#define AV_NUM_BBOX_CLASSIFY 4
+uint32_t classify_count;
+char classify_labels[AV_NUM_BBOX_CLASSIFY][BBOX_LABEL_NAME_MAX_LENGTH+1];
+AVRational classify_confidences[AV_NUM_BBOX_CLASSIFY];
+} BoundingBox;
+
+typedef struct BoundingBoxHeader {
+/**
+ * Information about how the bounding box is generated.
+ * for example, the DNN model name.
+ */
+char source[128];
+
+/**
+ * Must be set to the size of BoundingBox (that is,
+ * sizeof(BoundingBox)).
+ */
+uint32_t bbox_size;
+
+/**
+ * Pointer to the array of BoundingBox.
+ * Add one element here is to meet the possible
+ * alignment requirement of bboxes.
+ */
+BoundingBox bboxes[1];
+} BoundingBoxHeader;
typedef struct FFBoundingBox {
int x1, x2, y1, y2;
--
2.17.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] [PATCH V4 2/4] libavfilter/buffersink.c: unref private_ref when frame leaves libavfilter
private_ref is for internal use by a single libav* library.
It has to be NULL when ownership of the frame leaves the respective library,
buffersink is the last step when the frame leaves libavfilter, so add unref
here.
Signed-off-by: Guo, Yejun
---
libavfilter/buffersink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
index 58848941d4..837a6e9e82 100644
--- a/libavfilter/buffersink.c
+++ b/libavfilter/buffersink.c
@@ -98,6 +98,7 @@ static int return_or_keep_frame(BufferSinkContext *buf,
AVFrame *out, AVFrame *i
} else {
av_assert1(out);
buf->peeked_frame = NULL;
+av_buffer_unref(&in->private_ref);
av_frame_move_ref(out, in);
av_frame_free(&in);
return 0;
--
2.17.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] [PATCH V4 3/4] libavfilter/dnn: add ff_dnn_set_proc to set pre/post proc
Signed-off-by: Guo, Yejun
---
libavfilter/dnn_filter_common.c | 7 +++
libavfilter/dnn_filter_common.h | 1 +
libavfilter/dnn_interface.h | 6 --
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/libavfilter/dnn_filter_common.c b/libavfilter/dnn_filter_common.c
index 413adba406..2a1d045be1 100644
--- a/libavfilter/dnn_filter_common.c
+++ b/libavfilter/dnn_filter_common.c
@@ -64,6 +64,13 @@ int ff_dnn_init(DnnContext *ctx, DNNFunctionType func_type,
AVFilterContext *fil
return 0;
}
+int ff_dnn_set_proc(DnnContext *ctx, PrePostProc pre_proc, PrePostProc
post_proc)
+{
+ctx->model->pre_proc = pre_proc;
+ctx->model->post_proc = post_proc;
+return 0;
+}
+
DNNReturnType ff_dnn_get_input(DnnContext *ctx, DNNData *input)
{
return ctx->model->get_input(ctx->model->model, input,
ctx->model_inputname);
diff --git a/libavfilter/dnn_filter_common.h b/libavfilter/dnn_filter_common.h
index 79c4d3efe3..4810c7baaf 100644
--- a/libavfilter/dnn_filter_common.h
+++ b/libavfilter/dnn_filter_common.h
@@ -48,6 +48,7 @@ typedef struct DnnContext {
int ff_dnn_init(DnnContext *ctx, DNNFunctionType func_type, AVFilterContext
*filter_ctx);
+int ff_dnn_set_proc(DnnContext *ctx, PrePostProc pre_proc, PrePostProc
post_proc);
DNNReturnType ff_dnn_get_input(DnnContext *ctx, DNNData *input);
DNNReturnType ff_dnn_get_output(DnnContext *ctx, int input_width, int
input_height, int *output_width, int *output_height);
DNNReturnType ff_dnn_execute_model(DnnContext *ctx, AVFrame *in_frame, AVFrame
*out_frame);
diff --git a/libavfilter/dnn_interface.h b/libavfilter/dnn_interface.h
index d3a0c58a61..c92434ee55 100644
--- a/libavfilter/dnn_interface.h
+++ b/libavfilter/dnn_interface.h
@@ -63,6 +63,8 @@ typedef struct DNNData{
DNNColorOrder order;
} DNNData;
+typedef int (*PrePostProc)(AVFrame *frame, DNNData *model, AVFilterContext
*filter_ctx);
+
typedef struct DNNModel{
// Stores model that can be different for different backends.
void *model;
@@ -80,10 +82,10 @@ typedef struct DNNModel{
const char *output_name, int *output_width,
int *output_height);
// set the pre process to transfer data from AVFrame to DNNData
// the default implementation within DNN is used if it is not provided by
the filter
-int (*pre_proc)(AVFrame *frame_in, DNNData *model_input, AVFilterContext
*filter_ctx);
+PrePostProc pre_proc;
// set the post process to transfer data from DNNData to AVFrame
// the default implementation within DNN is used if it is not provided by
the filter
-int (*post_proc)(AVFrame *frame_out, DNNData *model_output,
AVFilterContext *filter_ctx);
+PrePostProc post_proc;
} DNNModel;
// Stores pointers to functions for loading, executing, freeing DNN models for
one of the backends.
--
2.17.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] [PATCH V4 4/4] libavfilter: add filter dnn_detect for object detection
Below are the example steps to do object detection:
1. download and install l_openvino_toolkit_p_2021.1.110.tgz from
https://software.intel.com/content/www/us/en/develop/tools/openvino-toolkit/download.html
or, we can get source code (tag 2021.1), build and install.
2. export LD_LIBRARY_PATH with openvino settings, for example:
.../deployment_tools/inference_engine/lib/intel64/:.../deployment_tools/inference_engine/external/tbb/lib/
3. rebuild ffmpeg from source code with configure option:
--enable-libopenvino
--extra-cflags='-I.../deployment_tools/inference_engine/include/'
--extra-ldflags='-L.../deployment_tools/inference_engine/lib/intel64'
4. download model files and test image
wget
https://github.com/guoyejun/ffmpeg_dnn/raw/main/models/openvino/2021.1/face-detection-adas-0001.bin
wget
https://github.com/guoyejun/ffmpeg_dnn/raw/main/models/openvino/2021.1/face-detection-adas-0001.xml
wget
https://github.com/guoyejun/ffmpeg_dnn/raw/main/models/openvino/2021.1/face-detection-adas-0001.label
wget https://github.com/guoyejun/ffmpeg_dnn/raw/main/images/cici.jpg
5. run ffmpeg with:
./ffmpeg -i cici.jpg -vf
dnn_detect=dnn_backend=openvino:model=face-detection-adas-0001.xml:input=data:output=detection_out:confidence=0.6:labels=face-detection-adas-0001.label
-f null -
We'll see the detect result as below:
[Parsed_dnn_detect_0 @ 0x56226644e540] frame->private_ref (bounding boxes):
[Parsed_dnn_detect_0 @ 0x56226644e540] source: face-detection-adas-0001.xml
[Parsed_dnn_detect_0 @ 0x56226644e540] index: 0, region: (1005, 813) -> (1086,
905), label: face, confidence: 1/1.
[Parsed_dnn_detect_0 @ 0x56226644e540] index: 1, region: (888, 839) -> (967,
926), label: face, confidence: 6917/1.
There are two faces detected with confidence 100% and 69.17%.
Signed-off-by: Guo, Yejun
---
will update vf_drawbox/text to visualize the bounding boxes,
and will also add tensorflow support next.
configure | 1 +
doc/filters.texi | 40 +++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/dnn/dnn_backend_openvino.c | 12 +
libavfilter/vf_dnn_detect.c| 463 +
6 files changed, 518 insertions(+)
create mode 100644 libavfilter/vf_dnn_detect.c
diff --git a/configure b/configure
index d11942fced..f28c2b27e5 100755
--- a/configure
+++ b/configure
@@ -3548,6 +3548,7 @@ derain_filter_select="dnn"
deshake_filter_select="pixelutils"
deshake_opencl_filter_deps="opencl"
dilation_opencl_filter_deps="opencl"
+dnn_detect_filter_select="dnn"
dnn_processing_filter_select="dnn"
drawtext_filter_deps="libfreetype"
drawtext_filter_suggest="libfontconfig libfribidi"
diff --git a/doc/filters.texi b/doc/filters.texi
index 426cb158da..55368c6f1b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10133,6 +10133,46 @@ ffmpeg -i INPUT -f lavfi -i
nullsrc=hd720,geq='r=128+80*(sin(sqrt((X-W/2)*(X-W/2
@end example
@end itemize
+@section dnn_detect
+
+Do object detection with deep neural networks.
+
+The filter accepts the following options:
+
+@table @option
+@item dnn_backend
+Specify which DNN backend to use for model loading and execution. This option
accepts
+only openvino now, tensorflow backends will be added.
+
+@item model
+Set path to model file specifying network architecture and its parameters.
+Note that different backends use different file formats.
+
+@item input
+Set the input name of the dnn network.
+
+@item output
+Set the output name of the dnn network.
+
+@item confidence
+Set the confidence threshold (default: 0.5).
+
+@item labels
+Set path to label file specifying the mapping between label id and name.
+Each label name is written in one line, tailing spaces and empty lines are
skipped.
+The first line is the name of label id 0 (usually it is 'background'),
+and the second line is the name of label id 1, etc.
+The label id is considered as name if the label file is not provided.
+
+@item backend_configs
+Set the configs to be passed into backend
+
+@item async
+use DNN async execution if set (default: set),
+roll back to sync execution if the backend does not support async.
+
+@end table
+
@anchor{dnn_processing}
@section dnn_processing
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 359ea7f903..b14c0ecdb9 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -245,6 +245,7 @@ OBJS-$(CONFIG_DILATION_FILTER) +=
vf_neighbor.o
OBJS-$(CONFIG_DILATION_OPENCL_FILTER)+= vf_neighbor_opencl.o opencl.o \
opencl/neighbor.o
OBJS-$(CONFIG_DISPLACE_FILTER) += vf_displace.o framesync.o
+OBJS-$(CONFIG_DNN_DETECT_FILTER) += vf_dnn_detect.o
OBJS-$(CONFIG_DNN_PROCESSING_FILTER) += vf_dnn_processing.o
OBJS-$(CONFIG_DOUBLEWEAVE_FILTER)+= vf_weave.o
OBJS-$(CONFIG_DRAWBOX_FILTER)+= vf_drawbox.o
diff --git a/li
Re: [FFmpeg-devel] [PATCH V4 2/4] libavfilter/buffersink.c: unref private_ref when frame leaves libavfilter
Guo, Yejun (12021-03-01): > private_ref is for internal use by a single libav* library. > It has to be NULL when ownership of the frame leaves the respective library, > > buffersink is the last step when the frame leaves libavfilter, so add unref > here. > > Signed-off-by: Guo, Yejun > --- > libavfilter/buffersink.c | 1 + > 1 file changed, 1 insertion(+) NAK. buffersink did not take ownership of that reference, therefore it does not own it and cannot unref it. If this change actually fixes something, i.e. if there is a ref at this point, then we need to find who put it there, because they are responsible for freeing it. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH 3/5] tests/api-flac-test: convert to new encoding/decoding API
Quoting James Almer (2021-02-26 19:59:57) > > LGTM. > > Also, FWIW, this is not flushing the encoder (It wasn't before this > patch either). For being an API test it's not exactly using it right, > but it doesn't really matter here since for FLAC, flushing the encoder > will return a side data only packet with an updated stream header info > and not any delayed/buffered packet, and this test only cares about > comparing the raw pcm audio pre encoding and post decoding. I agree that this tests makes a bit too many assumptions, but I didn't want to rewrite everything, since I'd like to actually get to the bump reasonably soon. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH 2/5] tests/api-flac-test: ensure the frame is writable before writing to it
Quoting James Almer (2021-02-24 15:01:03) > On 2/24/2021 7:03 AM, Anton Khirnov wrote: > > The encoder may keep a reference to frames that were sent to it, so the > > caller cannot modify them without checking first. > > --- > > tests/api/api-flac-test.c | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/tests/api/api-flac-test.c b/tests/api/api-flac-test.c > > index 3fea3258f3..7c96a4d99e 100644 > > --- a/tests/api/api-flac-test.c > > +++ b/tests/api/api-flac-test.c > > @@ -154,6 +154,10 @@ static int run_test(AVCodec *enc, AVCodec *dec, > > AVCodecContext *enc_ctx, > > enc_pkt.data = NULL; > > enc_pkt.size = 0; > > > > +result = av_frame_make_writable(in_frame); > > This is going to make a copy of the existing frame data, only for the > code below to completely replace it. It will also make copies (not > references) of side data, if any. > Maybe instead unref it, set nb_samples, format and channel_layout again, > then call av_frame_get_buffer() (Factoring the existing relevant code > into its own function). > > LGTM either way. Watches pelcome. I'd rather not spend more effort on this code than strictly necessary. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect for object detection
Guo, Yejun:
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Andreas Rheinhardt
>> Sent: 2021年3月1日 20:24
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect
>> for object detection
>>
>> Guo, Yejun:
>>>
>>>
-Original Message-
From: ffmpeg-devel On Behalf Of
Andreas Rheinhardt
Sent: 2021年3月1日 20:13
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter
dnn_detect
for object detection
Guo, Yejun:
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Andreas Rheinhardt
>> Sent: 2021年3月1日 16:31
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter
>> dnn_detect for object detection
>>
>> Guo, Yejun:
>>>
>>>
-Original Message-
From: ffmpeg-devel On Behalf Of
Andreas Rheinhardt
Sent: 2021年3月1日 12:50
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter
dnn_detect for object detection
Guo, Yejun:
> Signed-off-by: Guo, Yejun
> ---
> configure | 1 +
> doc/filters.texi | 40 +++
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/dnn/dnn_backend_openvino.c | 12 +
> libavfilter/dnn_filter_common.c| 7 +
> libavfilter/dnn_filter_common.h| 1 +
> libavfilter/dnn_interface.h| 6 +-
> libavfilter/vf_dnn_detect.c| 462
+
> 9 files changed, 529 insertions(+), 2 deletions(-) create mode
>>>
> b/libavfilter/dnn_interface.h index d3a0c58a61..90a08129f4 100644
> --- a/libavfilter/dnn_interface.h
> +++ b/libavfilter/dnn_interface.h
> @@ -63,6 +63,8 @@ typedef struct DNNData{
> DNNColorOrder order;
> } DNNData;
>
> +typedef int (*PRE_POST_PROC)(AVFrame *frame, DNNData *model,
> +AVFilterContext *filter_ctx);
Why uppercase? It is a typedef, not a macro.
>>>
>>> will change to CamelCase, thanks.
>>>
> +
> typedef struct DNNModel{
> // Stores model that can be different for different backends.
> void *model;
> @@ -80,10 +82,10 @@ typedef struct DNNModel{
> const char *output_name, int
*output_width, int *output_height);
> // set the pre process to transfer data from AVFrame to
>> DNNData
> // the default implementation within DNN is used if it is not
> provided
by the filter
> -int (*pre_proc)(AVFrame *frame_in, DNNData *model_input,
AVFilterContext *filter_ctx);
> +PRE_POST_PROC pre_proc;
> // set the post process to transfer data from DNNData to
AVFrame
> // the default implementation within DNN is used if it is not
> provided
by the filter
> -int (*post_proc)(AVFrame *frame_out, DNNData
>> *model_output,
AVFilterContext *filter_ctx);
> +PRE_POST_PROC post_proc;
Spurious change.
>>>
>>> sorry, not quite understand this comment. It is used for code refine.
>>> Maybe I need to let it in a separate patch.
>>>
> } DNNModel;
>
> +
> +frame->private_ref = av_buffer_alloc(sizeof(*header) +
> + sizeof(*bbox) *
nb_bbox);
> +if (!frame->private_ref) {
> +av_log(filter_ctx, AV_LOG_ERROR, "failed to allocate
> + buffer for %d
bboxes\n", nb_bbox);
> +return AVERROR(ENOMEM);;
Double ;
>>>
>>> thanks, will remove it.
>>>
> +}
> +
> +header = (BoundingBoxHeader *)frame->private_ref->data;
> +strncpy(header->source, ctx->dnnctx.model_filename,
sizeof(header->source));
> +header->source[sizeof(header->source) - 1] = '\0';
> +header->bbox_size = sizeof(*bbox);
> +
> +bbox = (BoundingBox *)(header + 1);
This does not guarantee proper alignment. You could use a flexible
array member for that.
>>>
>>> The memory layout of frame->private_ref->data is:
>>> sizeof(*header) + sizeof(*bbox) + sizeof(*bbox) + ...
>>>
>>> I think 'header + 1' goes correctly to the first bbox. thanks.
>>>
>>
>> header + 1 points to the position where another BoundingBoxHeader
>> would be if header were an array of BoundingBoxHeaders (i.
Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect for object detection
Andreas Rheinhardt (12021-03-01): > > thanks for the info, this struct is expected to be in side_data in the > > future, > > I'll add 'bboxes[1]' in it, and allocate sizeof(*header) + (nb_bbox - 1) * > > sizeof(*bbox). > > Notice that in this case it is undefined behaviour to access any of the > boxes outside of BoundingBoxHeader (i.e. when using header->bboxes[i], > the compiler is allowed to infer that i == 0 as all other cases would be > undefined behaviour). Are you sure about it? Can you quote the standard? Anyway, even if this is true, we can work around it with an extra pointer or a cast, possibly wrapped in a macro. Saving a few dynamic allocation is well worth the unusual code; we should shoo away the people who oppose to go work on GStreamer or something. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH V4 2/4] libavfilter/buffersink.c: unref private_ref when frame leaves libavfilter
> -Original Message- > From: Nicolas George > Sent: 2021年3月1日 21:36 > To: FFmpeg development discussions and patches > Cc: Guo, Yejun > Subject: Re: [FFmpeg-devel] [PATCH V4 2/4] libavfilter/buffersink.c: unref > private_ref when frame leaves libavfilter > > Guo, Yejun (12021-03-01): > > private_ref is for internal use by a single libav* library. > > It has to be NULL when ownership of the frame leaves the respective > > library, > > > > buffersink is the last step when the frame leaves libavfilter, so add unref > > here. > > > > Signed-off-by: Guo, Yejun > > --- > > libavfilter/buffersink.c | 1 + > > 1 file changed, 1 insertion(+) > > NAK. buffersink did not take ownership of that reference, therefore it does > not > own it and cannot unref it. > > If this change actually fixes something, i.e. if there is a ref at this > point, then we > need to find who put it there, because they are responsible for freeing it. > Thanks for the review, as we talked at http://ffmpeg.org/pipermail/ffmpeg-devel/2021-February/276728.html, private_ref is allocated in filter vf_dnn_detect.c for detected results, and other filters such as vf_drawbox/text (in plan) will read it. Since private_ref is for a single libav* library, it has to be NULL when it leaves libavfilter, so I have to unref it at the last step of libavfilter, that's in buffersink. Any other suggestion? thanks. ___ 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".
Re: [FFmpeg-devel] [PATCH 2/5] tests/api-flac-test: ensure the frame is writable before writing to it
On 3/1/2021 10:43 AM, Anton Khirnov wrote: Quoting James Almer (2021-02-24 15:01:03) On 2/24/2021 7:03 AM, Anton Khirnov wrote: The encoder may keep a reference to frames that were sent to it, so the caller cannot modify them without checking first. --- tests/api/api-flac-test.c | 4 1 file changed, 4 insertions(+) diff --git a/tests/api/api-flac-test.c b/tests/api/api-flac-test.c index 3fea3258f3..7c96a4d99e 100644 --- a/tests/api/api-flac-test.c +++ b/tests/api/api-flac-test.c @@ -154,6 +154,10 @@ static int run_test(AVCodec *enc, AVCodec *dec, AVCodecContext *enc_ctx, enc_pkt.data = NULL; enc_pkt.size = 0; +result = av_frame_make_writable(in_frame); This is going to make a copy of the existing frame data, only for the code below to completely replace it. It will also make copies (not references) of side data, if any. Maybe instead unref it, set nb_samples, format and channel_layout again, then call av_frame_get_buffer() (Factoring the existing relevant code into its own function). LGTM either way. Watches pelcome. I'd rather not spend more effort on this code than strictly necessary. Sure, apply this and i'll change it later. ___ 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".
Re: [FFmpeg-devel] [PATCH V4 2/4] libavfilter/buffersink.c: unref private_ref when frame leaves libavfilter
Guo, Yejun (12021-03-01): > Thanks for the review, as we talked at > http://ffmpeg.org/pipermail/ffmpeg-devel/2021-February/276728.html, > private_ref is allocated in filter vf_dnn_detect.c for detected results, and > other > filters such as vf_drawbox/text (in plan) will read it. > > Since private_ref is for a single libav* library, it has to be NULL when it > leaves libavfilter, > so I have to unref it at the last step of libavfilter, that's in buffersink. > Any other suggestion? thanks. Sorry, I did not have this reply in my archives, I somehow missed it. What this is basically saying is that private_ref in libavfilter will be appropriated for the only use of bounding boxes. I think it is a significantly worse solution than using side data as you originally considered. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH] [RFC][v4] Tech Resolution Process
Hello, If you are a voter part of the FFmpeg General Assembly, you should have received an email to allow you to vote on this. Best, On Thu, 11 Feb 2021, at 11:46, Jean-Baptiste Kempf wrote: > --- > doc/dev_community/resolution_process.md | 91 + > 1 file changed, 91 insertions(+) > create mode 100644 doc/dev_community/resolution_process.md > > diff --git a/doc/dev_community/resolution_process.md > b/doc/dev_community/resolution_process.md > new file mode 100644 > index 00..4ed0b63c43 > --- /dev/null > +++ b/doc/dev_community/resolution_process.md > @@ -0,0 +1,91 @@ > +# Technical Committee > + > +_This document only makes sense with the rules from [the community > document](community)_. > + > +The Technical Committee (**TC**) is here to arbitrate and make > decisions when > +technical conflicts occur in the project. > + > +The TC main role is to resolve technical conflicts. > +It is therefore not a technical steering committee, but it is > understood that > +some decisions might impact the future of the project. > + > +# Process > + > +## Seizing > + > +The TC can take possession of any technical matter that it sees fit. > + > +To involve the TC in a matter, email tc@ or CC them on an ongoing > discussion. > + > +As members of TC are developers, they also can email tc@ to raise an > issue. > + > +## Announcement > + > +The TC, once seized, must announce itself on the main mailing list, > with a _[TC]_ tag. > + > +The TC has 2 modes of operation: a RFC one and an internal one. > + > +If the TC thinks it needs the input from the larger community, the TC > can call > +for a RFC. Else, it can decide by itself. > + > +If the disagreement involves a member of the TC, that member should > recuse > +themselves from the decision. > + > +The decision to use a RFC process or an internal discussion is a > discretionary > +decision of the TC. > + > +The TC can also reject a seizure for a few reasons such as: > +the matter was not discussed enough previously; it lacks expertise to > reach a > +beneficial decision on the matter; or the matter is too trivial. > + > +### RFC call > + > +In the RFC mode, one person from the TC posts on the mailing list the > +technical question and will request input from the community. > + > +The mail will have the following specification: > +* a precise title > +* a specific tag [TC RFC] > +* a top-level email > +* contain a precise question that does not exceed 100 words and that > is answerable by developers > +* may have an extra description, or a link to a previous discussion, > if deemed necessary, > +* contain a precise end date for the answers. > + > +The answers from the community must be on the main mailing list and > must have > +the following specification: > +* keep the tag and the title unchanged > +* limited to 400 words > +* a first-level, answering directly to the main email > +* answering to the question. > + > +Further replies to answers are permitted, as long as they conform to > the > +community standards of politeness, they are limited to 100 words, and > are not > +nested more than once. (max-depth=2) > + > +After the end-date, mails on the thread will be ignored. > + > +Violations of those rules will be escalated through the Community > Committee. > + > +After all the emails are in, the TC has 96 hours to give its final > decision. > +Exceptionally, the TC can request an extra delay, that will be > notified on the > +mailing list. > + > +### Within TC > + > +In the internal case, the TC has 96 hours to give its final decision. > +Exceptionally, the TC can request an extra delay. > + > + > +## Decisions > + > +The decisions from the TC will be sent on the mailing list, with the > _[TC]_ tag. > + > +Internally, the TC should take decisions with a majority, or using > +ranked-choice voting. > + > +The decision from the TC should be published with a summary of the > reasons that > +lead to this decision. > + > +The decisions from the TC are final, until the matters are reopened > after > +no less than one year. > + > -- > 2.30.0 > > -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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] [PATCH] avutil/timecode: Avoid fps overflow
Fixes: Integer overflow and division by 0 Fixes: poc-202102-div.mov Found-by: 1vanChen of NSFOCUS Security Team Signed-off-by: Michael Niedermayer --- libavutil/timecode.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavutil/timecode.c b/libavutil/timecode.c index b1b504edbf..2fc3295e25 100644 --- a/libavutil/timecode.c +++ b/libavutil/timecode.c @@ -114,8 +114,8 @@ char *av_timecode_make_string(const AVTimecode *tc, char *buf, int framenum) } ff = framenum % fps; ss = framenum / fps% 60; -mm = framenum / (fps*60) % 60; -hh = framenum / (fps*3600); +mm = framenum / (fps*60LL) % 60; +hh = framenum / (fps*3600LL); if (tc->flags & AV_TIMECODE_FLAG_24HOURSMAX) hh = hh % 24; snprintf(buf, AV_TIMECODE_STR_SIZE, "%s%02d:%02d:%02d%c%02d", -- 2.17.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".
Re: [FFmpeg-devel] [PATCH V4 2/4] libavfilter/buffersink.c: unref private_ref when frame leaves libavfilter
Just use frame metadata. On Mon, Mar 1, 2021 at 3:24 PM Nicolas George wrote: > Guo, Yejun (12021-03-01): > > Thanks for the review, as we talked at > http://ffmpeg.org/pipermail/ffmpeg-devel/2021-February/276728.html, > > private_ref is allocated in filter vf_dnn_detect.c for detected results, > and other > > filters such as vf_drawbox/text (in plan) will read it. > > > > Since private_ref is for a single libav* library, it has to be NULL when > it leaves libavfilter, > > so I have to unref it at the last step of libavfilter, that's in > buffersink. Any other suggestion? thanks. > > Sorry, I did not have this reply in my archives, I somehow missed it. > > What this is basically saying is that private_ref in libavfilter will be > appropriated for the only use of bounding boxes. I think it is a > significantly worse solution than using side data as you originally > considered. > > Regards, > > -- > Nicolas George > ___ > 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".
Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect for object detection
> -Original Message- > From: ffmpeg-devel On Behalf Of Nicolas > George > Sent: 2021年3月1日 21:57 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect > for object detection > > Andreas Rheinhardt (12021-03-01): > > > thanks for the info, this struct is expected to be in side_data in > > > the future, I'll add 'bboxes[1]' in it, and allocate sizeof(*header) + > > > (nb_bbox > - 1) * sizeof(*bbox). > > > > Notice that in this case it is undefined behaviour to access any of > > the boxes outside of BoundingBoxHeader (i.e. when using > > header->bboxes[i], the compiler is allowed to infer that i == 0 as all > > other cases would be undefined behaviour). > > Are you sure about it? Can you quote the standard? > > Anyway, even if this is true, we can work around it with an extra pointer or a > cast, possibly wrapped in a macro. Saving a few dynamic allocation is well > worth the unusual code; Hi, glad to hear there's a good solution, could you share a bit of code as an example, it would be nice if I could refine my code better when possible, thanks. ___ 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".
Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect for object detection
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: 2021年3月1日 21:50
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect
> for object detection
>
> Guo, Yejun:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel On Behalf Of
> >> Andreas Rheinhardt
> >> Sent: 2021年3月1日 20:24
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter
> >> dnn_detect for object detection
> >>
> >> Guo, Yejun:
> >>>
> >>>
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: 2021年3月1日 20:13
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter
> dnn_detect for object detection
>
> Guo, Yejun:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel On Behalf Of
> >> Andreas Rheinhardt
> >> Sent: 2021年3月1日 16:31
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add
> >> filter dnn_detect for object detection
> >>
> >> Guo, Yejun:
> >>>
> >>>
> -Original Message-
> From: ffmpeg-devel On Behalf
> Of Andreas Rheinhardt
> Sent: 2021年3月1日 12:50
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add
> filter dnn_detect for object detection
>
> Guo, Yejun:
> > Signed-off-by: Guo, Yejun
> > ---
> > configure | 1 +
> > doc/filters.texi | 40 +++
> > libavfilter/Makefile | 1 +
> > libavfilter/allfilters.c | 1 +
> > libavfilter/dnn/dnn_backend_openvino.c | 12 +
> > libavfilter/dnn_filter_common.c| 7 +
> > libavfilter/dnn_filter_common.h| 1 +
> > libavfilter/dnn_interface.h| 6 +-
> > libavfilter/vf_dnn_detect.c| 462
> +
> > 9 files changed, 529 insertions(+), 2 deletions(-) create
> > mode
> >>>
> > b/libavfilter/dnn_interface.h index d3a0c58a61..90a08129f4
> > 100644
> > --- a/libavfilter/dnn_interface.h
> > +++ b/libavfilter/dnn_interface.h
> > @@ -63,6 +63,8 @@ typedef struct DNNData{
> > DNNColorOrder order;
> > } DNNData;
> >
> > +typedef int (*PRE_POST_PROC)(AVFrame *frame, DNNData
> *model,
> > +AVFilterContext *filter_ctx);
>
> Why uppercase? It is a typedef, not a macro.
> >>>
> >>> will change to CamelCase, thanks.
> >>>
>
> > +
> > typedef struct DNNModel{
> > // Stores model that can be different for different backends.
> > void *model;
> > @@ -80,10 +82,10 @@ typedef struct DNNModel{
> > const char *output_name,
> int
> *output_width, int *output_height);
> > // set the pre process to transfer data from AVFrame to
> >> DNNData
> > // the default implementation within DNN is used if it is
> > not provided
> by the filter
> > -int (*pre_proc)(AVFrame *frame_in, DNNData *model_input,
> AVFilterContext *filter_ctx);
> > +PRE_POST_PROC pre_proc;
> > // set the post process to transfer data from DNNData to
> AVFrame
> > // the default implementation within DNN is used if it is
> > not provided
> by the filter
> > -int (*post_proc)(AVFrame *frame_out, DNNData
> >> *model_output,
> AVFilterContext *filter_ctx);
> > +PRE_POST_PROC post_proc;
>
> Spurious change.
> >>>
> >>> sorry, not quite understand this comment. It is used for code refine.
> >>> Maybe I need to let it in a separate patch.
> >>>
>
> > } DNNModel;
> >
> > +
> > +frame->private_ref = av_buffer_alloc(sizeof(*header) +
> > + sizeof(*bbox) *
> nb_bbox);
> > +if (!frame->private_ref) {
> > +av_log(filter_ctx, AV_LOG_ERROR, "failed to allocate
> > + buffer for %d
> bboxes\n", nb_bbox);
> > +return AVERROR(ENOMEM);;
>
> Double ;
> >>>
> >>> thanks, will remove it.
> >>>
>
> > +}
> > +
> > +header = (BoundingBoxHeader *)frame->private_ref->data;
> > +strncpy(header->source, ctx->dnnctx.model_filename,
> sizeof(header->source));
> > +header->source[sizeof(header->source) - 1] = '\0';
> > +header->bbox_size = sizeof(*bbox);
> > +
>
Re: [FFmpeg-devel] [PATCH] [RFC][v4] Tech Resolution Process
What is ranked choice voting? ___ 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".
Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect for object detection
Guo, Yejun (12021-03-01): > Hi, glad to hear there's a good solution, could you share a bit of > code as an example, it would be nice if I could refine my code better > when possible, thanks. The best choice is to go with BoundingBox boxes[], as Andreas pointed, and see if people who use compilers where it does not work manifest. Probably they will not, and if they do we can decide if we want to continue supporting these obsolete compilers. The second best choice is to go with BoundingBox boxes[1], if it is not proven that the compiler can make assumptions that will break the code. The third choice would be something like: #define BOX(p, i) (((BoundingBox *)&(p)->boxes)[i]) or similar. But best try to make the best choice work. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH] [RFC][v4] Tech Resolution Process
On Mon, 1 Mar 2021, at 15:48, Paul B Mahol wrote: > What is ranked choice voting? https://ballotpedia.org/Ranked-choice_voting_(RCV) For a binary vote, though, the interest is limited :) -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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".
Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect for object detection
On Mon, Mar 1, 2021 at 3:51 PM Nicolas George wrote: > Guo, Yejun (12021-03-01): > > Hi, glad to hear there's a good solution, could you share a bit of > > code as an example, it would be nice if I could refine my code better > > when possible, thanks. > > The best choice is to go with BoundingBox boxes[], as Andreas pointed, > and see if people who use compilers where it does not work manifest. > Probably they will not, and if they do we can decide if we want to > continue supporting these obsolete compilers. > > The second best choice is to go with BoundingBox boxes[1], if it is not > proven that the compiler can make assumptions that will break the code. > > The third choice would be something like: > > #define BOX(p, i) (((BoundingBox *)&(p)->boxes)[i]) > or similar. But best try to make the best choice work Why not use frame metadata for this? Instead of clumsy structures? > . > > Regards, > > -- > Nicolas George > ___ > 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".
Re: [FFmpeg-devel] [PATCH V4 2/4] libavfilter/buffersink.c: unref private_ref when frame leaves libavfilter
> -Original Message- > From: ffmpeg-devel On Behalf Of Nicolas > George > Sent: 2021年3月1日 22:24 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH V4 2/4] libavfilter/buffersink.c: unref > private_ref when frame leaves libavfilter > > Guo, Yejun (12021-03-01): > > Thanks for the review, as we talked at > > http://ffmpeg.org/pipermail/ffmpeg-devel/2021-February/276728.html, > > private_ref is allocated in filter vf_dnn_detect.c for detected > > results, and other filters such as vf_drawbox/text (in plan) will read it. > > > > Since private_ref is for a single libav* library, it has to be NULL > > when it leaves libavfilter, so I have to unref it at the last step of > > libavfilter, > that's in buffersink. Any other suggestion? thanks. > > Sorry, I did not have this reply in my archives, I somehow missed it. > > What this is basically saying is that private_ref in libavfilter will be > appropriated for the only use of bounding boxes. I think it is a significantly > worse solution than using side data as you originally considered. yes, this is what we did earlier. Actually, I think private_ref in libavfilter can only be used for an exclusive usage at a time. As Paul mentioned, I think AVFrame.metadata is a better choice. ___ 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".
Re: [FFmpeg-devel] [PATCH 5/5] lavc: remove tests/options
Quoting Andreas Rheinhardt (2021-02-26 14:55:26) > You forgot to remove the corresponding entry in .gitignore. LGTM otherwise. And the test output as well. Both removed locally. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH V4 2/4] libavfilter/buffersink.c: unref private_ref when frame leaves libavfilter
Guo, Yejun (12021-03-01): > Actually, I think private_ref in libavfilter can only > be used for an exclusive usage at a time. Exactly. If we use it for this, then we cannot use for anything else in libavfilter. This use seems too specific to warrant dedicating such an unique field to it, even though we do not have a better use in sight. > As Paul mentioned, I think AVFrame.metadata is a better choice. If you can express it as a string or set of strings with a clear syntax that can easily be parsed, then possibly, yes. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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] [PATCH] avcodec/speedhq: fix decoding 422 subsampling when width is not multiple of 16
Signed-off-by: Paul B Mahol
---
libavcodec/speedhq.c | 42 --
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c
index 759fc6dfc5..2a2fc42efa 100644
--- a/libavcodec/speedhq.c
+++ b/libavcodec/speedhq.c
@@ -283,6 +283,7 @@ static int decode_speedhq_field(const SHQContext *s, const
uint8_t *buf, int buf
int linesize_cb = frame->linesize[1] * line_stride;
int linesize_cr = frame->linesize[2] * line_stride;
int linesize_a;
+GetBitContext gb;
if (s->alpha_type != SHQ_NO_ALPHA)
linesize_a = frame->linesize[3] * line_stride;
@@ -304,7 +305,6 @@ static int decode_speedhq_field(const SHQContext *s, const
uint8_t *buf, int buf
}
for (slice_number = 0; slice_number < 4; slice_number++) {
-GetBitContext gb;
uint32_t slice_begin, slice_end;
int x, y;
@@ -333,7 +333,7 @@ static int decode_speedhq_field(const SHQContext *s, const
uint8_t *buf, int buf
dest_a = frame->data[3] + frame->linesize[3] * (y +
field_number);
}
-for (x = 0; x < frame->width; x += 16) {
+for (x = 0; x < frame->width - 8 * (s->subsampling !=
SHQ_SUBSAMPLING_444); x += 16) {
/* Decode the four luma blocks. */
if ((ret = decode_dct_block(s, &gb, last_dc, 0, dest_y,
linesize_y)) < 0)
return ret;
@@ -402,6 +402,44 @@ static int decode_speedhq_field(const SHQContext *s, const
uint8_t *buf, int buf
}
}
+if (s->subsampling == SHQ_SUBSAMPLING_444)
+return 0;
+
+if (!(frame->width & 15))
+return 0;
+
+for (int y = 0; y < frame->height; y += 16 * line_stride) {
+int last_dc[4] = { 1024, 1024, 1024, 1024 };
+uint8_t *dest_y, *dest_cb, *dest_cr;
+int x = frame->width - 8;
+
+dest_y = frame->data[0] + frame->linesize[0] * (y + field_number) + x;
+if (s->subsampling == SHQ_SUBSAMPLING_420) {
+dest_cb = frame->data[1] + frame->linesize[1] * (y/2 +
field_number) + x / 2;
+dest_cr = frame->data[2] + frame->linesize[2] * (y/2 +
field_number) + x / 2;
+} else if (s->subsampling == SHQ_SUBSAMPLING_422) {
+dest_cb = frame->data[1] + frame->linesize[1] * (y + field_number)
+ x / 2;
+dest_cr = frame->data[2] + frame->linesize[2] * (y + field_number)
+ x / 2;
+}
+
+if ((ret = decode_dct_block(s, &gb, last_dc, 0, dest_y, linesize_y)) <
0)
+return ret;
+if ((ret = decode_dct_block(s, &gb, last_dc, 0, dest_y + 8,
linesize_y)) < 0)
+return ret;
+if ((ret = decode_dct_block(s, &gb, last_dc, 0, dest_y + 8 *
linesize_y, linesize_y)) < 0)
+return ret;
+if ((ret = decode_dct_block(s, &gb, last_dc, 0, dest_y + 8 *
linesize_y + 8, linesize_y)) < 0)
+return ret;
+if ((ret = decode_dct_block(s, &gb, last_dc, 1, dest_cb, linesize_cb))
< 0)
+return ret;
+if ((ret = decode_dct_block(s, &gb, last_dc, 2, dest_cr, linesize_cr))
< 0)
+return ret;
+if ((ret = decode_dct_block(s, &gb, last_dc, 1, dest_cb + 8 *
linesize_cb, linesize_cb)) < 0)
+return ret;
+if ((ret = decode_dct_block(s, &gb, last_dc, 2, dest_cr + 8 *
linesize_cr, linesize_cr)) < 0)
+return ret;
+}
+
return 0;
}
--
2.17.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".
Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect for object detection
Nicolas George:
> Andreas Rheinhardt (12021-03-01):
>>> thanks for the info, this struct is expected to be in side_data in the
>>> future,
>>> I'll add 'bboxes[1]' in it, and allocate sizeof(*header) + (nb_bbox - 1) *
>>> sizeof(*bbox).
>>
>> Notice that in this case it is undefined behaviour to access any of the
>> boxes outside of BoundingBoxHeader (i.e. when using header->bboxes[i],
>> the compiler is allowed to infer that i == 0 as all other cases would be
>> undefined behaviour).
>
> Are you sure about it? Can you quote the standard?
>
> Anyway, even if this is true, we can work around it with an extra
> pointer or a cast, possibly wrapped in a macro. Saving a few dynamic
> allocation is well worth the unusual code; we should shoo away the
> people who oppose to go work on GStreamer or something.
>
1. The C standards committee seems to think so (at least, it did so a
few decades ago; the current composition has probably changed considerably):
"The validity of this construct has always been questionable. In the
response to one Defect Report, the Committee decided that it was
undefined behavior because the array p->itemscontains only one item,
irrespective of whether the space exists." (p.74 from
http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf)
2. 6.5.6 (the section on pointer arithmetic) contains this:
"When an expression that has integer type is added to or subtracted from
a pointer, the result has the type of the pointer operand. If the
pointer operand points to an element of an array object, and the array
is large enough,"
It also contains a provision that pointer arithmetic is legal up to one
past the last element of the array as long as the pointer pointing one
past the last element is not accessed. Everything else is UB.
So whether using [1] as a flexible-array member is UB or not depends
upon whether the array object still counts as containing only one
element when it is declared as [1] even when the allocated size is
sufficient for many more elements. Let's call them the small- and
big-object interpretations.
[1] contains a bug report where someone claims that using [1] led to a
miscompilation and fixed it by using [0] (a GCC extension). Yet said
code also did not put the [1] array at the end of the struct, so IMO it
doesn't count.
Compilers seem to intentionally treat [0] and [1] special in order not
to break code using this feature. When accessing array[3] of a two
element array located at the end of a struct, I get a warning from GCC
and Clang; I get no such warning for a one element array.
Also notice that when using an array of arrays GCC uses the small-object
interpretation: In the code fragment
extern int a[][2];
int f (int i, int j)
{
int t = a[1][j];
a[0][i] = 0;
return a[1][j] - t;
}
GCC does always returns 0, i.e it treats it as UB if i were outside of
0..1, so that a[0][i] and a[1][j] don't alias. Yet if the big-object
interpretation is the correct one, then this optimization is invalid: a
is first transformed to a pointer to its first element which (as an
array) is transformed to a pointer to its first element and then pointer
arithmetic (adding i) is applied to this pointer. And with the
big-object interpretation the compiler knows nothing about the real size
of the object it points to (except that it is at least two ints big).
If one makes the implicit array-to-pointer transformation explicit (i.e.
uses "(&a[0][0])[i] = 0;" or "((int*)(a[0]))[i] = 0;"), then GCC no
longer makes this optimization.
Other compilers are not that aggressive [2].
3. As you probably guessed from the last part of 2., I don't think that
casting avoids the possibility of undefined behaviour* (because this
conversion is done automatically anyway); but it might very well protect
the code from aggressively optimizing compilers.
- Andreas
[1]: https://lkml.org/lkml/2015/2/18/407
[2]: https://godbolt.org/z/j46bMn
*: In the int a[][2] case using ((int*)a)[i] would indeed avoid the
undefined behaviour, because even with the little-object interpretation
the object that is pointed to is the big one. But for the cases that you
are interested in this is not so.
___
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".
Re: [FFmpeg-devel] [PATCH 3/5] avcodec/mpegvideo: Schedule unused, deprecated rc_strategy for removal
Andreas Rheinhardt:
> Deprecated in d05c3b9ceeb9d00d4500c376448230e45f6ab108.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> Here is my current WIP branch for the bump for anyone who is interested:
> https://github.com/mkver/FFmpeg/commits/bump
>
> libavcodec/mpegvideo.h | 14 +++---
> libavcodec/version.h | 3 +++
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
> index 5f6e1da133..5a99c19656 100644
> --- a/libavcodec/mpegvideo.h
> +++ b/libavcodec/mpegvideo.h
> @@ -369,7 +369,9 @@ typedef struct MpegEncContext {
> uint8_t *mb_info_ptr;
> int mb_info_size;
> int ehc_mode;
> +#if FF_API_MPV_RC_STRATEGY
> int rc_strategy;///< deprecated
> +#endif
>
> /* H.263+ specific */
> int umvplus;///< == H.263+ && unrestricted_mv
> @@ -615,6 +617,14 @@ typedef struct MpegEncContext {
> #ifndef FF_MPV_OFFSET
> #define FF_MPV_OFFSET(x) offsetof(MpegEncContext, x)
> #endif
> +#if FF_API_MPV_RC_STRATEGY
> +#define FF_MPV_RC_STRATEGY_OPTS \
> +{"rc_strategy", "ratecontrol method",
> FF_MPV_OFFSET(rc_strategy), AV_OPT_TYPE_INT, {.i64 = 0 }, 0, 1,
> FF_MPV_OPT_FLAGS | AV_OPT_FLAG_DEPRECATED, "rc_strategy" }, \
> +{ "ffmpeg", "deprecated, does nothing", 0, AV_OPT_TYPE_CONST, { .i64 = 0
> }, 0, 0, FF_MPV_OPT_FLAGS | AV_OPT_FLAG_DEPRECATED, "rc_strategy" }, \
> +{ "xvid", "deprecated, does nothing", 0, AV_OPT_TYPE_CONST, { .i64 = 0
> }, 0, 0, FF_MPV_OPT_FLAGS | AV_OPT_FLAG_DEPRECATED, "rc_strategy" },
> +#else
> +#define FF_MPV_RC_STRATEGY_OPTS
> +#endif
> #define FF_MPV_OPT_FLAGS (AV_OPT_FLAG_VIDEO_PARAM |
> AV_OPT_FLAG_ENCODING_PARAM)
> #define FF_MPV_COMMON_OPTS \
> FF_MPV_OPT_CMP_FUNC, \
> @@ -648,9 +658,6 @@ FF_MPV_OPT_CMP_FUNC, \
> {"lmax", "maximum Lagrange factor (VBR)",
> FF_MPV_OFFSET(lmax), AV_OPT_TYPE_INT, {.i64 = 31*FF_QP2LAMBDA }, 0, INT_MAX,
> FF_MPV_OPT_FLAGS },\
> {"ibias", "intra quant bias",
> FF_MPV_OFFSET(intra_quant_bias), AV_OPT_TYPE_INT, {.i64 =
> FF_DEFAULT_QUANT_BIAS }, INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
> {"pbias", "inter quant bias",
> FF_MPV_OFFSET(inter_quant_bias), AV_OPT_TYPE_INT, {.i64 =
> FF_DEFAULT_QUANT_BIAS }, INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
> -{"rc_strategy", "ratecontrol method",
> FF_MPV_OFFSET(rc_strategy), AV_OPT_TYPE_INT, {.i64 = 0 }, 0, 1,
> FF_MPV_OPT_FLAGS | AV_OPT_FLAG_DEPRECATED, "rc_strategy" }, \
> -{ "ffmpeg", "deprecated, does nothing", 0, AV_OPT_TYPE_CONST, { .i64 = 0
> }, 0, 0, FF_MPV_OPT_FLAGS | AV_OPT_FLAG_DEPRECATED, "rc_strategy" }, \
> -{ "xvid", "deprecated, does nothing", 0, AV_OPT_TYPE_CONST, { .i64 = 0
> }, 0, 0, FF_MPV_OPT_FLAGS | AV_OPT_FLAG_DEPRECATED, "rc_strategy" }, \
> {"motion_est", "motion estimation algorithm",
> FF_MPV_OFFSET(motion_est), AV_OPT_TYPE_INT, {.i64 = FF_ME_EPZS }, FF_ME_ZERO,
> FF_ME_XONE, FF_MPV_OPT_FLAGS, "motion_est" }, \
> { "zero", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = FF_ME_ZERO }, 0, 0,
> FF_MPV_OPT_FLAGS, "motion_est" }, \
> { "epzs", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = FF_ME_EPZS }, 0, 0,
> FF_MPV_OPT_FLAGS, "motion_est" }, \
> @@ -671,6 +678,7 @@ FF_MPV_OPT_CMP_FUNC, \
> {"mepre", "pre motion estimation", FF_MPV_OFFSET(me_pre), AV_OPT_TYPE_INT,
> {.i64 = 0 }, INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
> {"intra_penalty", "Penalty for intra blocks in block decision",
> FF_MPV_OFFSET(intra_penalty), AV_OPT_TYPE_INT, {.i64 = 0 }, 0, INT_MAX/2,
> FF_MPV_OPT_FLAGS }, \
> {"a53cc", "Use A53 Closed Captions (if available)", FF_MPV_OFFSET(a53_cc),
> AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FF_MPV_OPT_FLAGS }, \
> +FF_MPV_RC_STRATEGY_OPTS
>
> extern const AVOption ff_mpv_generic_options[];
>
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 516411b4b2..488def4c23 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -147,6 +147,9 @@
> #ifndef FF_API_AVCODEC_PIX_FMT
> #define FF_API_AVCODEC_PIX_FMT (LIBAVCODEC_VERSION_MAJOR < 59)
> #endif
> +#ifndef FF_API_MPV_RC_STRATEGY
> +#define FF_API_MPV_RC_STRATEGY (LIBAVCODEC_VERSION_MAJOR < 59)
> +#endif
> #ifndef FF_API_THREAD_SAFE_CALLBACKS
> #define FF_API_THREAD_SAFE_CALLBACKS (LIBAVCODEC_VERSION_MAJOR < 60)
> #endif
>
Will apply this tomorrow unless there are objections.
- Andreas
___
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".
Re: [FFmpeg-devel] [PATCH 4/5] avcodec/parser: Schedule av_parser_change for removal
James Almer:
> On 2/26/2021 10:18 AM, Andreas Rheinhardt wrote:
>> Originally deprecated in 748c2fca7e4d99357c234936aa71212a6282be36,
>> publically deprecated in 9a07c1332cfe092b57b5758f22b686ca58806c60
>> (merged into FFmpeg in 1885ffb03d0af28e6bac2bcc8725fa15b93f6ac9).
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavcodec/avcodec.h | 6 +-
>> libavcodec/parser.c | 3 ++-
>> libavcodec/version.h | 3 +++
>> 3 files changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index 3178c163b9..a8741df04b 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -3576,14 +3576,18 @@ int av_parser_parse2(AVCodecParserContext *s,
>> int64_t pts, int64_t dts,
>> int64_t pos);
>> +#if FF_API_PARSER_CHANGE
>> /**
>> * @return 0 if the output buffer is a subset of the input, 1 if it
>> is allocated and must be freed
>> - * @deprecated use AVBitStreamFilter
>> + * @deprecated Use dump_extradata, remove_extra or extract_extradata
>> + * bitstream filters instead.
>> */
>> +attribute_deprecated
>> int av_parser_change(AVCodecParserContext *s,
>> AVCodecContext *avctx,
>> uint8_t **poutbuf, int *poutbuf_size,
>> const uint8_t *buf, int buf_size, int keyframe);
>> +#endif
>> void av_parser_close(AVCodecParserContext *s);
>> /**
>> diff --git a/libavcodec/parser.c b/libavcodec/parser.c
>> index a63f532c48..f4bc00da7d 100644
>> --- a/libavcodec/parser.c
>> +++ b/libavcodec/parser.c
>> @@ -186,6 +186,7 @@ int av_parser_parse2(AVCodecParserContext *s,
>> AVCodecContext *avctx,
>> return index;
>> }
>> +#if FF_API_PARSER_CHANGE
>> int av_parser_change(AVCodecParserContext *s, AVCodecContext *avctx,
>> uint8_t **poutbuf, int *poutbuf_size,
>> const uint8_t *buf, int buf_size, int keyframe)
>> @@ -220,7 +221,7 @@ int av_parser_change(AVCodecParserContext *s,
>> AVCodecContext *avctx,
>> return 0;
>> }
>> -
>> +#endif
>> void av_parser_close(AVCodecParserContext *s)
>> {
>> if (s) {
>> diff --git a/libavcodec/version.h b/libavcodec/version.h
>> index 488def4c23..815df15628 100644
>> --- a/libavcodec/version.h
>> +++ b/libavcodec/version.h
>> @@ -150,6 +150,9 @@
>> #ifndef FF_API_MPV_RC_STRATEGY
>> #define FF_API_MPV_RC_STRATEGY (LIBAVCODEC_VERSION_MAJOR < 59)
>> #endif
>> +#ifndef FF_API_PARSER_CHANGE
>> +#define FF_API_PARSER_CHANGE (LIBAVCODEC_VERSION_MAJOR < 59)
>
> A doxygen deprecation notice is not enough to consider the function
> deprecated. There was no APIChanges entry and no attribute added to the
> function prototype.
> So this needs the APIChanges entry, and therefore be scheduled as < 60.
I disagree. Of course Doxygen deprecations count and being on the list
of deprecated things [1] for more than eight years is enough.
- Andreas
[1]: https://ffmpeg.org/doxygen/trunk/deprecated.html#_deprecated07
>
> LGTM otherwise.
>
>> +#endif
>> #ifndef FF_API_THREAD_SAFE_CALLBACKS
>> #define FF_API_THREAD_SAFE_CALLBACKS (LIBAVCODEC_VERSION_MAJOR < 60)
>> #endif
>>
___
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".
Re: [FFmpeg-devel] [PATCH V4 2/4] libavfilter/buffersink.c: unref private_ref when frame leaves libavfilter
> -Original Message- > From: ffmpeg-devel On Behalf Of Nicolas > George > Sent: 2021年3月1日 23:07 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH V4 2/4] libavfilter/buffersink.c: unref > private_ref when frame leaves libavfilter > > Guo, Yejun (12021-03-01): > > Actually, I think private_ref in libavfilter can only be used for an > > exclusive usage at a time. > > Exactly. If we use it for this, then we cannot use for anything else in > libavfilter. > This use seems too specific to warrant dedicating such an unique field to it, > even though we do not have a better use in sight. > > > As Paul mentioned, I think AVFrame.metadata is a better choice. > > If you can express it as a string or set of strings with a clear syntax that > can > easily be parsed, then possibly, yes. ooo, it is not easy to express the bounding boxes as strings in AVDictionaryEntry.value, the bounding box has several data members, and they are data and have high possibility to contain '\0' in the middle of the data. So, we might not use AVFrame.metadata. So, where to put the bounding boxes (object detection result generated by vf_dnn_detect), I now see several possible methods which all have positive/negative comments: 1. Add into side data The final result is to be in side data since it might be used by new encoders in the future, but this method changes the API. 1.1 We just add a new enum for side data, and keep the .h file (for structs) internal at first. There's comment that this is not allowed. (I personally prefer this one.) 1.2 We add enum for side data, and also export the .h file as part of FFmpeg API. The risk is that we might change the structs in .h file later, it breaks API. We need a versioning management for the struct, just like film grain as explained at http://ffmpeg.org/pipermail/ffmpeg-devel/2021-February/276586.html . 2. Use private_ref Use private_ref for bounding boxes at first, and then change to side data when it is required. The disadvantage is that during the period, we cannot use it for anything else in libavfilter. any comment or any other suggestion? thanks. ___ 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".
Re: [FFmpeg-devel] [PATCH] lavc/alsdec: Add NEON optimizations
Hi Martin,
>> it's my first attempt to do some assembly, it might still includes some
>> dont's of the asm world...
>> Tested with gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
>>
>> Speed-wise, it sees a drop for small prediction orders until around 10 or 11.
>> Well, the maximum prediction order is 1023.
>> I therefore checked with the "real-world" samples from the fate-suite, which
>> suggests low prediction orders are non-dominant:
>>
>> pred_order = {7..17}, gain: 23%
>>
>> als_reconstruct_all_c: 26645.2
>> als_reconstruct_all_neon: 20635.2
>
> This is the combination that the patch actually tests by default, if I read
> the code correctly - right?
exactly.
> You didn't write what CPU you tested this on - do note that the actual
> peformance of the assembly is pretty heavily dependent on the CPU.
>
> I get roughly similar numbers if I build with GCC:
>
> Cortex A53 A72 A73
> als_reconstruct_all_c: 107708.2 44044.5 57427.7
> als_reconstruct_all_neon: 78895.7 38464.7 34065.5
Was a remote one, don't know exactly, yet. Will find out for v2.
> However - if I build with Clang, where vectorization isn't disabled by
> configure, the C code beats the handwritten assembly:
>
> Cortex A53
> als_reconstruct_all_c: 69145.7
> als_reconstruct_all_neon: 78895.7
>
> Even if I only test order 17, the C code still is faster. So clearly we can
> do better - if nothing else, we could copy the assembly code that Clang
> outputs :-)
Narf. Well maybe thoughts about the code itself will get more speed manually...
> First a couple technical details about the patch...
> [...]
I very much appreciate your excessive feedback, I will need quite some time to
work through it! :)
Thanks!
-Thilo
___
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] [PATCH v3] avcodec/decode: port last_pkt_props to AVFifoBuffer
Signed-off-by: James Almer
---
libavcodec/decode.c | 49 ++-
libavcodec/internal.h | 4 ++--
libavcodec/utils.c| 26 +--
3 files changed, 56 insertions(+), 23 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 8086362eb2..9d7cc107ae 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -145,24 +145,44 @@ fail2:
#define IS_EMPTY(pkt) (!(pkt)->data)
+static int copy_packet_props(AVPacket *dst, AVPacket *src)
+{
+int ret = av_packet_copy_props(dst, src);
+if (ret < 0)
+return ret;
+
+dst->size = src->size; // HACK: Needed for ff_decode_frame_props().
+dst->data = (void*)1; // HACK: Needed for IS_EMPTY().
+
+return 0;
+}
+
static int extract_packet_props(AVCodecInternal *avci, AVPacket *pkt)
{
+AVPacket tmp = { 0 };
int ret = 0;
-ret = avpriv_packet_list_put(&avci->pkt_props, &avci->pkt_props_tail, pkt,
- av_packet_copy_props, 0);
+if (IS_EMPTY(avci->last_pkt_props)) {
+if (av_fifo_size(avci->pkt_props) >= sizeof(*pkt)) {
+av_fifo_generic_read(avci->pkt_props, avci->last_pkt_props,
+ sizeof(*avci->last_pkt_props), NULL);
+} else
+return copy_packet_props(avci->last_pkt_props, pkt);
+}
+
+if (av_fifo_space(avci->pkt_props) < sizeof(*pkt)) {
+ret = av_fifo_grow(avci->pkt_props, sizeof(*pkt));
+if (ret < 0)
+return ret;
+}
+
+ret = copy_packet_props(&tmp, pkt);
if (ret < 0)
return ret;
-avci->pkt_props_tail->pkt.size = pkt->size; // HACK: Needed for
ff_decode_frame_props().
-avci->pkt_props_tail->pkt.data = (void*)1; // HACK: Needed for IS_EMPTY().
-if (IS_EMPTY(avci->last_pkt_props)) {
-ret = avpriv_packet_list_get(&avci->pkt_props,
- &avci->pkt_props_tail,
- avci->last_pkt_props);
-av_assert0(ret != AVERROR(EAGAIN));
-}
-return ret;
+av_fifo_generic_write(avci->pkt_props, &tmp, sizeof(tmp), NULL);
+
+return 0;
}
int ff_decode_bsfs_init(AVCodecContext *avctx)
@@ -1726,10 +1746,9 @@ int ff_decode_frame_props(AVCodecContext *avctx, AVFrame
*frame)
{ AV_PKT_DATA_S12M_TIMECODE, AV_FRAME_DATA_S12M_TIMECODE
},
};
-if (IS_EMPTY(pkt))
-avpriv_packet_list_get(&avctx->internal->pkt_props,
- &avctx->internal->pkt_props_tail,
- pkt);
+if (IS_EMPTY(pkt) && av_fifo_size(avctx->internal->pkt_props) >=
sizeof(*pkt))
+av_fifo_generic_read(avctx->internal->pkt_props,
+ pkt, sizeof(*pkt), NULL);
if (pkt) {
frame->pts = pkt->pts;
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 65760368d6..400ea508ef 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -28,6 +28,7 @@
#include "libavutil/buffer.h"
#include "libavutil/channel_layout.h"
+#include "libavutil/fifo.h"
#include "libavutil/mathematics.h"
#include "libavutil/pixfmt.h"
#include "avcodec.h"
@@ -147,8 +148,7 @@ typedef struct AVCodecInternal {
* for decoding.
*/
AVPacket *last_pkt_props;
-AVPacketList *pkt_props;
-AVPacketList *pkt_props_tail;
+AVFifoBuffer *pkt_props;
/**
* temporary buffer used for encoders to store their bitstream
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index db6cd0cde8..32d0288faa 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -594,9 +594,10 @@ int attribute_align_arg avcodec_open2(AVCodecContext
*avctx, const AVCodec *code
avci->es.in_frame = av_frame_alloc();
avci->ds.in_pkt = av_packet_alloc();
avci->last_pkt_props = av_packet_alloc();
+avci->pkt_props = av_fifo_alloc(sizeof(*avci->last_pkt_props));
if (!avci->buffer_frame || !avci->buffer_pkt ||
!avci->es.in_frame || !avci->ds.in_pkt ||
-!avci->last_pkt_props) {
+!avci->last_pkt_props || !avci->pkt_props) {
ret = AVERROR(ENOMEM);
goto free_and_end;
}
@@ -1077,7 +1078,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
#endif
av_frame_free(&avci->buffer_frame);
av_packet_free(&avci->buffer_pkt);
-av_packet_free(&avci->last_pkt_props);
+av_fifo_freep(&avci->pkt_props);
av_packet_free(&avci->ds.in_pkt);
av_frame_free(&avci->es.in_frame);
@@ -1120,8 +1121,13 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
av_packet_unref(avci->buffer_pkt);
av_packet_unref(avci->last_pkt_props);
-avpriv_packet_list_free(&avci->pkt_props,
-&avci->pkt_props_tail);
+while (av_fifo_size(avci->pkt_props) >= sizeof(*avci->last_pkt_props)) {
+av_fifo_generic_read(avci->pkt_props,
+ avci->last_pkt_props,
sizeof(*avci->last_pkt_props),
+
Re: [FFmpeg-devel] [PATCH 1/5] avformat/voc_packet: Add a basic check on max_size
On Sun, Dec 13, 2020 at 01:30:27AM +0100, Michael Niedermayer wrote: > Fixes: signed integer overflow: -2147483648 - 4 cannot be represented in type > 'int' > Fixes: > 28127/clusterfuzz-testcase-minimized-ffmpeg_dem_VOC_fuzzer-4880586455646208 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/voc_packet.c | 2 ++ > 1 file changed, 2 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH 2/5] avcodec/h2645_parse: Reduce the initial skipped_bytes_pos size with small inputs
On Sun, Dec 13, 2020 at 01:30:28AM +0100, Michael Niedermayer wrote: > Fixes: OOM > Fixes: > 23817/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_METADATA_fuzzer-6300869057576960 > Fixes: > 28055/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5706035297517568 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/h2645_parse.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH 4/5] avformat/aadec: Check for EOF while reading chapters
On Sun, Dec 13, 2020 at 01:30:30AM +0100, Michael Niedermayer wrote: > Fixes: timeout > Fixes: > 28199/clusterfuzz-testcase-minimized-ffmpeg_dem_AA_fuzzer-4896162657861632 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/aadec.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH 5/5] avformat/mov: Extend data_size check in mov_read_udta_string()
On Sun, Dec 13, 2020 at 01:30:31AM +0100, Michael Niedermayer wrote: > Fixes: signed integer overflow: -2147483634 - 16 cannot be represented in > type 'int' > Fixes: > 28322/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5711888402612224 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/mov.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH 4/5] avcodec/parser: Schedule av_parser_change for removal
On 3/1/2021 12:36 PM, Andreas Rheinhardt wrote:
James Almer:
On 2/26/2021 10:18 AM, Andreas Rheinhardt wrote:
Originally deprecated in 748c2fca7e4d99357c234936aa71212a6282be36,
publically deprecated in 9a07c1332cfe092b57b5758f22b686ca58806c60
(merged into FFmpeg in 1885ffb03d0af28e6bac2bcc8725fa15b93f6ac9).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/avcodec.h | 6 +-
libavcodec/parser.c | 3 ++-
libavcodec/version.h | 3 +++
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 3178c163b9..a8741df04b 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3576,14 +3576,18 @@ int av_parser_parse2(AVCodecParserContext *s,
int64_t pts, int64_t dts,
int64_t pos);
+#if FF_API_PARSER_CHANGE
/**
* @return 0 if the output buffer is a subset of the input, 1 if it
is allocated and must be freed
- * @deprecated use AVBitStreamFilter
+ * @deprecated Use dump_extradata, remove_extra or extract_extradata
+ * bitstream filters instead.
*/
+attribute_deprecated
int av_parser_change(AVCodecParserContext *s,
AVCodecContext *avctx,
uint8_t **poutbuf, int *poutbuf_size,
const uint8_t *buf, int buf_size, int keyframe);
+#endif
void av_parser_close(AVCodecParserContext *s);
/**
diff --git a/libavcodec/parser.c b/libavcodec/parser.c
index a63f532c48..f4bc00da7d 100644
--- a/libavcodec/parser.c
+++ b/libavcodec/parser.c
@@ -186,6 +186,7 @@ int av_parser_parse2(AVCodecParserContext *s,
AVCodecContext *avctx,
return index;
}
+#if FF_API_PARSER_CHANGE
int av_parser_change(AVCodecParserContext *s, AVCodecContext *avctx,
uint8_t **poutbuf, int *poutbuf_size,
const uint8_t *buf, int buf_size, int keyframe)
@@ -220,7 +221,7 @@ int av_parser_change(AVCodecParserContext *s,
AVCodecContext *avctx,
return 0;
}
-
+#endif
void av_parser_close(AVCodecParserContext *s)
{
if (s) {
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 488def4c23..815df15628 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -150,6 +150,9 @@
#ifndef FF_API_MPV_RC_STRATEGY
#define FF_API_MPV_RC_STRATEGY (LIBAVCODEC_VERSION_MAJOR < 59)
#endif
+#ifndef FF_API_PARSER_CHANGE
+#define FF_API_PARSER_CHANGE (LIBAVCODEC_VERSION_MAJOR < 59)
A doxygen deprecation notice is not enough to consider the function
deprecated. There was no APIChanges entry and no attribute added to the
function prototype.
So this needs the APIChanges entry, and therefore be scheduled as < 60.
I disagree. Of course Doxygen deprecations count and being on the list
of deprecated things [1] for more than eight years is enough.
If there was no APIChanges entry that references a library version, then
this can not be considered deprecated and can not be removed until a
bump at least 2 years from now. Even more so when there was no
deprecation attribute on the function to warn its users.
So please, change it to < 60. It's an absolutely harmless standalone
function and can stay around for a proper deprecation period.
- Andreas
[1]: https://ffmpeg.org/doxygen/trunk/deprecated.html#_deprecated07
LGTM otherwise.
+#endif
#ifndef FF_API_THREAD_SAFE_CALLBACKS
#define FF_API_THREAD_SAFE_CALLBACKS (LIBAVCODEC_VERSION_MAJOR < 60)
#endif
___
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".
Re: [FFmpeg-devel] [PATCH 4/5] avcodec/parser: Schedule av_parser_change for removal
Nope, remove it ASAP!
On Mon, Mar 1, 2021 at 8:36 PM James Almer wrote:
> On 3/1/2021 12:36 PM, Andreas Rheinhardt wrote:
> > James Almer:
> >> On 2/26/2021 10:18 AM, Andreas Rheinhardt wrote:
> >>> Originally deprecated in 748c2fca7e4d99357c234936aa71212a6282be36,
> >>> publically deprecated in 9a07c1332cfe092b57b5758f22b686ca58806c60
> >>> (merged into FFmpeg in 1885ffb03d0af28e6bac2bcc8725fa15b93f6ac9).
> >>>
> >>> Signed-off-by: Andreas Rheinhardt
> >>> ---
> >>>libavcodec/avcodec.h | 6 +-
> >>>libavcodec/parser.c | 3 ++-
> >>>libavcodec/version.h | 3 +++
> >>>3 files changed, 10 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> >>> index 3178c163b9..a8741df04b 100644
> >>> --- a/libavcodec/avcodec.h
> >>> +++ b/libavcodec/avcodec.h
> >>> @@ -3576,14 +3576,18 @@ int av_parser_parse2(AVCodecParserContext *s,
> >>> int64_t pts, int64_t dts,
> >>> int64_t pos);
> >>>+#if FF_API_PARSER_CHANGE
> >>>/**
> >>> * @return 0 if the output buffer is a subset of the input, 1 if it
> >>> is allocated and must be freed
> >>> - * @deprecated use AVBitStreamFilter
> >>> + * @deprecated Use dump_extradata, remove_extra or extract_extradata
> >>> + * bitstream filters instead.
> >>> */
> >>> +attribute_deprecated
> >>>int av_parser_change(AVCodecParserContext *s,
> >>> AVCodecContext *avctx,
> >>> uint8_t **poutbuf, int *poutbuf_size,
> >>> const uint8_t *buf, int buf_size, int
> keyframe);
> >>> +#endif
> >>>void av_parser_close(AVCodecParserContext *s);
> >>> /**
> >>> diff --git a/libavcodec/parser.c b/libavcodec/parser.c
> >>> index a63f532c48..f4bc00da7d 100644
> >>> --- a/libavcodec/parser.c
> >>> +++ b/libavcodec/parser.c
> >>> @@ -186,6 +186,7 @@ int av_parser_parse2(AVCodecParserContext *s,
> >>> AVCodecContext *avctx,
> >>>return index;
> >>>}
> >>>+#if FF_API_PARSER_CHANGE
> >>>int av_parser_change(AVCodecParserContext *s, AVCodecContext *avctx,
> >>> uint8_t **poutbuf, int *poutbuf_size,
> >>> const uint8_t *buf, int buf_size, int keyframe)
> >>> @@ -220,7 +221,7 @@ int av_parser_change(AVCodecParserContext *s,
> >>> AVCodecContext *avctx,
> >>> return 0;
> >>>}
> >>> -
> >>> +#endif
> >>>void av_parser_close(AVCodecParserContext *s)
> >>>{
> >>>if (s) {
> >>> diff --git a/libavcodec/version.h b/libavcodec/version.h
> >>> index 488def4c23..815df15628 100644
> >>> --- a/libavcodec/version.h
> >>> +++ b/libavcodec/version.h
> >>> @@ -150,6 +150,9 @@
> >>>#ifndef FF_API_MPV_RC_STRATEGY
> >>>#define FF_API_MPV_RC_STRATEGY (LIBAVCODEC_VERSION_MAJOR < 59)
> >>>#endif
> >>> +#ifndef FF_API_PARSER_CHANGE
> >>> +#define FF_API_PARSER_CHANGE (LIBAVCODEC_VERSION_MAJOR < 59)
> >>
> >> A doxygen deprecation notice is not enough to consider the function
> >> deprecated. There was no APIChanges entry and no attribute added to the
> >> function prototype.
> >> So this needs the APIChanges entry, and therefore be scheduled as < 60.
> >
> > I disagree. Of course Doxygen deprecations count and being on the list
> > of deprecated things [1] for more than eight years is enough.
>
> If there was no APIChanges entry that references a library version, then
> this can not be considered deprecated and can not be removed until a
> bump at least 2 years from now. Even more so when there was no
> deprecation attribute on the function to warn its users.
>
> So please, change it to < 60. It's an absolutely harmless standalone
> function and can stay around for a proper deprecation period.
>
> >
> > - Andreas
> >
> > [1]: https://ffmpeg.org/doxygen/trunk/deprecated.html#_deprecated07
> >
> >>
> >> LGTM otherwise.
> >>
> >>> +#endif
> >>>#ifndef FF_API_THREAD_SAFE_CALLBACKS
> >>>#define FF_API_THREAD_SAFE_CALLBACKS (LIBAVCODEC_VERSION_MAJOR < 60)
> >>>#endif
> >>>
> > ___
> > 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".
___
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".
Re: [FFmpeg-devel] [PATCH 4/5] avcodec/parser: Schedule av_parser_change for removal
On 3/1/2021 4:35 PM, James Almer wrote:
On 3/1/2021 12:36 PM, Andreas Rheinhardt wrote:
James Almer:
On 2/26/2021 10:18 AM, Andreas Rheinhardt wrote:
Originally deprecated in 748c2fca7e4d99357c234936aa71212a6282be36,
publically deprecated in 9a07c1332cfe092b57b5758f22b686ca58806c60
(merged into FFmpeg in 1885ffb03d0af28e6bac2bcc8725fa15b93f6ac9).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/avcodec.h | 6 +-
libavcodec/parser.c | 3 ++-
libavcodec/version.h | 3 +++
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 3178c163b9..a8741df04b 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3576,14 +3576,18 @@ int av_parser_parse2(AVCodecParserContext *s,
int64_t pts, int64_t dts,
int64_t pos);
+#if FF_API_PARSER_CHANGE
/**
* @return 0 if the output buffer is a subset of the input, 1 if it
is allocated and must be freed
- * @deprecated use AVBitStreamFilter
+ * @deprecated Use dump_extradata, remove_extra or extract_extradata
+ * bitstream filters instead.
*/
+attribute_deprecated
int av_parser_change(AVCodecParserContext *s,
AVCodecContext *avctx,
uint8_t **poutbuf, int *poutbuf_size,
const uint8_t *buf, int buf_size, int
keyframe);
+#endif
void av_parser_close(AVCodecParserContext *s);
/**
diff --git a/libavcodec/parser.c b/libavcodec/parser.c
index a63f532c48..f4bc00da7d 100644
--- a/libavcodec/parser.c
+++ b/libavcodec/parser.c
@@ -186,6 +186,7 @@ int av_parser_parse2(AVCodecParserContext *s,
AVCodecContext *avctx,
return index;
}
+#if FF_API_PARSER_CHANGE
int av_parser_change(AVCodecParserContext *s, AVCodecContext *avctx,
uint8_t **poutbuf, int *poutbuf_size,
const uint8_t *buf, int buf_size, int keyframe)
@@ -220,7 +221,7 @@ int av_parser_change(AVCodecParserContext *s,
AVCodecContext *avctx,
return 0;
}
-
+#endif
void av_parser_close(AVCodecParserContext *s)
{
if (s) {
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 488def4c23..815df15628 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -150,6 +150,9 @@
#ifndef FF_API_MPV_RC_STRATEGY
#define FF_API_MPV_RC_STRATEGY (LIBAVCODEC_VERSION_MAJOR < 59)
#endif
+#ifndef FF_API_PARSER_CHANGE
+#define FF_API_PARSER_CHANGE (LIBAVCODEC_VERSION_MAJOR < 59)
A doxygen deprecation notice is not enough to consider the function
deprecated. There was no APIChanges entry and no attribute added to the
function prototype.
So this needs the APIChanges entry, and therefore be scheduled as < 60.
I disagree. Of course Doxygen deprecations count and being on the list
of deprecated things [1] for more than eight years is enough.
If there was no APIChanges entry that references a library version, then
this can not be considered deprecated and can not be removed until a
bump at least 2 years from now. Even more so when there was no
deprecation attribute on the function to warn its users.
So please, change it to < 60. It's an absolutely harmless standalone
function and can stay around for a proper deprecation period.
What could also be done as part of this deprecation is doing the same to
AVCodecParser.split(). av_parser_change() is the only function that
makes use of it, so with the function gone it has no reason to exist
anymore, and it can all be removed at the same time.
You'd have to also wrap the relevant split functions on each parser that
implements it.
- Andreas
[1]: https://ffmpeg.org/doxygen/trunk/deprecated.html#_deprecated07
LGTM otherwise.
+#endif
#ifndef FF_API_THREAD_SAFE_CALLBACKS
#define FF_API_THREAD_SAFE_CALLBACKS (LIBAVCODEC_VERSION_MAJOR < 60)
#endif
___
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".
[FFmpeg-devel] [PATCH v2 2/5] avdevice/alsa_dec: make sure we have enough data in non-blocking mode
Otherwise we might return 1-2 samples per packet if av_read_frame() call rate is
only sligthly less than the stream sample rate.
Signed-off-by: Marton Balint
---
libavdevice/alsa.c | 5 +
libavdevice/alsa.h | 1 +
libavdevice/alsa_dec.c | 22 --
3 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/libavdevice/alsa.c b/libavdevice/alsa.c
index 117b2ea144..ee282fac16 100644
--- a/libavdevice/alsa.c
+++ b/libavdevice/alsa.c
@@ -286,6 +286,10 @@ av_cold int ff_alsa_open(AVFormatContext *ctx,
snd_pcm_stream_t mode,
}
}
+s->pkt = av_packet_alloc();
+if (!s->pkt)
+goto fail1;
+
s->h = h;
return 0;
@@ -308,6 +312,7 @@ av_cold int ff_alsa_close(AVFormatContext *s1)
if (CONFIG_ALSA_INDEV)
ff_timefilter_destroy(s->timefilter);
snd_pcm_close(s->h);
+av_packet_free(&s->pkt);
return 0;
}
diff --git a/libavdevice/alsa.h b/libavdevice/alsa.h
index 1ed8c82199..07783c983a 100644
--- a/libavdevice/alsa.h
+++ b/libavdevice/alsa.h
@@ -58,6 +58,7 @@ typedef struct AlsaData {
void *reorder_buf;
int reorder_buf_size; ///< in frames
int64_t timestamp; ///< current timestamp, without latency applied.
+AVPacket *pkt;
} AlsaData;
/**
diff --git a/libavdevice/alsa_dec.c b/libavdevice/alsa_dec.c
index 6d568737b3..88bf32d25f 100644
--- a/libavdevice/alsa_dec.c
+++ b/libavdevice/alsa_dec.c
@@ -104,34 +104,36 @@ static int audio_read_packet(AVFormatContext *s1,
AVPacket *pkt)
int64_t dts;
snd_pcm_sframes_t delay = 0;
-if (av_new_packet(pkt, s->period_size * s->frame_size) < 0) {
-return AVERROR(EIO);
+if (!s->pkt->data) {
+int ret = av_new_packet(s->pkt, s->period_size * s->frame_size);
+if (ret < 0)
+return ret;
+s->pkt->size = 0;
}
-while ((res = snd_pcm_readi(s->h, pkt->data, s->period_size)) < 0) {
+do {
+while ((res = snd_pcm_readi(s->h, s->pkt->data + s->pkt->size,
s->period_size - s->pkt->size / s->frame_size)) < 0) {
if (res == -EAGAIN) {
-av_packet_unref(pkt);
-
return AVERROR(EAGAIN);
}
+s->pkt->size = 0;
if (ff_alsa_xrun_recover(s1, res) < 0) {
av_log(s1, AV_LOG_ERROR, "ALSA read error: %s\n",
snd_strerror(res));
-av_packet_unref(pkt);
-
return AVERROR(EIO);
}
ff_timefilter_reset(s->timefilter);
-}
+}
+s->pkt->size += res * s->frame_size;
+} while (s->pkt->size < s->period_size * s->frame_size);
+av_packet_move_ref(pkt, s->pkt);
dts = av_gettime();
snd_pcm_delay(s->h, &delay);
dts -= av_rescale(delay + res, 100, s->sample_rate);
pkt->pts = ff_timefilter_update(s->timefilter, dts, s->last_period);
s->last_period = res;
-pkt->size = res * s->frame_size;
-
return 0;
}
--
2.26.2
___
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".
Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect for object detection
> -Original Message- > From: ffmpeg-devel On Behalf Of Nicolas > George > Sent: 2021年3月1日 22:51 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] libavfilter: add filter dnn_detect > for object detection > > Guo, Yejun (12021-03-01): > > Hi, glad to hear there's a good solution, could you share a bit of > > code as an example, it would be nice if I could refine my code better > > when possible, thanks. > > The best choice is to go with BoundingBox boxes[], as Andreas pointed, and see > if people who use compilers where it does not work manifest. > Probably they will not, and if they do we can decide if we want to continue > supporting these obsolete compilers. thanks, I will try this one. > > The second best choice is to go with BoundingBox boxes[1], if it is not proven > that the compiler can make assumptions that will break the code. > > The third choice would be something like: > > #define BOX(p, i) (((BoundingBox *)&(p)->boxes)[i]) > > or similar. But best try to make the best choice work. > > Regards, > > -- > Nicolas George ___ 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".
Re: [FFmpeg-devel] [PATCH 4/5] avcodec/parser: Schedule av_parser_change for removal
James Almer:
> On 3/1/2021 4:35 PM, James Almer wrote:
>> On 3/1/2021 12:36 PM, Andreas Rheinhardt wrote:
>>> James Almer:
On 2/26/2021 10:18 AM, Andreas Rheinhardt wrote:
> Originally deprecated in 748c2fca7e4d99357c234936aa71212a6282be36,
> publically deprecated in 9a07c1332cfe092b57b5758f22b686ca58806c60
> (merged into FFmpeg in 1885ffb03d0af28e6bac2bcc8725fa15b93f6ac9).
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/avcodec.h | 6 +-
> libavcodec/parser.c | 3 ++-
> libavcodec/version.h | 3 +++
> 3 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 3178c163b9..a8741df04b 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3576,14 +3576,18 @@ int av_parser_parse2(AVCodecParserContext *s,
> int64_t pts, int64_t dts,
> int64_t pos);
> +#if FF_API_PARSER_CHANGE
> /**
> * @return 0 if the output buffer is a subset of the input, 1 if it
> is allocated and must be freed
> - * @deprecated use AVBitStreamFilter
> + * @deprecated Use dump_extradata, remove_extra or extract_extradata
> + * bitstream filters instead.
> */
> +attribute_deprecated
> int av_parser_change(AVCodecParserContext *s,
> AVCodecContext *avctx,
> uint8_t **poutbuf, int *poutbuf_size,
> const uint8_t *buf, int buf_size, int
> keyframe);
> +#endif
> void av_parser_close(AVCodecParserContext *s);
> /**
> diff --git a/libavcodec/parser.c b/libavcodec/parser.c
> index a63f532c48..f4bc00da7d 100644
> --- a/libavcodec/parser.c
> +++ b/libavcodec/parser.c
> @@ -186,6 +186,7 @@ int av_parser_parse2(AVCodecParserContext *s,
> AVCodecContext *avctx,
> return index;
> }
> +#if FF_API_PARSER_CHANGE
> int av_parser_change(AVCodecParserContext *s, AVCodecContext
> *avctx,
> uint8_t **poutbuf, int *poutbuf_size,
> const uint8_t *buf, int buf_size, int
> keyframe)
> @@ -220,7 +221,7 @@ int av_parser_change(AVCodecParserContext *s,
> AVCodecContext *avctx,
> return 0;
> }
> -
> +#endif
> void av_parser_close(AVCodecParserContext *s)
> {
> if (s) {
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 488def4c23..815df15628 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -150,6 +150,9 @@
> #ifndef FF_API_MPV_RC_STRATEGY
> #define FF_API_MPV_RC_STRATEGY (LIBAVCODEC_VERSION_MAJOR < 59)
> #endif
> +#ifndef FF_API_PARSER_CHANGE
> +#define FF_API_PARSER_CHANGE (LIBAVCODEC_VERSION_MAJOR < 59)
A doxygen deprecation notice is not enough to consider the function
deprecated. There was no APIChanges entry and no attribute added to the
function prototype.
So this needs the APIChanges entry, and therefore be scheduled as < 60.
>>>
>>> I disagree. Of course Doxygen deprecations count and being on the list
>>> of deprecated things [1] for more than eight years is enough.
>>
>> If there was no APIChanges entry that references a library version,
>> then this can not be considered deprecated and can not be removed
>> until a bump at least 2 years from now. Even more so when there was no
>> deprecation attribute on the function to warn its users.
>>
>> So please, change it to < 60. It's an absolutely harmless standalone
>> function and can stay around for a proper deprecation period.
>
> What could also be done as part of this deprecation is doing the same to
> AVCodecParser.split(). av_parser_change() is the only function that
> makes use of it, so with the function gone it has no reason to exist
> anymore, and it can all be removed at the same time.
>
> You'd have to also wrap the relevant split functions on each parser that
> implements it.
>
The remove_extradata bsf also uses these. I actually intended to move
all the split functions to remove_extradata_bsf.c after the bump.
- Andreas
>>
>>>
>>> - Andreas
>>>
>>> [1]: https://ffmpeg.org/doxygen/trunk/deprecated.html#_deprecated07
>>>
LGTM otherwise.
> +#endif
> #ifndef FF_API_THREAD_SAFE_CALLBACKS
> #define FF_API_THREAD_SAFE_CALLBACKS (LIBAVCODEC_VERSION_MAJOR <
> 60)
> #endif
>
>>> ___
>>> 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
> ht
Re: [FFmpeg-devel] [PATCH 4/5] avcodec/parser: Schedule av_parser_change for removal
James Almer:
> On 3/1/2021 12:36 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> On 2/26/2021 10:18 AM, Andreas Rheinhardt wrote:
Originally deprecated in 748c2fca7e4d99357c234936aa71212a6282be36,
publically deprecated in 9a07c1332cfe092b57b5758f22b686ca58806c60
(merged into FFmpeg in 1885ffb03d0af28e6bac2bcc8725fa15b93f6ac9).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/avcodec.h | 6 +-
libavcodec/parser.c | 3 ++-
libavcodec/version.h | 3 +++
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 3178c163b9..a8741df04b 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3576,14 +3576,18 @@ int av_parser_parse2(AVCodecParserContext *s,
int64_t pts, int64_t dts,
int64_t pos);
+#if FF_API_PARSER_CHANGE
/**
* @return 0 if the output buffer is a subset of the input, 1 if it
is allocated and must be freed
- * @deprecated use AVBitStreamFilter
+ * @deprecated Use dump_extradata, remove_extra or extract_extradata
+ * bitstream filters instead.
*/
+attribute_deprecated
int av_parser_change(AVCodecParserContext *s,
AVCodecContext *avctx,
uint8_t **poutbuf, int *poutbuf_size,
const uint8_t *buf, int buf_size, int
keyframe);
+#endif
void av_parser_close(AVCodecParserContext *s);
/**
diff --git a/libavcodec/parser.c b/libavcodec/parser.c
index a63f532c48..f4bc00da7d 100644
--- a/libavcodec/parser.c
+++ b/libavcodec/parser.c
@@ -186,6 +186,7 @@ int av_parser_parse2(AVCodecParserContext *s,
AVCodecContext *avctx,
return index;
}
+#if FF_API_PARSER_CHANGE
int av_parser_change(AVCodecParserContext *s, AVCodecContext *avctx,
uint8_t **poutbuf, int *poutbuf_size,
const uint8_t *buf, int buf_size, int keyframe)
@@ -220,7 +221,7 @@ int av_parser_change(AVCodecParserContext *s,
AVCodecContext *avctx,
return 0;
}
-
+#endif
void av_parser_close(AVCodecParserContext *s)
{
if (s) {
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 488def4c23..815df15628 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -150,6 +150,9 @@
#ifndef FF_API_MPV_RC_STRATEGY
#define FF_API_MPV_RC_STRATEGY (LIBAVCODEC_VERSION_MAJOR < 59)
#endif
+#ifndef FF_API_PARSER_CHANGE
+#define FF_API_PARSER_CHANGE (LIBAVCODEC_VERSION_MAJOR < 59)
>>>
>>> A doxygen deprecation notice is not enough to consider the function
>>> deprecated. There was no APIChanges entry and no attribute added to the
>>> function prototype.
>>> So this needs the APIChanges entry, and therefore be scheduled as < 60.
>>
>> I disagree. Of course Doxygen deprecations count and being on the list
>> of deprecated things [1] for more than eight years is enough.
>
> If there was no APIChanges entry that references a library version, then
> this can not be considered deprecated and can not be removed until a
> bump at least 2 years from now. Even more so when there was no
> deprecation attribute on the function to warn its users.
>
I disagree; I just don't see why a doxygen deprecation should count for
nothing.
> So please, change it to < 60. It's an absolutely harmless standalone
> function and can stay around for a proper deprecation period.
>
>>
>> - Andreas
>>
>> [1]: https://ffmpeg.org/doxygen/trunk/deprecated.html#_deprecated07
>>
>>>
>>> LGTM otherwise.
>>>
+#endif
#ifndef FF_API_THREAD_SAFE_CALLBACKS
#define FF_API_THREAD_SAFE_CALLBACKS (LIBAVCODEC_VERSION_MAJOR < 60)
#endif
>> ___
>> 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".
___
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".
Re: [FFmpeg-devel] [PATCH 4/5] avcodec/parser: Schedule av_parser_change for removal
On Tue, Mar 2, 2021 at 6:14 AM Andreas Rheinhardt
wrote:
>
> James Almer:
> > On 3/1/2021 12:36 PM, Andreas Rheinhardt wrote:
> >> James Almer:
> >>> On 2/26/2021 10:18 AM, Andreas Rheinhardt wrote:
> Originally deprecated in 748c2fca7e4d99357c234936aa71212a6282be36,
> publically deprecated in 9a07c1332cfe092b57b5758f22b686ca58806c60
> (merged into FFmpeg in 1885ffb03d0af28e6bac2bcc8725fa15b93f6ac9).
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/avcodec.h | 6 +-
> libavcodec/parser.c | 3 ++-
> libavcodec/version.h | 3 +++
> 3 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 3178c163b9..a8741df04b 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3576,14 +3576,18 @@ int av_parser_parse2(AVCodecParserContext *s,
> int64_t pts, int64_t dts,
> int64_t pos);
> +#if FF_API_PARSER_CHANGE
> /**
> * @return 0 if the output buffer is a subset of the input, 1 if it
> is allocated and must be freed
> - * @deprecated use AVBitStreamFilter
> + * @deprecated Use dump_extradata, remove_extra or extract_extradata
> + * bitstream filters instead.
> */
> +attribute_deprecated
> int av_parser_change(AVCodecParserContext *s,
> AVCodecContext *avctx,
> uint8_t **poutbuf, int *poutbuf_size,
> const uint8_t *buf, int buf_size, int
> keyframe);
> +#endif
> void av_parser_close(AVCodecParserContext *s);
> /**
> diff --git a/libavcodec/parser.c b/libavcodec/parser.c
> index a63f532c48..f4bc00da7d 100644
> --- a/libavcodec/parser.c
> +++ b/libavcodec/parser.c
> @@ -186,6 +186,7 @@ int av_parser_parse2(AVCodecParserContext *s,
> AVCodecContext *avctx,
> return index;
> }
> +#if FF_API_PARSER_CHANGE
> int av_parser_change(AVCodecParserContext *s, AVCodecContext *avctx,
> uint8_t **poutbuf, int *poutbuf_size,
> const uint8_t *buf, int buf_size, int keyframe)
> @@ -220,7 +221,7 @@ int av_parser_change(AVCodecParserContext *s,
> AVCodecContext *avctx,
> return 0;
> }
> -
> +#endif
> void av_parser_close(AVCodecParserContext *s)
> {
> if (s) {
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 488def4c23..815df15628 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -150,6 +150,9 @@
> #ifndef FF_API_MPV_RC_STRATEGY
> #define FF_API_MPV_RC_STRATEGY (LIBAVCODEC_VERSION_MAJOR < 59)
> #endif
> +#ifndef FF_API_PARSER_CHANGE
> +#define FF_API_PARSER_CHANGE (LIBAVCODEC_VERSION_MAJOR < 59)
> >>>
> >>> A doxygen deprecation notice is not enough to consider the function
> >>> deprecated. There was no APIChanges entry and no attribute added to the
> >>> function prototype.
> >>> So this needs the APIChanges entry, and therefore be scheduled as < 60.
> >>
> >> I disagree. Of course Doxygen deprecations count and being on the list
> >> of deprecated things [1] for more than eight years is enough.
> >
> > If there was no APIChanges entry that references a library version, then
> > this can not be considered deprecated and can not be removed until a
> > bump at least 2 years from now. Even more so when there was no
> > deprecation attribute on the function to warn its users.
> >
>
> I disagree; I just don't see why a doxygen deprecation should count for
> nothing.
>
Because its hard to get notified about changes there, and thus people
don't notice. I might read doxygen when I write new code, but for
existing code I wouldn't go around reading docs for functions that I
am already using checking for changes.
The entire point of the deprecation period is to inform users of an
upcoming change, but putting it only in doxygen is just not effective
at that task at all. Users can be assumed to be reading APIchanges, a
central place for all relevant changes (even if most probably don't),
or even better get compiler deprecation warnings. Either of those
would be good, both even better.
- Hendrik
___
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".
Re: [FFmpeg-devel] [PATCH 6/6] avformat: Deprecate AVFMT_FLAG_PRIV_OPT, remove av_demuxer_open on bump
Andreas Rheinhardt:
> This flag was added in 492026209b9b58eaf6d2ea56423f6b1e1a8a76a5
> in conjunction with av_demuxer_open() to allow to pass private
> options to demuxers. It worked as follows: av_open_input_stream()
> (the predecessor of avformat_open_input()) would not call the
> read_header function if this flag is set. Instead the user could set
> private options of the demuxer via the format's private class after
> avformat_open_input() and then call av_demuxer_open() which called
> the format's read_header function.
>
> This approach was abandoned in e37f161e66e042d6c2c7470c4d9881df9427fc4a
> and av_demuxer_open() deprecated; instead the AVDictionary based way of
> passing private options to the demuxer was choosen. Yet
> AVFMT_FLAG_PRIV_OPT has never been deprecated and av_demuxer_open()
> never removed. This commit implements the deprecation of the flag and
> schedules av_demuxer_open for removal on the next major bump.
> Given that av_demuxer_open() has been deprecated in 2012 and that this
> flag is useless without it, the flag will be ignored after the next
> major version bump.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> doc/APIchanges | 4
> libavformat/avformat.h | 9 -
> libavformat/utils.c| 12 ++--
> libavformat/version.h | 8 +++-
> 4 files changed, 29 insertions(+), 4 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 33be750af2..baa2b24daf 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,10 @@ libavutil: 2017-10-21
>
> API changes, most recent first:
>
> +2021-02-26 - xx - lavf 58.69.100 - avformat.h
> + Deprecate AVFMT_FLAG_PRIV_OPT. It will do nothing
> + as soon as av_demuxer_open() is removed.
> +
> 2021-02-21 - xx - lavu 56.66.100 - tx.h
>Add enum AVTXFlags and AVTXFlags.AV_TX_INPLACE
>
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 41482328f6..7da2f3d98e 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -1379,7 +1379,9 @@ typedef struct AVFormatContext {
> #define AVFMT_FLAG_MP4A_LATM0x8000 ///< Deprecated, does nothing.
> #endif
> #define AVFMT_FLAG_SORT_DTS0x1 ///< try to interleave outputted
> packets by dts (using this flag can slow demuxing down)
> -#define AVFMT_FLAG_PRIV_OPT0x2 ///< Enable use of private options by
> delaying codec open (this could be made default once all code is converted)
> +#if FF_API_LAVF_PRIV_OPT
> +#define AVFMT_FLAG_PRIV_OPT0x2 ///< Enable use of private options by
> delaying codec open (deprecated, will do nothing once av_demuxer_open() is
> removed)
> +#endif
> #if FF_API_LAVF_KEEPSIDE_FLAG
> #define AVFMT_FLAG_KEEP_SIDE_DATA 0x4 ///< Deprecated, does nothing.
> #endif
> @@ -2210,8 +2212,13 @@ int av_probe_input_buffer(AVIOContext *pb, ff_const59
> AVInputFormat **fmt,
> */
> int avformat_open_input(AVFormatContext **ps, const char *url, ff_const59
> AVInputFormat *fmt, AVDictionary **options);
>
> +#if FF_API_DEMUXER_OPEN
> +/**
> + * @deprecated Use an AVDictionary to pass options to a demuxer.
> + */
> attribute_deprecated
> int av_demuxer_open(AVFormatContext *ic);
> +#endif
>
> /**
> * Read packets of a media file to get stream information. This
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 6e92bd777a..36164e0f0d 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -392,6 +392,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
> //
> /* input media file */
>
> +#if FF_API_DEMUXER_OPEN
> int av_demuxer_open(AVFormatContext *ic) {
> int err;
>
> @@ -411,7 +412,7 @@ int av_demuxer_open(AVFormatContext *ic) {
>
> return 0;
> }
> -
> +#endif
> /* Open input file and probe the format if necessary. */
> static int init_input(AVFormatContext *s, const char *filename,
>AVDictionary **options)
> @@ -594,8 +595,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
> if (s->pb)
> ff_id3v2_read_dict(s->pb, &s->internal->id3v2_meta,
> ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta);
>
> -
> +#if FF_API_DEMUXER_OPEN
> if (!(s->flags&AVFMT_FLAG_PRIV_OPT) && s->iformat->read_header)
> +#else
> +if (s->iformat->read_header)
> +#endif
> if ((ret = s->iformat->read_header(s)) < 0)
> goto fail;
>
> @@ -624,7 +628,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
> if ((ret = avformat_queue_attached_pictures(s)) < 0)
> goto close;
>
> +#if FF_API_DEMUXER_OPEN
> if (!(s->flags&AVFMT_FLAG_PRIV_OPT) && s->pb &&
> !s->internal->data_offset)
> +#else
> +if (s->pb && !s->internal->data_offset)
> +#endif
> s->internal->data_offset = avio_tell(s->pb);
>
> s->internal->raw_packet_buffer_remaining_size = RAW_PACKET_BUFFER_SIZE;
> diff --git a/libavformat/version.h b/libavformat/version.h
> index c11d885b83..7d16c4d6a5 100644
> --- a/libavformat/version.h
> +++ b/libavformat/ve
