Re: [FFmpeg-devel] [PATCH] avformat: Fix probing on some JPEGs

[Michael Niedermayer]

On Wed, Aug 21, 2019 at 01:58:52PM -0700, Niki Bowe wrote:
> On Mon, Aug 19, 2019 at 7:22 PM Carl Eugen Hoyos  wrote:
> 
> >
> > This score would mean that mjpeg can never be detected.
> > I suspect you have to reduce one of the demuxers to "- 1".
> >
> >
> Thanks Carl.
> Attached patch to reduce mpeg probe by -1, which also fixes the issue.
> 
> Alternatively I could bump both jpeg and mjpeg?
> mpegps_probe looks like it has some heuristics to come up with its scores,
> which may make it brittle.
> 
> -- 
> 
> Nikolas Bowe |  SWE |  nb...@google.com |  408-565-5137

>  mpeg.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 9bfc9441a3a3a2c060005d42fda9128ff39406ef  
> 0001-avformat-Fix-probing-on-some-JPEGs.patch
> From ab42e2041ec1469f43bccbf8c3e06084bbb7985a Mon Sep 17 00:00:00 2001
> From: Nikolas Bowe 
> Date: Thu, 8 Aug 2019 15:32:51 -0700
> Subject: [PATCH] avformat: Fix probing on some JPEGs
> 
> Fixes "Invalid data found when processing input" on some JPEGs.
> 
> Some large extensionless JPEGs can get probe score collisions with mpeg
> eg
> $ ffprobe -loglevel trace  /tmp/foo
> [NULL @ 0x55c130ab04c0] Opening '/tmp/foo' for reading
> [file @ 0x55c130ab0f40] Setting default whitelist 'file,crypto'
> Probing jpeg_pipe score:6 size:2048
> Probing jpeg_pipe score:6 size:4096
> Probing jpeg_pipe score:6 size:8192
> Probing jpeg_pipe score:6 size:16384
> Probing jpeg_pipe score:25 size:32768
> Probing jpeg_pipe score:25 size:65536
> Probing jpeg_pipe score:25 size:131072
> Probing jpeg_pipe score:25 size:262144
> Probing jpeg_pipe score:25 size:524288
> Probing mpeg score:25 size:1048576
> Probing jpeg_pipe score:25 size:1048576
> [AVIOContext @ 0x55c130ab9300] Statistics: 1048576 bytes read, 0 seeks
> /tmp/foo: Invalid data found when processing input
> 
> This patch fixes this by reducing probe score for mpeg
> ---
>  libavformat/mpeg.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/mpeg.c b/libavformat/mpeg.c
> index 3205f209e6..7a7de54894 100644
> --- a/libavformat/mpeg.c
> +++ b/libavformat/mpeg.c
> @@ -100,7 +100,7 @@ static int mpegps_probe(const AVProbeData *p)
>  }
>  
>  if (vid + audio > invalid + 1) /* invalid VDR files nd short PES streams 
> */
> -score = AVPROBE_SCORE_EXTENSION / 2;
> +score = AVPROBE_SCORE_EXTENSION / 2 - 1; // 1 less than jpeg in SOS
>  

jpeg and mpeg are quite different on the syntax side. Have you checked
if that jpeg file violates some easy checkable property that mpeg files
have ?
it would be better to make the detection better and more robust.
tuning the scores has a good chance of just moving the problem elsewhere

thx
[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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] Change libaom default to crf=32.

[Moritz Barsnick]

On Wed, Aug 21, 2019 at 18:03:23 -0700, James Zern wrote:
> > From: elliottk 
> > Current default is 256kbps, which produces inconsistent
> > results (too high for low-res, too low for hi-res).
> > Use CRF instead, which will adapt.
>
> lgtm. I'll apply this soon if there aren't any other comments. libvpx
> could probably use a similar update.

Is this a behavioral change which would justify a bump of libavcodec
micro?

Just wondering,
Moritz
___
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] avcodec/libvpxenc: add ROI-based encoding support for VP8/VP9 support

[Moritz Barsnick]

