Re: [FFmpeg-devel] [PATCH] avfilter: Added siti filter

2021-01-14 Thread Lynne
Jan 15, 2021, 06:06 by borba...@fb.com:

>
> Calculate Spatial Info (SI) and Temporal Info (TI) scores for a video, as 
> defined
> in ITU-T P.910: Subjective video quality assessment methods for multimedia
> applications.
> ---
>  Changelog|   1 +
>  doc/filters.texi |  25 
>  libavfilter/Makefile |   1 +
>  libavfilter/allfilters.c |   1 +
>  libavfilter/version.h|   2 +-
>  libavfilter/vf_siti.c| 359 
> +++
>  6 files changed, 388 insertions(+), 1 deletion(-)
>  create mode 100644 libavfilter/vf_siti.c
>
> +// Determine whether the video is in full or limited range. If not defined, 
> assume limited.
> +static int is_full_range(AVFrame* frame)
> +{
> +if (frame->color_range == AVCOL_RANGE_UNSPECIFIED || frame->color_range 
> == AVCOL_RANGE_NB)
> +{
> +// If color range not specified, fallback to pixel format
> +return frame->format == AV_PIX_FMT_YUVJ420P || frame->format == 
> AV_PIX_FMT_YUVJ422P;
> +}
> +return frame->color_range == AVCOL_RANGE_JPEG;
> +}
> +
> +// Check frame's color range and convert to full range if needed
> +static uint16_t convert_full_range(uint16_t y, SiTiContext *s)
> +{
> +if (s->full_range == 1)
> +{
> +return y;
> +}
> +
> +// For 8 bits, limited range goes from 16 to 235, for 10 bits the range 
> is multiplied by 4
> +double factor = s->pixel_depth == 1? 1 : 4;
> +double shift = 16 * factor;
> +double limit_upper = 235 * factor - shift;
> +double full_upper = 256 * factor - 1;
> +double limit_y = fmin(fmax(y - shift, 0), limit_upper);
> +return (uint16_t) (full_upper * limit_y / limit_upper);
> +}
> +
> +// Applies sobel convolution
> +static void convolve_sobel(const unsigned char* src, double* dst, int 
> linesize, SiTiContext *s)
> +{
> +int filter_width = 3;
> +int filter_size = filter_width * filter_width;
> +for (int j=1; jheight-1; j++)
> +{
> +for (int i=1; iwidth-1; i++)
> +{
> +double x_conv_sum = 0, y_conv_sum = 0;
> +for (int k=0; k +{
> +int ki = k % filter_width - 1;
> +int kj = floor(k / filter_width) - 1;
> +int index = (j + kj) * (linesize / s->pixel_depth) + (i + 
> ki);
> +uint16_t data = convert_full_range(get_frame_data(src, 
> s->pixel_depth, index), s);
> +x_conv_sum += data * X_FILTER[k];
> +y_conv_sum += data * Y_FILTER[k];
> +}
> +double gradient = sqrt(x_conv_sum * x_conv_sum + y_conv_sum * 
> y_conv_sum);
> +// Dst matrix is smaller than src since we ignore edges that 
> can't be convolved
> +dst[(j - 1) * (s->width - 2) + (i - 1)] = gradient;
> +}
> +}
> +}
> +
> +// Calculate pixel difference between current and previous frame, and update 
> previous
> +static void calculate_motion(const unsigned char* curr, double* 
> motion_matrix,
> + int linesize, SiTiContext *s)
> +{
> +for (int j=0; jheight; j++)
> +{
> +for (int i=0; iwidth; i++)
> +{
> +double motion = 0;
> +int curr_index = j * (linesize / s->pixel_depth) + i;
> +int prev_index = j * s->width + i;
> +uint16_t curr_data = convert_full_range(get_frame_data(curr, 
> s->pixel_depth, curr_index), s);
> +
> +if (s->nb_frames > 1)
> +{
> +// Previous frame is already converted to full range
> +motion = curr_data - get_frame_data(s->prev_frame, 
> s->pixel_depth, prev_index);
> +}
> +set_frame_data(s->prev_frame, s->pixel_depth, prev_index, 
> curr_data);
> +motion_matrix[j * s->width + i] = motion;
> +}
> +}
> +}
> +
> +static double std_deviation(double* img_metrics, int width, int height)
> +{
> +double size = height * width;
> +
> +double mean_sum = 0;
> +for (int j=0; j +{
> +for (int i=0; i +{
> +mean_sum += img_metrics[j * width + i];
> +}
> +}
> +double mean = mean_sum / size;
> +
> +double sqr_diff_sum = 0;
> +for (int j=0; j +{
> +for (int i=0; i +{
> +double mean_diff = img_metrics[j * width + i] - mean;
> +sqr_diff_sum += (mean_diff * mean_diff);
> +}
> +}
>

The coding style mismatches the project's style.
We don't put opening brackets on a new line and in
case of single-line blocks we leave the brackets off entirely.


> +
> +#define OFFSET(x) offsetof(SiTiContext, x)
> +#define FLAGS AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
> +
> +static const AVOption siti_options[] = {
> +{"stats_file", "Set file where to store per-frame si-ti scores", 
> OFFSET(stats_file_str), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, FLAGS },
> +{ NULL }
> +};
>

Make it output the data 

Re: [FFmpeg-devel] [PATCH V2] libavfilter/dnn: add batch mode for async execution

2021-01-14 Thread Steven Liu


> 2021年1月10日 下午9:16,Guo, Yejun  写道:
> 
> the default number of batch_size is 1
> 
> Signed-off-by: Xie, Lin 
> Signed-off-by: Wu Zhiwen 
> Signed-off-by: Guo, Yejun 
> ---
> libavfilter/dnn/dnn_backend_openvino.c | 187 -
> libavfilter/dnn/dnn_backend_openvino.h |   1 +
> libavfilter/dnn/dnn_interface.c|   1 +
> libavfilter/dnn_interface.h|   2 +
> libavfilter/vf_dnn_processing.c|  36 -
> 5 files changed, 194 insertions(+), 33 deletions(-)
> 
> diff --git a/libavfilter/dnn/dnn_backend_openvino.c 
> b/libavfilter/dnn/dnn_backend_openvino.c
> index d27e451eea..5271d1caa5 100644
> --- a/libavfilter/dnn/dnn_backend_openvino.c
> +++ b/libavfilter/dnn/dnn_backend_openvino.c
> @@ -37,6 +37,7 @@
> typedef struct OVOptions{
> char *device_type;
> int nireq;
> +int batch_size;
> } OVOptions;
> 
> typedef struct OVContext {
> @@ -70,7 +71,8 @@ typedef struct TaskItem {
> 
> typedef struct RequestItem {
> ie_infer_request_t *infer_request;
> -TaskItem *task;
> +TaskItem **tasks;
> +int task_count;
> ie_complete_call_back_t callback;
> } RequestItem;
> 
> @@ -83,6 +85,7 @@ typedef struct RequestItem {
> static const AVOption dnn_openvino_options[] = {
> { "device", "device to run model", OFFSET(options.device_type), 
> AV_OPT_TYPE_STRING, { .str = "CPU" }, 0, 0, FLAGS },
> { "nireq",  "number of request",   OFFSET(options.nireq),   
> AV_OPT_TYPE_INT,{ .i64 = 0 }, 0, INT_MAX, FLAGS },
> +{ "batch_size",  "batch size per request", OFFSET(options.batch_size),  
> AV_OPT_TYPE_INT,{ .i64 = 1 }, 1, 1000, FLAGS},
> { NULL }
> };
> 
> @@ -100,7 +103,19 @@ static DNNDataType precision_to_datatype(precision_e 
> precision)
> }
> }
> 
> -static DNNReturnType fill_model_input_ov(OVModel *ov_model, TaskItem *task, 
> RequestItem *request)
> +static int get_datatype_size(DNNDataType dt)
> +{
> +switch (dt)
> +{
> +case DNN_FLOAT:
> +return sizeof(float);
> +default:
> +av_assert0(!"not supported yet.");
> +return 1;
Why don’t try about this way ? :D
avpriv_request_sample()
AVERROR_PATCHWELCOME;

> +}
> +}
> +
> +static DNNReturnType fill_model_input_ov(OVModel *ov_model, RequestItem 
> *request)
> {
> dimensions_t dims;
> precision_e precision;
> @@ -109,6 +124,7 @@ static DNNReturnType fill_model_input_ov(OVModel 
> *ov_model, TaskItem *task, Requ
> IEStatusCode status;
> DNNData input;
> ie_blob_t *input_blob = NULL;
> +TaskItem *task = request->tasks[0];
> 
> status = ie_infer_request_get_blob(request->infer_request, 
> task->input_name, _blob);
> if (status != OK) {
> @@ -134,12 +150,19 @@ static DNNReturnType fill_model_input_ov(OVModel 
> *ov_model, TaskItem *task, Requ
> input.channels = dims.dims[1];
> input.data = blob_buffer.buffer;
> input.dt = precision_to_datatype(precision);
> -if (task->do_ioproc) {
> -if (ov_model->model->pre_proc != NULL) {
> -ov_model->model->pre_proc(task->in_frame, , 
> ov_model->model->filter_ctx);
> -} else {
> -proc_from_frame_to_dnn(task->in_frame, , ctx);
> +
> +av_assert0(request->task_count <= dims.dims[0]);
> +for (int i = 0; i < request->task_count; ++i) {
> +task = request->tasks[i];
> +if (task->do_ioproc) {
> +if (ov_model->model->pre_proc != NULL) {
> +ov_model->model->pre_proc(task->in_frame, , 
> ov_model->model->filter_ctx);
> +} else {
> +proc_from_frame_to_dnn(task->in_frame, , ctx);
> +}
> }
> +input.data = (uint8_t *)input.data
> + + input.width * input.height * input.channels * 
> get_datatype_size(input.dt);
> }
> ie_blob_free(_blob);
> 
> @@ -152,7 +175,7 @@ static void infer_completion_callback(void *args)
> precision_e precision;
> IEStatusCode status;
> RequestItem *request = args;
> -TaskItem *task = request->task;
> +TaskItem *task = request->tasks[0];
> ie_blob_t *output_blob = NULL;
> ie_blob_buffer_t blob_buffer;
> DNNData output;
> @@ -194,41 +217,56 @@ static void infer_completion_callback(void *args)
> output.width= dims.dims[3];
> output.dt   = precision_to_datatype(precision);
> output.data = blob_buffer.buffer;
> -if (task->do_ioproc) {
> -if (task->ov_model->model->post_proc != NULL) {
> -task->ov_model->model->post_proc(task->out_frame, , 
> task->ov_model->model->filter_ctx);
> +
> +av_assert0(request->task_count <= dims.dims[0]);
> +av_assert0(request->task_count >= 1);
> +for (int i = 0; i < request->task_count; ++i) {
> +task = request->tasks[i];
> +if (task->do_ioproc) {
> +if (task->ov_model->model->post_proc != NULL) {
> +task->ov_model->model->post_proc(task->out_frame, , 
> task->ov_model->model->filter_ctx);
> +

Re: [FFmpeg-devel] [PATCH V2] libavfilter/dnn: add batch mode for async execution

2021-01-14 Thread Guo, Yejun


> -Original Message-
> From: ffmpeg-devel  On Behalf Of Fu,
> Ting
> Sent: 2021年1月14日 22:45
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH V2] libavfilter/dnn: add batch mode for
> async execution
> 
> 
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of Guo,
> > Yejun
> > Sent: Sunday, January 10, 2021 09:16 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Guo, Yejun 
> > Subject: [FFmpeg-devel] [PATCH V2] libavfilter/dnn: add batch mode for
> > async execution
> >
> > the default number of batch_size is 1
> >
> > Signed-off-by: Xie, Lin 
> > Signed-off-by: Wu Zhiwen 
> > Signed-off-by: Guo, Yejun 
> > ---
> >  libavfilter/dnn/dnn_backend_openvino.c | 187
> -
> >  libavfilter/dnn/dnn_backend_openvino.h |   1 +
> >  libavfilter/dnn/dnn_interface.c|   1 +
> >  libavfilter/dnn_interface.h|   2 +
> >  libavfilter/vf_dnn_processing.c|  36 -
> >  5 files changed, 194 insertions(+), 33 deletions(-)
> >
> > --
> > 2.17.1
> 
> Hi Yejun,
> This patch works well for me.
> Testing was carried on my machine, which CPU is i7-8700K 3.7Ghz and iGPU is
> UHD630.
> The patch was tested by using espcn super resolution model (950*540 video as
> input), with async on and off. The fps increased from 11fps to 13fps (~18% up)
> on CPU, from 8fps to 11fps (~37% up) on iGPU.
> 
> On CPU with async off:
> ./ffmpeg -i input_video.mp4 -vf
> dnn_processing=dnn_backend=openvino:model=espcn1080p.xml:input=x:outp
> ut=espcn/prediction:async=0:options=device=CPU\_size=1 -y
> output_video.mp4 On CPU with async on:
> ./ffmpeg -i input_video.mp4 -vf
> dnn_processing=dnn_backend=openvino:model=espcn1080p.xml:input=x:outp
> ut=espcn/prediction:async=1:options=device=CPU\_size=2 -y
> output_video.mp4
> 
> On GPU with async off:
> ./ffmpeg -i input_video.mp4 -vf
> dnn_processing=dnn_backend=openvino:model=espcn1080p.xml:input=x:outp
> ut=espcn/prediction:async=0:options=device=GPU\_size=1 -y
> output_video.mp4 On GPU with async on:
> ./ffmpeg -i input_video.mp4 -vf
> dnn_processing=dnn_backend=openvino:model=espcn1080p.xml:input=x:outp
> ut=espcn/prediction:async=1:options=device=GPU\_size=2 -y
> output_video.mp4
> 
thanks Ting for the test, will push 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".

[FFmpeg-devel] [PATCH 2/7] avformat/bfi: Check chunk_header

2021-01-14 Thread Michael Niedermayer
Fixes: signed integer overflow: -2147483648 - 3 cannot be represented in type 
'int'
Fixes: 
26910/clusterfuzz-testcase-minimized-ffmpeg_dem_BFI_fuzzer-6665764123836416

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavformat/bfi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/bfi.c b/libavformat/bfi.c
index 29e2cf8cf4..2dab986f3a 100644
--- a/libavformat/bfi.c
+++ b/libavformat/bfi.c
@@ -69,6 +69,9 @@ static int bfi_read_header(AVFormatContext * s)
 /* Set the total number of frames. */
 avio_skip(pb, 8);
 chunk_header   = avio_rl32(pb);
+if (chunk_header < 3)
+return AVERROR_INVALIDDATA;
+
 bfi->nframes   = avio_rl32(pb);
 avio_rl32(pb);
 avio_rl32(pb);
-- 
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 7/7] avformat/mccdec: Use av_sat_add64() for fs

2021-01-14 Thread Michael Niedermayer
Fixes: signed integer overflow: -9223372036854775808 + -242 cannot be 
represented in type 'long'
Fixes: 
26910/clusterfuzz-testcase-minimized-ffmpeg_dem_MCC_fuzzer-6723018395090944

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavformat/mccdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mccdec.c b/libavformat/mccdec.c
index 874ff45cdf..2a0b7905a0 100644
--- a/libavformat/mccdec.c
+++ b/libavformat/mccdec.c
@@ -142,7 +142,7 @@ static int mcc_read_header(AVFormatContext *s)
 if (av_sscanf(line, "%d:%d:%d:%d", , , , ) != 4)
 continue;
 
-ts = av_rescale(hh * 3600LL + mm * 60LL + ss, rate.num, rate.den) + fs;
+ts = av_sat_add64(av_rescale(hh * 3600LL + mm * 60LL + ss, rate.num, 
rate.den), fs);
 
 lline = (char *)
 lline += 12;
-- 
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 1/7] avformat/ads: Check size

2021-01-14 Thread Michael Niedermayer
Fixes: signed integer overflow: -2147483616 - 64 cannot be represented in type 
'int'
Fixes: 
26910/clusterfuzz-testcase-minimized-ffmpeg_dem_ADS_fuzzer-6617769344892928

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavformat/ads.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavformat/ads.c b/libavformat/ads.c
index f25141b3c6..544d652829 100644
--- a/libavformat/ads.c
+++ b/libavformat/ads.c
@@ -34,8 +34,9 @@ static int ads_probe(const AVProbeData *p)
 
 static int ads_read_header(AVFormatContext *s)
 {
-int align, codec, size;
+int align, codec;
 AVStream *st;
+int64_t size;
 
 st = avformat_new_stream(s, NULL);
 if (!st)
@@ -62,7 +63,7 @@ static int ads_read_header(AVFormatContext *s)
 st->codecpar->block_align = st->codecpar->channels * align;
 avio_skip(s->pb, 12);
 size = avio_rl32(s->pb);
-if (st->codecpar->codec_id == AV_CODEC_ID_ADPCM_PSX)
+if (st->codecpar->codec_id == AV_CODEC_ID_ADPCM_PSX && size >= 0x40)
 st->duration = (size - 0x40) / 16 / st->codecpar->channels * 28;
 avpriv_set_pts_info(st, 64, 1, st->codecpar->sample_rate);
 
-- 
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 6/7] avformat/lxfdec: Fix multiple integer overflows related to track_size

2021-01-14 Thread Michael Niedermayer
Fixes: signed integer overflow: 538976288 * 8 cannot be represented in type 
'int'
Fixes: 
26910/clusterfuzz-testcase-minimized-ffmpeg_dem_LXF_fuzzer-6634030636335104

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavformat/lxfdec.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/lxfdec.c b/libavformat/lxfdec.c
index fa84ceea78..509d19fe7f 100644
--- a/libavformat/lxfdec.c
+++ b/libavformat/lxfdec.c
@@ -195,7 +195,7 @@ static int get_packet_header(AVFormatContext *s)
 return AVERROR_PATCHWELCOME;
 }
 
-samples = track_size * 8 / st->codecpar->bits_per_coded_sample;
+samples = track_size * 8LL / st->codecpar->bits_per_coded_sample;
 
 //use audio packet size to determine video standard
 //for NTSC we have one 8008-sample audio frame per five video frames
@@ -210,6 +210,8 @@ static int get_packet_header(AVFormatContext *s)
 avpriv_set_pts_info(s->streams[0], 64, 1, 25);
 }
 
+if (av_popcount(channels) * (uint64_t)track_size > INT_MAX)
+return AVERROR_INVALIDDATA;
 //TODO: warning if track mask != (1 << channels) - 1?
 ret = av_popcount(channels) * track_size;
 
-- 
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 5/7] avformat/flvdec: Use av_sat_add64() for pts computation

2021-01-14 Thread Michael Niedermayer
Fixes: signed integer overflow: -9223372036854767583 + -65536 cannot be 
represented in type 'long'
Fixes: 
26910/clusterfuzz-testcase-minimized-ffmpeg_dem_FLV_fuzzer-6734549467922432

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavformat/flvdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index ad6e7a3ca5..07ef342278 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1231,7 +1231,7 @@ retry_duration:
 if (st->codecpar->codec_id == AV_CODEC_ID_H264 || 
st->codecpar->codec_id == AV_CODEC_ID_MPEG4) {
 // sign extension
 int32_t cts = (avio_rb24(s->pb) + 0xff80) ^ 0xff80;
-pts = dts + cts;
+pts = av_sat_add64(dts, cts);
 if (cts < 0) { // dts might be wrong
 if (!flv->wrong_dts)
 av_log(s, AV_LOG_WARNING,
-- 
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 4/7] avformat/utils: Check dts - (1<

2021-01-14 Thread Michael Niedermayer
Fixes: signed integer overflow: -9223372036842389247 - 2147483648 cannot be 
represented in type 'long long'
Fixes: 
26910/clusterfuzz-testcase-minimized-ffmpeg_dem_FLV_fuzzer-4845007531671552

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavformat/utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index d193f9e85f..bf904ef2c5 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1251,7 +1251,7 @@ static void compute_pkt_fields(AVFormatContext *s, 
AVStream *st,
 presentation_delayed = 1;
 
 if (pkt->pts != AV_NOPTS_VALUE && pkt->dts != AV_NOPTS_VALUE &&
-st->pts_wrap_bits < 63 &&
+st->pts_wrap_bits < 63 && pkt->dts > INT64_MIN + (1LL << 
(st->pts_wrap_bits - 1)) &&
 pkt->dts - (1LL << (st->pts_wrap_bits - 1)) > pkt->pts) {
 if (is_relative(st->cur_dts) || pkt->dts - (1LL<<(st->pts_wrap_bits - 
1)) > st->cur_dts) {
 pkt->dts -= 1LL << st->pts_wrap_bits;
-- 
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 3/7] avutil/parseutils: Check sign in av_parse_time()

2021-01-14 Thread Michael Niedermayer
Fixes: signed integer overflow: -9223372053736 * 100 cannot be represented 
in type 'long'
Fixes: 
26910/clusterfuzz-testcase-minimized-ffmpeg_dem_CONCAT_fuzzer-6607924558430208

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavutil/parseutils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/parseutils.c b/libavutil/parseutils.c
index 167e822648..6161f4ac95 100644
--- a/libavutil/parseutils.c
+++ b/libavutil/parseutils.c
@@ -736,7 +736,7 @@ int av_parse_time(int64_t *timeval, const char *timestr, 
int duration)
 if (*q)
 return AVERROR(EINVAL);
 
-if (INT64_MAX / suffix < t)
+if (t < 0 || INT64_MAX / suffix < t)
 return AVERROR(ERANGE);
 t *= suffix;
 if (INT64_MAX - microseconds < t)
-- 
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] [vf_tonemap_cuda] VERY alpha ground work- implemented only reinhard

2021-01-14 Thread Soft Works


> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Lynne
> Sent: Thursday, January 14, 2021 9:16 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [vf_tonemap_cuda] VERY alpha ground work-
> implemented only reinhard
> 
> Could we not have another bitrotting tonemap implementation?

Why? Because you're working on a Vulkan tone mapping filter?

From my point of view, a native CUDA tone mapping filter is an important
bit that is currently missing and preferable over a solution that requires
hw context derivation.

> On 2020-07-04 08:37, James Almer wrote:
> > …Another thing worth mentioning is a lack of new blood. Despite 
> > participating in GSoC for a long while, i can't name a student that 
> > stuck around after the fact. Mind, there are new devs that started 
> > contributing for other reasons, but perhaps not enough?

Hmm, let's think about this: how long do we expect this guy to stay
here when he's getting answers like above?

softworkz




___
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] [vf_tonemap_cuda] VERY alpha ground work- implemented only reinhard

2021-01-14 Thread Felix LeClair

Not sure what you mean by that?


On Thu, Jan 14, 2021 at 9:15 pm, Lynne  wrote:
Jan 14, 2021, 21:01 by felix.leclair...@hotmail.com 
:



 Hey everyone!

 Trying to wrap my mind around how to deal with cuda HW frames and 
how to implement them.


 The goal of this filter once completed will be to take in a cuda 
frame, tonemap the value to a given specification using a user 
requested algorithm (mobius, hable reinhard clip etc.)


 This is useful because it completes (should) outperform cpu based 
tonemapping by multiple 1-3 orders of magnitude depending on the gpu 
used for the filter.


 I've based the attached filter off of the vf_scale_cuda.cu filter.

 For ease of developement, I've kept everything the same including 
the name of the filter, only changing the funtion within the file. 
This is very much a bodge to facilitate development.  As such, for 
testing, this file should replace the vf_scale_cuda.cu file in 
ffmpeg/libavfilter/vf_scale_cuda.cu


 FFmpeg should then be compiled as standard for cuda filters and 
should be called as you would call the standard vf_scale_cuda filter.

 The command would be similar to:
  ffmpeg -y -vsync 0 -hwaccel cuda -hwaccel_output_format cuda -i 
input.mp4 -vf scale_cuda=Source_width:Source_Height -c:a copy -c:v 
h264_nvenc -b:v 5M output.mp4


 The above should decode in hardware, tonemap the frame on gpu and 
re-encode in hardware at a given bitrate.


 will be in the freenode soon after sending this email (going to put 
on another cup of coffee )


 Thanks,

 FelixCLC (felix__)

 Caviat: Like all HW filters, how effective this is will depend on 
how much overhead is faced by doing a memcpy over the pcie bus to 
the gpu itself, then passing the data back once processed.




Could we not have another bitrotting tonemap implementation?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org 


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] [vf_tonemap_cuda] VERY alpha ground work- implemented only reinhard

2021-01-14 Thread Lynne
Jan 14, 2021, 21:01 by felix.leclair...@hotmail.com:

> Hey everyone!
>
> Trying to wrap my mind around how to deal with cuda HW frames and how to 
> implement them.
>
> The goal of this filter once completed will be to take in a cuda frame, 
> tonemap the value to a given specification using a user requested algorithm 
> (mobius, hable reinhard clip etc.)
>
> This is useful because it completes (should) outperform cpu based tonemapping 
> by multiple 1-3 orders of magnitude depending on the gpu used for the filter.
>
> I've based the attached filter off of the vf_scale_cuda.cu filter.
>
> For ease of developement, I've kept everything the same including the name of 
> the filter, only changing the funtion within the file. This is very much a 
> bodge to facilitate development.  As such, for testing, this file should 
> replace the vf_scale_cuda.cu file in ffmpeg/libavfilter/vf_scale_cuda.cu
>
> FFmpeg should then be compiled as standard for cuda filters and should be 
> called as you would call the standard vf_scale_cuda filter.
> The command would be similar to:
>  ffmpeg -y -vsync 0 -hwaccel cuda -hwaccel_output_format cuda -i input.mp4 
> -vf scale_cuda=Source_width:Source_Height -c:a copy -c:v h264_nvenc -b:v 5M 
> output.mp4
>
> The above should decode in hardware, tonemap the frame on gpu and re-encode 
> in hardware at a given bitrate.
>
> will be in the freenode soon after sending this email (going to put on 
> another cup of coffee )
>
> Thanks,
>
> FelixCLC (felix__)
>
> Caviat: Like all HW filters, how effective this is will depend on how much 
> overhead is faced by doing a memcpy over the pcie bus to the gpu itself, then 
> passing the data back once processed.
>

Could we not have another bitrotting tonemap implementation?
___
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] [vf_tonemap_cuda] VERY alpha ground work- implemented only reinhard

2021-01-14 Thread Felix LeClair

Hey everyone!

Trying to wrap my mind around how to deal with cuda HW frames and how 
to implement them.


The goal of this filter once completed will be to take in a cuda frame, 
tonemap the value to a given specification using a user requested 
algorithm (mobius, hable reinhard clip etc.)


This is useful because it completes (should) outperform cpu based 
tonemapping by multiple 1-3 orders of magnitude depending on the gpu 
used for the filter.


I've based the attached filter off of the vf_scale_cuda.cu filter.

For ease of developement, I've kept everything the same including the 
name of the filter, only changing the funtion within the file. This is 
very much a bodge to facilitate development.  As such, for testing, 
this file should replace the vf_scale_cuda.cu file in 
ffmpeg/libavfilter/vf_scale_cuda.cu


FFmpeg should then be compiled as standard for cuda filters and should 
be called as you would call the standard vf_scale_cuda filter.

The command would be similar to:
	ffmpeg -y -vsync 0 -hwaccel cuda -hwaccel_output_format cuda -i 
input.mp4 -vf scale_cuda=Source_width:Source_Height -c:a copy -c:v 
h264_nvenc -b:v 5M output.mp4


The above should decode in hardware, tonemap the frame on gpu and 
re-encode in hardware at a given bitrate.


will be in the freenode soon after sending this email (going to put on 
another cup of coffee )


Thanks,

FelixCLC (felix__)

Caviat: Like all HW filters, how effective this is will depend on how 
much overhead is faced by doing a memcpy over the pcie bus to the gpu 
itself, then passing the data back once processed.





/*
 * original source Copyright (c) 2017, NVIDIA CORPORATION. All rights reserved.
 *
 * Change to tonemap style filter copyright Felix LeClair 
 *
 * Permission is hereby granted, free of charge, to any person obtaining a
 * copy of this software and associated documentation files (the "Software"),
 * to deal in the Software without restriction, including without limitation
 * the rights to use, copy, modify, merge, publish, distribute, sublicense,
 * and/or sell copies of the Software, and to permit persons to whom the
 * Software is furnished to do so, subject to the following conditions:
 *
 * The above copyright notice and this permission notice shall be included in
 * all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
 * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 * DEALINGS IN THE SOFTWARE.
 */

/*

Warning: this is a VERY early alpha of a cuda accelerated filter to tonemap. Please see ffmpeg devel mailing list for message of title [vf_tonemap_cuda] VERY alpha ground work- implemented as cuda frame
sent on the 14th of January 2021 
It's poorly written and documented. this should not be merged under any circumstance in it's present form.


*/


#include "cuda/vector_helpers.cuh"

template
__device__ inline void Subsample_Nearest(cudaTextureObject_t tex,
 T *dst,
 int dst_width, int dst_height, int dst_pitch,
 int src_width, int src_height,
 int bit_depth)
/*
tex is the cuda texture
T is a pointer to the destination frame
dst_width is the width of the output frame
dst_height is the height of the output frame 
dst_pitch is the I DON'T KNOW YET, but I suspect this has to do when changing the size of pixels when shifting aspect ratios.
	 as such I'm going to redifine as 1 so I don't have any issues 
bit_depth  is the amount of bits per colour channel
*/

{
	
	dst_pitch =1;// this is a bodge, but won't be needed when I change the rest of the source to not need to deal with the legacy scalling source code.
int xo = blockIdx.x * blockDim.x + threadIdx.x;
int yo = blockIdx.y * blockDim.y + threadIdx.y;

if (yo < dst_height && xo < dst_width)
{
float hscale = (float)src_width / (float)dst_width;// supposed to be the scalling factor in the original funtion, but I'm going to ignore it
float vscale = (float)src_height / (float)dst_height; // as above, going to ignore it
float xi = (xo + 0.5f); // * hscale;
float yi = (yo + 0.5f); // * vscale;
	float val_IN = tex2D(tex, xi, yi);// to start I'm doing reinhard because it's idiot proof
	float out = val_IN*(val_IN/(val_IN + 1.0f)); // this scales the incoming pixel by a factor of x/(x+1). this guarentees a value between 0 and 1. far from the best algortihm, but is fit for purpose 
	dst[yo*dst_pitch+xo] =out; // this is where I'm transforming the value to the tonemapped value.  
}
}



Re: [FFmpeg-devel] [PATCH v4] avcodec/libvpxenc: add a way to set VP9E_SET_SVC_REF_FRAME_CONFIG

2021-01-14 Thread James Zern
On Tue, Jan 12, 2021 at 3:28 PM James Zern  wrote:
>
> On Fri, Jan 8, 2021 at 3:33 PM Wonkap Jang
>  wrote:
> >
> > In order to fine-control referencing schemes in VP9 encoding, there
> > is a need to use VP9E_SET_SVC_REF_FRAME_CONFIG method. This commit
> > provides a way to use the API through frame metadata.
> > ---
> >  doc/encoders.texi  | 32 
> >  libavcodec/libvpxenc.c | 84 ++
> >  libavcodec/version.h   |  2 +-
> >  3 files changed, 117 insertions(+), 1 deletion(-)
> >
>
> lgtm. I'll push this soon if there aren't any other comments.
>

pushed. thanks for the patch.

> > [...]
> > +}
> > +
>
> I removed this extra whitespace locally.
>
> > +#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] Issue with ogg page termination on full last page with even last segment size

2021-01-14 Thread Peter Zebühr
Hi,

I had a look at different options on how to fix the regression, though I am not 
sure what I arrived at is what you had in mind. 

I tried to read up a bit on opus as well and I assume you are talking about the 
frame length coding allowing coding of zero-byte frames? If so, my 
understanding is that it would still not be represented as a zero byte length 
avpacket input to the oggmuxer?

I looked at how this is handled for flac, as the regression I see is in flac 
muxed in ogg). There libavcoded/flacenc that is intentionally just setting 
extradata in the last avpacket on the last block by no payload (packet_size=0). 
And libavformat/flacenc:flac_write_audio_packet that does not write any audio 
data if packet size is 0.

I am thinking that it should be safe to not mux any 0 sized packets in oggenc 
given that my understanding above is correct. Updated the patch to reflect 
that, let me know what you think.

/ Peter




0001-Fix-ogg-page-termination-on-even-last-packets.patch
Description: Binary data
___
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 2/2] avcodec/dolby_e: Split decoder/parser files

2021-01-14 Thread Nicolas Gaullier
---
 libavcodec/Makefile  |   1 +
 libavcodec/dolby_e.c | 149 +--
 libavcodec/dolby_e.h | 598 +-
 libavcodec/dolby_e_parser.c  | 227 ++
 libavcodec/dolby_e_parser.h  |  41 ++
 libavcodec/dolby_e_parser_internal.h |  46 ++
 libavcodec/dolby_edec.h  | 607 +++
 7 files changed, 932 insertions(+), 737 deletions(-)
 create mode 100644 libavcodec/dolby_e_parser.c
 create mode 100644 libavcodec/dolby_e_parser.h
 create mode 100644 libavcodec/dolby_e_parser_internal.h
 create mode 100644 libavcodec/dolby_edec.h

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 446e6e6b3b..18956b0767 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -40,6 +40,7 @@ OBJS = ac3_parser.o   
  \
d3d11va.o\
decode.o \
dirac.o  \
+   dolby_e_parser.o \
dv_profile.o \
encode.o \
imgconvert.o \
diff --git a/libavcodec/dolby_e.c b/libavcodec/dolby_e.c
index 6bb817ec5c..74388f43d1 100644
--- a/libavcodec/dolby_e.c
+++ b/libavcodec/dolby_e.c
@@ -28,13 +28,14 @@
 #include "put_bits.h"
 #include "parser.h"
 #include "dolby_e.h"
+#include "dolby_edec.h"
+#include "dolby_e_parser_internal.h"
 #include "fft.h"
 
 static int skip_input(DBEContext *s, int nb_words)
 {
 if (nb_words > s->input_size) {
-if (s->avctx)
-av_log(s->avctx, AV_LOG_ERROR, "Packet too short\n");
+av_log(s->avctx, AV_LOG_ERROR, "Packet too short\n");
 return AVERROR_INVALIDDATA;
 }
 
@@ -65,8 +66,7 @@ static int convert_input(DBEContext *s, int nb_words, int key)
 av_assert0(nb_words <= 1024u);
 
 if (nb_words > s->input_size) {
-if (s->avctx)
-av_log(s->avctx, AV_LOG_ERROR, "Packet too short\n");
+av_log(s->avctx, AV_LOG_ERROR, "Packet too short\n");
 return AVERROR_INVALIDDATA;
 }
 
@@ -92,69 +92,6 @@ static int convert_input(DBEContext *s, int nb_words, int 
key)
 return init_get_bits(>gb, s->buffer, nb_words * s->word_bits);
 }
 
-static int parse_metadata(DBEContext *s, DolbyEHeaderInfo *hdr)
-{
-int i, ret, key, mtd_size;
-
-if ((key = parse_key(s)) < 0)
-return key;
-if ((ret = convert_input(s, 1, key)) < 0)
-return ret;
-
-skip_bits(>gb, 4);
-mtd_size = get_bits(>gb, 10);
-if (!mtd_size) {
-if (s->avctx)
-av_log(s->avctx, AV_LOG_ERROR, "Invalid metadata size\n");
-return AVERROR_INVALIDDATA;
-}
-
-if ((ret = convert_input(s, mtd_size, key)) < 0)
-return ret;
-
-skip_bits(>gb, 14);
-hdr->prog_conf = get_bits(>gb, 6);
-if (hdr->prog_conf > MAX_PROG_CONF) {
-if (s->avctx)
-av_log(s->avctx, AV_LOG_ERROR, "Invalid program configuration\n");
-return AVERROR_INVALIDDATA;
-}
-
-hdr->nb_channels = nb_channels_tab[hdr->prog_conf];
-hdr->nb_programs = nb_programs_tab[hdr->prog_conf];
-
-hdr->fr_code  = get_bits(>gb, 4);
-hdr->fr_code_orig = get_bits(>gb, 4);
-if (!sample_rate_tab[hdr->fr_code] ||
-!sample_rate_tab[hdr->fr_code_orig]) {
-if (s->avctx)
-av_log(s->avctx, AV_LOG_ERROR, "Invalid frame rate code\n");
-return AVERROR_INVALIDDATA;
-}
-
-skip_bits_long(>gb, 88);
-for (i = 0; i < hdr->nb_channels; i++)
-hdr->ch_size[i] = get_bits(>gb, 10);
-hdr->mtd_ext_size = get_bits(>gb, 8);
-hdr->meter_size   = get_bits(>gb, 8);
-
-skip_bits_long(>gb, 10 * hdr->nb_programs);
-for (i = 0; i < hdr->nb_channels; i++) {
-hdr->rev_id[i] = get_bits(>gb,  4);
-skip_bits1(>gb);
-hdr->begin_gain[i] = get_bits(>gb, 10);
-hdr->end_gain[i]   = get_bits(>gb, 10);
-}
-
-if (get_bits_left(>gb) < 0) {
-if (s->avctx)
-av_log(s->avctx, AV_LOG_ERROR, "Read past end of metadata\n");
-return AVERROR_INVALIDDATA;
-}
-
-return skip_input(s, mtd_size + 1);
-}
-
 static int parse_metadata_ext(DBEDecodeContext *s1)
 {
 DBEContext *s = >dectx;
@@ -603,73 +540,6 @@ static int filter_frame(DBEDecodeContext *s, AVFrame 
*frame)
 return 0;
 }
 
-static int dolby_e_sync(DBEContext *s, const uint8_t *buf, int buf_size)
-{
-int hdr;
-
-if (buf_size < 3)
-return AVERROR_INVALIDDATA;
-
-hdr = AV_RB24(buf);
-if ((hdr & 0xfe) == 0x7888e) {
-s->word_bits = 24;
-} else if ((hdr & 0xe0) == 0x788e0) {
-s->word_bits = 20;
-} else if ((hdr & 

[FFmpeg-devel] [PATCH 1/2] avcodec/dolby_e: Add a parser

2021-01-14 Thread Nicolas Gaullier
---
 Changelog|   1 +
 libavcodec/dolby_e.c | 254 +++
 libavcodec/dolby_e.h |  38 ++-
 libavcodec/parsers.c |   1 +
 libavcodec/version.h |   2 +-
 5 files changed, 198 insertions(+), 98 deletions(-)

diff --git a/Changelog b/Changelog
index dcb80e0ed9..9785c409c6 100644
--- a/Changelog
+++ b/Changelog
@@ -55,6 +55,7 @@ version :
 - asuperpass and asuperstop filter
 - shufflepixels filter
 - tmidequalizer filter
+- Dolby E parser
 
 
 version 4.3:
diff --git a/libavcodec/dolby_e.c b/libavcodec/dolby_e.c
index 2b2f0a1640..6bb817ec5c 100644
--- a/libavcodec/dolby_e.c
+++ b/libavcodec/dolby_e.c
@@ -26,13 +26,15 @@
 #include "internal.h"
 #include "get_bits.h"
 #include "put_bits.h"
+#include "parser.h"
 #include "dolby_e.h"
 #include "fft.h"
 
 static int skip_input(DBEContext *s, int nb_words)
 {
 if (nb_words > s->input_size) {
-av_log(s->avctx, AV_LOG_ERROR, "Packet too short\n");
+if (s->avctx)
+av_log(s->avctx, AV_LOG_ERROR, "Packet too short\n");
 return AVERROR_INVALIDDATA;
 }
 
@@ -44,7 +46,7 @@ static int skip_input(DBEContext *s, int nb_words)
 static int parse_key(DBEContext *s)
 {
 if (s->key_present) {
-uint8_t *key = s->input;
+const uint8_t *key = s->input;
 int  ret = skip_input(s, 1);
 if (ret < 0)
 return ret;
@@ -55,7 +57,7 @@ static int parse_key(DBEContext *s)
 
 static int convert_input(DBEContext *s, int nb_words, int key)
 {
-uint8_t *src = s->input;
+const uint8_t *src = s->input;
 uint8_t *dst = s->buffer;
 PutBitContext pb;
 int i;
@@ -63,7 +65,8 @@ static int convert_input(DBEContext *s, int nb_words, int key)
 av_assert0(nb_words <= 1024u);
 
 if (nb_words > s->input_size) {
-av_log(s->avctx, AV_LOG_ERROR, "Packet too short\n");
+if (s->avctx)
+av_log(s->avctx, AV_LOG_ERROR, "Packet too short\n");
 return AVERROR_INVALIDDATA;
 }
 
@@ -89,7 +92,7 @@ static int convert_input(DBEContext *s, int nb_words, int key)
 return init_get_bits(>gb, s->buffer, nb_words * s->word_bits);
 }
 
-static int parse_metadata(DBEContext *s)
+static int parse_metadata(DBEContext *s, DolbyEHeaderInfo *hdr)
 {
 int i, ret, key, mtd_size;
 
@@ -101,7 +104,8 @@ static int parse_metadata(DBEContext *s)
 skip_bits(>gb, 4);
 mtd_size = get_bits(>gb, 10);
 if (!mtd_size) {
-av_log(s->avctx, AV_LOG_ERROR, "Invalid metadata size\n");
+if (s->avctx)
+av_log(s->avctx, AV_LOG_ERROR, "Invalid metadata size\n");
 return AVERROR_INVALIDDATA;
 }
 
@@ -109,49 +113,53 @@ static int parse_metadata(DBEContext *s)
 return ret;
 
 skip_bits(>gb, 14);
-s->prog_conf = get_bits(>gb, 6);
-if (s->prog_conf > MAX_PROG_CONF) {
-av_log(s->avctx, AV_LOG_ERROR, "Invalid program configuration\n");
+hdr->prog_conf = get_bits(>gb, 6);
+if (hdr->prog_conf > MAX_PROG_CONF) {
+if (s->avctx)
+av_log(s->avctx, AV_LOG_ERROR, "Invalid program configuration\n");
 return AVERROR_INVALIDDATA;
 }
 
-s->nb_channels = nb_channels_tab[s->prog_conf];
-s->nb_programs = nb_programs_tab[s->prog_conf];
+hdr->nb_channels = nb_channels_tab[hdr->prog_conf];
+hdr->nb_programs = nb_programs_tab[hdr->prog_conf];
 
-s->fr_code  = get_bits(>gb, 4);
-s->fr_code_orig = get_bits(>gb, 4);
-if (!sample_rate_tab[s->fr_code] ||
-!sample_rate_tab[s->fr_code_orig]) {
-av_log(s->avctx, AV_LOG_ERROR, "Invalid frame rate code\n");
+hdr->fr_code  = get_bits(>gb, 4);
+hdr->fr_code_orig = get_bits(>gb, 4);
+if (!sample_rate_tab[hdr->fr_code] ||
+!sample_rate_tab[hdr->fr_code_orig]) {
+if (s->avctx)
+av_log(s->avctx, AV_LOG_ERROR, "Invalid frame rate code\n");
 return AVERROR_INVALIDDATA;
 }
 
 skip_bits_long(>gb, 88);
-for (i = 0; i < s->nb_channels; i++)
-s->ch_size[i] = get_bits(>gb, 10);
-s->mtd_ext_size = get_bits(>gb, 8);
-s->meter_size   = get_bits(>gb, 8);
-
-skip_bits_long(>gb, 10 * s->nb_programs);
-for (i = 0; i < s->nb_channels; i++) {
-s->rev_id[i] = get_bits(>gb,  4);
+for (i = 0; i < hdr->nb_channels; i++)
+hdr->ch_size[i] = get_bits(>gb, 10);
+hdr->mtd_ext_size = get_bits(>gb, 8);
+hdr->meter_size   = get_bits(>gb, 8);
+
+skip_bits_long(>gb, 10 * hdr->nb_programs);
+for (i = 0; i < hdr->nb_channels; i++) {
+hdr->rev_id[i] = get_bits(>gb,  4);
 skip_bits1(>gb);
-s->begin_gain[i] = get_bits(>gb, 10);
-s->end_gain[i]   = get_bits(>gb, 10);
+hdr->begin_gain[i] = get_bits(>gb, 10);
+hdr->end_gain[i]   = get_bits(>gb, 10);
 }
 
 if (get_bits_left(>gb) < 0) {
-av_log(s->avctx, AV_LOG_ERROR, "Read past end of metadata\n");
+if (s->avctx)
+av_log(s->avctx, AV_LOG_ERROR, 

[FFmpeg-devel] [PATCH 0/2] avcodec/dolby_e: Add a parser

2021-01-14 Thread Nicolas Gaullier
I have limited duplicated code by making the decoder calling the parser.
An option would be to leave all common code to dolby_e.c and move decoding to 
dolby_edec.c,
but that would require either to duplicate 3 "very-internal" functions 
(skip_input/parse_key/convert_input) 3x times instead of twice currently,
or to share them with ff_ prefix although they are very-low level and difficult 
to document etc.

If you have an idea for a better design, please tell me.

Nicolas Gaullier (2):
  avcodec/dolby_e: Add a parser
  avcodec/dolby_e: Split decoder/parser files

 Changelog|   1 +
 libavcodec/Makefile  |   1 +
 libavcodec/dolby_e.c | 209 -
 libavcodec/dolby_e.h | 608 +--
 libavcodec/dolby_e_parser.c  | 227 ++
 libavcodec/dolby_e_parser.h  |  41 ++
 libavcodec/dolby_e_parser_internal.h |  46 ++
 libavcodec/dolby_edec.h  | 607 ++
 libavcodec/parsers.c |   1 +
 libavcodec/version.h |   2 +-
 10 files changed, 1019 insertions(+), 724 deletions(-)
 create mode 100644 libavcodec/dolby_e_parser.c
 create mode 100644 libavcodec/dolby_e_parser.h
 create mode 100644 libavcodec/dolby_e_parser_internal.h
 create mode 100644 libavcodec/dolby_edec.h

-- 
2.27.0.windows.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] [FFmpeg-user] Setup a rtmps server with nginx + ffmpeg.

2021-01-14 Thread Hongyi Zhao
On Thu, Jan 14, 2021 at 3:20 PM Vic Mortelmans  wrote:
>
> Hi HY,
>
> looks like you should be ok. Did you give it a try?

Till now, I only tried to stream a local mp4 media file to nginx rtmp
server and replay the stream simultaneously. The steps are shown
below:

1. Start the self-compiled nginx rtmp server with the following
settings appended at the end of the default
/usr/local/nginx/conf/nginx.conf:

rtmp {
server {
listen 1935;

application live {
live on;
}
}
}

2. Publishing a Stream via FFMPEG:
$ ffmpeg -re -i in.mp4 -c copy -f flv "rtmp://127.0.0.1:1935/live"

3. Pull the steam with vlc:
 Fill out the following URL in "vlc --> Media --> Open Network Stream"
and click on the play button:

rtmp://127.0.0.1:1935/live

> What will be the use?

Currently, I'm participating in a remote driverless car monitoring
system, which utilize the camera installed on the car to capture the
real-time state of the surrounding environment and transfer it to the
monitoring device located remotely. The platform installed on the car
is an embedded Linux distribution, say, Raspberry Pi.

I plan to do this with the following ideas: ffmpeg is used to capture
the camera device and then rtmp(s)/hls protocols are used to publish
the stream to the rtmp(s)/hls server supplied by nginx running on a
cloud based VPS. On the remote client/monitoring side, we can access
the nginx server by a rtmp(s)/hls capable client software/browser,
e.g. VLC/Firefox/Chrome for real time monitoring.


> Will the server be receiving RTMP, or rather sending out?

I think it should do the both simultaneously.

> What will it be connected to?

See the detailed description of the above-mentioned project background.

> I've been doing an nginx + ffmpeg RTMP setup myself very recently and I
> published my notes here:
> https://gelovenleren.net/blog/raspberry-pi-broadcaster-diy/

Wonderful notes and valuable experiences. Thanks a lot for sharing it
with me. But I still have a question on your notes, to be more
specific, I think for the rtmps/hls protocols, the stream URLs should
look like "rtmp://" and "hls://". But I don't know how to setup these
type of nginx based streaming servers. Furthermore, I also learned
that rtmps ptotocol is not supported by nginx rtmp module currently as
told by the notes give by
:

Unfortunately nginx-rtmp-module doesn't support replaying to an
rtmps:// address, and the feature is not supposed be added in a recent
release.
There's an issue nginx-rtmp-module#1397 discussing about this.


> I've been through a lot of trial and error, though!

Thanks again for your hard work and due diligence. I will make further
attempts according to your notes and give the necessary feedback.

Best regards
HY
-- 
Assoc. Prof. Hongyi Zhao 
Theory and Simulation of Materials
Hebei Polytechnic University of Science and Technology engineering
NO. 552 North Gangtie Road, Xingtai, China
___
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] avformat/async: Use the correct return values

2021-01-14 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavformat/async.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/async.c b/libavformat/async.c
index a0bdfa2..801b20e 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -263,24 +263,28 @@ static int async_open(URLContext *h, const char *arg, int 
flags, AVDictionary **
 ret = pthread_mutex_init(>mutex, NULL);
 if (ret != 0) {
 av_log(h, AV_LOG_ERROR, "pthread_mutex_init failed : %s\n", 
av_err2str(ret));
+ret = AVERROR(ret);
 goto mutex_fail;
 }
 
 ret = pthread_cond_init(>cond_wakeup_main, NULL);
 if (ret != 0) {
 av_log(h, AV_LOG_ERROR, "pthread_cond_init failed : %s\n", 
av_err2str(ret));
+ret = AVERROR(ret);
 goto cond_wakeup_main_fail;
 }
 
 ret = pthread_cond_init(>cond_wakeup_background, NULL);
 if (ret != 0) {
 av_log(h, AV_LOG_ERROR, "pthread_cond_init failed : %s\n", 
av_err2str(ret));
+ret = AVERROR(ret);
 goto cond_wakeup_background_fail;
 }
 
 ret = pthread_create(>async_buffer_thread, NULL, async_buffer_task, h);
 if (ret) {
 av_log(h, AV_LOG_ERROR, "pthread_create failed : %s\n", 
av_err2str(ret));
+ret = AVERROR(ret);
 goto thread_fail;
 }
 
-- 
1.8.3.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/5] avformat/mxfenc: prefer to use the existing metadata

2021-01-14 Thread lance . lmwang
On Thu, Jan 14, 2021 at 12:50:34PM +0100, Tomas Härdin wrote:
> ons 2021-01-06 klockan 23:35 +0800 skrev lance.lmw...@gmail.com:
> > From: Limin Wang 
> > 
> > Please check metadata with below command:
> > ./ffmpeg -i ../fate-suite/mxf/Sony-1.mxf -c:v copy -c:a copy
> > out.mxf
> > ./ffmpeg -i out.mxf
> > 
> > company_name: FFmpeg
> > product_name: OP1a Muxer
> > product_version : 58.65.101o
> > =>
> > company_name: SONY
> > product_name: eVTR
> > product_version : 1.00
> 
> Why? This patch would just create confusion. CompanyName is there so it
> is possible to track down what software wrote the file. If you copy it 
> from the input file then you'd be lying.

I have updated the patch to remove the metadata from input to avoid it,
please help to review:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/1610168848-17933-3-git-send-email-lance.lmw...@gmail.com/


> 
> /Tomas
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

-- 
Thanks,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 5/5] avformat/hlsenc: use AV_OPT_TYPE_DURATION

2021-01-14 Thread lance . lmwang

ping

On Wed, Jan 06, 2021 at 11:35:31PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang 
> 
> Signed-off-by: Limin Wang 
> ---
>  doc/muxers.texi  |  4 ++--
>  libavformat/hlsenc.c | 18 +-
>  2 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 8e12aca..044c16b 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -609,13 +609,13 @@ segmentation.
>  This muxer supports the following options:
>  
>  @table @option
> -@item hls_init_time @var{seconds}
> +@item hls_init_time @var{duration}
>  Set the initial target segment length in seconds. Default value is @var{0}.
>  Segment will be cut on the next key frame after this time has passed on the 
> first m3u8 list.
>  After the initial playlist is filled @command{ffmpeg} will cut segments
>  at duration equal to @code{hls_time}
>  
> -@item hls_time @var{seconds}
> +@item hls_time @var{duration}
>  Set the target segment length in seconds. Default value is 2.
>  Segment will be cut on the next key frame after this time has passed.
>  
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 7f38db7..021a1ea 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -196,8 +196,8 @@ typedef struct HLSContext {
>  int64_t start_sequence;
>  uint32_t start_sequence_source_type;  // enum StartSequenceSourceType
>  
> -float time;// Set by a private option.
> -float init_time;   // Set by a private option.
> +int64_t time;  // Set by a private option.
> +int64_t init_time; // Set by a private option.
>  int max_nb_segments;   // Set by a private option.
>  int hls_delete_threshold; // Set by a private option.
>  #if FF_API_HLS_WRAP
> @@ -2454,9 +2454,9 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  
>  if (vs->sequence - vs->nb_entries > hls->start_sequence && 
> hls->init_time > 0) {
>  /* reset end_pts, hls->recording_time at end of the init hls list */
> -int64_t init_list_dur = hls->init_time * vs->nb_entries * 
> AV_TIME_BASE;
> -int64_t after_init_list_dur = (vs->sequence - hls->start_sequence - 
> vs->nb_entries) * (hls->time * AV_TIME_BASE);
> -hls->recording_time = hls->time * AV_TIME_BASE;
> +int64_t init_list_dur = hls->init_time * vs->nb_entries;
> +int64_t after_init_list_dur = (vs->sequence - hls->start_sequence - 
> vs->nb_entries) * hls->time;
> +hls->recording_time = hls->time;
>  end_pts = init_list_dur + after_init_list_dur ;
>  }
>  
> @@ -2941,7 +2941,7 @@ static int hls_init(AVFormatContext *s)
>  av_log(hls, AV_LOG_DEBUG, "start_number evaluated to %"PRId64"\n", 
> hls->start_sequence);
>  }
>  
> -hls->recording_time = (hls->init_time ? hls->init_time : hls->time) * 
> AV_TIME_BASE;
> +hls->recording_time = hls->init_time ? hls->init_time : hls->time;
>  
>  if (hls->flags & HLS_SPLIT_BY_TIME && hls->flags & 
> HLS_INDEPENDENT_SEGMENTS) {
>  // Independent segments cannot be guaranteed when splitting by time
> @@ -3094,7 +3094,7 @@ static int hls_init(AVFormatContext *s)
>  av_log(s, AV_LOG_WARNING, "append_list mode does not support 
> hls_init_time,"
> " hls_init_time value will have no effect\n");
>  hls->init_time = 0;
> -hls->recording_time = hls->time * AV_TIME_BASE;
> +hls->recording_time = hls->time;
>  }
>  }
>  
> @@ -3110,8 +3110,8 @@ static int hls_init(AVFormatContext *s)
>  #define E AV_OPT_FLAG_ENCODING_PARAM
>  static const AVOption options[] = {
>  {"start_number",  "set first number in the sequence",
> OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0}, 0, INT64_MAX, E},
> -{"hls_time",  "set segment length in seconds",   
> OFFSET(time),AV_OPT_TYPE_FLOAT,  {.dbl = 2}, 0, FLT_MAX, E},
> -{"hls_init_time", "set segment length in seconds at init list",  
>  OFFSET(init_time),AV_OPT_TYPE_FLOAT,  {.dbl = 0}, 0, FLT_MAX, E},
> +{"hls_time",  "set segment length in seconds",   
> OFFSET(time),AV_OPT_TYPE_DURATION,  {.i64 = 200}, 0, INT64_MAX, 
> E},
> +{"hls_init_time", "set segment length in seconds at init list",  
>  OFFSET(init_time),AV_OPT_TYPE_DURATION,  {.i64 = 0}, 0, INT64_MAX, 
> E},
>  {"hls_list_size", "set maximum number of playlist entries",  
> OFFSET(max_nb_segments),AV_OPT_TYPE_INT,{.i64 = 5}, 0, INT_MAX, 
> E},
>  {"hls_delete_threshold", "set number of unreferenced segments to keep 
> before deleting",  OFFSET(hls_delete_threshold),AV_OPT_TYPE_INT,{.i64 
> = 1}, 1, INT_MAX, E},
>  {"hls_ts_options","set hls mpegts list of options for the container 
> format used for hls", OFFSET(format_options), AV_OPT_TYPE_DICT, {.str = 
> NULL},  0, 0,E},
> -- 
> 1.8.3.1
> 

[FFmpeg-devel] [PATCH] Moves yuv2yuvX_sse3 to yasm, unrolls main loop and other small optimizations for ~20% speedup.

2021-01-14 Thread Alan Kelly
---
 Replaces cpuflag(mmx) with notcpuflag(sse3) for store macro
 Tests for multiple sizes in checkasm-sw_scale
 checkasm-sw_scale aligns memory on 8 bytes instad of 32 to catch aligned loads
 libswscale/x86/Makefile   |   1 +
 libswscale/x86/swscale.c  | 130 
 libswscale/x86/swscale_template.c |  82 --
 libswscale/x86/yuv2yuvX.asm   | 136 ++
 tests/checkasm/sw_scale.c | 103 ++
 5 files changed, 294 insertions(+), 158 deletions(-)
 create mode 100644 libswscale/x86/yuv2yuvX.asm

diff --git a/libswscale/x86/Makefile b/libswscale/x86/Makefile
index 831d5359aa..bfe383364e 100644
--- a/libswscale/x86/Makefile
+++ b/libswscale/x86/Makefile
@@ -13,3 +13,4 @@ X86ASM-OBJS += x86/input.o
  \
x86/scale.o  \
x86/rgb_2_rgb.o  \
x86/yuv_2_rgb.o  \
+   x86/yuv2yuvX.o   \
diff --git a/libswscale/x86/swscale.c b/libswscale/x86/swscale.c
index 15c0b22f20..3df193a067 100644
--- a/libswscale/x86/swscale.c
+++ b/libswscale/x86/swscale.c
@@ -63,6 +63,16 @@ DECLARE_ASM_ALIGNED(8, const uint64_t, ff_bgr2UVOffset) = 
0x8080808080808080ULL;
 DECLARE_ASM_ALIGNED(8, const uint64_t, ff_w)= 
0x0001000100010001ULL;
 
 
+#define YUV2YUVX_FUNC_DECL(opt)  \
+static void yuv2yuvX_ ##opt(const int16_t *filter, int filterSize, const 
int16_t **src, \
+   uint8_t *dest, int dstW, \
+   const uint8_t *dither, int offset); \
+
+YUV2YUVX_FUNC_DECL(mmx)
+YUV2YUVX_FUNC_DECL(mmxext)
+YUV2YUVX_FUNC_DECL(sse3)
+YUV2YUVX_FUNC_DECL(avx2)
+
 //MMX versions
 #if HAVE_MMX_INLINE
 #undef RENAME
@@ -198,81 +208,44 @@ void ff_updateMMXDitherTables(SwsContext *c, int dstY)
 }
 
 #if HAVE_MMXEXT
-static void yuv2yuvX_sse3(const int16_t *filter, int filterSize,
-   const int16_t **src, uint8_t *dest, int dstW,
-   const uint8_t *dither, int offset)
-{
-if(((uintptr_t)dest) & 15){
-yuv2yuvX_mmxext(filter, filterSize, src, dest, dstW, dither, offset);
-return;
-}
-filterSize--;
-#define MAIN_FUNCTION \
-"pxor   %%xmm0, %%xmm0 \n\t" \
-"punpcklbw  %%xmm0, %%xmm3 \n\t" \
-"movd   %4, %%xmm1 \n\t" \
-"punpcklwd  %%xmm1, %%xmm1 \n\t" \
-"punpckldq  %%xmm1, %%xmm1 \n\t" \
-"punpcklqdq %%xmm1, %%xmm1 \n\t" \
-"psllw  $3, %%xmm1 \n\t" \
-"paddw  %%xmm1, %%xmm3 \n\t" \
-"psraw  $4, %%xmm3 \n\t" \
-"movdqa %%xmm3, %%xmm4 \n\t" \
-"movdqa %%xmm3, %%xmm7 \n\t" \
-"movl   %3, %%ecx  \n\t" \
-"mov %0, %%"FF_REG_d"\n\t"\
-"mov(%%"FF_REG_d"), %%"FF_REG_S" \n\t"\
-".p2align 4 \n\t" /* FIXME 
Unroll? */\
-"1: \n\t"\
-"movddup  8(%%"FF_REG_d"), %%xmm0   \n\t" /* 
filterCoeff */\
-"movdqa  (%%"FF_REG_S", %%"FF_REG_c", 2), %%xmm2 \n\t" /* 
srcData */\
-"movdqa16(%%"FF_REG_S", %%"FF_REG_c", 2), %%xmm5 \n\t" /* 
srcData */\
-"add$16, %%"FF_REG_d"\n\t"\
-"mov(%%"FF_REG_d"), %%"FF_REG_S" \n\t"\
-"test %%"FF_REG_S", %%"FF_REG_S" \n\t"\
-"pmulhw   %%xmm0, %%xmm2  \n\t"\
-"pmulhw   %%xmm0, %%xmm5  \n\t"\
-"paddw%%xmm2, %%xmm3  \n\t"\
-"paddw%%xmm5, %%xmm4  \n\t"\
-" jnz1b \n\t"\
-"psraw   $3, %%xmm3  \n\t"\
-"psraw   $3, %%xmm4  \n\t"\
-"packuswb %%xmm4, %%xmm3  \n\t"\
-"movntdq  %%xmm3, (%1, %%"FF_REG_c") \n\t"\
-"add $16, %%"FF_REG_c"\n\t"\
-"cmp  %2, %%"FF_REG_c"\n\t"\
-"movdqa   %%xmm7, %%xmm3\n\t" \
-"movdqa   %%xmm7, %%xmm4\n\t" \
-"mov %0, %%"FF_REG_d"\n\t"\
-"mov(%%"FF_REG_d"), %%"FF_REG_S" \n\t"\
-"jb  1b \n\t"
-
-if (offset) {
-__asm__ volatile(
-"movq  %5, %%xmm3  \n\t"
-"movdqa

Re: [FFmpeg-devel] [PATCH V2] libavfilter/dnn: add batch mode for async execution

2021-01-14 Thread Fu, Ting


> -Original Message-
> From: ffmpeg-devel  On Behalf Of Guo,
> Yejun
> Sent: Sunday, January 10, 2021 09:16 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Guo, Yejun 
> Subject: [FFmpeg-devel] [PATCH V2] libavfilter/dnn: add batch mode for async
> execution
> 
> the default number of batch_size is 1
> 
> Signed-off-by: Xie, Lin 
> Signed-off-by: Wu Zhiwen 
> Signed-off-by: Guo, Yejun 
> ---
>  libavfilter/dnn/dnn_backend_openvino.c | 187 -
>  libavfilter/dnn/dnn_backend_openvino.h |   1 +
>  libavfilter/dnn/dnn_interface.c|   1 +
>  libavfilter/dnn_interface.h|   2 +
>  libavfilter/vf_dnn_processing.c|  36 -
>  5 files changed, 194 insertions(+), 33 deletions(-)
> 
[...]
>  if (ff_inlink_acknowledge_status(inlink, , )) {
>  if (status == AVERROR_EOF) {
> -ff_outlink_set_status(outlink, status, pts);
> +int64_t out_pts = pts;
> +ret = flush_frame(outlink, pts, _pts);
> +ff_outlink_set_status(outlink, status, out_pts);
>  return ret;
>  }
>  }
> --
> 2.17.1

Hi Yejun,
This patch works well for me.
Testing was carried on my machine, which CPU is i7-8700K 3.7Ghz and iGPU is 
UHD630.
The patch was tested by using espcn super resolution model (950*540 video as 
input), with async on and off. The fps increased from 11fps to 13fps (~18% up) 
on CPU, from 8fps to 11fps (~37% up) on iGPU.

On CPU with async off:
./ffmpeg -i input_video.mp4 -vf 
dnn_processing=dnn_backend=openvino:model=espcn1080p.xml:input=x:output=espcn/prediction:async=0:options=device=CPU\_size=1
 -y output_video.mp4
On CPU with async on:
./ffmpeg -i input_video.mp4 -vf 
dnn_processing=dnn_backend=openvino:model=espcn1080p.xml:input=x:output=espcn/prediction:async=1:options=device=CPU\_size=2
 -y output_video.mp4

On GPU with async off:
./ffmpeg -i input_video.mp4 -vf 
dnn_processing=dnn_backend=openvino:model=espcn1080p.xml:input=x:output=espcn/prediction:async=0:options=device=GPU\_size=1
 -y output_video.mp4
On GPU with async on:
./ffmpeg -i input_video.mp4 -vf 
dnn_processing=dnn_backend=openvino:model=espcn1080p.xml:input=x:output=espcn/prediction:async=1:options=device=GPU\_size=2
 -y output_video.mp4

> 
> ___
> 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 1/2] avcodec/librav1e: Fix indentation

2021-01-14 Thread Derek Buitenhuis
Signed-off-by: Derek Buitenhuis 
---
Seems it got mangled at some point.
---
 libavcodec/librav1e.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/libavcodec/librav1e.c b/libavcodec/librav1e.c
index e9b82a724a..46071bcdac 100644
--- a/libavcodec/librav1e.c
+++ b/libavcodec/librav1e.c
@@ -443,23 +443,23 @@ static int librav1e_receive_packet(AVCodecContext *avctx, 
AVPacket *pkt)
 return ret;
 
 if (frame->buf[0]) {
-const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
+const AVPixFmtDescriptor *desc = 
av_pix_fmt_desc_get(frame->format);
 
-rframe = rav1e_frame_new(ctx->ctx);
-if (!rframe) {
-av_log(avctx, AV_LOG_ERROR, "Could not allocate new rav1e 
frame.\n");
-av_frame_unref(frame);
-return AVERROR(ENOMEM);
-}
+rframe = rav1e_frame_new(ctx->ctx);
+if (!rframe) {
+av_log(avctx, AV_LOG_ERROR, "Could not allocate new rav1e 
frame.\n");
+av_frame_unref(frame);
+return AVERROR(ENOMEM);
+}
 
-for (int i = 0; i < desc->nb_components; i++) {
-int shift = i ? desc->log2_chroma_h : 0;
-int bytes = desc->comp[0].depth == 8 ? 1 : 2;
-rav1e_frame_fill_plane(rframe, i, frame->data[i],
-   (frame->height >> shift) * 
frame->linesize[i],
-   frame->linesize[i], bytes);
-}
-av_frame_unref(frame);
+for (int i = 0; i < desc->nb_components; i++) {
+int shift = i ? desc->log2_chroma_h : 0;
+int bytes = desc->comp[0].depth == 8 ? 1 : 2;
+rav1e_frame_fill_plane(rframe, i, frame->data[i],
+   (frame->height >> shift) * 
frame->linesize[i],
+   frame->linesize[i], bytes);
+}
+av_frame_unref(frame);
 }
 }
 
@@ -468,7 +468,7 @@ static int librav1e_receive_packet(AVCodecContext *avctx, 
AVPacket *pkt)
 if (ret == RA_ENCODER_STATUS_ENOUGH_DATA) {
 ctx->rframe = rframe; /* Queue is full. Store the RaFrame to retry 
next call */
 } else {
- rav1e_frame_unref(rframe); /* No need to unref if flushing. */
+rav1e_frame_unref(rframe); /* No need to unref if flushing. */
 ctx->rframe = NULL;
 }
 
-- 
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 2/2] avcodec/librav1e: Pass through timestamps as opaque user data

2021-01-14 Thread Derek Buitenhuis
On 14/01/2021 14:09, James Almer wrote:
> Is the ownership of the opaque user data moved from the RaFrame to the 
> RaPacket to ensure this is safe? If so, why does 
> rav1e_frame_set_opaque() take a free callback argument? When does it 
> trigger?

It's a bit of a weird API. The free callback that rav1e_frame_set_opaque takes
is only executed in case of a failue inside of rav1e - once the packet is 
output,
it's up to the API caller to free it.

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/librav1e: Pass through timestamps as opaque user data

2021-01-14 Thread James Almer

On 1/14/2021 10:55 AM, Derek Buitenhuis wrote:

avcodec has no facilities to generate timestamps properly from
output frame numbers (and it would be wrong for VFR anyway),
so pass through the timestamps using rav1e's opaque user data
feature, which was added in v0.4.0.

This bumps the minimum librav1e version to 0.4.0.

Signed-off-by: Derek Buitenhuis 
---
  configure |  2 +-
  libavcodec/librav1e.c | 12 +++-
  2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 900505756b..54fbbd6b5f 100755
--- a/configure
+++ b/configure
@@ -6408,7 +6408,7 @@ enabled libopus   && {
  }
  enabled libpulse  && require_pkg_config libpulse libpulse 
pulse/pulseaudio.h pa_context_new
  enabled librabbitmq   && require_pkg_config librabbitmq "librabbitmq >= 
0.7.1" amqp.h amqp_new_connection
-enabled librav1e  && require_pkg_config librav1e "rav1e >= 0.1.0" 
rav1e.h rav1e_context_new
+enabled librav1e  && require_pkg_config librav1e "rav1e >= 0.4.0" 
rav1e.h rav1e_context_new
  enabled librsvg   && require_pkg_config librsvg librsvg-2.0 
librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
  enabled librtmp   && require_pkg_config librtmp librtmp 
librtmp/rtmp.h RTMP_Socket
  enabled librubberband && require_pkg_config librubberband "rubberband >= 1.8.1" 
rubberband/rubberband-c.h rubberband_new -lstdc++ && append librubberband_extralibs "-lstdc++"
diff --git a/libavcodec/librav1e.c b/libavcodec/librav1e.c
index 46071bcdac..c1c0de45a6 100644
--- a/libavcodec/librav1e.c
+++ b/libavcodec/librav1e.c
@@ -445,10 +445,18 @@ static int librav1e_receive_packet(AVCodecContext *avctx, 
AVPacket *pkt)
  if (frame->buf[0]) {
  const AVPixFmtDescriptor *desc = 
av_pix_fmt_desc_get(frame->format);
  
+int64_t *pts = av_malloc(sizeof(int64_t));

+if (!pts) {
+av_log(avctx, AV_LOG_ERROR, "Could not allocate PTS 
buffer.\n");
+return AVERROR(ENOMEM);
+}
+*pts = frame->pts;
+
  rframe = rav1e_frame_new(ctx->ctx);
  if (!rframe) {
  av_log(avctx, AV_LOG_ERROR, "Could not allocate new rav1e 
frame.\n");
  av_frame_unref(frame);
+av_freep();
  return AVERROR(ENOMEM);
  }
  
@@ -461,6 +469,7 @@ static int librav1e_receive_packet(AVCodecContext *avctx, AVPacket *pkt)

  }
  av_frame_unref(frame);
  }
+rav1e_frame_set_opaque(rframe, pts, av_free);
  }
  
  ret = rav1e_send_frame(ctx->ctx, rframe);

@@ -535,7 +544,8 @@ retry:
  if (rpkt->frame_type == RA_FRAME_TYPE_KEY)
  pkt->flags |= AV_PKT_FLAG_KEY;
  
-pkt->pts = pkt->dts = rpkt->input_frameno * avctx->ticks_per_frame;

+pkt->pts = pkt->dts = *((int64_t *) rpkt->opaque);
+av_free(rpkt->opaque);


Is the ownership of the opaque user data moved from the RaFrame to the 
RaPacket to ensure this is safe? If so, why does 
rav1e_frame_set_opaque() take a free callback argument? When does it 
trigger?



  rav1e_packet_unref(rpkt);
  
  if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) {




___
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 2/2] avcodec/librav1e: Pass through timestamps as opaque user data

2021-01-14 Thread Derek Buitenhuis
avcodec has no facilities to generate timestamps properly from
output frame numbers (and it would be wrong for VFR anyway),
so pass through the timestamps using rav1e's opaque user data
feature, which was added in v0.4.0.

This bumps the minimum librav1e version to 0.4.0.

Signed-off-by: Derek Buitenhuis 
---
 configure |  2 +-
 libavcodec/librav1e.c | 12 +++-
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 900505756b..54fbbd6b5f 100755
--- a/configure
+++ b/configure
@@ -6408,7 +6408,7 @@ enabled libopus   && {
 }
 enabled libpulse  && require_pkg_config libpulse libpulse 
pulse/pulseaudio.h pa_context_new
 enabled librabbitmq   && require_pkg_config librabbitmq "librabbitmq >= 
0.7.1" amqp.h amqp_new_connection
-enabled librav1e  && require_pkg_config librav1e "rav1e >= 0.1.0" 
rav1e.h rav1e_context_new
+enabled librav1e  && require_pkg_config librav1e "rav1e >= 0.4.0" 
rav1e.h rav1e_context_new
 enabled librsvg   && require_pkg_config librsvg librsvg-2.0 
librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
 enabled librtmp   && require_pkg_config librtmp librtmp librtmp/rtmp.h 
RTMP_Socket
 enabled librubberband && require_pkg_config librubberband "rubberband >= 
1.8.1" rubberband/rubberband-c.h rubberband_new -lstdc++ && append 
librubberband_extralibs "-lstdc++"
diff --git a/libavcodec/librav1e.c b/libavcodec/librav1e.c
index 46071bcdac..c1c0de45a6 100644
--- a/libavcodec/librav1e.c
+++ b/libavcodec/librav1e.c
@@ -445,10 +445,18 @@ static int librav1e_receive_packet(AVCodecContext *avctx, 
AVPacket *pkt)
 if (frame->buf[0]) {
 const AVPixFmtDescriptor *desc = 
av_pix_fmt_desc_get(frame->format);
 
+int64_t *pts = av_malloc(sizeof(int64_t));
+if (!pts) {
+av_log(avctx, AV_LOG_ERROR, "Could not allocate PTS 
buffer.\n");
+return AVERROR(ENOMEM);
+}
+*pts = frame->pts;
+
 rframe = rav1e_frame_new(ctx->ctx);
 if (!rframe) {
 av_log(avctx, AV_LOG_ERROR, "Could not allocate new rav1e 
frame.\n");
 av_frame_unref(frame);
+av_freep();
 return AVERROR(ENOMEM);
 }
 
@@ -461,6 +469,7 @@ static int librav1e_receive_packet(AVCodecContext *avctx, 
AVPacket *pkt)
 }
 av_frame_unref(frame);
 }
+rav1e_frame_set_opaque(rframe, pts, av_free);
 }
 
 ret = rav1e_send_frame(ctx->ctx, rframe);
@@ -535,7 +544,8 @@ retry:
 if (rpkt->frame_type == RA_FRAME_TYPE_KEY)
 pkt->flags |= AV_PKT_FLAG_KEY;
 
-pkt->pts = pkt->dts = rpkt->input_frameno * avctx->ticks_per_frame;
+pkt->pts = pkt->dts = *((int64_t *) rpkt->opaque);
+av_free(rpkt->opaque);
 rav1e_packet_unref(rpkt);
 
 if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) {
-- 
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 3/5] avformat/mxfenc: prefer to use the existing metadata

2021-01-14 Thread Tomas Härdin
ons 2021-01-06 klockan 23:35 +0800 skrev lance.lmw...@gmail.com:
> From: Limin Wang 
> 
> Please check metadata with below command:
> ./ffmpeg -i ../fate-suite/mxf/Sony-1.mxf -c:v copy -c:a copy
> out.mxf
> ./ffmpeg -i out.mxf
> 
> company_name: FFmpeg
> product_name: OP1a Muxer
> product_version : 58.65.101o
> =>
> company_name: SONY
> product_name: eVTR
> product_version : 1.00

Why? This patch would just create confusion. CompanyName is there so it
is possible to track down what software wrote the file. If you copy it 
from the input file then you'd be lying.

/Tomas

___
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 v2 1/3] avutil/{avstring, bprint}: add XML escaping from ffprobe to avutil

2021-01-14 Thread Jan Ekström
On Thu, Jan 14, 2021 at 1:40 PM Nicolas George  wrote:
>
> Jan Ekström (12021-01-13):
> > Yea, I actually noticed that one, but never got to responding to it.
> > Sorry about that.
>
> No problem.
>
> > While I do agree that such modes could be useful, currently I have no
> > need for the additional modes and thus the original code by Stefano
> > was just moved in avutil (and then utilized from ttmlenc). I did check
> > the XML specification that this code originally seemed to follow the
> > requirements (and thus mentioned the exact spot in the spec where this
> > is mentioned).
>
> Yes, it is technically correct. So would be escaping every character as
> a numeric entity.
>
> 
>
> XML is meant to be both machine-readable and human-readable. Escaping
> unnecessarily pulls us away from human-readable.

I did not do the selection of what this code (which I just moved)
does, I just moved it and referred to the originator document that
those five symbols match what is defined in the XML spec as per 2.4.

As far as I can tell, it does not do nor was I implying that I would
do something like that.

>
> > Thus, is the lack of those additional XML modes a blocker? Or should
> > they be added as the need arises?
>
> Considering that this is so simple that it would have taken you less
> time to just do it than to wait for my answer, I would say that I insist
> to do things properly immediately, before code starts piling on it and
> requires to be revised.
>

Alright. I only took this position since it required to check out the
XML specification again to see if that stuff was properly defined (it
probably is?), so there wouldn't be guesswork required and rather just
implementing the rules. I can check the spec again, and see if it
clearly defines those cases that you have mentioned.

Jan
___
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 v2 1/3] avutil/{avstring, bprint}: add XML escaping from ffprobe to avutil

2021-01-14 Thread Nicolas George
Jan Ekström (12021-01-13):
> Yea, I actually noticed that one, but never got to responding to it.
> Sorry about that.

No problem.

> While I do agree that such modes could be useful, currently I have no
> need for the additional modes and thus the original code by Stefano
> was just moved in avutil (and then utilized from ttmlenc). I did check
> the XML specification that this code originally seemed to follow the
> requirements (and thus mentioned the exact spot in the spec where this
> is mentioned).

Yes, it is technically correct. So would be escaping every character as
a numeric entity.



XML is meant to be both machine-readable and human-readable. Escaping
unnecessarily pulls us away from human-readable.

> Thus, is the lack of those additional XML modes a blocker? Or should
> they be added as the need arises?

Considering that this is so simple that it would have taken you less
time to just do it than to wait for my answer, I would say that I insist
to do things properly immediately, before code starts piling on it and
requires to be revised.

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] Moves yuv2yuvX_sse3 to yasm, unrolls main loop and other small optimizations for ~20% speedup.

2021-01-14 Thread Alan Kelly
Apologies for this: when I added mmx to the yasm file, I added a macro for
the stores selecting mova for mmx and movdqu for the others. if
cpuflag(mmx) evaluates to true for all architectures so I replaced it with
if notcpuflag(sse3).

The alignment in the checkasm test has been changed to 8 from 32 so that
the test catches problems with alignment.

On Thu, Jan 14, 2021 at 1:11 AM Michael Niedermayer 
wrote:

> On Mon, Jan 11, 2021 at 05:46:31PM +0100, Alan Kelly wrote:
> > ---
> >  Fixes a bug where if there is no offset and a tail which is not
> processed by the
> >  sse3/avx2 version the dither is modified
> >  Deletes mmx/mmxext yuv2yuvX version from swscale_template and adds it
> >  to yuv2yuvX.asm to reduce code duplication and so that it may be used
> >  to process the tail from the larger cardinal simd versions.
> >  src argument of yuv2yuvX_* is now srcOffset, so that tails and offsets
> >  are accounted for correctly.
> >  Changes input size in checkasm so that this corner case is tested.
> >
> >  libswscale/x86/Makefile   |   1 +
> >  libswscale/x86/swscale.c  | 130 
> >  libswscale/x86/swscale_template.c |  82 --
> >  libswscale/x86/yuv2yuvX.asm   | 136 ++
> >  tests/checkasm/sw_scale.c | 100 ++
> >  5 files changed, 291 insertions(+), 158 deletions(-)
> >  create mode 100644 libswscale/x86/yuv2yuvX.asm
>
> This seems to be crashing again unless i messed up testing
>
> (gdb) disassemble $rip-32,$rip+32
> Dump of assembler code from 0x55572f02 to 0x55572f42:
>0x55572f02 :   int$0x71
>0x55572f04 :   out%al,$0x3
>0x55572f06 :   vpsraw $0x3,%ymm1,%ymm1
>0x55572f0b :   vpackuswb %ymm4,%ymm3,%ymm3
>0x55572f0f :   vpackuswb %ymm1,%ymm6,%ymm6
>0x55572f13 :   mov(%rdi),%rdx
>0x55572f16 :   vpermq $0xd8,%ymm3,%ymm3
>0x55572f1c :   vpermq $0xd8,%ymm6,%ymm6
> => 0x55572f22 :   vmovdqa %ymm3,(%rcx,%rax,1)
>0x55572f27 :   vmovdqa
> %ymm6,0x20(%rcx,%rax,1)
>0x55572f2d :   add$0x40,%rax
>0x55572f31 :   mov%rdi,%rsi
>0x55572f34 :   cmp%r8,%rax
>0x55572f37 :   jb 0x55572eae
> 
>0x55572f3d :   vzeroupper
>0x55572f40 :   retq
>0x55572f41 :   nopw   %cs:0x0(%rax,%rax,1)
>
> rax0x0  0
> rbx0x30 48
> rcx0x5583f470   93824995292272
> rdx0x5585e500   93824995419392
>
> #0  0x55572f22 in ff_yuv2yuvX_avx2 ()
> #1  0x555724ee in yuv2yuvX_avx2 ()
> #2  0x5556b4f6 in chr_planar_vscale ()
> #3  0x55566d41 in swscale ()
> #4  0x55568284 in sws_scale ()
>
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> What does censorship reveal? It reveals fear. -- Julian Assange
> ___
> 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".