On Thu, Aug 22, 2019 at 08:56:28 +0800, Guo, Yejun wrote:
> +/* This list must be iterated in reverse, so for the case that
> + * two regions overlapping, the more important area takes effect.

Nit: "overlap" or "are overlapping".

> +#ifdef VPX_CTRL_VP9E_SET_ROI_MAP
[...]
> +#endif
> +
> +av_assert0(!roi_supported);
> +if (!ctx->roi_warned) {
> +ctx->roi_warned = 1;
> +av_log(avctx, AV_LOG_WARNING, "ROI is not supported, please upgrade 
> libvpx to version >= 1.8.1\n");
> +}

Nit: upgrading alone won't help, you'll actually need to rebuild. ;-)
(I'm saying it may be confusing to the end user, if they ever encounter
it.)

Cheers,
Moritz
___
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/4] avcodec/iff: Check for overlap in cmap_read_palette()

[Moritz Barsnick]

On Thu, Aug 22, 2019 at 00:18:54 +0200, Michael Niedermayer wrote:

Nits:

> Fixes: undefined mempcpy() use

memcpy

> +avpriv_request_sample(avctx, "overlaping mask");

overlapping

Cheers,
Moritz
___
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] [REQUEST] avcodec/scpr: revert d70276921348

[Paul B Mahol]

On Wed, Aug 21, 2019 at 10:10 PM Marton Balint  wrote:

>
>
> On Tue, 20 Aug 2019, Carl Eugen Hoyos wrote:
>
> > Am Di., 20. Aug. 2019 um 14:48 Uhr schrieb Paul B Mahol <
> one...@gmail.com>:
> >
> >> I kindly ask that following commit:
> d702769213487923c0fb0abe4b61f4d9ebddb88b
> >
> > I still believe what the patch does is a very good idea and a revert
> would
> > hurt FFmpeg.
>
> If the patch is kept then probably a workaround is needed here as well for
> an issue like #7880, as it affects all cases where duplicated frames are
> dropped.
>

That is additional precise reason why should commit be reverted.


>
> Regards,
> Marton
> ___
> 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 2/4] avformat/vividas: Check av_xiphlacing() return value before use

[Paul B Mahol]

probably ok

On Thu, Aug 22, 2019 at 12:21 AM Michael Niedermayer 
wrote:

> Fixes: out of array access
> Fixes:
> 16277/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5696629440512000
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  libavformat/vividas.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/vividas.c b/libavformat/vividas.c
> index 0c33ca2da8..645e322b6e 100644
> --- a/libavformat/vividas.c
> +++ b/libavformat/vividas.c
> @@ -392,8 +392,14 @@ static int track_header(VividasDemuxContext *viv,
> AVFormatContext *s,  uint8_t *
>  p = st->codecpar->extradata;
>  p[0] = 2;
>
> -for (j = 0; j < num_data - 1; j++)
> -offset += av_xiphlacing(&p[offset], data_len[j]);
> +for (j = 0; j < num_data - 1; j++) {
> +unsigned delta = av_xiphlacing(&p[offset], data_len[j]);
> +if (delta > data_len[j]) {
> +av_free(pb);
> +return AVERROR_INVALIDDATA;
> +}
> +offset += delta;
> +}
>
>  for (j = 0; j < num_data; j++) {
>  int ret = avio_read(pb, &p[offset], data_len[j]);
> --
> 2.23.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 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/4] tools/target_dec_fuzzer: Adjust max_pixels for IDCIN

[Paul B Mahol]

Why not fix issues listed in decoder code instead of this hack?

On Thu, Aug 22, 2019 at 12:21 AM Michael Niedermayer 
wrote:

> Fixes: Timeout (128sec -> 6sec)
> Fixes:
> 16568/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IDCIN_fuzzer-5675004095627264
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  tools/target_dec_fuzzer.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
> index d83039417c..fd76553ec8 100644
> --- a/tools/target_dec_fuzzer.c
> +++ b/tools/target_dec_fuzzer.c
> @@ -177,6 +177,8 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
> size) {
>  case AV_CODEC_ID_GDV:   maxpixels /= 256; break;
>  // Postprocessing in C
>  case AV_CODEC_ID_HNM4_VIDEO:maxpixels /= 128; break;
> +// Unoptimized VLC reading and allows a small input to generate
> gigantic output
> +case AV_CODEC_ID_IDCIN: maxpixels /= 2048; break;
>  }
>
>
> --
> 2.23.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 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/4] tools/target_dec_fuzzer: Adjust max_pixels for IDCIN

[Michael Niedermayer]

On Thu, Aug 22, 2019 at 10:09:30AM +0200, Paul B Mahol wrote:
> Why not fix issues listed in decoder code instead of this hack?

I can improve the VLC reader and will probably look into that
but i dont think that will provide the factor of 2000 speedup needed 
to avoid the adjustment. It might reduce the factor needed though.

thx


[...]

> > +// Unoptimized VLC reading and allows a small input to generate
> > gigantic output
> > +case AV_CODEC_ID_IDCIN: maxpixels /= 2048; break;
[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.


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/4] tools/target_dec_fuzzer: Adjust max_pixels for IDCIN

[Paul B Mahol]

On Thu, Aug 22, 2019 at 10:16 AM Michael Niedermayer 
wrote:

> On Thu, Aug 22, 2019 at 10:09:30AM +0200, Paul B Mahol wrote:
> > Why not fix issues listed in decoder code instead of this hack?
>
> I can improve the VLC reader and will probably look into that
> but i dont think that will provide the factor of 2000 speedup needed
> to avoid the adjustment. It might reduce the factor needed though.
>
>
Also all this old game codecs never used very high resolutions.
Max something vga, but not even that.


> thx
>
>
> [...]
>
> > > +// Unoptimized VLC reading and allows a small input to
> generate
> > > gigantic output
> > > +case AV_CODEC_ID_IDCIN: maxpixels /= 2048; break;
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Take away the freedom of one citizen and you will be jailed, take away
> the freedom of all citizens and you will be congratulated by your peers
> in Parliament.
> ___
> 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/4] tools/target_dec_fuzzer: Adjust max_pixels for IDCIN

[Michael Niedermayer]

On Thu, Aug 22, 2019 at 10:23:40AM +0200, Paul B Mahol wrote:
> On Thu, Aug 22, 2019 at 10:16 AM Michael Niedermayer 
> wrote:
> 
> > On Thu, Aug 22, 2019 at 10:09:30AM +0200, Paul B Mahol wrote:
> > > Why not fix issues listed in decoder code instead of this hack?
> >
> > I can improve the VLC reader and will probably look into that
> > but i dont think that will provide the factor of 2000 speedup needed
> > to avoid the adjustment. It might reduce the factor needed though.
> >
> >
> Also all this old game codecs never used very high resolutions.
> Max something vga, but not even that.

limiting to 640x480 instead of 4096x4096 would give a factor of about 55
speedup, thats still a long way from 2000 so that solves also only
part of it

anyway ill provide a patch that limits resolution so theres something
that can be discussed. 

Thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Any man who breaks a law that conscience tells him is unjust and willingly 
accepts the penalty by staying in jail in order to arouse the conscience of 
the community on the injustice of the law is at that moment expressing the 
very highest respect for law. - Martin Luther King Jr


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] [REQUEST] avcodec/scpr: revert d70276921348

[Michael Niedermayer]

On Wed, Aug 21, 2019 at 10:10:02PM +0200, Marton Balint wrote:
> 
> 
> On Tue, 20 Aug 2019, Carl Eugen Hoyos wrote:
> 
> >Am Di., 20. Aug. 2019 um 14:48 Uhr schrieb Paul B Mahol :
> >
> >>I kindly ask that following commit: d702769213487923c0fb0abe4b61f4d9ebddb88b
> >
> >I still believe what the patch does is a very good idea and a revert would
> >hurt FFmpeg.
> 
> If the patch is kept then probably a workaround is needed here as well for
> an issue like #7880, as it affects all cases where duplicated frames are
> dropped.

I can implement this if theres consensus that this should be done.

Thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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] EOF and IO error checking

[Marton Balint]

On Sun, 18 Aug 2019, Michael Niedermayer wrote:


On Sat, Aug 17, 2019 at 09:10:59PM +0200, Marton Balint wrote:

Hi,

As you might now avio_feof() returns true both in case of actual EOF and in
case of IO errors.

Some demuxers (matroska) have special handling for this exact reason, e.g.:

if (avio_feof(pb)) {
if (pb->error) {
return pb->error;
} else {
return AVERROR_EOF;
}
}

Most of the demuxers do not, so there is a real chance that IO errrors are
mistaken for EOF.

What should we do about this?

a) Fix every demuxer to return IO error if there is one.

b) Add special code to ff_read_packet which checks if there is an error in
the IO context and return that if there is?




c) Add code to ffmpeg.c which checks the IO context error code after every
av_read_frame call?


This while generally correct is not guranteed to be correct.
The internal IO context may have an IO error without the demuxer having an
error. From the possibility of reconnects to redundancy to errors after
all essential parts of a file ...
so this may need some flag per demuxer that either declares this relation
true or a flag declaring it false


Do you have an example in mind for a demuxer which specifically needs 
this? From the top of my head I can't think of one.


Reconnects happen in the protocol handlers, so errors there should not 
affect the AVIO context errors.


I am also sceptical about the use case of gracefully handling IO errors 
in non-essential parts of the file. Signalling IO errors is a lot more 
important and I bet there are cases where some demuxer won't set the 
packet corrupt flag (which is by the way not propagated correctly through 
the API) if it encounters an IO error when reading something.


In any case, I don't mind too much option a), if that what seems more 
clean but we will probably miss a few cases of the issue.


Thanks,
Marton
___
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] libavfilter: Add dehaze-filter option in existing derain filter.

[Xuewei Meng]

Add the support of dehaze filter in existing derain filter source
code. As the processing procedure in FFmpeg is the same for current
derain and dehaze, we reuse the derain filter source code. The
model training and generation scripts are in repo
https://github.com/XueweiMeng/derain_filter.git.

Signed-off-by: Xuewei Meng 
---
 doc/filters.texi| 14 +-
 libavfilter/vf_derain.c | 13 +
 2 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 323c02970e..49fc030489 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8431,7 +8431,7 @@ delogo=x=0:y=0:w=100:h=77:band=10
 
 @section derain
 
-Remove the rain in the input image/video by applying the derain methods based 
on
+Remove the rain/haze in the input image/video by applying the derain/dehaze 
methods based on
 convolutional neural networks. Supported models:
 
 @itemize
@@ -8449,6 +8449,18 @@ files (.pb) by using tools/python/convert.py
 The filter accepts the following options:
 
 @table @option
+@item filter_type
+Specify which filter to use. This option accepts the following values:
+
+@table @samp
+@item derain
+Derain filter. To conduct derain filter, you need to use a derain model.
+
+@item dehaze
+Dehaze filter. To conduct dehaze filter, you need to use a dehaze model.
+@end table
+Default value is @samp{derain}.
+
 @item dnn_backend
 Specify which DNN backend to use for model loading and execution. This option 
accepts
 the following values:
diff --git a/libavfilter/vf_derain.c b/libavfilter/vf_derain.c
index c380b40122..b33c37bfb4 100644
--- a/libavfilter/vf_derain.c
+++ b/libavfilter/vf_derain.c
@@ -35,6 +35,7 @@ typedef struct DRContext {
 const AVClass *class;
 
 char  *model_filename;
+intfilter_type;
 DNNBackendType backend_type;
 DNNModule *dnn_module;
 DNNModel  *model;
@@ -46,12 +47,16 @@ typedef struct DRContext {
 #define OFFSET(x) offsetof(DRContext, x)
 #define FLAGS AV_OPT_FLAG_FILTERING_PARAM | AV_OPT_FLAG_VIDEO_PARAM
 static const AVOption derain_options[] = {
-{ "dnn_backend", "DNN backend", OFFSET(backend_type),   
AV_OPT_TYPE_INT,{ .i64 = 0 },0, 1, FLAGS, "backend" },
-{ "native",  "native backend flag", 0,  
AV_OPT_TYPE_CONST,  { .i64 = 0 },0, 0, FLAGS, "backend" },
+{ "filter_type", "filter type(derain/dehaze)",  OFFSET(filter_type),
AV_OPT_TYPE_INT,{ .i64 = 0 },0, 1, FLAGS, "type" },
+{ "derain",  "derain filter flag",  0,  
AV_OPT_TYPE_CONST,  { .i64 = 0 },0, 0, FLAGS, "type" },
+{ "dehaze",  "dehaze filter flag",  0,  
AV_OPT_TYPE_CONST,  { .i64 = 1 },0, 0, FLAGS, "type" },
+
+{ "dnn_backend", "DNN backend", OFFSET(backend_type),   
AV_OPT_TYPE_INT,{ .i64 = 0 },0, 1, FLAGS, "backend" },
+{ "native",  "native backend flag", 0,  
AV_OPT_TYPE_CONST,  { .i64 = 0 },0, 0, FLAGS, "backend" },
 #if (CONFIG_LIBTENSORFLOW == 1)
-{ "tensorflow",  "tensorflow backend flag", 0,  
AV_OPT_TYPE_CONST,  { .i64 = 1 },0, 0, FLAGS, "backend" },
+{ "tensorflow",  "tensorflow backend flag", 0,  
AV_OPT_TYPE_CONST,  { .i64 = 1 },0, 0, FLAGS, "backend" },
 #endif
-{ "model",   "path to model file",  OFFSET(model_filename), 
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, FLAGS },
+{ "model",   "path to model file",  OFFSET(model_filename), 
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, FLAGS },
 { NULL }
 };
 
-- 
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] libavfilter: Add dehaze-filter option in existing derain filter.

[Liu Steven]

> 在 2019年8月22日，下午5:08，Xuewei Meng  写道：
> 
> Add the support of dehaze filter in existing derain filter source
> code. As the processing procedure in FFmpeg is the same for current
> derain and dehaze, we reuse the derain filter source code. The
> model training and generation scripts are in repo
> https://github.com/XueweiMeng/derain_filter.git.
> 
> Signed-off-by: Xuewei Meng 
> ---
> doc/filters.texi| 14 +-
> libavfilter/vf_derain.c | 13 +
> 2 files changed, 22 insertions(+), 5 deletions(-)
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 323c02970e..49fc030489 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -8431,7 +8431,7 @@ delogo=x=0:y=0:w=100:h=77:band=10
> 
> @section derain
> 
> -Remove the rain in the input image/video by applying the derain methods 
> based on
> +Remove the rain/haze in the input image/video by applying the derain/dehaze 
> methods based on
> convolutional neural networks. Supported models:
> 
> @itemize
> @@ -8449,6 +8449,18 @@ files (.pb) by using tools/python/convert.py
> The filter accepts the following options:
> 
> @table @option
> +@item filter_type
> +Specify which filter to use. This option accepts the following values:
> +
> +@table @samp
> +@item derain
> +Derain filter. To conduct derain filter, you need to use a derain model.
> +
> +@item dehaze
> +Dehaze filter. To conduct dehaze filter, you need to use a dehaze model.
> +@end table
> +Default value is @samp{derain}.
> +
> @item dnn_backend
> Specify which DNN backend to use for model loading and execution. This option 
> accepts
> the following values:
> diff --git a/libavfilter/vf_derain.c b/libavfilter/vf_derain.c
> index c380b40122..b33c37bfb4 100644
> --- a/libavfilter/vf_derain.c
> +++ b/libavfilter/vf_derain.c
> @@ -35,6 +35,7 @@ typedef struct DRContext {
> const AVClass *class;
> 
> char  *model_filename;
> +intfilter_type;
> DNNBackendType backend_type;
> DNNModule *dnn_module;
> DNNModel  *model;
> @@ -46,12 +47,16 @@ typedef struct DRContext {
> #define OFFSET(x) offsetof(DRContext, x)
> #define FLAGS AV_OPT_FLAG_FILTERING_PARAM | AV_OPT_FLAG_VIDEO_PARAM
> static const AVOption derain_options[] = {
> -{ "dnn_backend", "DNN backend", OFFSET(backend_type),   
> AV_OPT_TYPE_INT,{ .i64 = 0 },0, 1, FLAGS, "backend" },
> -{ "native",  "native backend flag", 0,  
> AV_OPT_TYPE_CONST,  { .i64 = 0 },0, 0, FLAGS, "backend" },
> +{ "filter_type", "filter type(derain/dehaze)",  OFFSET(filter_type),
> AV_OPT_TYPE_INT,{ .i64 = 0 },0, 1, FLAGS, "type" },
> +{ "derain",  "derain filter flag",  0,  
> AV_OPT_TYPE_CONST,  { .i64 = 0 },0, 0, FLAGS, "type" },
> +{ "dehaze",  "dehaze filter flag",  0,  
> AV_OPT_TYPE_CONST,  { .i64 = 1 },0, 0, FLAGS, "type" },
> +
> +{ "dnn_backend", "DNN backend", OFFSET(backend_type),   
> AV_OPT_TYPE_INT,{ .i64 = 0 },0, 1, FLAGS, "backend" },
This should no modify context.

> +{ "native",  "native backend flag", 0,  
> AV_OPT_TYPE_CONST,  { .i64 = 0 },0, 0, FLAGS, "backend" },
This should no modify context.

> #if (CONFIG_LIBTENSORFLOW == 1)
> -{ "tensorflow",  "tensorflow backend flag", 0,  
> AV_OPT_TYPE_CONST,  { .i64 = 1 },0, 0, FLAGS, "backend" },
> +{ "tensorflow",  "tensorflow backend flag", 0,  
> AV_OPT_TYPE_CONST,  { .i64 = 1 },0, 0, FLAGS, "backend" },
This should no modify context.

> #endif
> -{ "model",   "path to model file",  OFFSET(model_filename), 
> AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, FLAGS },
> +{ "model",   "path to model file",  OFFSET(model_filename), 
> AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, FLAGS },
This should no modify context.
> { NULL }
> };
> 
maybe only need add tree parameters, is it?
> -- 
> 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 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] avformat: Fix probing on some JPEGs

[Carl Eugen Hoyos]

Am Mi., 21. Aug. 2019 um 23:05 Uhr schrieb Niki Bowe
:
>
> On Mon, Aug 19, 2019 at 7:22 PM Carl Eugen Hoyos  wrote:
>
> >
> > This score would mean that mjpeg can never be detected.
> > I suspect you have to reduce one of the demuxers to "- 1".
> >
> >
> Thanks Carl.
> Attached patch to reduce mpeg probe by -1, which also fixes the issue.

Sorry, I misread the original report, it looked to me as if mJpeg was
the culprit.

Imo, the mpeg probing should be fixed (return a smaller value) for your sample
by detecting that it is not mpeg, not by returning a smaller value for
all samples.

Carl Eugen
___
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] Add assembly support for -fsanitize=hwaddress tagged globals.

[Carl Eugen Hoyos]

Am Mi., 21. Aug. 2019 um 21:27 Uhr schrieb Peter Collingbourne
:
>
> As of LLVM r368102, Clang will set a pointer tag in bits 56-63 of the
> address of a global when compiling with -fsanitize=hwaddress. This requires
> an adjustment to assembly code that takes the address of such globals: the
> code cannot use the regular R_AARCH64_ADR_PREL_PG_HI21 relocation to refer
> to the global, since the tag would take the address out of range. Instead,
> the code must use the non-checking (_NC) variant of the relocation (the
> link-time check is substituted by a runtime check).
>
> This change makes the necessary adjustment in the movrel macro, where it is
> needed when compiling with -fsanitize=hwaddress.

Patch applied.

Thank you, Carl Eugen
___
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/4] tools/target_dec_fuzzer: Adjust max_pixels for IDCIN

[Tomas Härdin]

tor 2019-08-22 klockan 10:34 +0200 skrev Michael Niedermayer:
> On Thu, Aug 22, 2019 at 10:23:40AM +0200, Paul B Mahol wrote:
> > On Thu, Aug 22, 2019 at 10:16 AM Michael Niedermayer <
> > mich...@niedermayer.cc>
> > wrote:
> > 
> > > On Thu, Aug 22, 2019 at 10:09:30AM +0200, Paul B Mahol wrote:
> > > > Why not fix issues listed in decoder code instead of this hack?

I think there's better things we could have Michael do. That said:

> > Also all this old game codecs never used very high resolutions.
> > Max something vga, but not even that.
> 
> limiting to 640x480 instead of 4096x4096 would give a factor of about
> 55
> speedup, thats still a long way from 2000 so that solves also only
> part of it
> 
> anyway ill provide a patch that limits resolution so theres something
> that can be discussed. 

The probing in lavf/idcin.c already limits the resolution to 1024x1024.
The only sample we have is 320x240. The Quake 2 decoder (cl_cin.c)
limits CIN frames to 128 KiB compressed, from which the 1024x1024 limit
in idcinvideo.c likely derives (128 KiB == 1 Mib == 1 Mipx if always
using the shortest Huffman code). Zero-byte packets are also not
allowed.

If we're looking over this anyway we could toss in all these
limitations, and maybe limit audio to 11025, 22050 and 44100 Hz.

I also notice that idcinvideo.c contains code copy-pasted from cl_cin.c
in Quake 2 (SmallestNode1 -> huff_smallest_node). The copyright header
should reflect this.

/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 4/4] tools/target_dec_fuzzer: Adjust max_pixels for IDCIN

[Paul B Mahol]

On Thu, Aug 22, 2019 at 11:24 AM Tomas Härdin  wrote:

> tor 2019-08-22 klockan 10:34 +0200 skrev Michael Niedermayer:
> > On Thu, Aug 22, 2019 at 10:23:40AM +0200, Paul B Mahol wrote:
> > > On Thu, Aug 22, 2019 at 10:16 AM Michael Niedermayer <
> > > mich...@niedermayer.cc>
> > > wrote:
> > >
> > > > On Thu, Aug 22, 2019 at 10:09:30AM +0200, Paul B Mahol wrote:
> > > > > Why not fix issues listed in decoder code instead of this hack?
>
> I think there's better things we could have Michael do. That said:
>

Yes, more timeouts fixes as always.


>
> > > Also all this old game codecs never used very high resolutions.
> > > Max something vga, but not even that.
> >
> > limiting to 640x480 instead of 4096x4096 would give a factor of about
> > 55
> > speedup, thats still a long way from 2000 so that solves also only
> > part of it
> >
> > anyway ill provide a patch that limits resolution so theres something
> > that can be discussed.
>
> The probing in lavf/idcin.c already limits the resolution to 1024x1024.
> The only sample we have is 320x240. The Quake 2 decoder (cl_cin.c)
> limits CIN frames to 128 KiB compressed, from which the 1024x1024 limit
> in idcinvideo.c likely derives (128 KiB == 1 Mib == 1 Mipx if always
> using the shortest Huffman code). Zero-byte packets are also not
> allowed.
>
> If we're looking over this anyway we could toss in all these
> limitations, and maybe limit audio to 11025, 22050 and 44100 Hz.
>
> I also notice that idcinvideo.c contains code copy-pasted from cl_cin.c
> in Quake 2 (SmallestNode1 -> huff_smallest_node). The copyright header
> should reflect this.
>

That is sole reason why that awful code should not be kept, and instead
should be rewritten.


> /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".
___
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] avformat: Fix probing on some JPEGs

[Paul B Mahol]

On Thu, Aug 22, 2019 at 11:19 AM Carl Eugen Hoyos 
wrote:

> Am Mi., 21. Aug. 2019 um 23:05 Uhr schrieb Niki Bowe
> :
> >
> > On Mon, Aug 19, 2019 at 7:22 PM Carl Eugen Hoyos 
> wrote:
> >
> > >
> > > This score would mean that mjpeg can never be detected.
> > > I suspect you have to reduce one of the demuxers to "- 1".
> > >
> > >
> > Thanks Carl.
> > Attached patch to reduce mpeg probe by -1, which also fixes the issue.
>
> Sorry, I misread the original report, it looked to me as if mJpeg was
> the culprit.
>
> Imo, the mpeg probing should be fixed (return a smaller value) for your
> sample
> by detecting that it is not mpeg, not by returning a smaller value for
> all samples.
>

1000% agree.


> Carl Eugen
> ___
> 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]lavf/r3d: Check avio_read() return value

[Carl Eugen Hoyos]

Hi!

Attached patch fixes usage of uninitialized data reading broken r3d files.

Please review, Carl Eugen
From efce9940b890b9cf5a9e7400b05be10f6906fbb1 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Thu, 22 Aug 2019 12:02:36 +0200
Subject: [PATCH] lavf/r3d: Check avio_read() return value.

Fixes use of uninitialized data reading broken files.
Reported-by: Anatoly Trosinenko 
---
 libavformat/r3d.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/r3d.c b/libavformat/r3d.c
index 224bcf780d..919c3c4960 100644
--- a/libavformat/r3d.c
+++ b/libavformat/r3d.c
@@ -98,7 +98,8 @@ static int r3d_read_red1(AVFormatContext *s)
 r3d->audio_channels = avio_r8(s->pb); // audio channels
 av_log(s, AV_LOG_TRACE, "audio channels %d\n", tmp);
 
-avio_read(s->pb, filename, 257);
+if (avio_read(s->pb, filename, 257) < 0)
+return AVERROR_INVALIDDATA;
 filename[sizeof(filename)-1] = 0;
 av_dict_set(&st->metadata, "filename", filename, 0);
 
-- 
2.22.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]lavc/g729dec: Support decoding ACELP.KELVIN

[Carl Eugen Hoyos]

Am Mo., 19. Aug. 2019 um 23:37 Uhr schrieb Carl Eugen Hoyos
:
>
> Hi!
>
> Attached patch fixes tickets #4799 and #8081, thanks to Paul for his help.

New patch attached.

Carl Eugen
From 8af0b279ad0c25425d075498f60b0770528687a2 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Mon, 19 Aug 2019 23:34:37 +0200
Subject: [PATCH] lavc/g729dec: Support decoding Sipro ACELP.KELVIN.

Fixes ticket #4799.
Analyzed-by: Aleksandr Ustinov
---
 Changelog|  3 +++
 configure|  1 +
 doc/general.texi |  1 +
 libavcodec/allcodecs.c   |  1 +
 libavcodec/avcodec.h |  1 +
 libavcodec/codec_desc.c  |  6 ++
 libavcodec/g729_parser.c |  5 +++--
 libavcodec/g729dec.c | 21 +++--
 libavcodec/version.h |  2 +-
 libavformat/riff.c   |  1 +
 10 files changed, 37 insertions(+), 5 deletions(-)

diff --git a/Changelog b/Changelog
index 52096eed0e..1c0ceddb4c 100644
--- a/Changelog
+++ b/Changelog
@@ -5,6 +5,7 @@ version :
 - v360 filter
 - Intel QSV-accelerated MJPEG decoding
 - Intel QSV-accelerated VP9 decoding
+- support Sipro ACELP.KELVIN decoding
 
 version 4.2:
 - tpad filter
diff --git a/doc/general.texi b/doc/general.texi
index 3c0c803449..d90588c63a 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1057,6 +1057,7 @@ following image formats are supported:
 @item AAC+   @tab  E  @tab  IX
 @tab encoding supported through external library libfdk-aac
 @item AC-3   @tab IX  @tab  IX
+@item ACELP.KELVIN   @tab @tab  X
 @item ADPCM 4X Movie @tab @tab  X
 @item APDCM Yamaha AICA  @tab @tab  X
 @item ADPCM CDROM XA @tab @tab  X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index e49188357b..ff4004f39a 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -173,6 +173,7 @@ OBJS-$(CONFIG_AC3_FIXED_DECODER)   += ac3dec_fixed.o ac3dec_data.o ac3.o kbd
 OBJS-$(CONFIG_AC3_ENCODER) += ac3enc_float.o ac3enc.o ac3tab.o \
   ac3.o kbdwin.o
 OBJS-$(CONFIG_AC3_FIXED_ENCODER)   += ac3enc_fixed.o ac3enc.o ac3tab.o ac3.o
+OBJS-$(CONFIG_ACELP_KELVIN_DECODER)+= g729dec.o lsp.o celp_math.o celp_filters.o acelp_filters.o acelp_pitch_delay.o acelp_vectors.o g729postfilter.o
 OBJS-$(CONFIG_AGM_DECODER) += agm.o
 OBJS-$(CONFIG_AIC_DECODER) += aic.o
 OBJS-$(CONFIG_ALAC_DECODER)+= alac.o alac_data.o alacdsp.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index d2f9a39ce5..5936cdc467 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -32,6 +32,7 @@
 extern AVCodec ff_a64multi_encoder;
 extern AVCodec ff_a64multi5_encoder;
 extern AVCodec ff_aasc_decoder;
+extern AVCodec ff_acelp_kelvin_decoder;
 extern AVCodec ff_aic_decoder;
 extern AVCodec ff_alias_pix_encoder;
 extern AVCodec ff_alias_pix_decoder;
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index d234271c5b..7ec4014d8b 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -629,6 +629,7 @@ enum AVCodecID {
 AV_CODEC_ID_ON2AVC,
 AV_CODEC_ID_DSS_SP,
 AV_CODEC_ID_CODEC2,
+AV_CODEC_ID_ACELP_KELVIN,
 
 AV_CODEC_ID_FFWAVESYNTH = 0x15800,
 AV_CODEC_ID_SONIC,
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 4d033c20ff..716e278b93 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -2834,6 +2834,12 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("codec2 (very low bitrate speech codec)"),
 .props = AV_CODEC_PROP_LOSSY,
 },
+{
+.id= AV_CODEC_ID_ACELP_KELVIN,
+.name  = "acelp.kelvin",
+.long_name = NULL_IF_CONFIG_SMALL("Sipro ACELP.KELVIN"),
+.props = AV_CODEC_PROP_LOSSY,
+},
 {
 .id= AV_CODEC_ID_FFWAVESYNTH,
 .type  = AVMEDIA_TYPE_AUDIO,
diff --git a/libavcodec/g729_parser.c b/libavcodec/g729_parser.c
index 9982dbfffc..5a57025d62 100644
--- a/libavcodec/g729_parser.c
+++ b/libavcodec/g729_parser.c
@@ -45,9 +45,10 @@ static int g729_parse(AVCodecParserContext *s1, AVCodecContext *avctx,
 int next;
 
 if (!s->block_size) {
-av_assert1(avctx->codec_id == AV_CODEC_ID_G729);
 /* FIXME: replace this heuristic block_size with more precise estimate */
 s->block_size = (avctx->bit_rate < 8000) ? G729D_6K4_BLOCK_SIZE : G729_8K_BLOCK_SIZE;
+if (avctx->codec_id == AV_CODEC_ID_ACELP_KELVIN)
+s->block_size++;
 s->block_size *= avctx->channels;
 s->duration   = avctx->frame_size;
 }
@@ -76,7 +77,7 @@ static int g729_parse(AVCodecParserContext *s1, AVCodecContext *avctx,
 }
 
 AVCodecParser ff_g729_parser = {
-.codec_ids  = { AV_CODEC_ID_G729 },
+.codec_ids  = { AV_CODEC_ID_G729, AV_CODEC_ID_ACELP_KELVIN },
 .priv_data_size = sizeof(G729ParseContext),
 .parser_parse   = g729_parse,
 .parser_clo

Re: [FFmpeg-devel] [PATCH 1/3] avformat/mxfdec: do not ignore bad size errors

[Tomas Härdin]

ons 2019-08-21 klockan 21:54 +0200 skrev Marton Balint:
> 
> On Sun, 18 Aug 2019, Tomas Härdin wrote:
> 
> > lör 2019-08-17 klockan 21:41 +0200 skrev Marton Balint:
> > > The return value was unintentionally lost after
> > > 00a2652df3bf25a27d174cc67ed508b5317cb115.
> > > 
> > > Signed-off-by: Marton Balint 
> > > ---
> > >  libavformat/mxfdec.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > > index bb72fb9841..397f820b3f 100644
> > > --- a/libavformat/mxfdec.c
> > > +++ b/libavformat/mxfdec.c
> > > @@ -3508,8 +3508,8 @@ static int mxf_read_packet(AVFormatContext *s, 
> > > AVPacket *pkt)
> > >  } else {
> > >  if ((size = next_ofs - pos) <= 0) {
> > >  av_log(s, AV_LOG_ERROR, "bad size: %"PRId64"\n", 
> > > size);
> > > -ret = AVERROR_INVALIDDATA;
> > > -goto skip;
> > > +mxf->current_klv_data = (KLVPacket){{0}};
> > > +return AVERROR_INVALIDDATA;
> > 
> > Should maybe ask for a sample. Else looks OK
> 
> I don't think this can happen with any of the valid files, so the text 
> saying that ffmpeg is missing a feature probably won't be true. It is a 
> lot more likely that the user has a broken file if this error is shown.
> 
> So I'd rather keep it as is.

Right, the skip had me confused. This is fine of course

/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".

[FFmpeg-devel] [PATCH v2] libavfilter: Add dehaze-filter option in existing derain.

[Xuewei Meng]

Add the support of dehaze filter in existing derain filter source
code. As the processing procedure in FFmpeg is the same for current
derain and dehaze, we reuse the derain filter source code. The
model training and generation scripts are in repo
https://github.com/XueweiMeng/derain_filter.git

Signed-off-by: Xuewei Meng 
---
 doc/filters.texi| 12 
 libavfilter/vf_derain.c |  5 +
 2 files changed, 17 insertions(+)

diff --git a/doc/filters.texi b/doc/filters.texi
index 323c02970e..5d63b337f8 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8449,6 +8449,18 @@ files (.pb) by using tools/python/convert.py
 The filter accepts the following options:
 
 @table @option
+@item filter_type
+Specify which filter to use. This option accepts the following values:
+
+@table @samp
+@item derain
+Derain filter. To conduct derain filter, you need to use a derain model.
+
+@item dehaze
+Dehaze filter. To conduct dehaze filter, you need to use a dehaze model.
+@end table
+Default value is @samp{derain}.
+
 @item dnn_backend
 Specify which DNN backend to use for model loading and execution. This option 
accepts
 the following values:
diff --git a/libavfilter/vf_derain.c b/libavfilter/vf_derain.c
index c380b40122..110eab54ff 100644
--- a/libavfilter/vf_derain.c
+++ b/libavfilter/vf_derain.c
@@ -34,6 +34,7 @@
 typedef struct DRContext {
 const AVClass *class;
 
+intfilter_type;
 char  *model_filename;
 DNNBackendType backend_type;
 DNNModule *dnn_module;
@@ -46,6 +47,10 @@ typedef struct DRContext {
 #define OFFSET(x) offsetof(DRContext, x)
 #define FLAGS AV_OPT_FLAG_FILTERING_PARAM | AV_OPT_FLAG_VIDEO_PARAM
 static const AVOption derain_options[] = {
+{ "filter_type", "filter type(derain/dehaze)",  OFFSET(filter_type),
AV_OPT_TYPE_INT,{ .i64 = 0 },0, 1, FLAGS, "type" },
+{ "derain",  "derain filter flag",  0,  
AV_OPT_TYPE_CONST,  { .i64 = 0 },0, 0, FLAGS, "type" },
+{ "dehaze",  "dehaze filter flag",  0,  
AV_OPT_TYPE_CONST,  { .i64 = 1 },0, 0, FLAGS, "type" },
+
 { "dnn_backend", "DNN backend", OFFSET(backend_type),   
AV_OPT_TYPE_INT,{ .i64 = 0 },0, 1, FLAGS, "backend" },
 { "native",  "native backend flag", 0,  
AV_OPT_TYPE_CONST,  { .i64 = 0 },0, 0, FLAGS, "backend" },
 #if (CONFIG_LIBTENSORFLOW == 1)
-- 
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] DVB EPG decoder

[Michael Niedermayer]

On Wed, Aug 21, 2019 at 06:28:08PM +0200, Anthony Delannoy wrote:
> Hi,
> 
> In the attached files is the first implementation of:
> * dvb descriptors parsing api to ease their use on different sections (for
> now i've only implemented EIT section)
> * EIT table and subtable
> * EIT callback in lavf/mpegts.c generating epg AVPacket
> * EPG decoder to decode epg AVPacket and store decoded infos in
> AVFrame::side_data with a new type AV_FRAME_DATA_EPG_TABLE
> 
> I kept the EPG{Sub,}Table as raw as possible, EPG data manipulation have to
> be done using FFmpeg API for now.
> 
> Let me know if those patch need changements/improvements.

fate checksums change so this needs to update them if the changes are intended

fails to build on MIPS
CC  libavcodec/epgdec.o
In file included from src/libavcodec/epgdec.c:31:
src/libavutil/dvb.h:123: warning: declaration does not declare anything
In file included from src/libavcodec/epgdec.c:31:
src/libavutil/dvb.h:158: warning: declaration does not declare anything
In file included from src/libavcodec/epgdec.c:32:
src/libavutil/dvbdescriptors.h:275: warning: declaration does not declare 
anything
In file included from src/libavcodec/epgdec.c:32:
src/libavutil/dvbdescriptors.h:748: warning: declaration does not declare 
anything
In file included from src/libavcodec/epgdec.c:32:
src/libavutil/dvbdescriptors.h:965: warning: declaration does not declare 
anything
src/libavcodec/epgdec.c: In function ‘epg_handle_descriptor’:
src/libavcodec/epgdec.c:57: error: ‘EPGSubTable’ has no member named 
‘descriptors’
src/libavcodec/epgdec.c:57: error: ‘EPGSubTable’ has no member named 
‘nb_descriptors’
src/libavcodec/epgdec.c:61: error: ‘EPGSubTable’ has no member named 
‘descriptors’
src/libavcodec/epgdec.c:61: error: ‘EPGSubTable’ has no member named 
‘nb_descriptors’
src/libavcodec/epgdec.c: In function ‘epg_receive_frame’:
src/libavcodec/epgdec.c:159: error: ‘EPGTable’ has no member named ‘subtables’
src/libavcodec/epgdec.c:159: error: ‘EPGTable’ has no member named 
‘nb_subtables’
src/libavcodec/epgdec.c:162: error: ‘EPGTable’ has no member named ‘subtables’
src/libavcodec/epgdec.c:162: error: ‘EPGTable’ has no member named 
‘nb_subtables’
src/libavcodec/epgdec.c:163: error: ‘EPGTable’ has no member named ‘subtables’
src/libavcodec/epgdec.c:163: error: ‘EPGTable’ has no member named 
‘nb_subtables’
src/libavcodec/epgdec.c:165: error: ‘EPGTable’ has no member named ‘subtables’
src/libavcodec/epgdec.c:165: error: ‘EPGTable’ has no member named 
‘nb_subtables’
make: *** [libavcodec/epgdec.o] Error 1


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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] libavformat/mxfenc: Allow more bitrates for NTSC IMX50

[Tomas Härdin]

ons 2019-08-21 klockan 12:47 -0700 skrev Baptiste Coudurier:
> Hey guys,
> 
> 
> > On Aug 19, 2019, at 9:54 AM, Thomas Mundt  wrote:
> > 
> > Am Fr., 16. Aug. 2019 um 23:31 Uhr schrieb Tomas Härdin  > > :
> > > tor 2019-08-15 klockan 13:55 +0200 skrev Thomas Mundt:
> > > > Am Do., 15. Aug. 2019 um 11:01 Uhr schrieb Tomas Härdin <
> > > tjop...@acc.umu.se
> > > > > :
> > > > > ons 2019-08-14 klockan 22:18 +0200 skrev Thomas Mundt:
> > > > > > 
> > > > > > New patch attached.
> > > > > 
> > > > > Looks OK. I'll push in a few days if no one else has any comments
> > > > > 
> > > > 
> > > > Thanks. Would you mind porting it to branches 4.1 and 4.2?
> > > 
> > > I'm not quite sure what the process is for that. I have confirmed that
> > > the problem exists in 4.1 and 4.2 and that your patch fixes it.
> > > 
> > > I think we also might want to put a note somewhere in the documentation
> > > how to make NTSC IMX50 files.
> > > 
> 
> Yeah, it’s been an issue for quite some time, s356m mentions:
> "When used as a signal source for the type D-10 recording format, the
> bit stream is carried by SDTI-CP, as defined in SMPTE 326M, using
> recommended operating point bit rates as defined in this annex. Other
> bit rates may be used. However, users are cautioned that other system
> design parameters within the studio may not support all bit rates.
> 
> Table A.1 indicates recommended operating points to simplify studio
> operations and to provide users with a tool to be used in designing
> systems."
> 
> Then specifies the exact value of the sequence_header bit_rate_value,
> 50mit/s being “1E848h”, "To be used when compliant with EBU D84 and
> D85"

mpeg12enc.c does this, if I read it correctly. 4840 / 400 =
124999.6 which gets rounded up to 125000.

> I don’t think it is a good idea to produce files with the wrong
> bit_rate value, and I know for a fact that many file analyzers in use
> today will simply reject the d-10 essence.

Would writing 5000 in mxfenc for values in the range
[4840,5000] make it pass?

> The current code is simply a hack, and IMHO the right solution is to
> put an option to force the ratecontrol to behave as people want for
> NTSC D-10. I’ve submitted a patch for that but Michael wanted it as
> an option.

An option to set the exact desired packet size would be useful for
other things too, so sounds like a good idea.

/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] [v3] avformat/flvdec: delete unused code

[Tao Zhang]

Michael Niedermayer  于2019年8月18日周日 下午5:49写道：
>
> On Wed, Aug 14, 2019 at 11:07:18AM +0800, leozhang wrote:
> > Reviewed-by: Carl Eugen Hoyos 
> > Signed-off-by: leozhang 
> > ---
> >  libavformat/flvdec.c | 17 -
> >  1 file changed, 17 deletions(-)
>
> probably ok
Hi Michael, I'm sorry to bother you at your busy time and is it the
time to push it?
>
> thx
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> it is not once nor twice but times without number that the same ideas make
> their appearance in the world. -- Aristotle
> ___
> 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] DVB EPG decoder

[Carl Eugen Hoyos]

Am Do., 22. Aug. 2019 um 12:42 Uhr schrieb Michael Niedermayer
:
>
> On Wed, Aug 21, 2019 at 06:28:08PM +0200, Anthony Delannoy wrote:
> > Hi,
> >
> > In the attached files is the first implementation of:
> > * dvb descriptors parsing api to ease their use on different sections (for
> > now i've only implemented EIT section)
> > * EIT table and subtable
> > * EIT callback in lavf/mpegts.c generating epg AVPacket
> > * EPG decoder to decode epg AVPacket and store decoded infos in
> > AVFrame::side_data with a new type AV_FRAME_DATA_EPG_TABLE
> >
> > I kept the EPG{Sub,}Table as raw as possible, EPG data manipulation have to
> > be done using FFmpeg API for now.
> >
> > Let me know if those patch need changements/improvements.
>
> fate checksums change so this needs to update them if the changes are intended

To clarify: This should not be a 13th patch but every patch has to include
the fate changes it causes.

> fails to build on MIPS

Seems to be because of these two structs within EPGTable and EPGSubTable:
+struct {
+int nb_descriptors;
+void **descriptors;
+};

Some of your new files do not contain license headers, please fix that
independently
of other reviews.

Afaict, some patches change files that were added in earlier patches. This may
not be ideal.

Why are the big api changes necessary at all?

Carl Eugen
___
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] avcodec/libvpxenc: add ROI-based encoding support for VP8/VP9 support

[Guo, Yejun]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Moritz Barsnick
> Sent: Thursday, August 22, 2019 3:31 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH V4] avcodec/libvpxenc: add ROI-based
> encoding support for VP8/VP9 support
> 
> On Thu, Aug 22, 2019 at 08:56:28 +0800, Guo, Yejun wrote:
> > +/* This list must be iterated in reverse, so for the case that
> > + * two regions overlapping, the more important area takes effect.
> 
> Nit: "overlap" or "are overlapping".

thanks, will change.

> 
> > +#ifdef VPX_CTRL_VP9E_SET_ROI_MAP
> [...]
> > +#endif
> > +
> > +av_assert0(!roi_supported);
> > +if (!ctx->roi_warned) {
> > +ctx->roi_warned = 1;
> > +av_log(avctx, AV_LOG_WARNING, "ROI is not supported, please
> upgrade libvpx to version >= 1.8.1\n");
> > +}
> 
> Nit: upgrading alone won't help, you'll actually need to rebuild. ;-)
> (I'm saying it may be confusing to the end user, if they ever encounter
> it.)

yes, it will confuse end user. For version 1.8.0 to 1.8.1, there is no need to 
rebuild, but for others, the rebuild is needed.

I'll add message like: and you might need to build ffmpeg again.

> 
> Cheers,
> Moritz
> ___
> 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 v15 03/15] lavc/tiff: Convert DNGs to sRGB color space

[Moritz Barsnick]

On Tue, Aug 20, 2019 at 16:37:35 +0300, Nick Renieris wrote:
> +static float av_always_inline linear_to_srgb(float value) {
> +if (value <= 0.0031308)
> +return value * 12.92;
> +else
> +return pow(value * 1.055, 1.0 / 2.4) - 0.055;
> +}

Do you need the intermediate double precision, which this promotes to?
If not:
- The constants require the suffix 'f'.
- pow() should be powf().

if (value <= 0.0031308f)
return value * 12.92f;
else
return powf(value * 1.055f, 1.0f / 2.4f) - 0.055f;

Cheers,
Moritz
___
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 v15 05/15] lavc/jpegtables: Handle multiple mappings to the same value

[Moritz Barsnick]

On Tue, Aug 20, 2019 at 16:37:37 +0300, Nick Renieris wrote:
> Some JPEGs [1] have incorrect DHT entries that map 2 codes to

This [1] becomes part of the commit message, ...

> ---
>
> [1]: Embedded JPEGs in "X7 RAW" and "X7 CinemaDNG" samples here:
>  https://www.dji.com/gr/zenmuse-x7/info#downloads

..., and this not, as far as I can tell, because you used three dashes to
separate? I may be totally wrong.

> Signed-off-by: Nick Renieris 
> ---

Like these.

Moritz
___
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 v15 06/15] lavc/tiff: Fix edge case with full-length/width tiles

[Moritz Barsnick]

On Tue, Aug 20, 2019 at 16:37:38 +0300, Nick Renieris wrote:
> In an image [1], the height was equal to the tile length (full-height

Nit: "[1]" doesn't refer to anything here.

Moritz
___
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 v15 08/15] lavc/tiff: Force DNG pixel data endianness on an edge case

[Moritz Barsnick]

On Tue, Aug 20, 2019 at 16:37:40 +0300, Nick Renieris wrote:
> +/* Force endianness as mentioned in 'DNG Specification: Chapter 3: 
> BitsPerSample'
> +NOTE: The spec actually specifies big-endian, not sure why we 
> need little-endian,
> +  but such images don't work otherwise. */

Were there certain samples which exposed this need? Do you want to
share a link? Are you sure the samples are correctly encoded?

Cheers,
Moritz
___
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 2/3] avfilter/vsrc_mptestsrc: simplify the code and change the type of frame

[Moritz Barsnick]

On Mon, Aug 12, 2019 at 23:39:52 +0800, lance.lmw...@gmail.com wrote:

This looks very wrong. Does it work?

> -if (tt == TEST_ALL && frame%test->max_frames) /* draw a black frame at 
> the beginning of each test */
> -tt = (frame/test->max_frames)%(TEST_NB-1);
> +frame = frame/test->max_frames;

Here, you reduce frame to frame/test->max_frames.

> +if (tt == TEST_ALL && frame) /* draw a black frame at the beginning of 
> each test */
> +tt = frame%(TEST_NB-1);

Which makes this replacement correct. But:

> -case TEST_DC_LUMA:   dc_test(picref->data[0], picref->linesize[0], 
> 256, 256, frame%test->max_frames); break;
> -case TEST_DC_CHROMA: dc_test(picref->data[1], picref->linesize[1], 
> 256, 256, frame%test->max_frames); break;
> -case TEST_FREQ_LUMA:   freq_test(picref->data[0], picref->linesize[0], 
> frame%test->max_frames); break;
> -case TEST_FREQ_CHROMA: freq_test(picref->data[1], picref->linesize[1], 
> frame%test->max_frames); break;
> -case TEST_AMP_LUMA: amp_test(picref->data[0], picref->linesize[0], 
> frame%test->max_frames); break;
> -case TEST_AMP_CHROMA:   amp_test(picref->data[1], picref->linesize[1], 
> frame%test->max_frames); break;
> -case TEST_CBP:  cbp_test(picref->data   , picref->linesize   , 
> frame%test->max_frames); break;
> -case TEST_MV:mv_test(picref->data[0], picref->linesize[0], 
> frame%test->max_frames); break;
> -case TEST_RING1:  ring1_test(picref->data[0], picref->linesize[0], 
> frame%test->max_frames); break;
> -case TEST_RING2:  ring2_test(picref->data[0], picref->linesize[0], 
> frame%test->max_frames); break;
> +case TEST_DC_LUMA:   dc_test(picref->data[0], picref->linesize[0], 
> 256, 256, frame); break;
> +case TEST_DC_CHROMA: dc_test(picref->data[1], picref->linesize[1], 
> 256, 256, frame); break;
> +case TEST_FREQ_LUMA:   freq_test(picref->data[0], picref->linesize[0], 
> frame); break;
> +case TEST_FREQ_CHROMA: freq_test(picref->data[1], picref->linesize[1], 
> frame); break;
> +case TEST_AMP_LUMA: amp_test(picref->data[0], picref->linesize[0], 
> frame); break;
> +case TEST_AMP_CHROMA:   amp_test(picref->data[1], picref->linesize[1], 
> frame); break;
> +case TEST_CBP:  cbp_test(picref->data   , picref->linesize   , 
> frame); break;
> +case TEST_MV:mv_test(picref->data[0], picref->linesize[0], 
> frame); break;
> +case TEST_RING1:  ring1_test(picref->data[0], picref->linesize[0], 
> frame); break;
> +case TEST_RING2:  ring2_test(picref->data[0], picref->linesize[0], 
> frame); break;

Here, you have effectively replaced "frame%test->max_frames" with
"frame/test->max_frames" (now "frame"). Are you sure?

Cheers,
Moritz
___
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] EOF and IO error checking

[James Almer]

On 8/17/2019 4:10 PM, Marton Balint wrote:
> Hi,
> 
> As you might now avio_feof() returns true both in case of actual EOF and
> in case of IO errors.
> 
> Some demuxers (matroska) have special handling for this exact reason, e.g.:
> 
> if (avio_feof(pb)) {
>     if (pb->error) {
>     return pb->error;
>     } else {
>     return AVERROR_EOF;
>     }
> }
> 
> Most of the demuxers do not, so there is a real chance that IO errrors
> are mistaken for EOF.
> 
> What should we do about this?
> 
> a) Fix every demuxer to return IO error if there is one.
> 
> b) Add special code to ff_read_packet which checks if there is an error
> in the IO context and return that if there is?

Handling things in generic code is preferred over adding checks to every
demuxer, IMO.

Also, fixes in libavformat are always preferred over fixes/workarounds
in ffmpeg.c, since the latter will not have any effect on every other
library user.

> 
> c) Add code to ffmpeg.c which checks the IO context error code after
> every av_read_frame call?
> 
> Some other idea? Which one is preferred from these?
> 
> Thanks,
> Marton
> 
> 
> ___
> 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 3/4] avcodec/iff: Check for overlap in cmap_read_palette()

[Michael Niedermayer]

On Thu, Aug 22, 2019 at 09:32:39AM +0200, Moritz Barsnick wrote:
> On Thu, Aug 22, 2019 at 00:18:54 +0200, Michael Niedermayer wrote:
> 
> Nits:
> 
> > Fixes: undefined mempcpy() use
> 
> memcpy
> 
> > +avpriv_request_sample(avctx, "overlaping mask");
> 
> overlapping

locally corrected

[...]
-- 
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 1/4] avformat/realtextdec: free queue on error

[Michael Niedermayer]

On Wed, Aug 21, 2019 at 08:48:25PM -0300, James Almer wrote:
> On 8/21/2019 7:18 PM, Michael Niedermayer wrote:
> > Fixes: memleak
> > Fixes: 
> > 16277/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5696629440512000
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/realtextdec.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/libavformat/realtextdec.c b/libavformat/realtextdec.c
> > index 204e557aa2..c2316da0ed 100644
> > --- a/libavformat/realtextdec.c
> > +++ b/libavformat/realtextdec.c
> > @@ -123,6 +123,8 @@ static int realtext_read_header(AVFormatContext *s)
> >  
> >  end:
> >  av_bprint_finalize(&buf, NULL);
> > +if (res < 0)
> > +ff_subtitles_queue_clean(&rt->q);
> 
> LGTM

will apply

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Any man who breaks a law that conscience tells him is unjust and willingly 
accepts the penalty by staying in jail in order to arouse the conscience of 
the community on the injustice of the law is at that moment expressing the 
very highest respect for law. - Martin Luther King Jr


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/4] avformat/vividas: Check av_xiphlacing() return value before use

[Michael Niedermayer]

On Thu, Aug 22, 2019 at 09:44:02AM +0200, Paul B Mahol wrote:
> probably ok

will apply

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- 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 1/2] avcodec/vp5/6/8: use vpX_rac_is_end()

[Michael Niedermayer]

On Wed, Aug 21, 2019 at 07:41:00PM +1000, Peter Ross wrote:
> On Tue, Aug 20, 2019 at 11:51:48AM +0200, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/vp5.c | 2 +-
> >  libavcodec/vp6.c | 2 +-
> >  libavcodec/vp8.c | 8 
> >  3 files changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/libavcodec/vp5.c b/libavcodec/vp5.c
> > index 49988b8b76..0fca282918 100644
> > --- a/libavcodec/vp5.c
> > +++ b/libavcodec/vp5.c
> > @@ -183,7 +183,7 @@ static int vp5_parse_coeff(VP56Context *s)
> >  int b, i, cg, idx, ctx, ctx_last;
> >  int pt = 0;/* plane type (0 for Y, 1 for U or V) */
> >  
> > -if (c->end <= c->buffer && c->bits >= 0) {
> > +if (vpX_rac_is_end(c)) {
> >  av_log(s->avctx, AV_LOG_ERROR, "End of AC stream reached in 
> > vp5_parse_coeff\n");
> >  return AVERROR_INVALIDDATA;
> >  }
> > diff --git a/libavcodec/vp6.c b/libavcodec/vp6.c
> > index 977fcb7076..e5dec19f50 100644
> > --- a/libavcodec/vp6.c
> > +++ b/libavcodec/vp6.c
> > @@ -473,7 +473,7 @@ static int vp6_parse_coeff(VP56Context *s)
> >  int b, i, cg, idx, ctx;
> >  int pt = 0;/* plane type (0 for Y, 1 for U or V) */
> >  
> > -if (c->end <= c->buffer && c->bits >= 0) {
> > +if (vpX_rac_is_end(c)) {
> >  av_log(s->avctx, AV_LOG_ERROR, "End of AC stream reached in 
> > vp6_parse_coeff\n");
> >  return AVERROR_INVALIDDATA;
> >  }
> > diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
> > index efc62aabaf..eb51d1f3c9 100644
> > --- a/libavcodec/vp8.c
> > +++ b/libavcodec/vp8.c
> > @@ -658,7 +658,7 @@ static int vp7_decode_frame_header(VP8Context *s, const 
> > uint8_t *buf, int buf_si
> >  s->fade_present = vp8_rac_get(c);
> >  }
> >  
> > -if (c->end <= c->buffer && c->bits >= 0)
> > +if (vpX_rac_is_end(c))
> >  return AVERROR_INVALIDDATA;
> >  /* E. Fading information for previous frame */
> >  if (s->fade_present && vp8_rac_get(c)) {
> > @@ -693,7 +693,7 @@ static int vp7_decode_frame_header(VP8Context *s, const 
> > uint8_t *buf, int buf_si
> >  vp78_update_pred16x16_pred8x8_mvc_probabilities(s, VP7_MVC_SIZE);
> >  }
> >  
> > -if (c->end <= c->buffer && c->bits >= 0)
> > +if (vpX_rac_is_end(c))
> >  return AVERROR_INVALIDDATA;
> >  
> >  if ((ret = vp7_fade_frame(s, alpha, beta)) < 0)
> > @@ -2375,7 +2375,7 @@ static av_always_inline int 
> > decode_mb_row_no_filter(AVCodecContext *avctx, void
> >  curframe->tf.f->data[2] +  8 * mb_y * s->uvlinesize
> >  };
> >  
> > -if (c->end <= c->buffer && c->bits >= 0)
> > +if (vpX_rac_is_end(c))
> >   return AVERROR_INVALIDDATA;
> >  
> >  if (mb_y == 0)
> > @@ -2406,7 +2406,7 @@ static av_always_inline int 
> > decode_mb_row_no_filter(AVCodecContext *avctx, void
> >  td->mv_bounds.mv_max.x = ((s->mb_width - 1) << 6) + MARGIN;
> >  
> >  for (mb_x = 0; mb_x < s->mb_width; mb_x++, mb_xy++, mb++) {
> > -if (c->end <= c->buffer && c->bits >= 0)
> > +if (vpX_rac_is_end(c))
> >  return AVERROR_INVALIDDATA;
> >  // Wait for previous thread to read mb_x+2, and reach mb_y-1.
> >  if (prev_td != td) {
> 
> approve.

will apply

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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] avformat/mov: improve timecode calculation

[Paul B Mahol]

Hi,

patch attached.
___
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] Change libaom default to crf=32.

[James Zern]

Hi,

On Thu, Aug 22, 2019 at 12:25 AM Moritz Barsnick  wrote:
>
> On Wed, Aug 21, 2019 at 18:03:23 -0700, James Zern wrote:
> > > From: elliottk 
> > > Current default is 256kbps, which produces inconsistent
> > > results (too high for low-res, too low for hi-res).
> > > Use CRF instead, which will adapt.
> >
> > lgtm. I'll apply this soon if there aren't any other comments. libvpx
> > could probably use a similar update.
>
> Is this a behavioral change which would justify a bump of libavcodec
> micro?
>

Yes I had that thought and had a bump locally. It is only a setting
change not the introduction of a new option, but I thought increasing
it would be safest.
___
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] libavformat/mxfenc: Allow more bitrates for NTSC IMX50

[Baptiste Coudurier]

Hi Tomas


> On Aug 22, 2019, at 3:47 AM, Tomas Härdin  wrote:
> 
> ons 2019-08-21 klockan 12:47 -0700 skrev Baptiste Coudurier:
>> Hey guys,
>> 
>> 
>>> On Aug 19, 2019, at 9:54 AM, Thomas Mundt  wrote:
>>> 
>>> Am Fr., 16. Aug. 2019 um 23:31 Uhr schrieb Tomas Härdin >>> :
 tor 2019-08-15 klockan 13:55 +0200 skrev Thomas Mundt:
> Am Do., 15. Aug. 2019 um 11:01 Uhr schrieb Tomas Härdin <
 tjop...@acc.umu.se
>> :
>> ons 2019-08-14 klockan 22:18 +0200 skrev Thomas Mundt:
>>> 
>>> New patch attached.
>> 
>> Looks OK. I'll push in a few days if no one else has any comments
>> 
> 
> Thanks. Would you mind porting it to branches 4.1 and 4.2?
 
 I'm not quite sure what the process is for that. I have confirmed that
 the problem exists in 4.1 and 4.2 and that your patch fixes it.
 
 I think we also might want to put a note somewhere in the documentation
 how to make NTSC IMX50 files.
 
>> 
>> Yeah, it’s been an issue for quite some time, s356m mentions:
>> "When used as a signal source for the type D-10 recording format, the
>> bit stream is carried by SDTI-CP, as defined in SMPTE 326M, using
>> recommended operating point bit rates as defined in this annex. Other
>> bit rates may be used. However, users are cautioned that other system
>> design parameters within the studio may not support all bit rates.
>> 
>> Table A.1 indicates recommended operating points to simplify studio
>> operations and to provide users with a tool to be used in designing
>> systems."
>> 
>> Then specifies the exact value of the sequence_header bit_rate_value,
>> 50mit/s being “1E848h”, "To be used when compliant with EBU D84 and
>> D85"
> 
> mpeg12enc.c does this, if I read it correctly. 4840 / 400 =
> 124999.6 which gets rounded up to 125000.

Oh, that’s good actually.

>> I don’t think it is a good idea to produce files with the wrong
>> bit_rate value, and I know for a fact that many file analyzers in use
>> today will simply reject the d-10 essence.
> 
> Would writing 5000 in mxfenc for values in the range
> [4840,5000] make it pass?

If the d-10 mpeg-2 essence has the right bit_rate value, the analyzer works.
Thinking about this, and assuming the seq header bit_rate_value is correctly 
set,
Could we infer the D-10 UL after the first frame according to the mpeg-2 
essence ? 
That would guarantee correctness and eliminate the hackish bitrate check.

Thanks!

— 
Baptiste
___
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] avformat/mov: improve timecode calculation

[Kieran O Leary]

On Thu, 22 Aug 2019, 17:18 Paul B Mahol,  wrote:

> Hi,
>
> patch attached.
>


Maybe it's a Gmail issue but I see no attachment. Also for those of us
unable to understand the code,what's the improvement?

Best,

Kieran

>
>
___
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/3] tools/target_dec_fuzzer: Do not increase max_pixels

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 tools/target_dec_fuzzer.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index d83039417c..5119a7c5da 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -180,12 +180,13 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t 
size) {
 }
 
 
-AVCodecContext* ctx = avcodec_alloc_context3(NULL);
+AVCodecContext* ctx = avcodec_alloc_context3(c);
 AVCodecContext* parser_avctx = avcodec_alloc_context3(NULL);
 if (!ctx || !parser_avctx)
 error("Failed memory allocation");
 
-ctx->max_pixels = maxpixels_per_frame; //To reduce false positive OOM and 
hangs
+if (ctx->max_pixels == 0 || ctx->max_pixels > maxpixels_per_frame)
+ctx->max_pixels = maxpixels_per_frame; //To reduce false positive OOM 
and hangs
 
 if (size > 1024) {
 GetByteContext gbc;
-- 
2.23.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 2/3] avcodec/idcinvideo: Add 320x240 default maximum resolution

[Michael Niedermayer]

Fixes: Timeout (128sec -> 2ms)
Fixes: 
16568/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IDCIN_fuzzer-5675004095627264

See: [FFmpeg-devel] [PATCH 4/4] tools/target_dec_fuzzer: Adjust max_pixels for 
IDCIN

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

diff --git a/libavcodec/idcinvideo.c b/libavcodec/idcinvideo.c
index cff9ad31ac..6b2d8087ae 100644
--- a/libavcodec/idcinvideo.c
+++ b/libavcodec/idcinvideo.c
@@ -243,6 +243,11 @@ static int idcin_decode_frame(AVCodecContext *avctx,
 return buf_size;
 }
 
+static const AVCodecDefault idcin_defaults[] = {
+{ "max_pixels", "320*240" },
+{ NULL },
+};
+
 AVCodec ff_idcin_decoder = {
 .name   = "idcinvideo",
 .long_name  = NULL_IF_CONFIG_SMALL("id Quake II CIN video"),
@@ -252,4 +257,5 @@ AVCodec ff_idcin_decoder = {
 .init   = idcin_decode_init,
 .decode = idcin_decode_frame,
 .capabilities   = AV_CODEC_CAP_DR1,
+.defaults   = idcin_defaults,
 };
-- 
2.23.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 3/3] avcodec/vqavideo: Limit resolution

[Michael Niedermayer]

Fixes: Timeout (288sec -> 1ms)
Fixes: 
16353/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VQA_fuzzer-5633402606190592

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

diff --git a/libavcodec/vqavideo.c b/libavcodec/vqavideo.c
index b9743abda9..f45390cfe5 100644
--- a/libavcodec/vqavideo.c
+++ b/libavcodec/vqavideo.c
@@ -637,6 +637,11 @@ static av_cold int vqa_decode_end(AVCodecContext *avctx)
 return 0;
 }
 
+static const AVCodecDefault vqa_defaults[] = {
+{ "max_pixels", "320*240" },
+{ NULL },
+};
+
 AVCodec ff_vqa_decoder = {
 .name   = "vqavideo",
 .long_name  = NULL_IF_CONFIG_SMALL("Westwood Studios VQA (Vector 
Quantized Animation) video"),
@@ -647,4 +652,5 @@ AVCodec ff_vqa_decoder = {
 .close  = vqa_decode_end,
 .decode = vqa_decode_frame,
 .capabilities   = AV_CODEC_CAP_DR1,
+.defaults   = vqa_defaults,
 };
-- 
2.23.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 v2] avcodec/h264_parse: retry decoding SPS with complete NAL

[Jun Li]

On Tue, Aug 20, 2019 at 5:52 PM Jun Li  wrote:

>
>
> On Mon, Aug 19, 2019 at 7:24 PM Jun Li  wrote:
>
>> Fix #6591
>> The content has no rbsp_stop_one_bit for ending the SPS, that
>> causes the decoding SPS failure, results decoding frame failure as well.
>>
>> The patch is just adding a retry with complete NALU, copied from the
>> retry in decode_nal_unit()
>> ---
>>  libavcodec/h264_parse.c | 11 +--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
>> index ac31f54e07..ea7a958dd9 100644
>> --- a/libavcodec/h264_parse.c
>> +++ b/libavcodec/h264_parse.c
>> @@ -376,8 +376,15 @@ static int decode_extradata_ps(const uint8_t *data,
>> int size, H264ParamSets *ps,
>>  switch (nal->type) {
>>  case H264_NAL_SPS:
>>  ret = ff_h264_decode_seq_parameter_set(&nal->gb, logctx, ps,
>> 0);
>> -if (ret < 0)
>> -goto fail;
>> +if (ret < 0) {
>> +GetBitContext tmp_gb = nal->gb;
>> +av_log(logctx, AV_LOG_DEBUG,
>> +   "SPS decoding failure, trying again with the complete
>> NAL\n");
>> +init_get_bits8(&tmp_gb, nal->raw_data + 1, nal->raw_size
>> - 1);
>> +if ((ret = ff_h264_decode_seq_parameter_set(&tmp_gb,
>> logctx, ps, 0)) < 0 &&
>> +(ret = ff_h264_decode_seq_parameter_set(&tmp_gb,
>> logctx, ps, 1)) < 0)
>> +goto fail;
>> +}
>>  break;
>>  case H264_NAL_PPS:
>>  ret = ff_h264_decode_picture_parameter_set(&nal->gb, logctx,
>> ps,
>> --
>> 2.17.1
>>
>>
> Ping
>

Ping :)
___
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] avcodec/h264_parse: retry decoding SPS with complete NAL

[James Almer]

On 8/19/2019 11:24 PM, Jun Li wrote:
> Fix #6591
> The content has no rbsp_stop_one_bit for ending the SPS, that
> causes the decoding SPS failure, results decoding frame failure as well.
> 
> The patch is just adding a retry with complete NALU, copied from the retry in 
> decode_nal_unit()
> ---
>  libavcodec/h264_parse.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
> index ac31f54e07..ea7a958dd9 100644
> --- a/libavcodec/h264_parse.c
> +++ b/libavcodec/h264_parse.c
> @@ -376,8 +376,15 @@ static int decode_extradata_ps(const uint8_t *data, int 
> size, H264ParamSets *ps,
>  switch (nal->type) {
>  case H264_NAL_SPS:
>  ret = ff_h264_decode_seq_parameter_set(&nal->gb, logctx, ps, 0);
> -if (ret < 0)
> -goto fail;
> +if (ret < 0) {
> +GetBitContext tmp_gb = nal->gb;

nal->gb will already be changed here and will not be pointing to the
start of the SPS.

> +av_log(logctx, AV_LOG_DEBUG,
> +   "SPS decoding failure, trying again with the complete 
> NAL\n");
> +init_get_bits8(&tmp_gb, nal->raw_data + 1, nal->raw_size - 
> 1);

And you're overwriting it here, so the above assignment was pointless.

> +if ((ret = ff_h264_decode_seq_parameter_set(&tmp_gb, logctx, 
> ps, 0)) < 0 &&
> +(ret = ff_h264_decode_seq_parameter_set(&tmp_gb, logctx, 
> ps, 1)) < 0)

Similarly, tmp_gb will be not be pointing to the start of the SPS if the
second ff_h264_decode_seq_parameter_set() call (with truncation enabled)
is ever executed.

> +goto fail;
> +}
>  break;
>  case H264_NAL_PPS:
>  ret = ff_h264_decode_picture_parameter_set(&nal->gb, logctx, ps,
> 

___
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] fate/als: Add test for conformance file with 512 channels.

[Thilo Borgmann]

Hi,

new fate test for many channels in ALS, like requested.

I already uploaded the corresponding file into fate-suite.
If there are no objections, I'll commit this in a day or two.

Thanks,
Thilo
From 5ed096ab3eac956f235e7924d52810b5ec9e8203 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann 
Date: Thu, 22 Aug 2019 21:21:12 +0200
Subject: [PATCH] fate/als: Add test for conformance file with 512 channels.

---
 tests/fate/als.mak  | 4 
 tests/ref/fate/mpeg4-als-conformance-09 | 1 +
 2 files changed, 5 insertions(+)
 create mode 100644 tests/ref/fate/mpeg4-als-conformance-09

diff --git a/tests/fate/als.mak b/tests/fate/als.mak
index ff2badf5ed..c7287dee86 100644
--- a/tests/fate/als.mak
+++ b/tests/fate/als.mak
@@ -7,5 +7,9 @@ endef
 
 $(foreach N,$(ALS_SUITE),$(eval $(call FATE_ALS_SUITE,$(N
 
+FATE_ALS += fate-mpeg4-als-conformance-09
+
+fate-mpeg4-als-conformance-09: CMD = crc -i 
$(TARGET_SAMPLES)/lossless-audio/als_09_512ch2k16b.mp4
+
 FATE_SAMPLES_AVCONV-$(call DEMDEC, MOV, ALS) += $(FATE_ALS)
 fate-als: $(FATE_ALS)
diff --git a/tests/ref/fate/mpeg4-als-conformance-09 
b/tests/ref/fate/mpeg4-als-conformance-09
new file mode 100644
index 00..b26276da91
--- /dev/null
+++ b/tests/ref/fate/mpeg4-als-conformance-09
@@ -0,0 +1 @@
+CRC=0xbf3e7189
-- 
2.17.2 (Apple Git-113)

___
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] tools/target_dec_fuzzer: use refcounted packets

[James Almer]

On 8/21/2019 10:21 AM, James Almer wrote:
> On 8/21/2019 6:15 AM, Tomas Härdin wrote:
>> tis 2019-08-20 klockan 21:05 -0300 skrev James Almer:
>>> Should reduce date copying considerably.
>>>
>>> Signed-off-by: James Almer 
>>> ---
>>> Fixed a stupid mistake when checking the return value for av_new_packet().
>>> Still untested.
>>
>> Works great for me. Should make fuzzing faster overall, better use of
>> computing resources imo
>>
>>> @@ -186,6 +144,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t 
>>> size) {
>>>  error("Failed memory allocation");
>>>  
>>>  ctx->max_pixels = maxpixels_per_frame; //To reduce false positive OOM 
>>> and hangs
>>> +ctx->refcounted_frames = 1;
>>
>> Could maybe have a comment that this is also to reduce false positives,
>> or that we want to focus on the new API rather than the old one
> 
> Sure.
> 
>>
>>> @@ -240,7 +199,10 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t 
>>> size) {
>>>  if (data + sizeof(fuzz_tag) > end)
>>>  data = end;
>>>  
>>> -FDBPrepare(&buffer, &parsepkt, last, data - last);
>>> +res = av_new_packet(&parsepkt, data - last);
>>> +if (res < 0)
>>> +error("Failed memory allocation");
>>> +memcpy(parsepkt.data, last, data - last);
>>
>> Is there some way to avoid this copy?
> 
> I could create packets that point to a specific offset in the input
> fuzzed buffer, but that will mean they will lack the padding required by
> the API, not to mention the complete lack of control over said buffer's
> lifetime. This could either generate no issues, or make things go really
> wrong.
> 
> So to make proper use of the AVPacket API, i need to allocate their
> reference counted buffers and populate them. After this patch the
> behaviour of this fuzzer is essentially the same as if it was a
> libavformat demuxer, creating packets out of an input file and
> propagating them to libavcodec.
> If the idea was to imitate an average library user's behavior, this
> pretty much is it.
> 
>>
>> /Tomas

Will push with the requested comment added 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 2/3] avutil/imgutils: remove dead assignment

[Marton Balint]

On Sun, 18 Aug 2019, Michael Niedermayer wrote:


On Sat, Aug 17, 2019 at 09:41:04PM +0200, Marton Balint wrote:

Signed-off-by: Marton Balint 
---
 libavutil/imgutils.c | 1 -
 1 file changed, 1 deletion(-)


LGTM


Applied, thanks.

Marton
___
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] avformat/mxfdec: do not ignore bad size errors

[Marton Balint]

On Thu, 22 Aug 2019, Tomas Härdin wrote:


ons 2019-08-21 klockan 21:54 +0200 skrev Marton Balint:


On Sun, 18 Aug 2019, Tomas Härdin wrote:

> lör 2019-08-17 klockan 21:41 +0200 skrev Marton Balint:
> > The return value was unintentionally lost after
> > 00a2652df3bf25a27d174cc67ed508b5317cb115.
> > 
> > Signed-off-by: Marton Balint 

> > ---
> >  libavformat/mxfdec.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c

> > index bb72fb9841..397f820b3f 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -3508,8 +3508,8 @@ static int mxf_read_packet(AVFormatContext *s, 
AVPacket *pkt)
> >  } else {
> >  if ((size = next_ofs - pos) <= 0) {
> >  av_log(s, AV_LOG_ERROR, "bad size: %"PRId64"\n", 
size);
> > -ret = AVERROR_INVALIDDATA;
> > -goto skip;
> > +mxf->current_klv_data = (KLVPacket){{0}};
> > +return AVERROR_INVALIDDATA;
> 
> Should maybe ask for a sample. Else looks OK


I don't think this can happen with any of the valid files, so the text 
saying that ffmpeg is missing a feature probably won't be true. It is a 
lot more likely that the user has a broken file if this error is shown.


So I'd rather keep it as is.


Right, the skip had me confused. This is fine of course


Thanks, applied.

Regards,
Marton
___
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/3] avcodec: remove some dead assignments

[Marton Balint]

On Sat, 17 Aug 2019, Marton Balint wrote:


Signed-off-by: Marton Balint 
---
libavcodec/bsf.c| 1 -
libavcodec/decode.c | 1 -
2 files changed, 2 deletions(-)


Applied this as well, as it was trivial enough.

Regards,
Marton



diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c
index 5081307603..71915dea85 100644
--- a/libavcodec/bsf.c
+++ b/libavcodec/bsf.c
@@ -306,7 +306,6 @@ static int bsf_list_filter(AVBSFContext *bsf, AVPacket *out)
ret = av_bsf_receive_packet(lst->bsfs[lst->idx-1], out);
if (ret == AVERROR(EAGAIN)) {
/* no more packets from idx-1, try with previous */
-ret = 0;
lst->idx--;
continue;
} else if (ret == AVERROR_EOF) {
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 6c31166ec2..cf9676e2ac 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -300,7 +300,6 @@ static int bsfs_poll(AVCodecContext *avctx, AVPacket *pkt)
ret = av_bsf_receive_packet(s->bsfs[idx], pkt);
if (ret == AVERROR(EAGAIN)) {
/* no packets available, try the next filter up the chain */
-ret = 0;
idx--;
continue;
} else if (ret < 0 && ret != AVERROR_EOF) {
--
2.16.4

___
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]lavf/r3d: Check avio_read() return value

[Reimar Döffinger]

On Thu, Aug 22, 2019 at 12:06:03PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes usage of uninitialized data reading broken r3d files.
>
> Please review, Carl Eugen

> From efce9940b890b9cf5a9e7400b05be10f6906fbb1 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Thu, 22 Aug 2019 12:02:36 +0200
> Subject: [PATCH] lavf/r3d: Check avio_read() return value.
>
> Fixes use of uninitialized data reading broken files.
> Reported-by: Anatoly Trosinenko 
> ---
>  libavformat/r3d.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/r3d.c b/libavformat/r3d.c
> index 224bcf780d..919c3c4960 100644
> --- a/libavformat/r3d.c
> +++ b/libavformat/r3d.c
> @@ -98,7 +98,8 @@ static int r3d_read_red1(AVFormatContext *s)
>  r3d->audio_channels = avio_r8(s->pb); // audio channels
>  av_log(s, AV_LOG_TRACE, "audio channels %d\n", tmp);
>
> -avio_read(s->pb, filename, 257);
> +if (avio_read(s->pb, filename, 257) < 0)
> +return AVERROR_INVALIDDATA;
>  filename[sizeof(filename)-1] = 0;

As far as I can tell most code would either return the avio_read return
value or AVERROR(EIO).
Also I think short reads are also an issue and would
cause the same issue?
Maybe it would be sensible to also change the 257 to
sizeof(filename)-1 while at it?
Overall something along the lines (with possibly less stupid names) of

namebytes = sizeof(filename)-1;
ret = avio_read(s->pb, filename, namebytes);
if (ret < namebytes)
return ret < 0 ? ret : AVERROR(EIO);
filename[namebytes] = 0;

The hard failure return here seems appropriate as this logic reads the
very start of the file, so if a read error happens here I
don't think there's any way to recover anything.
___
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/h264_parse: retry decoding SPS with complete NAL

[Jun Li]

Fix #6591
The content has no rbsp_stop_one_bit for ending the SPS, that
causes the decoding SPS failure, results decoding frame failure as well.

The patch is just adding a retry with complete NALU, copied from the retry in 
decode_nal_unit()
---
 libavcodec/h264_parse.c | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
index ac31f54e07..baf8246cdc 100644
--- a/libavcodec/h264_parse.c
+++ b/libavcodec/h264_parse.c
@@ -374,11 +374,23 @@ static int decode_extradata_ps(const uint8_t *data, int 
size, H264ParamSets *ps,
 for (i = 0; i < pkt.nb_nals; i++) {
 H2645NAL *nal = &pkt.nals[i];
 switch (nal->type) {
-case H264_NAL_SPS:
-ret = ff_h264_decode_seq_parameter_set(&nal->gb, logctx, ps, 0);
-if (ret < 0)
-goto fail;
+case H264_NAL_SPS: {
+GetBitContext tmp_gb = nal->gb;
+ret = ff_h264_decode_seq_parameter_set(&tmp_gb, logctx, ps, 0);
+if (ret < 0) {
+av_log(logctx, AV_LOG_DEBUG,
+  "SPS decoding failure, trying again with the complete 
NAL\n");
+init_get_bits8(&tmp_gb, nal->raw_data + 1, nal->raw_size - 1);
+ret = ff_h264_decode_seq_parameter_set(&tmp_gb, logctx, ps, 0);
+if (ret >= 0)
+break;
+
+ret = ff_h264_decode_seq_parameter_set(&nal->gb, logctx, ps, 
1);
+if (ret < 0)
+goto fail;
+}
 break;
+}
 case H264_NAL_PPS:
 ret = ff_h264_decode_picture_parameter_set(&nal->gb, logctx, ps,
nal->size_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".

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/idcinvideo: Add 320x240 default maximum resolution

[Tomas Härdin]

tor 2019-08-22 klockan 20:09 +0200 skrev Michael Niedermayer:
> Fixes: Timeout (128sec -> 2ms)
> Fixes: 
> 16568/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IDCIN_fuzzer-5675004095627264
> 
> See: [FFmpeg-devel] [PATCH 4/4] tools/target_dec_fuzzer: Adjust max_pixels 
> for IDCIN
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/idcinvideo.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/libavcodec/idcinvideo.c b/libavcodec/idcinvideo.c
> index cff9ad31ac..6b2d8087ae 100644
> --- a/libavcodec/idcinvideo.c
> +++ b/libavcodec/idcinvideo.c
> @@ -243,6 +243,11 @@ static int idcin_decode_frame(AVCodecContext *avctx,
>  return buf_size;
>  }
>  
> +static const AVCodecDefault idcin_defaults[] = {
> +{ "max_pixels", "320*240" },
> +{ NULL },
> +};

Should be OK since we don't know of any samples larger than this. If we
want to be *really* strict we could limit it to 320x240 only

/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 2/3] avcodec/idcinvideo: Add 320x240 default maximum resolution

[Tomas Härdin]

tor 2019-08-22 klockan 23:00 +0200 skrev Tomas Härdin:
> tor 2019-08-22 klockan 20:09 +0200 skrev Michael Niedermayer:
> > Fixes: Timeout (128sec -> 2ms)
> > Fixes: 
> > 16568/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IDCIN_fuzzer-5675004095627264
> > 
> > See: [FFmpeg-devel] [PATCH 4/4] tools/target_dec_fuzzer: Adjust max_pixels 
> > for IDCIN
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/idcinvideo.c | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/libavcodec/idcinvideo.c b/libavcodec/idcinvideo.c
> > index cff9ad31ac..6b2d8087ae 100644
> > --- a/libavcodec/idcinvideo.c
> > +++ b/libavcodec/idcinvideo.c
> > @@ -243,6 +243,11 @@ static int idcin_decode_frame(AVCodecContext *avctx,
> >  return buf_size;
> >  }
> >  
> > +static const AVCodecDefault idcin_defaults[] = {
> > +{ "max_pixels", "320*240" },
> > +{ NULL },
> > +};
> 
> Should be OK since we don't know of any samples larger than this. If we
> want to be *really* strict we could limit it to 320x240 only

I forgot to add: we should have a corresponding limit in
libavformat/idcin.c, preferably using the same option if possible

/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] avcodec/h264_parse: retry decoding SPS with complete NAL

[Jun Li]

On Thu, Aug 22, 2019 at 12:00 PM James Almer  wrote:

> On 8/19/2019 11:24 PM, Jun Li wrote:
> > Fix #6591
> > The content has no rbsp_stop_one_bit for ending the SPS, that
> > causes the decoding SPS failure, results decoding frame failure as well.
> >
> > The patch is just adding a retry with complete NALU, copied from the
> retry in decode_nal_unit()
> > ---
> >  libavcodec/h264_parse.c | 11 +--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
> > index ac31f54e07..ea7a958dd9 100644
> > --- a/libavcodec/h264_parse.c
> > +++ b/libavcodec/h264_parse.c
> > @@ -376,8 +376,15 @@ static int decode_extradata_ps(const uint8_t *data,
> int size, H264ParamSets *ps,
> >  switch (nal->type) {
> >  case H264_NAL_SPS:
> >  ret = ff_h264_decode_seq_parameter_set(&nal->gb, logctx,
> ps, 0);
> > -if (ret < 0)
> > -goto fail;
> > +if (ret < 0) {
> > +GetBitContext tmp_gb = nal->gb;
>
> nal->gb will already be changed here and will not be pointing to the
> start of the SPS.
>
> > +av_log(logctx, AV_LOG_DEBUG,
> > +   "SPS decoding failure, trying again with the
> complete NAL\n");
> > +init_get_bits8(&tmp_gb, nal->raw_data + 1,
> nal->raw_size - 1);
>
> And you're overwriting it here, so the above assignment was pointless.
>
> > +if ((ret = ff_h264_decode_seq_parameter_set(&tmp_gb,
> logctx, ps, 0)) < 0 &&
> > +(ret = ff_h264_decode_seq_parameter_set(&tmp_gb,
> logctx, ps, 1)) < 0)
>
> Similarly, tmp_gb will be not be pointing to the start of the SPS if the
> second ff_h264_decode_seq_parameter_set() call (with truncation enabled)
> is ever executed.
>
> > +goto fail;
> > +}
> >  break;
> >  case H264_NAL_PPS:
> >  ret = ff_h264_decode_picture_parameter_set(&nal->gb,
> logctx, ps,
> >
>
> ___
> 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 a lot James for pointing it out. Sorry about those obvious bugs.
I updated the version accordingly https://patchwork.ffmpeg.org/patch/14660/

-Jun
___
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] libavformat/mxfenc: Allow more bitrates for NTSC IMX50

[Tomas Härdin]

tor 2019-08-22 klockan 09:17 -0700 skrev Baptiste Coudurier:
> Hi Tomas
> 
> 
> > On Aug 22, 2019, at 3:47 AM, Tomas Härdin  wrote:
> > 
> > ons 2019-08-21 klockan 12:47 -0700 skrev Baptiste Coudurier:
> > > Hey guys,
> > > 
> > > Yeah, it’s been an issue for quite some time, s356m mentions:
> > > "When used as a signal source for the type D-10 recording format, the
> > > bit stream is carried by SDTI-CP, as defined in SMPTE 326M, using
> > > recommended operating point bit rates as defined in this annex. Other
> > > bit rates may be used. However, users are cautioned that other system
> > > design parameters within the studio may not support all bit rates.
> > > 
> > > Table A.1 indicates recommended operating points to simplify studio
> > > operations and to provide users with a tool to be used in designing
> > > systems."
> > > 
> > > Then specifies the exact value of the sequence_header bit_rate_value,
> > > 50mit/s being “1E848h”, "To be used when compliant with EBU D84 and
> > > D85"
> > 
> > mpeg12enc.c does this, if I read it correctly. 4840 / 400 =
> > 124999.6 which gets rounded up to 125000.
> 
> Oh, that’s good actually.
> 
> > > I don’t think it is a good idea to produce files with the wrong
> > > bit_rate value, and I know for a fact that many file analyzers in use
> > > today will simply reject the d-10 essence.
> > 
> > Would writing 5000 in mxfenc for values in the range
> > [4840,5000] make it pass?
> 
> If the d-10 mpeg-2 essence has the right bit_rate value, the analyzer works.
> Thinking about this, and assuming the seq header bit_rate_value is correctly 
> set,
> Could we infer the D-10 UL after the first frame according to the mpeg-2 
> essence ? 
> That would guarantee correctness and eliminate the hackish bitrate check.

We could write a tentative D-10 UL and change it if any packet is off,
or maybe error out with a suggestion to pester the relevant people for
a proper CBR encoding option :]

If the output file isn't seekable (quite probable when dealing with
tape formats) then writing the header will have to be delayed until the
first packet has been inspected

We're definitely going to need something in the manual for this, since
D-10 is used in lots of places

/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".

[FFmpeg-devel] [PATCH 1/8] avcodec/v4l2_m2m: log planar mode used by driver

[Aman Gupta]

From: Aman Gupta 

Signed-off-by: Aman Gupta 
---
 libavcodec/v4l2_m2m.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
index 427e165f58..7d65747df2 100644
--- a/libavcodec/v4l2_m2m.c
+++ b/libavcodec/v4l2_m2m.c
@@ -76,7 +76,9 @@ static int v4l2_prepare_contexts(V4L2m2mContext* s)
 if (ret < 0)
 return ret;
 
-av_log(s->avctx, AV_LOG_INFO, "driver '%s' on card '%s'\n", cap.driver, 
cap.card);
+av_log(s->avctx, AV_LOG_INFO, "driver '%s' on card '%s' in %s mode\n", 
cap.driver, cap.card,
+   v4l2_mplane_video(&cap) ? "mplane" :
+   v4l2_splane_video(&cap) ? "splane" : 
"unknown");
 
 if (v4l2_mplane_video(&cap)) {
 s->capture.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
-- 
2.20.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/8] avcodec/v4l2_m2m: remove trailing whitespace in output identifier

[Aman Gupta]

From: Aman Gupta 

Signed-off-by: Aman Gupta 
---
 libavcodec/v4l2_m2m.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
index 334ba0a038..746ae96a21 100644
--- a/libavcodec/v4l2_m2m.c
+++ b/libavcodec/v4l2_m2m.c
@@ -67,7 +67,7 @@ static int v4l2_prepare_contexts(V4L2m2mContext* s, int probe)
 
 s->capture.done = s->output.done = 0;
 s->capture.name = "capture";
-s->output.name = "output ";
+s->output.name = "output";
 atomic_init(&s->refcount, 0);
 sem_init(&s->refsync, 0, 0);
 
-- 
2.20.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/8] avcodec/v4l2_m2m: log requested pixel formats

[Aman Gupta]

From: Aman Gupta 

Signed-off-by: Aman Gupta 
---
 libavcodec/v4l2_m2m.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
index be13f68707..334ba0a038 100644
--- a/libavcodec/v4l2_m2m.c
+++ b/libavcodec/v4l2_m2m.c
@@ -135,6 +135,7 @@ static int v4l2_configure_contexts(V4L2m2mContext* s)
 {
 void *log_ctx = s->avctx;
 int ret;
+struct v4l2_format ofmt, cfmt;
 
 s->fd = open(s->devname, O_RDWR | O_NONBLOCK, 0);
 if (s->fd < 0)
@@ -144,6 +145,16 @@ static int v4l2_configure_contexts(V4L2m2mContext* s)
 if (ret < 0)
 goto error;
 
+ofmt = s->output.format;
+cfmt = s->capture.format;
+av_log(log_ctx, AV_LOG_INFO, "requesting formats: output=%s capture=%s\n",
+ 
av_fourcc2str(V4L2_TYPE_IS_MULTIPLANAR(ofmt.type) ?
+   ofmt.fmt.pix_mp.pixelformat :
+   ofmt.fmt.pix.pixelformat),
+ 
av_fourcc2str(V4L2_TYPE_IS_MULTIPLANAR(cfmt.type) ?
+   cfmt.fmt.pix_mp.pixelformat :
+   cfmt.fmt.pix.pixelformat));
+
 ret = ff_v4l2_context_set_format(&s->output);
 if (ret) {
 av_log(log_ctx, AV_LOG_ERROR, "can't set v4l2 output format\n");
-- 
2.20.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 2/8] avcodec/v4l2_m2m: disable info logging during device probe

[Aman Gupta]

From: Aman Gupta 

Signed-off-by: Aman Gupta 
---
 libavcodec/v4l2_m2m.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
index 7d65747df2..be13f68707 100644
--- a/libavcodec/v4l2_m2m.c
+++ b/libavcodec/v4l2_m2m.c
@@ -60,7 +60,7 @@ static inline int v4l2_mplane_video(struct v4l2_capability 
*cap)
 return 0;
 }
 
-static int v4l2_prepare_contexts(V4L2m2mContext* s)
+static int v4l2_prepare_contexts(V4L2m2mContext* s, int probe)
 {
 struct v4l2_capability cap;
 int ret;
@@ -76,9 +76,10 @@ static int v4l2_prepare_contexts(V4L2m2mContext* s)
 if (ret < 0)
 return ret;
 
-av_log(s->avctx, AV_LOG_INFO, "driver '%s' on card '%s' in %s mode\n", 
cap.driver, cap.card,
-   v4l2_mplane_video(&cap) ? "mplane" :
-   v4l2_splane_video(&cap) ? "splane" : 
"unknown");
+av_log(s->avctx, probe ? AV_LOG_DEBUG : AV_LOG_INFO,
+ "driver '%s' on card '%s' in %s mode\n", cap.driver, 
cap.card,
+ v4l2_mplane_video(&cap) ? "mplane" :
+ v4l2_splane_video(&cap) ? "splane" : "unknown");
 
 if (v4l2_mplane_video(&cap)) {
 s->capture.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
@@ -103,7 +104,7 @@ static int v4l2_probe_driver(V4L2m2mContext* s)
 if (s->fd < 0)
 return AVERROR(errno);
 
-ret = v4l2_prepare_contexts(s);
+ret = v4l2_prepare_contexts(s, 1);
 if (ret < 0)
 goto done;
 
@@ -139,7 +140,7 @@ static int v4l2_configure_contexts(V4L2m2mContext* s)
 if (s->fd < 0)
 return AVERROR(errno);
 
-ret = v4l2_prepare_contexts(s);
+ret = v4l2_prepare_contexts(s, 0);
 if (ret < 0)
 goto error;
 
-- 
2.20.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/8] avcodec/v4l2_context: log VIDIOC_REQBUFS failures

[Aman Gupta]

From: Aman Gupta 

Signed-off-by: Aman Gupta 
---
 libavcodec/v4l2_context.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
index efcb0426e4..4958c634bf 100644
--- a/libavcodec/v4l2_context.c
+++ b/libavcodec/v4l2_context.c
@@ -678,8 +678,10 @@ int ff_v4l2_context_init(V4L2Context* ctx)
 req.memory = V4L2_MEMORY_MMAP;
 req.type = ctx->type;
 ret = ioctl(s->fd, VIDIOC_REQBUFS, &req);
-if (ret < 0)
+if (ret < 0) {
+av_log(logger(ctx), AV_LOG_ERROR, "%s VIDIOC_REQBUFS failed: %s\n", 
ctx->name, strerror(errno));
 return AVERROR(errno);
+}
 
 ctx->num_buffers = req.count;
 ctx->buffers = av_mallocz(ctx->num_buffers * sizeof(V4L2Buffer));
-- 
2.20.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 8/8] avcodec/v4l2_buffers: Add handling for NV21 and YUV420P

[Aman Gupta]

From: Dave Stevenson 

The single planar support was for NV21 only.
Add NV21 and YUV420P support.

Signed-off-by: Aman Gupta 
---
 libavcodec/v4l2_buffers.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index 3f9b8b5e31..efbd84b0b3 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -348,11 +348,20 @@ int ff_v4l2_buffer_buf_to_avframe(AVFrame *frame, 
V4L2Buffer *avbuf)
 /* 1.1 fixup special cases */
 switch (avbuf->context->av_pix_fmt) {
 case AV_PIX_FMT_NV12:
+case AV_PIX_FMT_NV21:
 if (avbuf->num_planes > 1)
 break;
 frame->linesize[1] = avbuf->plane_info[0].bytesperline;
 frame->data[1] = frame->buf[0]->data + 
avbuf->plane_info[0].bytesperline * avbuf->context->format.fmt.pix_mp.height;
 break;
+case AV_PIX_FMT_YUV420P:
+if (avbuf->num_planes > 1)
+break;
+frame->linesize[1] = avbuf->plane_info[0].bytesperline >> 1;
+frame->linesize[2] = avbuf->plane_info[0].bytesperline >> 1;
+frame->data[1] = frame->buf[0]->data + 
avbuf->plane_info[0].bytesperline * avbuf->context->format.fmt.pix_mp.height;
+frame->data[2] = frame->data[1] + ((avbuf->plane_info[0].bytesperline 
* avbuf->context->format.fmt.pix_mp.height) >> 2);
+break;
 default:
 break;
 }
-- 
2.20.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/8] avcodec/v4l2_buffers: teach ff_v4l2_buffer_avframe_to_buf about contiguous planar formats

[Aman Gupta]

From: Aman Gupta 

Signed-off-by: Aman Gupta 
---
 libavcodec/v4l2_buffers.c | 43 +++
 1 file changed, 35 insertions(+), 8 deletions(-)

diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index 4f889509f9..3f9b8b5e31 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -29,6 +29,7 @@
 #include 
 #include "libavcodec/avcodec.h"
 #include "libavcodec/internal.h"
+#include "libavutil/pixdesc.h"
 #include "v4l2_context.h"
 #include "v4l2_buffers.h"
 #include "v4l2_m2m.h"
@@ -257,17 +258,17 @@ static int v4l2_buf_to_bufref(V4L2Buffer *in, int plane, 
AVBufferRef **buf)
 return 0;
 }
 
-static int v4l2_bufref_to_buf(V4L2Buffer *out, int plane, const uint8_t* data, 
int size, AVBufferRef* bref)
+static int v4l2_bufref_to_buf(V4L2Buffer *out, int plane, const uint8_t* data, 
int size, int offset, AVBufferRef* bref)
 {
 unsigned int bytesused, length;
 
 if (plane >= out->num_planes)
 return AVERROR(EINVAL);
 
-bytesused = FFMIN(size, out->plane_info[plane].length);
 length = out->plane_info[plane].length;
+bytesused = FFMIN(size+offset, length);
 
-memcpy(out->plane_info[plane].mm_addr, data, FFMIN(size, 
out->plane_info[plane].length));
+memcpy((uint8_t*)out->plane_info[plane].mm_addr+offset, data, FFMIN(size, 
length-offset));
 
 if (V4L2_TYPE_IS_MULTIPLANAR(out->buf.type)) {
 out->planes[plane].bytesused = bytesused;
@@ -289,15 +290,41 @@ static int v4l2_bufref_to_buf(V4L2Buffer *out, int plane, 
const uint8_t* data, i
 int ff_v4l2_buffer_avframe_to_buf(const AVFrame *frame, V4L2Buffer *out)
 {
 int i, ret;
+struct v4l2_format fmt = out->context->format;
+int pixel_format = V4L2_TYPE_IS_MULTIPLANAR(fmt.type) ? 
fmt.fmt.pix_mp.pixelformat
+  : 
fmt.fmt.pix.pixelformat;
+int is_planar_format = ((pixel_format >> 8) & 0xFF) == 'M'; // YU12 vs 
YM12, NV12 vs NM12, etc
 
-for(i = 0; i < out->num_planes; i++) {
-ret = v4l2_bufref_to_buf(out, i, frame->buf[i]->data, 
frame->buf[i]->size, frame->buf[i]);
+v4l2_set_pts(out, frame->pts);
+
+if (!is_planar_format) {
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
+int planes_nb = 0;
+int offset = 0;
+
+for (i = 0; i < desc->nb_components; i++)
+planes_nb = FFMAX(planes_nb, desc->comp[i].plane + 1);
+
+for (i = 0; i < planes_nb; i++) {
+int size, h = frame->height;
+if (i == 1 || i == 2) {
+h = AV_CEIL_RSHIFT(frame->height, desc->log2_chroma_h);
+}
+size = frame->linesize[i] * FFALIGN(h, 16);
+ret = v4l2_bufref_to_buf(out, 0, frame->buf[i]->data, size, 
offset, frame->buf[i]);
+if (ret)
+return ret;
+offset += size;
+}
+return 0;
+}
+
+for (i = 0; i < out->num_planes; i++) {
+ret = v4l2_bufref_to_buf(out, i, frame->buf[i]->data, 
frame->buf[i]->size, 0, frame->buf[i]);
 if (ret)
 return ret;
 }
 
-v4l2_set_pts(out, frame->pts);
-
 return 0;
 }
 
@@ -381,7 +408,7 @@ int ff_v4l2_buffer_avpkt_to_buf(const AVPacket *pkt, 
V4L2Buffer *out)
 {
 int ret;
 
-ret = v4l2_bufref_to_buf(out, 0, pkt->data, pkt->size, pkt->buf);
+ret = v4l2_bufref_to_buf(out, 0, pkt->data, pkt->size, 0, pkt->buf);
 if (ret)
 return ret;
 
-- 
2.20.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 2/4] avcodec/omx: add support for -force_key_frames

[Aman Gupta]

From: Aman Gupta 

Signed-off-by: Aman Gupta 
---
 libavcodec/omx.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/libavcodec/omx.c b/libavcodec/omx.c
index a1e5a46a54..8c722b573c 100644
--- a/libavcodec/omx.c
+++ b/libavcodec/omx.c
@@ -802,6 +802,26 @@ static int omx_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt,
 // Convert the timestamps to microseconds; some encoders can ignore
 // the framerate and do VFR bit allocation based on timestamps.
 buffer->nTimeStamp = to_omx_ticks(av_rescale_q(frame->pts, 
avctx->time_base, AV_TIME_BASE_Q));
+if (frame->pict_type == AV_PICTURE_TYPE_I) {
+#if CONFIG_OMX_RPI
+OMX_CONFIG_BOOLEANTYPE config = {0, };
+INIT_STRUCT(config);
+config.bEnabled = OMX_TRUE;
+err = OMX_SetConfig(s->handle, 
OMX_IndexConfigBrcmVideoRequestIFrame, &config);
+if (err != OMX_ErrorNone) {
+av_log(avctx, AV_LOG_ERROR, "OMX_SetConfig(RequestIFrame) 
failed: %x\n", err);
+}
+#else
+OMX_CONFIG_INTRAREFRESHVOPTYPE config = {0, };
+INIT_STRUCT(config);
+config.nPortIndex = s->out_port;
+config.IntraRefreshVOP = OMX_TRUE;
+err = OMX_SetConfig(s->handle, 
OMX_IndexConfigVideoIntraVOPRefresh, &config);
+if (err != OMX_ErrorNone) {
+av_log(avctx, AV_LOG_ERROR, "OMX_SetConfig(IntraVOPRefresh) 
failed: %x\n", err);
+}
+#endif
+}
 err = OMX_EmptyThisBuffer(s->handle, buffer);
 if (err != OMX_ErrorNone) {
 append_buffer(&s->input_mutex, &s->input_cond, 
&s->num_free_in_buffers, s->free_in_buffers, buffer);
-- 
2.20.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/4] MAINTAINERS: add myself to OMX

[Aman Gupta]

From: Aman Gupta 

Signed-off-by: Aman Gupta 
Signed-off-by: Martin Storsjö 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 84dcb411f1..7f60ef0021 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -213,6 +213,7 @@ Codecs:
   msvideo1.cMike Melanson
   nuv.c Reimar Doeffinger
   nvdec*, nvenc*Timo Rothenpieler
+  omx.c Martin Storsjo, Aman Gupta
   opus* Rostislav Pehlivanov
   paf.* Paul B Mahol
   pcx.c Ivo van Poorten
-- 
2.20.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/4] avcodec/omx: Fix handling of fragmented buffers

[Aman Gupta]

From: Dave Stevenson 

See https://trac.ffmpeg.org/ticket/7687

If an encoded frame is returned split over two or more
IL buffers due to the size, then there is a race between
whether get_buffer will fail, return NULL, and a truncated
frame is passed on, or IL will return the remaining part
of the encoded frame.
If get_buffer returns NULL, part of the frame is left behind
in the codec, and will be collected on the next call. That
then leaves a frame stuck in the codec. Repeat enough times
and the codec FIFO is full, and the pipeline stalls.

A performance improvement in the Raspberry Pi firmware means
that the timing has changed, and now frequently drops into the
case where get_buffer returns NULL.

Add code such that should a buffer be received without
OMX_BUFFERFLAG_ENDOFFRAME that get_buffer is called with wait
set, so we wait for the remainder of the frame.
This code has been made conditional on the Pi build in case
other IL implementations don't handle ENDOFFRAME correctly.

Signed-off-by: Dave Stevenson 
Signed-off-by: Aman Gupta 
---
 libavcodec/omx.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavcodec/omx.c b/libavcodec/omx.c
index 1a9a0715f8..837f5df666 100644
--- a/libavcodec/omx.c
+++ b/libavcodec/omx.c
@@ -735,6 +735,7 @@ static int omx_encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 int ret = 0;
 OMX_BUFFERHEADERTYPE* buffer;
 OMX_ERRORTYPE err;
+int had_partial = 0;
 
 if (frame) {
 uint8_t *dst[4];
@@ -846,7 +847,7 @@ static int omx_encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 // packet, or get EOS.
 buffer = get_buffer(&s->output_mutex, &s->output_cond,
 &s->num_done_out_buffers, s->done_out_buffers,
-!frame);
+!frame || had_partial);
 if (!buffer)
 break;
 
@@ -881,6 +882,9 @@ static int omx_encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 s->output_buf = NULL;
 s->output_buf_size = 0;
 }
+#if CONFIG_OMX_RPI
+had_partial = 1;
+#endif
 } else {
 // End of frame, and the caller provided a preallocated frame
 if ((ret = ff_alloc_packet2(avctx, pkt, s->output_buf_size + 
buffer->nFilledLen, 0)) < 0) {
-- 
2.20.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/4] avcodec/omx: ensure zerocopy mode can be disabled on rpi builds

[Aman Gupta]

From: Aman Gupta 

fixes https://trac.ffmpeg.org/ticket/6586

Signed-off-by: Aman Gupta 
---
 libavcodec/omx.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/libavcodec/omx.c b/libavcodec/omx.c
index 8c722b573c..1a9a0715f8 100644
--- a/libavcodec/omx.c
+++ b/libavcodec/omx.c
@@ -644,10 +644,6 @@ static av_cold int omx_encode_init(AVCodecContext *avctx)
 OMX_BUFFERHEADERTYPE *buffer;
 OMX_ERRORTYPE err;
 
-#if CONFIG_OMX_RPI
-s->input_zerocopy = 1;
-#endif
-
 s->omx_context = omx_init(avctx, s->libname, s->libprefix);
 if (!s->omx_context)
 return AVERROR_ENCODER_NOT_FOUND;
@@ -933,7 +929,7 @@ static av_cold int omx_encode_end(AVCodecContext *avctx)
 static const AVOption options[] = {
 { "omx_libname", "OpenMAX library name", OFFSET(libname), 
AV_OPT_TYPE_STRING, { 0 }, 0, 0, VDE },
 { "omx_libprefix", "OpenMAX library prefix", OFFSET(libprefix), 
AV_OPT_TYPE_STRING, { 0 }, 0, 0, VDE },
-{ "zerocopy", "Try to avoid copying input frames if possible", 
OFFSET(input_zerocopy), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE },
+{ "zerocopy", "Try to avoid copying input frames if possible", 
OFFSET(input_zerocopy), AV_OPT_TYPE_INT, { .i64 = CONFIG_OMX_RPI }, 0, 1, VE },
 { "profile",  "Set the encoding profile", OFFSET(profile), 
AV_OPT_TYPE_INT,   { .i64 = FF_PROFILE_UNKNOWN },   FF_PROFILE_UNKNOWN, 
FF_PROFILE_H264_HIGH, VE, "profile" },
 { "baseline", "", 0,   
AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_BASELINE }, 0, 0, VE, "profile" },
 { "main", "", 0,   
AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_MAIN }, 0, 0, VE, "profile" },
-- 
2.20.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/8] avcodec/v4l2_buffers: fix minor typos and whitespace

[Aman Gupta]

From: Aman Gupta 

Signed-off-by: Aman Gupta 
---
 libavcodec/v4l2_buffers.c | 4 ++--
 libavcodec/v4l2_buffers.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index aef911f3bb..4f889509f9 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -282,11 +282,11 @@ static int v4l2_bufref_to_buf(V4L2Buffer *out, int plane, 
const uint8_t* data, i
 
 /**
  *
- *  V4L2uffer interface
+ *  V4L2Buffer interface
  *
  
**/
 
-int ff_v4l2_buffer_avframe_to_buf(const AVFrame *frame, V4L2Buffer* out)
+int ff_v4l2_buffer_avframe_to_buf(const AVFrame *frame, V4L2Buffer *out)
 {
 int i, ret;
 
diff --git a/libavcodec/v4l2_buffers.h b/libavcodec/v4l2_buffers.h
index 7a57caf949..8dbc7fc104 100644
--- a/libavcodec/v4l2_buffers.h
+++ b/libavcodec/v4l2_buffers.h
@@ -106,7 +106,7 @@ int ff_v4l2_buffer_avpkt_to_buf(const AVPacket *pkt, 
V4L2Buffer *out);
  *
  * @returns 0 in case of success, a negative AVERROR code otherwise
  */
-int ff_v4l2_buffer_avframe_to_buf(const AVFrame *frame, V4L2Buffer* out);
+int ff_v4l2_buffer_avframe_to_buf(const AVFrame *frame, V4L2Buffer *out);
 
 /**
  * Initializes a V4L2Buffer
-- 
2.20.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] DVB EPG decoder

[Marton Balint]

On Thu, 22 Aug 2019, Anthony Delannoy wrote:


Hi


fails to build on MIPS


Seems to be because of these two structs within EPGTable and EPGSubTable:
+struct {
+int nb_descriptors;
+void **descriptors;
+};


I made modifications to avoid issues you encountered and put fate
modifications in the right commit(s).


Afaict, some patches change files that were added in earlier patches. This may
not be ideal.


I committed changements to files (dvb.{h,c}) I added earlier because I
need descriptors files (dvbdescriptors.{h,c})
before those changes and  descriptors files need the first version of
the dvb file (basic get functions).


Why are the big api changes necessary at all?


I made those big changements to ease the implementation of all others
DVB tables (i'd like to add support for NIT,
AIT, TDT,... after EPG) by using the same helper functions
(avpriv_dvb_get{8,16,32}()) and especially the same
DVB descriptors code because each descriptor is supported by multiple
table in general.


I think we should only merge the part of this patchset which makes the EIT 
available as a data stream. Parsing the whole EIT or dumping the data as 
ASCII is not libavcodec's or libavutil's job. Also there is no such 
concept in libavcodec as a data decoder, if something happens to 
work with avcodec_send_packet/avcodec_receive_frame that is mostly luck I 
believe.


I am also not sure if we should add the EIT PID to all programs, that 
would mess up the direct relation between a PMT and an AVProgram, and we 
probably don't want that. So I'd rather see the EIT data stream as a 
standalone PID separate from the programs.


Regards,
Marton

___
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/4] avformat/mpegtsenc: add support for setting PCR interval for VBR streams

[Marton Balint]

On Fri, 16 Aug 2019, Andreas Håkon wrote:


Hi Marton,

Very good work with your series of patches on the mpegtsenc!

‐‐‐ Original Message ‐‐‐
On Thursday, 15 de August de 2019 1:51, Marton Balint  wrote:


Also document the algorithm for the default PCR interval.



[...]



+   if (ts->mux_rate > 1 || ts->pcr_period_ms >= 0) {
+  int pcr_period_ms = ts->pcr_period_ms == -1 ? PCR_RETRANS_TIME : 
ts->pcr_period_ms;
+  ts_st->pcr_period = av_rescale(pcr_period_ms, PCR_TIME_BASE, 1000);
} else {
/* For VBR we select the highest multiple of frame duration which is less 
than 100 ms. */


A simple aesthetic comment:
Please, change this to...
/* By default, for VBR we select the highest multiple of frame duration which 
is less than 100 ms. */


Ok, changed locally.

Will apply patchset soon.

Regards,
Marton
___
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/aacdec: Add FF_CODEC_CAP_INIT_CLEANUP

[Michael Niedermayer]

Fixes: memleaks
Fixes: 
16289/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-5200695692623872

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

diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index c606ad40a9..98b6e58be3 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -559,7 +559,7 @@ AVCodec ff_aac_decoder = {
 AV_SAMPLE_FMT_FLTP, AV_SAMPLE_FMT_NONE
 },
 .capabilities= AV_CODEC_CAP_CHANNEL_CONF | AV_CODEC_CAP_DR1,
-.caps_internal   = FF_CODEC_CAP_INIT_THREADSAFE,
+.caps_internal   = FF_CODEC_CAP_INIT_THREADSAFE | 
FF_CODEC_CAP_INIT_CLEANUP,
 .channel_layouts = aac_channel_layout,
 .flush = flush,
 .priv_class  = &aac_decoder_class,
@@ -584,7 +584,7 @@ AVCodec ff_aac_latm_decoder = {
 AV_SAMPLE_FMT_FLTP, AV_SAMPLE_FMT_NONE
 },
 .capabilities= AV_CODEC_CAP_CHANNEL_CONF | AV_CODEC_CAP_DR1,
-.caps_internal   = FF_CODEC_CAP_INIT_THREADSAFE,
+.caps_internal   = FF_CODEC_CAP_INIT_THREADSAFE | 
FF_CODEC_CAP_INIT_CLEANUP,
 .channel_layouts = aac_channel_layout,
 .flush = flush,
 .profiles= NULL_IF_CONFIG_SMALL(ff_aac_profiles),
-- 
2.23.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 2/2] avcodec/mpeg4videodec: Fix integer overflow in mpeg4_decode_studio_block()

[Michael Niedermayer]

Fixes: signed integer overflow: 24023040 * 112 cannot be represented in type 
'int'
Fixes: 
16570/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-5173275211071488

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

diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index b6f2ae7b7b..25f528d59e 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -1826,6 +1826,7 @@ static int mpeg4_decode_studio_block(MpegEncContext *s, 
int32_t block[64], int n
 uint32_t flc;
 const int min = -1 *  (1 << (s->avctx->bits_per_raw_sample + 6));
 const int max =  ((1 << (s->avctx->bits_per_raw_sample + 6)) - 1);
+int shift =  3 - s->dct_precision;
 
 mismatch = 1;
 
@@ -1921,7 +1922,7 @@ static int mpeg4_decode_studio_block(MpegEncContext *s, 
int32_t block[64], int n
 else
 block[j] = flc;
 }
-block[j] = ((8 * 2 * block[j] * quant_matrix[j] * s->qscale) >> 
s->dct_precision) / 32;
+block[j] = ((block[j] * quant_matrix[j] * s->qscale) * (1 << shift)) / 
16;
 block[j] = av_clip(block[j], min, max);
 mismatch ^= block[j];
 }
-- 
2.23.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 v3 3/3] lavfi: add deshake_opencl filter

[Mark Thompson]

On 08/08/2019 14:24, Jarek Samic wrote:
> ---
> 
> This filter is the subject of my GSoC project.
> 
> This is a video stabilization / deshake filter (name undetermined, feel free 
> to discuss) that uses feature
> point matching and RANSAC to determine a camera path, smooths the camera path 
> with a gaussian filter, and
> then applies the new path to the video.
> 
> There are a number of debug features that can be turned on (viewing point 
> matches, viewing transform
> details, viewing average kernel execution times). See the bottom of the file.
> 
> Since the last version of the patch, I have:
> 
> * Greatly improved the performance of the match_descriptors kernel
> * Also improved the performance of various other kernels / buffer reads 
> with the same change
> * Tested the filter on the Intel OpenCL drivers
> * For some reason OpenCL compilation warnings get displayed to the user 
> on this platform; if anyone knows how to fix that, please let me know
> 
> Performance of the harris_response kernel still leaves something to be 
> desired, but I am out of ideas currently to improve it. I am fairly certain
> it is simply caused by poor memory access patterns, but I haven't been able 
> to find any functioning OpenCL profiling tools so I don't have any way
> of confirming that. In any case, even in its current state, the filter is 
> faster than the existing deshake filter on both my NVIDIA GPU and my
> Intel iGPU with improved output quality.
> 
> At this point the filter is ready to be merged (as the end of GSoC is drawing 
> near). If anyone has a few minutes to spare, please take the time
> to give this filter a try and report any bugs / issues (there is only time 
> left to fix major, blocking bugs at this point, such as crashes and
> malformed output, but other issues are always great for future work).
> 
>  configure   |1 +
>  doc/filters.texi|   69 +
>  libavfilter/Makefile|2 +
>  libavfilter/allfilters.c|1 +
>  libavfilter/opencl/deshake.cl   |  647 +
>  libavfilter/opencl_source.h |1 +
>  libavfilter/vf_deshake_opencl.c | 2202 +++
>  7 files changed, 2923 insertions(+)
>  create mode 100644 libavfilter/opencl/deshake.cl
>  create mode 100644 libavfilter/vf_deshake_opencl.c

Everything LGTM, and I did a load more testing (Intel and Mali).

I fixed two unwanted doubles, added version bump, and applied.

Thanks,

- Mark
___
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 V5] avcodec/libvpxenc: add ROI-based encoding support for VP8/VP9 support

[Guo, Yejun]

example command line to verify it:
./ffmpeg -i input.stream -vf addroi=0:0:iw/3:ih/3:-0.8 -c:v libvpx -b:v 2M 
tmp.webm

Signed-off-by: Guo, Yejun 
---
 libavcodec/libvpxenc.c | 194 +
 1 file changed, 194 insertions(+)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index feb52ea..0139314 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -116,6 +116,9 @@ typedef struct VPxEncoderContext {
 int tune_content;
 int corpus_complexity;
 int tpl_model;
+// If the driver does not support ROI then warn the first time we
+// encounter a frame with ROI side data.
+int roi_warned;
 } VPxContext;
 
 /** String mappings for enum vp8e_enc_control_id */
@@ -1057,6 +1060,189 @@ static int queue_frames(AVCodecContext *avctx, AVPacket 
*pkt_out)
 return size;
 }
 
+static int set_roi_map(AVCodecContext *avctx, const AVFrameSideData *sd, int 
frame_width, int frame_height,
+   vpx_roi_map_t *roi_map, int block_size, int segment_cnt)
+{
+/* range of vpx_roi_map_t.delta_q[i] is [-63, 63] */
+#define MAX_DELTA_Q 63
+
+const AVRegionOfInterest *roi = NULL;
+int nb_rois;
+uint32_t self_size;
+int segment_id;
+
+/* record the mapping from delta_q to "segment id + 1" in 
segment_mapping[].
+ * the range of delta_q is [-MAX_DELTA_Q, MAX_DELTA_Q],
+ * and its corresponding array index is [0, 2 * MAX_DELTA_Q],
+ * and so the length of the mapping array is 2 * MAX_DELTA_Q + 1.
+ * "segment id + 1", so we can say there's no mapping if the value of 
array element is zero.
+ */
+int segment_mapping[2 * MAX_DELTA_Q + 1] = { 0 };
+
+memset(roi_map, 0, sizeof(*roi_map));
+
+/* segment id 0 in roi_map is reserved for the areas not covered by 
AVRegionOfInterest.
+ * segment id 0 in roi_map is also for the areas with 
AVRegionOfInterest.qoffset near 0.
+ * (delta_q of segment id 0 is 0).
+ */
+segment_mapping[MAX_DELTA_Q] = 1;
+segment_id = 1;
+
+roi = (const AVRegionOfInterest*)sd->data;
+self_size = roi->self_size;
+if (!self_size || sd->size % self_size != 0) {
+av_log(avctx, AV_LOG_ERROR, "Invalid AVRegionOfInterest.self_size.\n");
+return AVERROR(EINVAL);
+}
+nb_rois = sd->size / self_size;
+
+/* This list must be iterated from zero because regions are
+ * defined in order of decreasing importance. So discard less
+ * important areas if they exceed the segment count.
+ */
+for (int i = 0; i < nb_rois; i++) {
+int delta_q;
+int mapping_index;
+
+roi = (const AVRegionOfInterest*)(sd->data + self_size * i);
+if (roi->qoffset.den == 0) {
+av_log(avctx, AV_LOG_ERROR, "AVRegionOfInterest.qoffset.den must 
not be zero.\n");
+return AVERROR(EINVAL);
+}
+
+delta_q = (int)(roi->qoffset.num * 1.0f / roi->qoffset.den * 
MAX_DELTA_Q);
+delta_q = av_clip(delta_q, -MAX_DELTA_Q, MAX_DELTA_Q);
+
+mapping_index = delta_q + MAX_DELTA_Q;
+if (!segment_mapping[mapping_index]) {
+if (segment_id == segment_cnt) {
+av_log(avctx, AV_LOG_WARNING,
+   "ROI only supports %d segments (and segment 0 is 
reserved for non-ROIs), skipping the left ones.\n",
+   segment_cnt);
+break;
+}
+
+segment_mapping[mapping_index] = segment_id + 1;
+roi_map->delta_q[segment_id] = delta_q;
+segment_id++;
+}
+}
+
+
+roi_map->rows = (frame_height + block_size - 1) / block_size;
+roi_map->cols = (frame_width  + block_size - 1) / block_size;
+roi_map->roi_map = av_mallocz_array(roi_map->rows * roi_map->cols, 
sizeof(*roi_map->roi_map));
+if (!roi_map->roi_map) {
+av_log(avctx, AV_LOG_ERROR, "roi_map alloc failed.\n");
+return AVERROR(ENOMEM);
+}
+
+/* This list must be iterated in reverse, so for the case that
+ * two regions are overlapping, the more important area takes effect.
+ */
+for (int i = nb_rois - 1; i >= 0; i--) {
+int delta_q;
+int mapping_value;
+int starty, endy, startx, endx;
+
+roi = (const AVRegionOfInterest*)(sd->data + self_size * i);
+
+starty = av_clip(roi->top / block_size, 0, roi_map->rows);
+endy   = av_clip((roi->bottom + block_size - 1) / block_size, 0, 
roi_map->rows);
+startx = av_clip(roi->left / block_size, 0, roi_map->cols);
+endx   = av_clip((roi->right + block_size - 1) / block_size, 0, 
roi_map->cols);
+
+delta_q = (int)(roi->qoffset.num * 1.0f / roi->qoffset.den * 
MAX_DELTA_Q);
+delta_q = av_clip(delta_q, -MAX_DELTA_Q, MAX_DELTA_Q);
+
+mapping_value = segment_mapping[delta_q + MAX_DELTA_Q];
+if (mapping_value) {
+for (int y = starty; y < endy; y++)
+for (int x = startx; x < endx; x++)
+  

Re: [FFmpeg-devel] [PATCH 8/8] avcodec/v4l2_buffers: Add handling for NV21 and YUV420P

[Moritz Barsnick]

On Thu, Aug 22, 2019 at 14:47:41 -0700, Aman Gupta wrote:
> The single planar support was for NV21 only.
^
Nit: NV12


> Add NV21 and YUV420P support.
>
> Signed-off-by: Aman Gupta 

Cheers,
Moritz
___
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/2] avcodec/aacdec: Add FF_CODEC_CAP_INIT_CLEANUP

[Paul B Mahol]

lgtm

On Fri, Aug 23, 2019 at 12:54 AM Michael Niedermayer 
wrote:

> Fixes: memleaks
> Fixes:
> 16289/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-5200695692623872
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  libavcodec/aacdec.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
> index c606ad40a9..98b6e58be3 100644
> --- a/libavcodec/aacdec.c
> +++ b/libavcodec/aacdec.c
> @@ -559,7 +559,7 @@ AVCodec ff_aac_decoder = {
>  AV_SAMPLE_FMT_FLTP, AV_SAMPLE_FMT_NONE
>  },
>  .capabilities= AV_CODEC_CAP_CHANNEL_CONF | AV_CODEC_CAP_DR1,
> -.caps_internal   = FF_CODEC_CAP_INIT_THREADSAFE,
> +.caps_internal   = FF_CODEC_CAP_INIT_THREADSAFE |
> FF_CODEC_CAP_INIT_CLEANUP,
>  .channel_layouts = aac_channel_layout,
>  .flush = flush,
>  .priv_class  = &aac_decoder_class,
> @@ -584,7 +584,7 @@ AVCodec ff_aac_latm_decoder = {
>  AV_SAMPLE_FMT_FLTP, AV_SAMPLE_FMT_NONE
>  },
>  .capabilities= AV_CODEC_CAP_CHANNEL_CONF | AV_CODEC_CAP_DR1,
> -.caps_internal   = FF_CODEC_CAP_INIT_THREADSAFE,
> +.caps_internal   = FF_CODEC_CAP_INIT_THREADSAFE |
> FF_CODEC_CAP_INIT_CLEANUP,
>  .channel_layouts = aac_channel_layout,
>  .flush = flush,
>  .profiles= NULL_IF_CONFIG_SMALL(ff_aac_profiles),
> --
> 2.23.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 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".