Re: [FFmpeg-devel] [PATCH v2 3/5] tests/fate/filter-video: add fate pixfmts test for lut1d and lut3d

[Limin Wang]

On Fri, Nov 01, 2019 at 01:56:06PM +0100, Michael Niedermayer wrote:
> On Wed, Oct 30, 2019 at 09:20:54PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang 
> > 
> > Signed-off-by: Limin Wang 
> > ---
> >  tests/fate/filter-video.mak |  6 ++
> >  tests/ref/fate/filter-pixfmts-lut1d | 24 
> >  tests/ref/fate/filter-pixfmts-lut3d | 24 
> >  3 files changed, 54 insertions(+)
> >  create mode 100644 tests/ref/fate/filter-pixfmts-lut1d
> >  create mode 100644 tests/ref/fate/filter-pixfmts-lut3d
> 
> fails
> make: *** [fate-filter-pixfmts-lut3d] Error 1
> make: *** [fate-filter-pixfmts-lut1d] Error 1
> on x86-32

It seems that the float operation can't get consistent result, I have
tested with interp=nearest, however there're 2 pixfmt is different still.
So please ignore the patch.

> 
> --- src/tests/ref/fate/filter-pixfmts-lut3d   2019-11-01 13:51:40.807408107 
> +0100
> +++ tests/data/fate/filter-pixfmts-lut3d  2019-11-01 13:53:45.595410736 
> +0100
> @@ -1,24 +1,24 @@
> -0bgr5087cdbb3da0d014de02fda75618f278
> -0rgb9ccde40a857919017558353aaecfa5de
> -abgr0505ae7e852cf32ce9e2a0fc06462f48
> -argb77e7baba2d8b4389267a2ecb67662c15
> -bgr0cded4da42263da5bf0153e8bad09a0de
> -bgr24   fef9ee2e37a1d5c1787ffb3ed5dcc3bf
> -bgr48le 39fe9f41285f3325833d28ce1611d586
> -bgra3433cdbdf07abbd8af4698a3b7a1a189
> -bgra64le8f33508d6c0362df83296513ebee3a2d
> -gbrap   4227379340c3d822dd6c59263b170972
> -gbrap10le   90721f63d6e3d5d7a6bafcefdca5151d
> -gbrap12le   e1eee70df0c2578937dcd7a90e22f4b7
> -gbrap16le   2fd82ec30573ed65fa23c4d1c150d596
> -gbrpe615c8ea180a0358261953812df0aa3d
> -gbrp10led61faad75dbd7cbb0271b47fa33d714e
> -gbrp12le90c4ec04807bbfbe194eddcc8d7bcb2a
> -gbrp14lec424158744f9e16dbfcf00c66ba651f9
> -gbrp16le8ccb63f9407cae03b2e061ed1249127d
> -gbrp9le 4a267ed7c6535c8829e83e35c51df6bf
> -rgb0545f5c4e4a7b7f3e61373149db0b932a
> -rgb24   aec4f0a1954823de17024383d6401b75
> -rgb48le 1d1e5a1849ed3c326961184bb2f45400
> -rgbaecd54389d03bded1e8209f5bdea5
> -rgba64leb26c35d221b026304db46014260ed1db
> +0bgr7b83991d73694572a29f9655ad4a1c84
> +0rgbd559f4a889a119ecede1821b561fdded
> +abgrc09eeb64d67b2feee042fec6c82d19f2
> +argba18a4a3a1125cfe8cba94e9472a9d255
> +bgr0f7db08eaee52afa722aabb67adaaf4ea
> +bgr24   11db3c5fe5f705ba4994ec9a5ada3cff
> +bgr48le 569c425858f68a809ba30e4599a48fe4
> +bgraf6c5a568b5c41238a7a64cf62330f337
> +bgra64lea8e90780f59afb31cd11ee35d5e476c2
> +gbrap   ae8ce6a9a43b1a29c77e768bb3219ced
> +gbrap10le   d91ec08222f53ad2d13eb55526c4ebbe
> +gbrap12le   d9902c437e1a634c7debb9b26a78af05
> +gbrap16le   45eb3cd875157c057c1c9931fe7cc0e2
> +gbrp92873a0fa33a0e71b57654ad883aa902
> +gbrp10led7008353207928923330a484c255a31d
> +gbrp12le6ccaad2d08e11f06f41d1f925fc91e7f
> +gbrp14leb1d20a9df7193d524e20e0c057307176
> +gbrp16lee23c0cdec81cea1ddc9be45ac610ca64
> +gbrp9le 06173cd4a5569f303eecbe1d19f9e9d3
> +rgb005b576915d8fd30b1de3d3a7d59aba06
> +rgb24   7ec80634e169ea94adc4efde25592e31
> +rgb48le f4671cad79547953dc1ca8a0661ad131
> +rgbae98ce9f6b490413fe325bcb30b9c0eac
> +rgba64leeda79f1558a53d14e4e236c8c4aaef4d
> Test filter-pixfmts-lut3d failed. Look at 
> tests/data/fate/filter-pixfmts-lut3d.err for details.
> 
> 
> --- src/tests/ref/fate/filter-pixfmts-lut1d   2019-11-01 13:51:40.807408107 
> +0100
> +++ tests/data/fate/filter-pixfmts-lut1d  2019-11-01 13:53:45.587410736 
> +0100
> @@ -1,24 +1,24 @@
> -0bgr89655364415a9893ccdf403b32ff588c
> -0rgbe86013d5c46c02ed6a555d669877e9d7
> -abgrfe237c269cf66969b99a028dd6a34214
> -argbd9b49a3a68087eb99ba208edcbf087a4
> -bgr09f8de7f2afbb07b4fa56e3386f06a1d4
> -bgr24   ec35fb477c56d6ecf5f1651797e1a456
> -bgr48le e713ca125c7a4f6d91d7a054155af81f
> -bgracd9424cf54a3a6ed65d7eaf9d412c3df
> -bgra64le7d11a05feef943d7abdecc39ad1e941a
> -gbrap   bc87d42fc26eb0e54323c2b1e4de4cde
> -gbrap10le   732c3682336d505be11beb9624aa7866
> -gbrap12le   83699133174282c5d6ac81bf7878462b
> -gbrap16le   da278e22602bccc4ecef7194b462a6ff
> -gbrp5a031c0eaf96442715a7cc71b4a97f07
> -gbrp10le56fe2aa5e1bf130aa32a24fc99ce528f
> -gbrp12le11cabeca5ae713c0fc1e08aaeddfa17d
> -gbrp14lee71c1fd4277ce9873c0893740cb2cd83
> -gb

Re: [FFmpeg-devel] [PATCH] lavf/mov: initial support for reading HEIF images

[Carl Eugen Hoyos]

Am Do., 31. Okt. 2019 um 18:30 Uhr schrieb Dale Curtis
:
>
> On Thu, Oct 31, 2019 at 1:32 AM Swaraj Hota  wrote:
>
> > Yes I will send the patch soon for review. Still a few things left to do.
> >
> > Swaraj
> >
>
> Great! Let me know if there's anything I can help with.

Testing would be helpful.

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 1/2] avcodec/v4l2_buffers: Fix infinite loop

[Aman Gupta]

On Fri, Nov 1, 2019 at 6:39 AM Andriy Gelman 
wrote:

> On Sun, 27. Oct 00:19, Andriy Gelman wrote:
> > From: Andriy Gelman 
> >
> > This part of the code counts the number of planes returned by the v4l2
> > device for each queried capture/output buffer.
> > When testing the GPU h264 encoder on Nvidia's Jetson Nano, this caused an
> > infinite loop because avbuf->buf.length included some empty buffers (i.e.
> > where avbuf->buf.m.planes[i].length = 0), meaning that the counter was
> > never incremented and break was never reached.
> > This is fixed in the commit by using a well defined iteration range.
> > ---
> >  libavcodec/v4l2_buffers.c | 8 +++-
> >  1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
> > index e301dcd6bd..dc1b9eaf24 100644
> > --- a/libavcodec/v4l2_buffers.c
> > +++ b/libavcodec/v4l2_buffers.c
> > @@ -511,11 +511,9 @@ int ff_v4l2_buffer_initialize(V4L2Buffer* avbuf,
> int index)
> >
> >  if (V4L2_TYPE_IS_MULTIPLANAR(ctx->type)) {
> >  avbuf->num_planes = 0;
> > -for (;;) {
> > -/* in MP, the V4L2 API states that buf.length means
> num_planes */
> > -if (avbuf->num_planes >= avbuf->buf.length)
> > -break;
> > -if (avbuf->buf.m.planes[avbuf->num_planes].length)
> > +/* in MP, the V4L2 API states that buf.length means num_planes
> */
> > +for (i = 0; i < avbuf->buf.length; i++) {
> > +if (avbuf->buf.m.planes[i].length)
> >  avbuf->num_planes++;
> >  }
> >  } else
> > --
> > 2.23.0
> >
>
> ping
>

Applied, thank you!


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

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

[FFmpeg-devel] [PATCH 1/5] configure: select jpegtables for rtp muxer

[Lou Logan]

Signed-off-by: Lou Logan 

---

Fixes:
./configure --disable-everything --enable-muxer=rtp && make
/usr/bin/ld: libavformat/libavformat.a(rtpenc_jpeg.o): in function 
`ff_rtp_send_jpeg':
libavformat/rtpenc_jpeg.c:116: undefined reference to 
`avpriv_mjpeg_bits_dc_chrominance'
/usr/bin/ld: libavformat/rtpenc_jpeg.c:117: undefined reference to 
`avpriv_mjpeg_val_dc'
/usr/bin/ld: libavformat/rtpenc_jpeg.c:140: undefined reference to 
`avpriv_mjpeg_bits_ac_chrominance'
/usr/bin/ld: libavformat/rtpenc_jpeg.c:141: undefined reference to 
`avpriv_mjpeg_val_ac_chrominance'
/usr/bin/ld: libavformat/rtpenc_jpeg.c:104: undefined reference to 
`avpriv_mjpeg_bits_dc_luminance'
/usr/bin/ld: libavformat/rtpenc_jpeg.c:105: undefined reference to 
`avpriv_mjpeg_val_dc'
/usr/bin/ld: libavformat/rtpenc_jpeg.c:128: undefined reference to 
`avpriv_mjpeg_bits_ac_luminance'
/usr/bin/ld: libavformat/rtpenc_jpeg.c:129: undefined reference to 
`avpriv_mjpeg_val_ac_luminance'

---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 875b77fdf1..8d260caa4e 100755
--- a/configure
+++ b/configure
@@ -3284,7 +3284,7 @@ ogv_muxer_select="ogg_muxer"
 opus_muxer_select="ogg_muxer"
 psp_muxer_select="mov_muxer"
 rtp_demuxer_select="sdp_demuxer"
-rtp_muxer_select="golomb"
+rtp_muxer_select="golomb jpegtables"
 rtpdec_select="asf_demuxer jpegtables mov_demuxer mpegts_demuxer rm_demuxer 
rtp_protocol srtp"
 rtsp_demuxer_select="http_protocol rtpdec"
 rtsp_muxer_select="rtp_muxer http_protocol rtp_protocol rtpenc_chain"
-- 
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/5] avformat/Makefile: add missing pcm dependency to hcom demuxer

[Lou Logan]

Signed-off-by: Lou Logan 

---

Fixes:
./configure --disable-everything --enable-demuxer=hcom && make
/usr/bin/ld: libavformat/libavformat.a(hcom.o):(.data.rel+0x58): undefined 
reference to `ff_pcm_read_packet'

---
 libavformat/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 615156c120..8ea85ee828 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -219,7 +219,7 @@ OBJS-$(CONFIG_H263_MUXER)+= rawenc.o
 OBJS-$(CONFIG_H264_DEMUXER)  += h264dec.o rawdec.o
 OBJS-$(CONFIG_H264_MUXER)+= rawenc.o
 OBJS-$(CONFIG_HASH_MUXER)+= hashenc.o
-OBJS-$(CONFIG_HCOM_DEMUXER)  += hcom.o
+OBJS-$(CONFIG_HCOM_DEMUXER)  += hcom.o pcm.o
 OBJS-$(CONFIG_HDS_MUXER) += hdsenc.o
 OBJS-$(CONFIG_HEVC_DEMUXER)  += hevcdec.o rawdec.o
 OBJS-$(CONFIG_HEVC_MUXER)+= rawenc.o
-- 
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 4/5] avformat/Makefile: add missing pcm dependency to nsp demuxer

[Lou Logan]

Signed-off-by: Lou Logan 

---

Fixes:
./configure --disable-everything --enable-demuxer=nsp && make
/usr/bin/ld: libavformat/libavformat.a(nspdec.o):(.data.rel+0x58): undefined 
reference to `ff_pcm_read_packet'
/usr/bin/ld: libavformat/libavformat.a(nspdec.o):(.data.rel+0x68): undefined 
reference to `ff_pcm_read_seek'

---
 libavformat/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 8ea85ee828..396061ef46 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -344,7 +344,7 @@ OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o 
audiointerleave.o avc
 OBJS-$(CONFIG_MXG_DEMUXER)   += mxg.o
 OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o
 OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o
-OBJS-$(CONFIG_NSP_DEMUXER)   += nspdec.o
+OBJS-$(CONFIG_NSP_DEMUXER)   += nspdec.o pcm.o
 OBJS-$(CONFIG_NSV_DEMUXER)   += nsvdec.o
 OBJS-$(CONFIG_NULL_MUXER)+= nullenc.o
 OBJS-$(CONFIG_NUT_DEMUXER)   += nutdec.o nut.o isom.o
-- 
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 5/5] avformat/Makefile: add missing pcm dependency to sdx demuxer

[Lou Logan]

Signed-off-by: Lou Logan 

---

Fixes:
./configure --disable-everything --enable-demuxer=sdx && make
/usr/bin/ld: libavformat/libavformat.a(sdxdec.o):(.data.rel+0x58): undefined 
reference to `ff_pcm_read_packet'
/usr/bin/ld: libavformat/libavformat.a(sdxdec.o):(.data.rel+0x68): undefined 
reference to `ff_pcm_read_seek'

---
 libavformat/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 396061ef46..8251f8f657 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -470,7 +470,7 @@ OBJS-$(CONFIG_SCC_MUXER) += sccenc.o 
subtitles.o
 OBJS-$(CONFIG_SDP_DEMUXER)   += rtsp.o
 OBJS-$(CONFIG_SDR2_DEMUXER)  += sdr2.o
 OBJS-$(CONFIG_SDS_DEMUXER)   += sdsdec.o
-OBJS-$(CONFIG_SDX_DEMUXER)   += sdxdec.o
+OBJS-$(CONFIG_SDX_DEMUXER)   += sdxdec.o pcm.o
 OBJS-$(CONFIG_SEGAFILM_DEMUXER)  += segafilm.o
 OBJS-$(CONFIG_SEGAFILM_MUXER)+= segafilmenc.o
 OBJS-$(CONFIG_SEGMENT_MUXER) += segment.o
-- 
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/5] configure: select riffdec for act demuxer

[Lou Logan]

Signed-off-by: Lou Logan 

---

Fixes:
./configure --disable-everything --enable-demuxer=act && make
/usr/bin/ld: libavformat/libavformat.a(act.o): in function `read_header':
libavformat/act.c:78: undefined reference to `ff_get_wav_header'

---
 configure | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index 8d260caa4e..6ccc6fbbe9 100755
--- a/configure
+++ b/configure
@@ -3230,6 +3230,7 @@ videotoolbox_encoder_deps="videotoolbox 
VTCompressionSessionPrepareToEncodeFrame
 
 # demuxers / muxers
 ac3_demuxer_select="ac3_parser"
+act_demuxer_select="riffdec"
 aiff_muxer_select="iso_media"
 asf_demuxer_select="riffdec"
 asf_o_demuxer_select="riffdec"
-- 
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] avfilter: add eval video filter

[Paul B Mahol]

On 11/1/19, Michael Niedermayer  wrote:
> On Fri, Nov 01, 2019 at 04:50:38PM +0100, Paul B Mahol wrote:
>> On 11/1/19, Michael Niedermayer  wrote:
>> > On Fri, Nov 01, 2019 at 01:09:24PM +0100, Paul B Mahol wrote:
>> >> Signed-off-by: Paul B Mahol 
>> >> ---
>> >>  doc/filters.texi |  78 +
>> >>  libavfilter/Makefile |   1 +
>> >>  libavfilter/allfilters.c |   1 +
>> >>  libavfilter/vf_eval.c| 687
>> >> +++
>> >>  4 files changed, 767 insertions(+)
>> >>  create mode 100644 libavfilter/vf_eval.c
>> >
>> > This looks like it duplicates code from vf_geq.c
>> > also this should be integrated with or in vf_geq.c
>> >
>> > IIUC this was written because geq is GPL, but i had already agreed to
>> > relicense the code in it i wrote to LGPL, so iam not sure why you wrote
>> > this.
>> >
>> > Who disagreed to relicnce their contribution to geq to avoid this extra
>> > work you did ?
>> > Or did noone disagree ? then i do not understand why you wrote a
>> > seperate
>> > filter
>>
>> Do I need to contact all on blame list of vf_geq? or also mplayer devs
>> that touched geq in mplayer?
>
> all who touched it MINUS anyone who made a change that is totally not
> in the current version (there are several developers in mplayer who
> made auch changes)
> also in case of mplayer you may need to look at the commit messages
> some developers did apply patches from others.
>
> I took a quick look and these are the people i saw
> carl, ubitux, ivan, ods15, Alexis Ballier, derek, Marc-Antoine Arnaud,
> Nicolas George, Stefano and Paul
> reimar, zuxy and diego

I do not think I can contact ods15.

>
> For the last 3 i could not find a change that persists in the current
> code
>
> Either way please check the list of names, i may have made a mistake!
>
> Thanks
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Opposition brings concord. Out of discord comes the fairest harmony.
> -- Heraclitus
>
___
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/mov: initial support for reading HEIF images

[Dale Curtis]

On Fri, Nov 1, 2019 at 4:14 AM Swaraj Hota  wrote:

> Sure. Thanks for the samples!
> I have not currently tested the patch with avif format, was only focused on
> heif. But as the only difference is the decoder (?), this support could be
> easily added. I'll try to add it but as I have been working on this for a
> long time now, someone else can surely add it if I couldn't, after my patch
> is merged that is.
>

Should just be adding 'a,'v','0','1' and doing the same thing you do for
hvc1 here:
https://github.com/Swaraj1998/FFmpeg/commit/c20779fea73ed8fa49ce04b99178328e231c9952#diff-44e5be1f9a8e0df35dd607e74773ce6eR6812

Either way sounds good though!

- dale
___
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] add phqm filter and img_hash

[Paul B Mahol]

On 11/1/19, Christopher Kennedy  wrote:
> On Wed, Oct 30, 2019 at 10:57 AM Paul B Mahol  wrote:
>>
>> On 10/30/19, Christopher Kennedy  wrote:
>> > On Wed, Oct 30, 2019 at 10:07 AM Paul B Mahol  wrote:
>> >>
>> >> On 10/30/19, Christopher Kennedy  wrote:
>> >> > On Sat, Oct 26, 2019 at 9:15 AM Paul B Mahol 
>> >> > wrote:
>> >> >>
>> >> >> On 10/26/19, Christopher Kennedy  wrote:
>> >> >> > On Sat, Oct 26, 2019 at 8:22 AM Paul B Mahol 
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> On 10/26/19, Christopher Kennedy  wrote:
>> >> >> >> > This is a reference/encode comparison filter with two files
>> >> >> >> > input
>> >> >> >> > like
>> >> >> >> > the psnr or vmaf filter.
>> >> >> >> > So it is completely different and uses the C++ OpenCV API
>> >> >> >> > since
>> >> >> >> > this
>> >> >> >> > img_hash library is not in the C API.
>> >> >> >> > It's unique to what the OCV filter does, and has more research
>> >> >> >> > implications from my talk at Demuxed 2019.
>> >> >> >>
>> >> >> >> I do not see how that is relevant.
>> >> >> >>
>> >> >> >> There should be generic opencv filter which could do this above
>> >> >> >> in
>> >> >> >> generic way, and not by adding yet another filter that uses only
>> >> >> >> some
>> >> >> >> part of opencv.
>> >> >> >
>> >> >> > Is it really possible to do framesync() operations like dual
>> >> >> > input
>> >> >> > filters
>> >> >> > like psnr/vmaf and also handle input/output rendering of the
>> >> >> > frames
>> >> >> > too?
>> >> >> > This sounds odd to me but I would love to understand how this is
>> >> >> > possible.
>> >> >>
>> >> >> framesync is nothing special, its just used a lot, there are video
>> >> >> filters that do not use it and still operate on multiple inputs.
>> >> >>
>> >> >> >
>> >> >> > The C OpenCV API is not recommended so this does the OpenCV part
>> >> >> > in C++ which allows it to be fully utilized and supported. So
>> >> >> > that
>> >> >> > seems
>> >> >> > better to me than using the API OpenCV won't really support and
>> >> >> > doesn't
>> >> >> > allow usage of img_hash (it is NOT in the C API of OpenCV,
>> >> >> > impossible
>> >> >> > to
>> >> >> > use).
>> >> >> >
>> >> >> > The OpenCV C++ img_hash library is the fastest implementation and
>> >> >> > does
>> >> >> > work best in OpenCV. So implementing this in C directly isn't a
>> >> >> > task
>> >> >> > I
>> >> >> > believe
>> >> >> > is good to do.
>> >> >>
>> >> >> I do not care how generic opencv filter is done, it can be C++ just
>> >> >> fine.
>> >> >>
>> >> >> >
>> >> >> > So should the current OpenCV stuff be merged into this filter, is
>> >> >> > that
>> >> >> > possible?
>> >> >>
>> >> >> Current opencv stuff in libavfilter is pretty dead and not
>> >> >> maintained
>> >> >> at
>> >> >> all.
>> >> >> So I'm not really fond of adding yet another opencv filter that not
>> >> >> gonna be maintained.
>> >> >
>> >> > Well I would maintain it, but maybe I should instead run a Fork of
>> >> > FFmpeg
>> >> > with
>> >> > C++ and OpenCV properly done.
>> >> >
>> >> > Yes the current OCV stuff is dead and not supported by OpenCV or
>> >> > maintained
>> >> > it sounds like.
>> >> >
>> >> > So if we can't put C++ into FFmpeg (yet we already have with
>> >> > decklink
>> >> > filters,
>> >> > so that is unfair to say).
>> >> >
>> >> > And we can't switch to use OpenCV C++ yet the C API is dead and not
>> >> > supported.
>> >>
>> >> Who said that?
>> >> C++ module filter in libavfilter dealing with latest OpenCV and well
>> >> maintained is always welcome.
>> >
>> >
>> > So I should be moving the functionality of the current ocv filter into
>> > a
>> > C++ file for filters to use like phqm, the current ocv transforms?
>> >
>> > Is this a good plan, separate the C++ from the vf_ filter as I have
>> > done
>> > with img_hash.cpp (yet make it a more generic set of OpenCV C++
>> > helper functions to plug into C vf_filters which can be separated by
>> > function yet unified in code used from the C++ base code)?
>>
>> IMHO filter file can be cpp file without issues. And even if not use
>> ff_ prefixed functions,
>
> Okay how about this layout...
>
> libavfilter/opencv.cpp (all OpenCV code, using C++ API, helper
> functions for use by the filters)
>
> libafilter/vf_libopencv.c   current filter, but uses opencv.cpp
> functions for OpenCV code
>
> libavfilter/vf_phqm.c   uses OpenCV functions from opencv.cpp

This also should be in libopencv filter.

>
> Since OpenCV ranges in varying functions we may need, and doing
> it as C++ cleanly separately in one place sharing with the C filters seems
> nice.
>
> I agree the duplication of OpenCV in C and C++ APIs seems bad, and
> using just the C++
> API is what I see as best according to the OpenCV devs statements
> against using the C API.
>
>
> Is that acceptable or is a better layout suggested?
>
> Thanks,
> Christopher
>
>>
>> >
>> > Wanting to clarify exactly what is acceptable so I can do it and not
>> > waste
>> > time / effort doing stuff that is

Re: [FFmpeg-devel] [PATCH] avformat/nutenc: Do not pass NULL to memcmp() in get_needed_flags()

[Andreas Rheinhardt]

On Fri, Nov 1, 2019 at 1:32 PM Michael Niedermayer 
wrote:

> On Fri, Nov 01, 2019 at 11:22:41AM +0100, Andreas Rheinhardt wrote:
> > On Fri, Nov 1, 2019 at 10:42 AM Michael Niedermayer
> 
> > wrote:
> >
> > > This compared to the other suggestions is cleaner and easer to
> understand
> > > keeping the condition in the if() simple
> > >
> > > See: [FFmpeg-devel] [PATCH] avformat/nutenc: Fix memleak
> > > See: [FFmpeg-devel] [PATCH]lavf/nutenc: Do not call memcmp() with NULL
> > > argument
> > >
> > > Fixes: Ticket 7980
> > >
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  libavformat/nutenc.c | 11 ++-
> > >  1 file changed, 6 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
> > > index d212f0c245..46dce7722d 100644
> > > --- a/libavformat/nutenc.c
> > > +++ b/libavformat/nutenc.c
> > > @@ -792,11 +792,12 @@ static int get_needed_flags(NUTContext *nut,
> > > StreamContext *nus, FrameCode *fc,
> > >  flags |= FLAG_CHECKSUM;
> > >  if (FFABS(pkt->pts - nus->last_pts) > nus->max_pts_distance)
> > >  flags |= FLAG_CHECKSUM;
> > > -if (pkt->size < nut->header_len[fc->header_idx] ||
> > > -(pkt->size > 4096 && fc->header_idx)||
> > > -memcmp(pkt->data, nut->header[fc->header_idx],
> > > -   nut->header_len[fc->header_idx]))
> > > -flags |= FLAG_HEADER_IDX;
> > > +if (fc->header_idx)
> > > +if (pkt->size < nut->header_len[fc->header_idx] ||
> > > +pkt->size > 4096||
> > > +memcmp(pkt->data, nut->header[fc->header_idx],
> > > +  nut->header_len[fc->header_idx]))
> > > +flags |= FLAG_HEADER_IDX;
> > >
> > >  return flags | (fc->flags & FLAG_CODED);
> > >  }
> > > --
> > > 2.23.0
> > >
> > >
> > The reference to  [FFmpeg-devel] [PATCH] avformat/nutenc: Fix memleak is
> > inappropriate.
>
> yes, oops that was a copy and paste error
> fixed locally
>
>
> > Carl's patch was titled "[FFmpeg-devel] lavf/nutenc: Do not call memcmp()
> > with NULL argument".
>
> Its copy and pasted from here:
> 179255 0701  1:12 Carl Eugen Hoyo (2,2K) [FFmpeg-devel]
> [PATCH]lavf/nutenc: Do not call memcmp() with NULL argument
>
> iam not sure what you refer to, but theres a [PATCH] in the subject with a
> missing space and the reference should duplicate that if theres a reference
>
>
Sorry, my mistake: I thought that you mentioned two of my patches (namely
the memleak and my nutenc patch) when in reality you actually referenced my
memleak patch and Carl's patch.

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

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

Re: [FFmpeg-devel] [PATCH 6/6] avcodec/libvpxdec: reject video and alpha dimension mismatches

[James Zern]

On Sun, Oct 27, 2019 at 10:11 AM Marton Balint  wrote:
>
> Signed-off-by: Marton Balint 
> ---
>  libavcodec/libvpxdec.c | 11 +++
>  1 file changed, 11 insertions(+)
>

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

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

Re: [FFmpeg-devel] [PATCH 5/6] avcodec/libvpxdec: decode to custom framebuffers for vp9

[James Zern]

On Sun, Oct 27, 2019 at 10:11 AM Marton Balint  wrote:
>
> This avoids copying the full frame after decoding.
>
> Signed-off-by: Marton Balint 
> ---
>  libavcodec/libvpxdec.c | 73 
> ++
>  1 file changed, 68 insertions(+), 5 deletions(-)
>

lgtm.

> diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
> index 5c72be5439..fdd5d458d3 100644
> [...]
> +if (min_size > ctx->pool_size) {
> +av_buffer_pool_uninit(&ctx->pool);
> +/* According to the libvpx docs the buffer must be zeroed out. */

I think this is stale and may have been only when using msan and
related tools at one point. We can start with this to cover older
versions, but for reference, Chrome doesn't 0 the buffers.
___
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] avcodec/libtwolame: fix mono default bitrate

[Moritz Barsnick]

On Fri, Nov 01, 2019 at 08:51:07 +, James Cowgill wrote:
> As of libtwolame 0.4.0, 384 kbps is not accepted as a valid bitrate
> for encoding mono audio and the maximum bitrate is now halved to 192
> kbps to comply with the MP2 standard. Example error:

I also just noticed this, after update to twolame-0.4.0.

Does this imply that the native mp2 encoder is creating invalid mono
streams? (It too apparently defaults to 384k, even in mono mode, and
allows setting it.)

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/6] avcodec/rv10: Check input for minimal frame size

[Michael Niedermayer]

On Wed, Oct 09, 2019 at 12:14:51PM +0200, Michael Niedermayer wrote:
> Fixes: Timeout (18sec -> 4sec)
> Fixes: 
> 18012/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV20_fuzzer-5767486145822720
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/rv10.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)

will apply this and the rest of the patch which isnt applied yet


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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


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] avcodec/truemotion2: Fix several integer overflows with *Yo, *Uo, *Vo

[Michael Niedermayer]

On Sun, Oct 27, 2019 at 01:15:44AM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 538976288 - -2080374792 cannot be represented 
> in type 'int'
> Fixes: 
> 16196/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEMOTION2_fuzzer-5144044274974720
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/truemotion2.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)

will apply

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

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


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] avcodec/truemotion2: Fix several integer overflows in tm2_low_res_block()

[Michael Niedermayer]

On Sun, Oct 27, 2019 at 01:15:45AM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 1077952576 + 1355863565 cannot be represented 
> in type 'int'
> Fixes: 
> 16196/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEMOTION2_fuzzer-5679842317565952
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/truemotion2.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

will apply

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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] add phqm filter and img_hash

[Christopher Kennedy]

On Wed, Oct 30, 2019 at 10:57 AM Paul B Mahol  wrote:
>
> On 10/30/19, Christopher Kennedy  wrote:
> > On Wed, Oct 30, 2019 at 10:07 AM Paul B Mahol  wrote:
> >>
> >> On 10/30/19, Christopher Kennedy  wrote:
> >> > On Sat, Oct 26, 2019 at 9:15 AM Paul B Mahol  wrote:
> >> >>
> >> >> On 10/26/19, Christopher Kennedy  wrote:
> >> >> > On Sat, Oct 26, 2019 at 8:22 AM Paul B Mahol 
> >> >> > wrote:
> >> >> >>
> >> >> >> On 10/26/19, Christopher Kennedy  wrote:
> >> >> >> > This is a reference/encode comparison filter with two files input
> >> >> >> > like
> >> >> >> > the psnr or vmaf filter.
> >> >> >> > So it is completely different and uses the C++ OpenCV API since
> >> >> >> > this
> >> >> >> > img_hash library is not in the C API.
> >> >> >> > It's unique to what the OCV filter does, and has more research
> >> >> >> > implications from my talk at Demuxed 2019.
> >> >> >>
> >> >> >> I do not see how that is relevant.
> >> >> >>
> >> >> >> There should be generic opencv filter which could do this above in
> >> >> >> generic way, and not by adding yet another filter that uses only
> >> >> >> some
> >> >> >> part of opencv.
> >> >> >
> >> >> > Is it really possible to do framesync() operations like dual input
> >> >> > filters
> >> >> > like psnr/vmaf and also handle input/output rendering of the frames
> >> >> > too?
> >> >> > This sounds odd to me but I would love to understand how this is
> >> >> > possible.
> >> >>
> >> >> framesync is nothing special, its just used a lot, there are video
> >> >> filters that do not use it and still operate on multiple inputs.
> >> >>
> >> >> >
> >> >> > The C OpenCV API is not recommended so this does the OpenCV part
> >> >> > in C++ which allows it to be fully utilized and supported. So that
> >> >> > seems
> >> >> > better to me than using the API OpenCV won't really support and
> >> >> > doesn't
> >> >> > allow usage of img_hash (it is NOT in the C API of OpenCV,
> >> >> > impossible
> >> >> > to
> >> >> > use).
> >> >> >
> >> >> > The OpenCV C++ img_hash library is the fastest implementation and
> >> >> > does
> >> >> > work best in OpenCV. So implementing this in C directly isn't a task
> >> >> > I
> >> >> > believe
> >> >> > is good to do.
> >> >>
> >> >> I do not care how generic opencv filter is done, it can be C++ just
> >> >> fine.
> >> >>
> >> >> >
> >> >> > So should the current OpenCV stuff be merged into this filter, is
> >> >> > that
> >> >> > possible?
> >> >>
> >> >> Current opencv stuff in libavfilter is pretty dead and not maintained
> >> >> at
> >> >> all.
> >> >> So I'm not really fond of adding yet another opencv filter that not
> >> >> gonna be maintained.
> >> >
> >> > Well I would maintain it, but maybe I should instead run a Fork of
> >> > FFmpeg
> >> > with
> >> > C++ and OpenCV properly done.
> >> >
> >> > Yes the current OCV stuff is dead and not supported by OpenCV or
> >> > maintained
> >> > it sounds like.
> >> >
> >> > So if we can't put C++ into FFmpeg (yet we already have with decklink
> >> > filters,
> >> > so that is unfair to say).
> >> >
> >> > And we can't switch to use OpenCV C++ yet the C API is dead and not
> >> > supported.
> >>
> >> Who said that?
> >> C++ module filter in libavfilter dealing with latest OpenCV and well
> >> maintained is always welcome.
> >
> >
> > So I should be moving the functionality of the current ocv filter into a
> > C++ file for filters to use like phqm, the current ocv transforms?
> >
> > Is this a good plan, separate the C++ from the vf_ filter as I have done
> > with img_hash.cpp (yet make it a more generic set of OpenCV C++
> > helper functions to plug into C vf_filters which can be separated by
> > function yet unified in code used from the C++ base code)?
>
> IMHO filter file can be cpp file without issues. And even if not use
> ff_ prefixed functions,

Okay how about this layout...

libavfilter/opencv.cpp (all OpenCV code, using C++ API, helper
functions for use by the filters)

libafilter/vf_libopencv.c   current filter, but uses opencv.cpp
functions for OpenCV code

libavfilter/vf_phqm.c   uses OpenCV functions from opencv.cpp

Since OpenCV ranges in varying functions we may need, and doing
it as C++ cleanly separately in one place sharing with the C filters seems nice.

I agree the duplication of OpenCV in C and C++ APIs seems bad, and
using just the C++
API is what I see as best according to the OpenCV devs statements
against using the C API.


Is that acceptable or is a better layout suggested?

Thanks,
Christopher

>
> >
> > Wanting to clarify exactly what is acceptable so I can do it and not waste
> > time / effort doing stuff that isn't right.
> >

> >> >
> >
___
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/6] avcodec/libvpxdec: make sure BlockAdditional side data size >= 8

[James Zern]

On Sun, Oct 27, 2019 at 10:11 AM Marton Balint  wrote:
>
> Signed-off-by: Marton Balint 
> ---
>  libavcodec/libvpxdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

lgtm. good catch.
___
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/6] avcodec/libvpxdec: pass decoder instances to vpx_init directly

[James Zern]

On Sun, Oct 27, 2019 at 10:11 AM Marton Balint  wrote:
>
> If the alpha decoder init failed we presented the error message from the 
> normal
> decoder. This change should prevent such mistakes.
>
> Signed-off-by: Marton Balint 
> ---
>  libavcodec/libvpxdec.c | 26 +-
>  1 file changed, 13 insertions(+), 13 deletions(-)
>

lgtm.
___
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/6] avcodec/libvpxenc: fix alpha stride

[James Zern]

On Sun, Oct 27, 2019 at 10:10 AM Marton Balint  wrote:
>
> Signed-off-by: Marton Balint 
> ---
>  libavcodec/libvpxenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

lgtm.
___
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/6] avcodec/libvpxenc: only allocate U/V planes once for the alpha encoder instance

[James Zern]

On Sun, Oct 27, 2019 at 10:11 AM Marton Balint  wrote:
>
> Signed-off-by: Marton Balint 
> ---
>  libavcodec/libvpxenc.c | 44 +++-
>  1 file changed, 23 insertions(+), 21 deletions(-)
>

The encoder can handle frame size changes. This seems to assume the
size will be constant when using alpha or we'll get a reinit.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2 1/5] swscale/swscale_unscaled: fix gbrap10be md5 different on big endian system

[Michael Niedermayer]

On Thu, Oct 31, 2019 at 11:12:56AM +0100, Paul B Mahol wrote:
> lgtm

will apply

thx

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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/1] libavformat/flacenc: reject too big picture blocks

[Michael Niedermayer]

On Wed, Oct 30, 2019 at 02:01:28PM +0100, Mattias Wadman wrote:
> A too big picture will case the muxer to write a truncated block size (uint24)
> causing the output file to be corrupt.
> 
> How to reproduce:
> 
> Write a file with truncated block size:
> ffmpeg -y -f lavfi -i sine -f lavfi -i color=red:size=2400x2400 -map 0:a:0 
> -map 1:v:0 -c:v:0 bmp -disposition:1 attached_pic -t 1 test.flac
> 
> Try to decode:
> ffmpeg -i test.flac test.wav
> 
> Signed-off-by: Mattias Wadman 
> ---
>  libavformat/flacenc.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)

will apply

thx

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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 v2 4/5] avfilter/vf_lut3d: simplify code

[Michael Niedermayer]

On Wed, Oct 30, 2019 at 03:34:59PM +0100, Paul B Mahol wrote:
> lgtm

will apply

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] avfilter: add eval video filter

[Michael Niedermayer]

On Fri, Nov 01, 2019 at 04:50:38PM +0100, Paul B Mahol wrote:
> On 11/1/19, Michael Niedermayer  wrote:
> > On Fri, Nov 01, 2019 at 01:09:24PM +0100, Paul B Mahol wrote:
> >> Signed-off-by: Paul B Mahol 
> >> ---
> >>  doc/filters.texi |  78 +
> >>  libavfilter/Makefile |   1 +
> >>  libavfilter/allfilters.c |   1 +
> >>  libavfilter/vf_eval.c| 687 +++
> >>  4 files changed, 767 insertions(+)
> >>  create mode 100644 libavfilter/vf_eval.c
> >
> > This looks like it duplicates code from vf_geq.c
> > also this should be integrated with or in vf_geq.c
> >
> > IIUC this was written because geq is GPL, but i had already agreed to
> > relicense the code in it i wrote to LGPL, so iam not sure why you wrote
> > this.
> >
> > Who disagreed to relicnce their contribution to geq to avoid this extra
> > work you did ?
> > Or did noone disagree ? then i do not understand why you wrote a seperate
> > filter
> 
> Do I need to contact all on blame list of vf_geq? or also mplayer devs
> that touched geq in mplayer?

all who touched it MINUS anyone who made a change that is totally not
in the current version (there are several developers in mplayer who
made auch changes)
also in case of mplayer you may need to look at the commit messages
some developers did apply patches from others.

I took a quick look and these are the people i saw
carl, ubitux, ivan, ods15, Alexis Ballier, derek, Marc-Antoine Arnaud, Nicolas 
George, Stefano and Paul
reimar, zuxy and diego

For the last 3 i could not find a change that persists in the current
code

Either way please check the list of names, i may have made a mistake!

Thanks

[...]
-- 
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 v2] avformat: Add max_probe_packets option

[Andriy Gelman]

Michael,
On Sat, 19. Oct 16:54, Michael Niedermayer wrote:
> On Thu, Oct 17, 2019 at 10:49:20AM -0400, Andriy Gelman wrote:
> > From: Andriy Gelman 
> > 
> > Allows user to set maximum number of buffered packets when
> > probing a codec. It was a hard-coded parameter before this commit.
> > ---
> >  doc/formats.texi| 4 
> >  libavformat/avformat.h  | 7 +++
> >  libavformat/internal.h  | 2 --
> >  libavformat/options_table.h | 1 +
> >  libavformat/utils.c | 6 +++---
> >  libavformat/version.h   | 2 +-
> >  6 files changed, 16 insertions(+), 6 deletions(-)
> 
> LGTM
> 
> thx
> 

Can this be pushed? 

Thanks,
-- 
Andriy
___
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] sdl2: map AV_PIX_FMT_NONE to SDL_PIXELFORMAT_UNKNOWN

[Marton Balint]

On Wed, 30 Oct 2019, Alfred E. Heggestad wrote:


This does not change the programs behaviour.
The purpose of this patch is to make the code more
robust against future changes, in case someone
starts using the AV_PIX_FMT_NONE entry.


PIX_FMT_NONE signals the end of the array, whatever it maps to is 
irrelevent. I'd rather keep code as is.


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 v2 1/4] frame: handle add side data with the same type

[Marton Balint]

On Sat, 2 Nov 2019, Zhao Zhili wrote:





On Nov 2, 2019, at 1:16 AM, Marton Balint  wrote:



On Fri, 1 Nov 2019, "zhilizhao(赵志立)" wrote:





On Nov 1, 2019, at 8:13 PM, Hendrik Leppkes  wrote:
On Fri, Nov 1, 2019 at 1:03 PM  wrote:

From: Zhao Zhili 
---
libavutil/frame.c | 13 +
libavutil/frame.h |  4 
2 files changed, 17 insertions(+)

I believe there have been some use-cases, especially around
closed-captions, where multiple blocks of the same type have been
used, somehow. Since this is really an API change, not sure its such a
good idea.


I guess it may be too late to change the behavior.


I am not sure, all our API around side data (get/remove) is based on the 
assumption that a single entry of a type exists. Also for packet/stream side 
data it is already assumed as far as I see. So at least for the sake of 
consistency it should be the same way. Maybe we should print a deprecation 
warning if something adds multiple side data of the same type. And later 
sometime it can be changed to actually replace the old side data.


Whether keep the current
behavior or not, remove_side_data is broken. It can remove multiple side data
and miss a few.


Yes.



It can be fixed in two different ways:

1. Remove the first side data of the supplied type, like get_side_data().
2. Remove all side data of the supplied type.

The first solution match current documentation.


I don't see why the 2nd would contradict docs:

/**
* If side data of the supplied type exists in the frame, free it and remove it
* from the frame.
*/

So I'd vote for 2), which removes all side data of the specified type.


APIchanges says (if it counts as part of the documentation):

2014-02-24 - 3e1f241 / d161ae0 - lavu 52.69.100 / 53.8.0 - frame.h
 Add av_frame_remove_side_data() for removing a single side data
 instance from a frame.


I guess that can be iterpreted that way, still I'd go for 2).

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 v2 1/4] frame: handle add side data with the same type

[Zhao Zhili]

> On Nov 2, 2019, at 1:16 AM, Marton Balint  wrote:
> 
> 
> 
> On Fri, 1 Nov 2019, "zhilizhao(赵志立)" wrote:
> 
>> 
>> 
>>> On Nov 1, 2019, at 8:13 PM, Hendrik Leppkes  wrote:
>>> On Fri, Nov 1, 2019 at 1:03 PM  wrote:
 From: Zhao Zhili 
 ---
 libavutil/frame.c | 13 +
 libavutil/frame.h |  4 
 2 files changed, 17 insertions(+)
>>> I believe there have been some use-cases, especially around
>>> closed-captions, where multiple blocks of the same type have been
>>> used, somehow. Since this is really an API change, not sure its such a
>>> good idea.
>> 
>> I guess it may be too late to change the behavior.
> 
> I am not sure, all our API around side data (get/remove) is based on the 
> assumption that a single entry of a type exists. Also for packet/stream side 
> data it is already assumed as far as I see. So at least for the sake of 
> consistency it should be the same way. Maybe we should print a deprecation 
> warning if something adds multiple side data of the same type. And later 
> sometime it can be changed to actually replace the old side data.
> 
>> Whether keep the current
>> behavior or not, remove_side_data is broken. It can remove multiple side data
>> and miss a few.
> 
> Yes.
> 
>> 
>> It can be fixed in two different ways:
>> 
>> 1. Remove the first side data of the supplied type, like get_side_data().
>> 2. Remove all side data of the supplied type.
>> 
>> The first solution match current documentation.
> 
> I don't see why the 2nd would contradict docs:
> 
> /**
> * If side data of the supplied type exists in the frame, free it and remove it
> * from the frame.
> */
> 
> So I'd vote for 2), which removes all side data of the specified type.

APIchanges says (if it counts as part of the documentation):

2014-02-24 - 3e1f241 / d161ae0 - lavu 52.69.100 / 53.8.0 - frame.h
  Add av_frame_remove_side_data() for removing a single side data
  instance from a frame.

> 
> 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 v2 1/4] frame: handle add side data with the same type

[Marton Balint]

On Fri, 1 Nov 2019, "zhilizhao(赵志立)" wrote:





On Nov 1, 2019, at 8:13 PM, Hendrik Leppkes  wrote:

On Fri, Nov 1, 2019 at 1:03 PM  wrote:


From: Zhao Zhili 

---
libavutil/frame.c | 13 +
libavutil/frame.h |  4 
2 files changed, 17 insertions(+)



I believe there have been some use-cases, especially around
closed-captions, where multiple blocks of the same type have been
used, somehow. Since this is really an API change, not sure its such a
good idea.


I guess it may be too late to change the behavior.


I am not sure, all our API around side data (get/remove) is based on the 
assumption that a single entry of a type exists. Also for packet/stream 
side data it is already assumed as far as I see. So at least for the sake 
of consistency it should be the same way. Maybe we should print a 
deprecation warning if something adds multiple side data of the same type. 
And later sometime it can be changed to actually replace the old side 
data.



Whether keep the current
behavior or not, remove_side_data is broken. It can remove multiple side data
and miss a few.


Yes.



It can be fixed in two different ways:

1. Remove the first side data of the supplied type, like get_side_data().
2. Remove all side data of the supplied type.

The first solution match current documentation.


I don't see why the 2nd would contradict docs:

/**
 * If side data of the supplied type exists in the frame, free it and remove it
 * from the frame.
 */

So I'd vote for 2), which removes all side data of the specified type.

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] avformat/segment: fix cuttting for non-zero start pts

[Marton Balint]

On Thu, 31 Oct 2019, Vasily wrote:


Hi Marton,


Please use a proper commit title: e.g:

avformat/segment: fix non-zero start pts

Also make sure you provide the author name you want when you send the
patch email. (you only provided an email address in the From field, not a
full name, I guess this is not intentional).


I've fixed "From" and subject (so it's just my first name, I don't want to 
share my family name etc), hope it's okay now (or do I need to send a completely new 
patch with fixed From and subject instead?).


Yes, you should send a new patch.





What happens if the first packet is not from a reference stream? As far as
I see in that case the output packet timestamp will be 0 based until we
get a packet from the refence stream... Maybe you should accept a packet
from any stream here?


I am not changing output packet timestamps here, I only change the way 
the cutting point for segment muxer is calculated.


You are setting these:

+seg->cur_entry.start_time = (double)pkt->pts * 
av_q2d(st->time_base);
+seg->cur_entry.start_pts = seg->start_pts;

These can affect the packet PTSes of the first segment, because later 
there is code like this:


/* compute new timestamps */
offset = av_rescale_q(seg->initial_offset - (seg->reset_timestamps ? 
seg->cur_entry.start_pts : 0),
  AV_TIME_BASE_Q, st->time_base);
if (pkt->pts != AV_NOPTS_VALUE)
pkt->pts += offset;
if (pkt->dts != AV_NOPTS_VALUE)
pkt->dts += offset;

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] avfilter: add eval video filter

[Paul B Mahol]

On 11/1/19, Michael Niedermayer  wrote:
> On Fri, Nov 01, 2019 at 01:09:24PM +0100, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol 
>> ---
>>  doc/filters.texi |  78 +
>>  libavfilter/Makefile |   1 +
>>  libavfilter/allfilters.c |   1 +
>>  libavfilter/vf_eval.c| 687 +++
>>  4 files changed, 767 insertions(+)
>>  create mode 100644 libavfilter/vf_eval.c
>
> This looks like it duplicates code from vf_geq.c
> also this should be integrated with or in vf_geq.c
>
> IIUC this was written because geq is GPL, but i had already agreed to
> relicense the code in it i wrote to LGPL, so iam not sure why you wrote
> this.
>
> Who disagreed to relicnce their contribution to geq to avoid this extra
> work you did ?
> Or did noone disagree ? then i do not understand why you wrote a seperate
> filter

Do I need to contact all on blame list of vf_geq? or also mplayer devs
that touched geq in mplayer?

>
> Thanks
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Everything should be made as simple as possible, but not simpler.
> -- Albert Einstein
>
___
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] avfilter: add eval video filter

[Michael Niedermayer]

On Fri, Nov 01, 2019 at 01:09:24PM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi |  78 +
>  libavfilter/Makefile |   1 +
>  libavfilter/allfilters.c |   1 +
>  libavfilter/vf_eval.c| 687 +++
>  4 files changed, 767 insertions(+)
>  create mode 100644 libavfilter/vf_eval.c

This looks like it duplicates code from vf_geq.c
also this should be integrated with or in vf_geq.c

IIUC this was written because geq is GPL, but i had already agreed to
relicense the code in it i wrote to LGPL, so iam not sure why you wrote this.

Who disagreed to relicnce their contribution to geq to avoid this extra
work you did ? 
Or did noone disagree ? then i do not understand why you wrote a seperate
filter 

Thanks

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 3/8] avcodec/utils: Check block_align

[Michael Niedermayer]

On Fri, Nov 01, 2019 at 09:26:52AM +0100, Paul B Mahol wrote:
> LGTM

will apply

thx

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

"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott



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/v4l2_buffers: Fix infinite loop

[Andriy Gelman]

On Sun, 27. Oct 00:19, Andriy Gelman wrote:
> From: Andriy Gelman 
> 
> This part of the code counts the number of planes returned by the v4l2
> device for each queried capture/output buffer.
> When testing the GPU h264 encoder on Nvidia's Jetson Nano, this caused an
> infinite loop because avbuf->buf.length included some empty buffers (i.e.
> where avbuf->buf.m.planes[i].length = 0), meaning that the counter was
> never incremented and break was never reached.
> This is fixed in the commit by using a well defined iteration range.
> ---
>  libavcodec/v4l2_buffers.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
> index e301dcd6bd..dc1b9eaf24 100644
> --- a/libavcodec/v4l2_buffers.c
> +++ b/libavcodec/v4l2_buffers.c
> @@ -511,11 +511,9 @@ int ff_v4l2_buffer_initialize(V4L2Buffer* avbuf, int 
> index)
>  
>  if (V4L2_TYPE_IS_MULTIPLANAR(ctx->type)) {
>  avbuf->num_planes = 0;
> -for (;;) {
> -/* in MP, the V4L2 API states that buf.length means num_planes */
> -if (avbuf->num_planes >= avbuf->buf.length)
> -break;
> -if (avbuf->buf.m.planes[avbuf->num_planes].length)
> +/* in MP, the V4L2 API states that buf.length means num_planes */
> +for (i = 0; i < avbuf->buf.length; i++) {
> +if (avbuf->buf.m.planes[i].length)
>  avbuf->num_planes++;
>  }
>  } else
> -- 
> 2.23.0
> 

ping

-- 
Andriy
___
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/qsv: improve the default GPU memory usage

[Max Dmitrichenko]

On Fri, Nov 1, 2019 at 11:20 AM Zhong Li  wrote:

> > A large initial_pool_size leads to redundant GPU memory allocations
> > compared with MSDK.
> >
> > For some special cases which needs larger GPU memory like look_ahead,
> > add -extra_hw_frames to allocate more.
> >
> > CMD:
> > ffmpeg -hwaccel qsv -extra_hw_frames 50 -c:v hevc_qsv -i hevc.h265 -c:v
> h264_qsv
> > -look_ahead 1 -look_ahead_depth 50 -y output.h264
> >
> > Fix #7943.
> >
> > Reported-by: Eero T
> > Signed-off-by: Linjie Fu 
> > ---
> >  fftools/ffmpeg_qsv.c | 2 +-
> >  libavcodec/qsvdec.c  | 5 -
> >  libavcodec/qsvenc_h264.c | 4 ++--
> >  3 files changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/fftools/ffmpeg_qsv.c b/fftools/ffmpeg_qsv.c
> > index 9c4285b..5039a5a 100644
> > --- a/fftools/ffmpeg_qsv.c
> > +++ b/fftools/ffmpeg_qsv.c
> > @@ -93,7 +93,7 @@ int qsv_init(AVCodecContext *s)
> >  frames_ctx->height= FFALIGN(s->coded_height, 32);
> >  frames_ctx->format= AV_PIX_FMT_QSV;
> >  frames_ctx->sw_format = s->sw_pix_fmt;
> > -frames_ctx->initial_pool_size = 64 + s->extra_hw_frames;
> > +frames_ctx->initial_pool_size = 24 + s->extra_hw_frames;
>
> Should be better add pool size when look_ahead is enabled.
>
>

yes, please follow this.



> E:g
> initial_pool_size = 24 + look_head_depth + s->extra_hw_frames;
>
> you can set a default look_ahead_depth when look_ahead is enabled bu
> no depth specified.
>
> >  frames_hwctx->frame_type  =
> MFX_MEMTYPE_VIDEO_MEMORY_DECODER_TARGET;
> >
> >  ret = av_hwframe_ctx_init(ist->hw_frames_ctx);
> > diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> > index 0d34021..407e6de 100644
> > --- a/libavcodec/qsvdec.c
> > +++ b/libavcodec/qsvdec.c
> > @@ -300,8 +300,11 @@ static int alloc_frame(AVCodecContext *avctx,
> QSVContext *q, QSVFrame *frame)
> >  else
> >  ret = ff_get_buffer(avctx, frame->frame,
> AV_GET_BUFFER_FLAG_REF);
> >
> > -if (ret < 0)
> > +if (ret < 0) {
> > +av_log(avctx, AV_LOG_ERROR, "More memory in need, "
> > +"try -extra_hw_frames to allocate more.\n");
> >  return ret;
> > +}
> >
> >  if (frame->frame->format == AV_PIX_FMT_QSV) {
> >  frame->surface = *(mfxFrameSurface1*)frame->frame->data[3];
> > diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
> > index 27f36b9..4e8035b 100644
> > --- a/libavcodec/qsvenc_h264.c
> > +++ b/libavcodec/qsvenc_h264.c
> > @@ -112,8 +112,8 @@ static const AVOption options[] = {
> >  { "max_dec_frame_buffering", "Maximum number of frames buffered in
> the DPB", OFFSET(qsv.max_dec_frame_buffering), AV_OPT_TYPE_INT, { .i64 = 0
> },   0, UINT16_MAX, VE },
> >
> >  #if QSV_HAVE_LA
> > -{ "look_ahead",   "Use VBR algorithm with look ahead",
> OFFSET(qsv.look_ahead),   AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE },
> > -{ "look_ahead_depth", "Depth of look ahead in number frames",
> OFFSET(qsv.look_ahead_depth), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 100, VE },
> > +{ "look_ahead",   "Use VBR algorithm with look ahead,
> extra_hw_frames is needed",OFFSET(qsv.look_ahead),
>  AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE },
> > +{ "look_ahead_depth", "Depth of look ahead in number frames,
> extra_hw_frames is needed", OFFSET(qsv.look_ahead_depth), AV_OPT_TYPE_INT,
> { .i64 = 0 }, 0, 100, VE },
>
> No need to update the message if follow comments above.
> ___
> 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 v2 3/5] tests/fate/filter-video: add fate pixfmts test for lut1d and lut3d

[Michael Niedermayer]

On Wed, Oct 30, 2019 at 09:20:54PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang 
> 
> Signed-off-by: Limin Wang 
> ---
>  tests/fate/filter-video.mak |  6 ++
>  tests/ref/fate/filter-pixfmts-lut1d | 24 
>  tests/ref/fate/filter-pixfmts-lut3d | 24 
>  3 files changed, 54 insertions(+)
>  create mode 100644 tests/ref/fate/filter-pixfmts-lut1d
>  create mode 100644 tests/ref/fate/filter-pixfmts-lut3d

fails
make: *** [fate-filter-pixfmts-lut3d] Error 1
make: *** [fate-filter-pixfmts-lut1d] Error 1
on x86-32

--- src/tests/ref/fate/filter-pixfmts-lut3d 2019-11-01 13:51:40.807408107 
+0100
+++ tests/data/fate/filter-pixfmts-lut3d2019-11-01 13:53:45.595410736 
+0100
@@ -1,24 +1,24 @@
-0bgr5087cdbb3da0d014de02fda75618f278
-0rgb9ccde40a857919017558353aaecfa5de
-abgr0505ae7e852cf32ce9e2a0fc06462f48
-argb77e7baba2d8b4389267a2ecb67662c15
-bgr0cded4da42263da5bf0153e8bad09a0de
-bgr24   fef9ee2e37a1d5c1787ffb3ed5dcc3bf
-bgr48le 39fe9f41285f3325833d28ce1611d586
-bgra3433cdbdf07abbd8af4698a3b7a1a189
-bgra64le8f33508d6c0362df83296513ebee3a2d
-gbrap   4227379340c3d822dd6c59263b170972
-gbrap10le   90721f63d6e3d5d7a6bafcefdca5151d
-gbrap12le   e1eee70df0c2578937dcd7a90e22f4b7
-gbrap16le   2fd82ec30573ed65fa23c4d1c150d596
-gbrpe615c8ea180a0358261953812df0aa3d
-gbrp10led61faad75dbd7cbb0271b47fa33d714e
-gbrp12le90c4ec04807bbfbe194eddcc8d7bcb2a
-gbrp14lec424158744f9e16dbfcf00c66ba651f9
-gbrp16le8ccb63f9407cae03b2e061ed1249127d
-gbrp9le 4a267ed7c6535c8829e83e35c51df6bf
-rgb0545f5c4e4a7b7f3e61373149db0b932a
-rgb24   aec4f0a1954823de17024383d6401b75
-rgb48le 1d1e5a1849ed3c326961184bb2f45400
-rgbaecd54389d03bded1e8209f5bdea5
-rgba64leb26c35d221b026304db46014260ed1db
+0bgr7b83991d73694572a29f9655ad4a1c84
+0rgbd559f4a889a119ecede1821b561fdded
+abgrc09eeb64d67b2feee042fec6c82d19f2
+argba18a4a3a1125cfe8cba94e9472a9d255
+bgr0f7db08eaee52afa722aabb67adaaf4ea
+bgr24   11db3c5fe5f705ba4994ec9a5ada3cff
+bgr48le 569c425858f68a809ba30e4599a48fe4
+bgraf6c5a568b5c41238a7a64cf62330f337
+bgra64lea8e90780f59afb31cd11ee35d5e476c2
+gbrap   ae8ce6a9a43b1a29c77e768bb3219ced
+gbrap10le   d91ec08222f53ad2d13eb55526c4ebbe
+gbrap12le   d9902c437e1a634c7debb9b26a78af05
+gbrap16le   45eb3cd875157c057c1c9931fe7cc0e2
+gbrp92873a0fa33a0e71b57654ad883aa902
+gbrp10led7008353207928923330a484c255a31d
+gbrp12le6ccaad2d08e11f06f41d1f925fc91e7f
+gbrp14leb1d20a9df7193d524e20e0c057307176
+gbrp16lee23c0cdec81cea1ddc9be45ac610ca64
+gbrp9le 06173cd4a5569f303eecbe1d19f9e9d3
+rgb005b576915d8fd30b1de3d3a7d59aba06
+rgb24   7ec80634e169ea94adc4efde25592e31
+rgb48le f4671cad79547953dc1ca8a0661ad131
+rgbae98ce9f6b490413fe325bcb30b9c0eac
+rgba64leeda79f1558a53d14e4e236c8c4aaef4d
Test filter-pixfmts-lut3d failed. Look at 
tests/data/fate/filter-pixfmts-lut3d.err for details.


--- src/tests/ref/fate/filter-pixfmts-lut1d 2019-11-01 13:51:40.807408107 
+0100
+++ tests/data/fate/filter-pixfmts-lut1d2019-11-01 13:53:45.587410736 
+0100
@@ -1,24 +1,24 @@
-0bgr89655364415a9893ccdf403b32ff588c
-0rgbe86013d5c46c02ed6a555d669877e9d7
-abgrfe237c269cf66969b99a028dd6a34214
-argbd9b49a3a68087eb99ba208edcbf087a4
-bgr09f8de7f2afbb07b4fa56e3386f06a1d4
-bgr24   ec35fb477c56d6ecf5f1651797e1a456
-bgr48le e713ca125c7a4f6d91d7a054155af81f
-bgracd9424cf54a3a6ed65d7eaf9d412c3df
-bgra64le7d11a05feef943d7abdecc39ad1e941a
-gbrap   bc87d42fc26eb0e54323c2b1e4de4cde
-gbrap10le   732c3682336d505be11beb9624aa7866
-gbrap12le   83699133174282c5d6ac81bf7878462b
-gbrap16le   da278e22602bccc4ecef7194b462a6ff
-gbrp5a031c0eaf96442715a7cc71b4a97f07
-gbrp10le56fe2aa5e1bf130aa32a24fc99ce528f
-gbrp12le11cabeca5ae713c0fc1e08aaeddfa17d
-gbrp14lee71c1fd4277ce9873c0893740cb2cd83
-gbrp16lef77722121d3c963da139f9e264713922
-gbrp9le 662a7fe5a4aa94fc43252deb54fc2880
-rgb0c7e68621c78fcd2d198c4d4af6116911
-rgb24   5f0bce5216958eac47159ea30b4594d5
-rgb48le a6c5dd31afe7fdeb23e68bddb9be9589
-rgbaae28588ea064087d2535bfc7a67273ee
-rgba64led3c5b32463001be46927e8909cce5859
+0bgr7b83991d73694572a29f9655ad4a1c84

Re: [FFmpeg-devel] [PATCH] avcodec/libtwolame: fix mono default bitrate

[Paul B Mahol]

applied

On 11/1/19, James Cowgill  wrote:
> As of libtwolame 0.4.0, 384 kbps is not accepted as a valid bitrate
> for encoding mono audio and the maximum bitrate is now halved to 192
> kbps to comply with the MP2 standard. Example error:
>
> twolame_init_params(): 384kbps is an invalid bitrate for mono encoding.
>
> Adjust the default bitrate calculation to take this into account.
>
> Signed-off-by: James Cowgill 
> ---
>  libavcodec/libtwolame.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/libtwolame.c b/libavcodec/libtwolame.c
> index 030f88868f..5ceb3d9f3f 100644
> --- a/libavcodec/libtwolame.c
> +++ b/libavcodec/libtwolame.c
> @@ -78,8 +78,12 @@ static av_cold int twolame_encode_init(AVCodecContext
> *avctx)
>  twolame_set_in_samplerate(s->glopts, avctx->sample_rate);
>  twolame_set_out_samplerate(s->glopts, avctx->sample_rate);
>
> -if (!avctx->bit_rate)
> -avctx->bit_rate = avctx->sample_rate < 28000 ? 16 : 384000;
> +if (!avctx->bit_rate) {
> +if ((s->mode == TWOLAME_AUTO_MODE && avctx->channels == 1) ||
> s->mode == TWOLAME_MONO)
> +avctx->bit_rate = avctx->sample_rate < 28000 ? 8 : 192000;
> +else
> +avctx->bit_rate = avctx->sample_rate < 28000 ? 16 : 384000;
> +}
>
>  if (avctx->flags & AV_CODEC_FLAG_QSCALE || !avctx->bit_rate) {
>  twolame_set_VBR(s->glopts, TRUE);
> --
> 2.24.0.rc1
>
> ___
> 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 v2 1/4] frame: handle add side data with the same type

[zhilizhao(赵志立)]

> On Nov 1, 2019, at 8:13 PM, Hendrik Leppkes  wrote:
> 
> On Fri, Nov 1, 2019 at 1:03 PM  wrote:
>> 
>> From: Zhao Zhili 
>> 
>> ---
>> libavutil/frame.c | 13 +
>> libavutil/frame.h |  4 
>> 2 files changed, 17 insertions(+)
>> 
> 
> I believe there have been some use-cases, especially around
> closed-captions, where multiple blocks of the same type have been
> used, somehow. Since this is really an API change, not sure its such a
> good idea.

I guess it may be too late to change the behavior. Whether keep the current
behavior or not, remove_side_data is broken. It can remove multiple side data
and miss a few.

It can be fixed in two different ways:

1. Remove the first side data of the supplied type, like get_side_data().
2. Remove all side data of the supplied type.

The first solution match current documentation.

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



___
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] Reimbursement request

[Stefano Sabatini]

On date Wednesday 2019-10-30 21:25:24 +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> I am requesting reimbursement for my travel to the Google mentor summit.
> My total travelling expenses were € 90,90

LGTM, please fill the form here:
https://www.spi-inc.org/treasurer/reimbursement-form/

and send it to me and Michael, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/1] avformat/mpegenc.c: vbvsize option

[Michael Niedermayer]

On Thu, Oct 31, 2019 at 06:04:58PM +0100, Nicolas Gaullier wrote:
> Allow the user to set or override the vbv size
> ---
>  libavformat/mpegenc.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/mpegenc.c b/libavformat/mpegenc.c
> index f6980231a2..1613c8afa1 100644
> --- a/libavformat/mpegenc.c
> +++ b/libavformat/mpegenc.c
> @@ -67,6 +67,7 @@ typedef struct MpegMuxContext {
>  int system_header_freq;
>  int system_header_size;
>  int user_mux_rate; /* bitrate in units of bits/s */
> +int user_vbv_size; /* vbv buffer size in units of bits/s */
>  int mux_rate; /* bitrate in units of 50 bytes/s */
>  /* stream info */
>  int audio_bound;
> @@ -433,7 +434,9 @@ static av_cold int mpeg_mux_init(AVFormatContext *ctx)
>  stream->id = mpv_id++;
>  
>  props = (AVCPBProperties*)av_stream_get_side_data(st, 
> AV_PKT_DATA_CPB_PROPERTIES, NULL);
> -if (props && props->buffer_size)
> +if (s->user_vbv_size)
> +stream->max_buffer_size = 6 * 1024 + s->user_vbv_size / 8;
> +else if (props && props->buffer_size)
>  stream->max_buffer_size = 6 * 1024 + props->buffer_size / 8;
>  else {
>  av_log(ctx, AV_LOG_WARNING,
> @@ -1268,6 +1271,7 @@ static void mpeg_mux_deinit(AVFormatContext *ctx)
>  #define E AV_OPT_FLAG_ENCODING_PARAM
>  static const AVOption options[] = {
>  { "muxrate", NULL,  
> OFFSET(user_mux_rate), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, ((1<<22) - 1) * (8 * 
> 50), E },
> +{ "vbvsize", "set vbv buffer size (in bits)",   
> OFFSET(user_vbv_size), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, (1LL<<32) - 1, E},
>  { "preload", "Initial demux-decode delay in microseconds.", 
> OFFSET(preload),  AV_OPT_TYPE_INT, { .i64 = 50 }, 0, INT_MAX, E },
>  { NULL },
>  };

This is not the "correct" way to handle this, because one mpeg container
can contain many streams and this is just one parameter for the container.
while the vbvsize is a parameter per stream.

[...]
-- 
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".

[FFmpeg-devel] [PATCH] avformat/nutenc: Do not pass NULL to memcmp() in get_needed_flags()

[Michael Niedermayer]

This compared to the other suggestions is cleaner and easier to understand
keeping the condition in the if() simple.

This affects alot of fate tests.

See: [FFmpeg-devel] [PATCH 05/11] avformat/nutenc: Don't pass NULL to memcmp
See: [FFmpeg-devel] [PATCH]lavf/nutenc: Do not call memcmp() with NULL argument

Fixes: Ticket 7980

Signed-off-by: Michael Niedermayer 
---
 libavformat/nutenc.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
index d212f0c245..46dce7722d 100644
--- a/libavformat/nutenc.c
+++ b/libavformat/nutenc.c
@@ -792,11 +792,12 @@ static int get_needed_flags(NUTContext *nut, 
StreamContext *nus, FrameCode *fc,
 flags |= FLAG_CHECKSUM;
 if (FFABS(pkt->pts - nus->last_pts) > nus->max_pts_distance)
 flags |= FLAG_CHECKSUM;
-if (pkt->size < nut->header_len[fc->header_idx] ||
-(pkt->size > 4096 && fc->header_idx)||
-memcmp(pkt->data, nut->header[fc->header_idx],
-   nut->header_len[fc->header_idx]))
-flags |= FLAG_HEADER_IDX;
+if (fc->header_idx)
+if (pkt->size < nut->header_len[fc->header_idx] ||
+pkt->size > 4096||
+memcmp(pkt->data, nut->header[fc->header_idx],
+  nut->header_len[fc->header_idx]))
+flags |= FLAG_HEADER_IDX;
 
 return flags | (fc->flags & FLAG_CODED);
 }
-- 
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] avformat/nutenc: Do not pass NULL to memcmp() in get_needed_flags()

[Michael Niedermayer]

On Fri, Nov 01, 2019 at 11:22:41AM +0100, Andreas Rheinhardt wrote:
> On Fri, Nov 1, 2019 at 10:42 AM Michael Niedermayer 
> wrote:
> 
> > This compared to the other suggestions is cleaner and easer to understand
> > keeping the condition in the if() simple
> >
> > See: [FFmpeg-devel] [PATCH] avformat/nutenc: Fix memleak
> > See: [FFmpeg-devel] [PATCH]lavf/nutenc: Do not call memcmp() with NULL
> > argument
> >
> > Fixes: Ticket 7980
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/nutenc.c | 11 ++-
> >  1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
> > index d212f0c245..46dce7722d 100644
> > --- a/libavformat/nutenc.c
> > +++ b/libavformat/nutenc.c
> > @@ -792,11 +792,12 @@ static int get_needed_flags(NUTContext *nut,
> > StreamContext *nus, FrameCode *fc,
> >  flags |= FLAG_CHECKSUM;
> >  if (FFABS(pkt->pts - nus->last_pts) > nus->max_pts_distance)
> >  flags |= FLAG_CHECKSUM;
> > -if (pkt->size < nut->header_len[fc->header_idx] ||
> > -(pkt->size > 4096 && fc->header_idx)||
> > -memcmp(pkt->data, nut->header[fc->header_idx],
> > -   nut->header_len[fc->header_idx]))
> > -flags |= FLAG_HEADER_IDX;
> > +if (fc->header_idx)
> > +if (pkt->size < nut->header_len[fc->header_idx] ||
> > +pkt->size > 4096||
> > +memcmp(pkt->data, nut->header[fc->header_idx],
> > +  nut->header_len[fc->header_idx]))
> > +flags |= FLAG_HEADER_IDX;
> >
> >  return flags | (fc->flags & FLAG_CODED);
> >  }
> > --
> > 2.23.0
> >
> >
> The reference to  [FFmpeg-devel] [PATCH] avformat/nutenc: Fix memleak is
> inappropriate.

yes, oops that was a copy and paste error
fixed locally


> Carl's patch was titled "[FFmpeg-devel] lavf/nutenc: Do not call memcmp()
> with NULL argument".

Its copy and pasted from here:
179255 0701  1:12 Carl Eugen Hoyo (2,2K) [FFmpeg-devel] [PATCH]lavf/nutenc: 
Do not call memcmp() with NULL argument

iam not sure what you refer to, but theres a [PATCH] in the subject with a
missing space and the reference should duplicate that if theres a reference


> You could also mention that this affected lots of fate-tests. 

will do


> And "easer"
> is missing an "i".

will correct


> I have no objections apart from that. I didn't test your code, but it looks
> fine.

ok, ill wait a bit more in case others want to comment or test

Thanks!

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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 v2 1/4] frame: handle add side data with the same type

[Hendrik Leppkes]

On Fri, Nov 1, 2019 at 1:03 PM  wrote:
>
> From: Zhao Zhili 
>
> ---
>  libavutil/frame.c | 13 +
>  libavutil/frame.h |  4 
>  2 files changed, 17 insertions(+)
>

I believe there have been some use-cases, especially around
closed-captions, where multiple blocks of the same type have been
used, somehow. Since this is really an API change, not sure its such a
good idea.

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

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

[FFmpeg-devel] [PATCH] avfilter: add eval video filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |  78 +
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_eval.c| 687 +++
 4 files changed, 767 insertions(+)
 create mode 100644 libavfilter/vf_eval.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 7e9d50782a..e26ee53c1e 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -9977,6 +9977,84 @@ Flags to local 3x3 coordinates maps like this:
 6 7 8
 @end table
 
+@section eval
+Filter video frames according to specified expressions.
+
+The filter accepts the following options:
+
+@table @option
+@item inputs
+Set number of inputs. All input must be of same format.
+Note that inputs width and height might be different.
+
+@item size
+Set output video size. Default is hd720.
+
+@item sar
+Set output sample aspect ratio.
+
+@item expr0
+@item expr1
+@item expr2
+@item expr3
+Set expression for each component. Components with unset or invalid expression
+will be replaced with zero values in output.
+@end table
+
+Each expression can contain the following constants and functions:
+
+@table @option
+@item C
+Number of color components in currently used format.
+
+@item DEPTH
+Bit depth of current used format.
+
+@item W
+Width of current plane of output frame.
+
+@item H
+Height of current plane of output frame.
+
+@item SW
+@item SH
+Width and height scale for the plane being filtered. It is the
+ratio between the dimensions of the current plane to the frame dimensions,
+
+@item X
+@item Y
+The coordinates of the current output pixel component.
+
+@item CC
+The current color component.
+
+@item N
+Current output frame number, starting from 0.
+
+@item T
+Time of the current frame, expressed in seconds.
+
+@item sw(c)
+Return width scale for component @var{c}.
+
+@item sh(c)
+Return height scale for component @var{c}.
+
+@item iw(n)
+Return frame width of input @var{n}.
+
+@item ih(n)
+Return frame height of input @var{n}.
+
+@item fNc0(x, y)
+@item fNc1(x, y)
+@item fNc2(x, y)
+@item fNc3(x, y)
+Return the value of pixel component at location (@var{x}, @var{y}) of
+N-th input frame and components @var{0}-@var{3}. N is replaced with input 
number.
+Min allowed N is @var{0}, and max allowed N is number of @var{inputs} less one.
+@end table
+
 @section extractplanes
 
 Extract color channel components from input video stream into
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 2080eed559..0fcc273e10 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -235,6 +235,7 @@ OBJS-$(CONFIG_EQ_FILTER) += vf_eq.o
 OBJS-$(CONFIG_EROSION_FILTER)+= vf_neighbor.o
 OBJS-$(CONFIG_EROSION_OPENCL_FILTER) += vf_neighbor_opencl.o opencl.o \
 opencl/neighbor.o
+OBJS-$(CONFIG_EVAL_FILTER)   += vf_eval.o
 OBJS-$(CONFIG_EXTRACTPLANES_FILTER)  += vf_extractplanes.o
 OBJS-$(CONFIG_FADE_FILTER)   += vf_fade.o
 OBJS-$(CONFIG_FFTDNOIZ_FILTER)   += vf_fftdnoiz.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index cb609067b6..ed9e8c2d4f 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -220,6 +220,7 @@ extern AVFilter ff_vf_entropy;
 extern AVFilter ff_vf_eq;
 extern AVFilter ff_vf_erosion;
 extern AVFilter ff_vf_erosion_opencl;
+extern AVFilter ff_vf_eval;
 extern AVFilter ff_vf_extractplanes;
 extern AVFilter ff_vf_fade;
 extern AVFilter ff_vf_fftdnoiz;
diff --git a/libavfilter/vf_eval.c b/libavfilter/vf_eval.c
new file mode 100644
index 00..6cb5f9d030
--- /dev/null
+++ b/libavfilter/vf_eval.c
@@ -0,0 +1,687 @@
+/*
+ * Copyright (c) 2019 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avstring.h"
+#include "libavutil/eval.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "filters.h"
+#include "framesync.h"
+#include "video.h"
+
+enum Variables {
+VAR_C,
+VAR_DEPTH,
+VAR_W,
+VAR_H,
+VAR_SW,
+VAR_SH,
+VAR_X,
+VAR_Y,
+VAR_CC,
+VAR

[FFmpeg-devel] [PATCH v2 4/4] avcodec/avcodec.h: document add/new_side_data with the same type

[quinkblack]

From: Zhao Zhili 

---
 libavcodec/avcodec.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index bcb931f0dd..84dcf52285 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -4486,6 +4486,8 @@ void av_free_packet(AVPacket *pkt);
 /**
  * Allocate new information of a packet.
  *
+ * @note replace existing side data of the same type
+ *
  * @param pkt packet
  * @param type side information type
  * @param size side information size
@@ -4497,6 +4499,8 @@ uint8_t* av_packet_new_side_data(AVPacket *pkt, enum 
AVPacketSideDataType type,
 /**
  * Wrap an existing array as a packet side data.
  *
+ * @note replace existing side data of the same type
+ *
  * @param pkt packet
  * @param type side information type
  * @param data the side data array. It must be allocated with the av_malloc()
-- 
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".

[FFmpeg-devel] [PATCH v2 2/4] frame: make av_frame_remove_side_data return early

[quinkblack]

From: Zhao Zhili 

---
 libavutil/frame.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index bb20e99331..9edf971c55 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -825,6 +825,7 @@ void av_frame_remove_side_data(AVFrame *frame, enum 
AVFrameSideDataType type)
 free_side_data(&frame->side_data[i]);
 frame->side_data[i] = frame->side_data[frame->nb_side_data - 1];
 frame->nb_side_data--;
+return;
 }
 }
 }
-- 
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".

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

[quinkblack]

From: Zhao Zhili 

---
 libavutil/frame.c | 13 +
 libavutil/frame.h |  4 
 2 files changed, 17 insertions(+)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index dcf1fc3d17..bb20e99331 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -692,10 +692,23 @@ AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame 
*frame,
  AVBufferRef *buf)
 {
 AVFrameSideData *ret, **tmp;
+int i;
 
 if (!buf)
 return NULL;
 
+for (i = 0; i < frame->nb_side_data; i++) {
+AVFrameSideData *sd = frame->side_data[i];
+if (sd->type == type) {
+av_buffer_unref(&sd->buf);
+av_dict_free(&sd->metadata);
+sd->buf = buf;
+sd->data = buf->data;
+sd->size = buf->size;
+return sd;
+}
+}
+
 if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1)
 return NULL;
 
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 5d3231e7bb..906143f894 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -886,6 +886,8 @@ AVBufferRef *av_frame_get_plane_buffer(AVFrame *frame, int 
plane);
 /**
  * Add a new side data to a frame.
  *
+ * @note replace existing side data of the same type
+ *
  * @param frame a frame to which the side data should be added
  * @param type type of the added side data
  * @param size size of the side data
@@ -899,6 +901,8 @@ AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
 /**
  * Add a new side data to a frame from an existing AVBufferRef
  *
+ * @note replace existing side data of the same type
+ *
  * @param frame a frame to which the side data should be added
  * @param type  the type of the added side data
  * @param buf   an AVBufferRef to add as side data. The ownership of
-- 
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".

[FFmpeg-devel] [PATCH v2 3/4] avformat/avformat.h: document add/new_side_data with the same type

[quinkblack]

From: Zhao Zhili 

---
 libavformat/avformat.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 6eb329f13f..acce242398 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -2162,6 +2162,8 @@ AVStream *avformat_new_stream(AVFormatContext *s, const 
AVCodec *c);
 /**
  * Wrap an existing array as stream side data.
  *
+ * @note replace existing side data of the same type
+ *
  * @param st stream
  * @param type side information type
  * @param data the side data array. It must be allocated with the av_malloc()
@@ -2177,6 +2179,8 @@ int av_stream_add_side_data(AVStream *st, enum 
AVPacketSideDataType type,
 /**
  * Allocate new information from stream.
  *
+ * @note replace existing side data of the same type
+ *
  * @param stream stream
  * @param type desired side information type
  * @param size side information size
-- 
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] lavf/mov: initial support for reading HEIF images

[Swaraj Hota]

On Thu, Oct 31, 2019, 11:00 PM Dale Curtis  wrote:

> On Thu, Oct 31, 2019 at 1:32 AM Swaraj Hota 
> wrote:
>
> > Yes I will send the patch soon for review. Still a few things left to do.
> >
> > Swaraj
> >
>
> Great! Let me know if there's anything I can help with. If you need some
> AVIF samples they can be found here:
> https://github.com/AOMediaCodec/av1-avif/tree/master/testFiles/


Sure. Thanks for the samples!
I have not currently tested the patch with avif format, was only focused on
heif. But as the only difference is the decoder (?), this support could be
easily added. I'll try to add it but as I have been working on this for a
long time now, someone else can surely add it if I couldn't, after my patch
is merged that is.

Swaraj
___
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] frame: handle add side data with the same type

[Marton Balint]

On Fri, 1 Nov 2019, "zhilizhao(赵志立)" wrote:


Ping for review, thanks!


You should update the documentation for the function, that it replaces 
existing side data of the same type. You should also make sure it works as 
it is documented now: on failure, the frame is unchanged.


Regards,
Marton




On Oct 25, 2019, at 1:00 PM, quinkbl...@foxmail.com wrote:

From: Zhao Zhili 

---
libavutil/frame.c | 13 +
1 file changed, 13 insertions(+)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index dcf1fc3d17..bb20e99331 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -692,10 +692,23 @@ AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame 
*frame,
 AVBufferRef *buf)
{
AVFrameSideData *ret, **tmp;
+int i;

if (!buf)
return NULL;

+for (i = 0; i < frame->nb_side_data; i++) {
+AVFrameSideData *sd = frame->side_data[i];
+if (sd->type == type) {
+av_buffer_unref(&sd->buf);
+av_dict_free(&sd->metadata);
+sd->buf = buf;
+sd->data = buf->data;
+sd->size = buf->size;
+return sd;
+}
+}
+
if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1)
return NULL;

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

___
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/nutenc: Do not pass NULL to memcmp() in get_needed_flags()

[Andreas Rheinhardt]

On Fri, Nov 1, 2019 at 10:42 AM Michael Niedermayer 
wrote:

> This compared to the other suggestions is cleaner and easer to understand
> keeping the condition in the if() simple
>
> See: [FFmpeg-devel] [PATCH] avformat/nutenc: Fix memleak
> See: [FFmpeg-devel] [PATCH]lavf/nutenc: Do not call memcmp() with NULL
> argument
>
> Fixes: Ticket 7980
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/nutenc.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
> index d212f0c245..46dce7722d 100644
> --- a/libavformat/nutenc.c
> +++ b/libavformat/nutenc.c
> @@ -792,11 +792,12 @@ static int get_needed_flags(NUTContext *nut,
> StreamContext *nus, FrameCode *fc,
>  flags |= FLAG_CHECKSUM;
>  if (FFABS(pkt->pts - nus->last_pts) > nus->max_pts_distance)
>  flags |= FLAG_CHECKSUM;
> -if (pkt->size < nut->header_len[fc->header_idx] ||
> -(pkt->size > 4096 && fc->header_idx)||
> -memcmp(pkt->data, nut->header[fc->header_idx],
> -   nut->header_len[fc->header_idx]))
> -flags |= FLAG_HEADER_IDX;
> +if (fc->header_idx)
> +if (pkt->size < nut->header_len[fc->header_idx] ||
> +pkt->size > 4096||
> +memcmp(pkt->data, nut->header[fc->header_idx],
> +  nut->header_len[fc->header_idx]))
> +flags |= FLAG_HEADER_IDX;
>
>  return flags | (fc->flags & FLAG_CODED);
>  }
> --
> 2.23.0
>
>
The reference to  [FFmpeg-devel] [PATCH] avformat/nutenc: Fix memleak is
inappropriate.
Carl's patch was titled "[FFmpeg-devel] lavf/nutenc: Do not call memcmp()
with NULL argument".
You could also mention that this affected lots of fate-tests. And "easer"
is missing an "i".
I have no objections apart from that. I didn't test your code, but it looks
fine.

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

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

Re: [FFmpeg-devel] [PATCH] lavc/qsv: improve the default GPU memory usage

[Zhong Li]

> A large initial_pool_size leads to redundant GPU memory allocations
> compared with MSDK.
>
> For some special cases which needs larger GPU memory like look_ahead,
> add -extra_hw_frames to allocate more.
>
> CMD:
> ffmpeg -hwaccel qsv -extra_hw_frames 50 -c:v hevc_qsv -i hevc.h265 -c:v 
> h264_qsv
> -look_ahead 1 -look_ahead_depth 50 -y output.h264
>
> Fix #7943.
>
> Reported-by: Eero T
> Signed-off-by: Linjie Fu 
> ---
>  fftools/ffmpeg_qsv.c | 2 +-
>  libavcodec/qsvdec.c  | 5 -
>  libavcodec/qsvenc_h264.c | 4 ++--
>  3 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/fftools/ffmpeg_qsv.c b/fftools/ffmpeg_qsv.c
> index 9c4285b..5039a5a 100644
> --- a/fftools/ffmpeg_qsv.c
> +++ b/fftools/ffmpeg_qsv.c
> @@ -93,7 +93,7 @@ int qsv_init(AVCodecContext *s)
>  frames_ctx->height= FFALIGN(s->coded_height, 32);
>  frames_ctx->format= AV_PIX_FMT_QSV;
>  frames_ctx->sw_format = s->sw_pix_fmt;
> -frames_ctx->initial_pool_size = 64 + s->extra_hw_frames;
> +frames_ctx->initial_pool_size = 24 + s->extra_hw_frames;

Should be better add pool size when look_ahead is enabled.

E:g
initial_pool_size = 24 + look_head_depth + s->extra_hw_frames;

you can set a default look_ahead_depth when look_ahead is enabled bu
no depth specified.

>  frames_hwctx->frame_type  = MFX_MEMTYPE_VIDEO_MEMORY_DECODER_TARGET;
>
>  ret = av_hwframe_ctx_init(ist->hw_frames_ctx);
> diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> index 0d34021..407e6de 100644
> --- a/libavcodec/qsvdec.c
> +++ b/libavcodec/qsvdec.c
> @@ -300,8 +300,11 @@ static int alloc_frame(AVCodecContext *avctx, QSVContext 
> *q, QSVFrame *frame)
>  else
>  ret = ff_get_buffer(avctx, frame->frame, AV_GET_BUFFER_FLAG_REF);
>
> -if (ret < 0)
> +if (ret < 0) {
> +av_log(avctx, AV_LOG_ERROR, "More memory in need, "
> +"try -extra_hw_frames to allocate more.\n");
>  return ret;
> +}
>
>  if (frame->frame->format == AV_PIX_FMT_QSV) {
>  frame->surface = *(mfxFrameSurface1*)frame->frame->data[3];
> diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
> index 27f36b9..4e8035b 100644
> --- a/libavcodec/qsvenc_h264.c
> +++ b/libavcodec/qsvenc_h264.c
> @@ -112,8 +112,8 @@ static const AVOption options[] = {
>  { "max_dec_frame_buffering", "Maximum number of frames buffered in the 
> DPB", OFFSET(qsv.max_dec_frame_buffering), AV_OPT_TYPE_INT, { .i64 = 0 },   
> 0, UINT16_MAX, VE },
>
>  #if QSV_HAVE_LA
> -{ "look_ahead",   "Use VBR algorithm with look ahead",
> OFFSET(qsv.look_ahead),   AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE },
> -{ "look_ahead_depth", "Depth of look ahead in number frames", 
> OFFSET(qsv.look_ahead_depth), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 100, VE },
> +{ "look_ahead",   "Use VBR algorithm with look ahead, 
> extra_hw_frames is needed",OFFSET(qsv.look_ahead),   AV_OPT_TYPE_INT, 
> { .i64 = 0 }, 0, 1, VE },
> +{ "look_ahead_depth", "Depth of look ahead in number frames, 
> extra_hw_frames is needed", OFFSET(qsv.look_ahead_depth), AV_OPT_TYPE_INT, { 
> .i64 = 0 }, 0, 100, VE },

No need to update the message if follow comments above.
___
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] frame: handle add side data with the same type

[zhilizhao(赵志立)]

Ping for review, thanks!

> On Oct 25, 2019, at 1:00 PM, quinkbl...@foxmail.com wrote:
> 
> From: Zhao Zhili 
> 
> ---
> libavutil/frame.c | 13 +
> 1 file changed, 13 insertions(+)
> 
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index dcf1fc3d17..bb20e99331 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -692,10 +692,23 @@ AVFrameSideData 
> *av_frame_new_side_data_from_buf(AVFrame *frame,
>  AVBufferRef *buf)
> {
> AVFrameSideData *ret, **tmp;
> +int i;
> 
> if (!buf)
> return NULL;
> 
> +for (i = 0; i < frame->nb_side_data; i++) {
> +AVFrameSideData *sd = frame->side_data[i];
> +if (sd->type == type) {
> +av_buffer_unref(&sd->buf);
> +av_dict_free(&sd->metadata);
> +sd->buf = buf;
> +sd->data = buf->data;
> +sd->size = buf->size;
> +return sd;
> +}
> +}
> +
> if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1)
> return NULL;
> 
> -- 
> 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".

[FFmpeg-devel] [PATCH] avformat/nutenc: Do not pass NULL to memcmp() in get_needed_flags()

[Michael Niedermayer]

This compared to the other suggestions is cleaner and easer to understand
keeping the condition in the if() simple

See: [FFmpeg-devel] [PATCH] avformat/nutenc: Fix memleak
See: [FFmpeg-devel] [PATCH]lavf/nutenc: Do not call memcmp() with NULL argument

Fixes: Ticket 7980

Signed-off-by: Michael Niedermayer 
---
 libavformat/nutenc.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
index d212f0c245..46dce7722d 100644
--- a/libavformat/nutenc.c
+++ b/libavformat/nutenc.c
@@ -792,11 +792,12 @@ static int get_needed_flags(NUTContext *nut, 
StreamContext *nus, FrameCode *fc,
 flags |= FLAG_CHECKSUM;
 if (FFABS(pkt->pts - nus->last_pts) > nus->max_pts_distance)
 flags |= FLAG_CHECKSUM;
-if (pkt->size < nut->header_len[fc->header_idx] ||
-(pkt->size > 4096 && fc->header_idx)||
-memcmp(pkt->data, nut->header[fc->header_idx],
-   nut->header_len[fc->header_idx]))
-flags |= FLAG_HEADER_IDX;
+if (fc->header_idx)
+if (pkt->size < nut->header_len[fc->header_idx] ||
+pkt->size > 4096||
+memcmp(pkt->data, nut->header[fc->header_idx],
+  nut->header_len[fc->header_idx]))
+flags |= FLAG_HEADER_IDX;
 
 return flags | (fc->flags & FLAG_CODED);
 }
-- 
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] doc/filters: fix overlay_opencl document typo

[Steven Liu]

> 在 2019年11月1日，17:10，Gyan  写道：
> 
> 
> 
> On 01-11-2019 02:15 PM, Steven Liu wrote:
>> Reported-by: Yabo Wei 
>> Signed-off-by: Steven Liu 
>> ---
>>  doc/filters.texi | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/doc/filters.texi b/doc/filters.texi
>> index 9d387be1f5..a6ff5037a6 100644
>> --- a/doc/filters.texi
>> +++ b/doc/filters.texi
>> @@ -20503,7 +20503,7 @@ Set the x coordinate of the overlaid video on the 
>> main video.
>>  Default value is @code{0}.
>>@item y
>> -Set the x coordinate of the overlaid video on the main video.
>> +Set the y coordinate of the overlaid video on the main video.
>>  Default value is @code{0}.
>>@end table
> 
> LGTM.
Applied.
> 
> Gyan
> ___
> 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
Steven





___
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 05/11] avformat/nutenc: Don't pass NULL to memcmp

[Michael Niedermayer]

On Thu, Oct 31, 2019 at 07:38:00AM +, Andreas Rheinhardt wrote:
> Andreas Rheinhardt:
> > Carl Eugen Hoyos:
> >> Am Fr., 20. Sept. 2019 um 00:30 Uhr schrieb Andreas Rheinhardt
> >> :
> >>>
> >>> Fixes lots of FATE tests, e.g. lavf-nut, as well as the nut part of
> >>> ticket #7980.
> >>>
> >>> Signed-off-by: Andreas Rheinhardt 
> >>> ---
> >>> This patch is made to match the previous behaviour; whether the previous
> >>> behaviour is correct at all if the header length is zero is unknown to
> >>> me.
> >>>
> >>>  libavformat/nutenc.c | 5 +++--
> >>>  1 file changed, 3 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
> >>> index e9a3bb49db..dc714eb809 100644
> >>> --- a/libavformat/nutenc.c
> >>> +++ b/libavformat/nutenc.c
> >>> @@ -791,8 +791,9 @@ static int get_needed_flags(NUTContext *nut, 
> >>> StreamContext *nus, FrameCode *fc,
> >>>  flags |= FLAG_CHECKSUM;
> >>>  if (pkt->size < nut->header_len[fc->header_idx] ||
> >>>  (pkt->size > 4096 && fc->header_idx)||
> >>> -memcmp(pkt->data, nut->header[fc->header_idx],
> >>> -   nut->header_len[fc->header_idx]))
> >>> +(nut->header_len[fc->header_idx] > 0 &&
> >>> + memcmp(pkt->data, nut->header[fc->header_idx],
> >>> +nut->header_len[fc->header_idx])))
> >>>  flags |= FLAG_HEADER_IDX;
> >>
> >> Is this different from the patch I sent?
> >> (Why does it look different)
> >> https://patchwork.ffmpeg.org/patch/13782/
> >>
> >> Carl Eugen
> > 
> > Yes.
> > a) Your patch checks whether nut->header[fc->header_idx] is NULL.
> > b) Michael's proposal is to check for fc->header_idx instead. This
> > would work, because it is the index of the only used pointer in
> > nut->header that is NULL, and this proposal has the advantage of one
> > dereferencing less than a).
> > c) My* patch checks whether nut->header_len[fc->header_idx] is zero.
> > Given that nut->header_len[fc->header_idx] is already used in the very
> > first check, my solution should not entail a dereference at all.
> > 
> > Furthermore, b) is very specific to the nutenc situation here and a)
> > might hide a situation where nut->header_len[fc->header_idx] is > 0,
> > but nut->header[fc->header_idx] == NULL, which should of course not
> > happen. And it singles out one of the two pointer arguments.
> > 
> > - Andreas
> > 
> > *: It is also what Reimar proposed (I was completely unaware of the
> > earlier patch when I submitted mine).
> > 
> Ping.

I dont think the resulting code is particularly readable with the
increasingly complex condition in the if()

ill post a alternative suggestion for consideration that has a simpler
condition after testing it

thx

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

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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] doc/filters: fix overlay_opencl document typo

[Gyan]

On 01-11-2019 02:15 PM, Steven Liu wrote:

Reported-by: Yabo Wei 
Signed-off-by: Steven Liu 
---
  doc/filters.texi | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 9d387be1f5..a6ff5037a6 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -20503,7 +20503,7 @@ Set the x coordinate of the overlaid video on the main 
video.
  Default value is @code{0}.
  
  @item y

-Set the x coordinate of the overlaid video on the main video.
+Set the y coordinate of the overlaid video on the main video.
  Default value is @code{0}.
  
  @end table


LGTM.

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

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

[FFmpeg-devel] [PATCH] avcodec/libtwolame: fix mono default bitrate

[James Cowgill]

As of libtwolame 0.4.0, 384 kbps is not accepted as a valid bitrate
for encoding mono audio and the maximum bitrate is now halved to 192
kbps to comply with the MP2 standard. Example error:

twolame_init_params(): 384kbps is an invalid bitrate for mono encoding.

Adjust the default bitrate calculation to take this into account.

Signed-off-by: James Cowgill 
---
 libavcodec/libtwolame.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libavcodec/libtwolame.c b/libavcodec/libtwolame.c
index 030f88868f..5ceb3d9f3f 100644
--- a/libavcodec/libtwolame.c
+++ b/libavcodec/libtwolame.c
@@ -78,8 +78,12 @@ static av_cold int twolame_encode_init(AVCodecContext *avctx)
 twolame_set_in_samplerate(s->glopts, avctx->sample_rate);
 twolame_set_out_samplerate(s->glopts, avctx->sample_rate);
 
-if (!avctx->bit_rate)
-avctx->bit_rate = avctx->sample_rate < 28000 ? 16 : 384000;
+if (!avctx->bit_rate) {
+if ((s->mode == TWOLAME_AUTO_MODE && avctx->channels == 1) || s->mode 
== TWOLAME_MONO)
+avctx->bit_rate = avctx->sample_rate < 28000 ? 8 : 192000;
+else
+avctx->bit_rate = avctx->sample_rate < 28000 ? 16 : 384000;
+}
 
 if (avctx->flags & AV_CODEC_FLAG_QSCALE || !avctx->bit_rate) {
 twolame_set_VBR(s->glopts, TRUE);
-- 
2.24.0.rc1

___
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] doc/filters: fix overlay_opencl document typo

[Steven Liu]

Reported-by: Yabo Wei 
Signed-off-by: Steven Liu 
---
 doc/filters.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 9d387be1f5..a6ff5037a6 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -20503,7 +20503,7 @@ Set the x coordinate of the overlaid video on the main 
video.
 Default value is @code{0}.
 
 @item y
-Set the x coordinate of the overlaid video on the main video.
+Set the y coordinate of the overlaid video on the main video.
 Default value is @code{0}.
 
 @end table
-- 
2.15.1



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

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

Re: [FFmpeg-devel] [PATCH 3/8] avcodec/utils: Check block_align

[Paul B Mahol]

LGTM

On 10/31/19, Michael Niedermayer  wrote:
> Fixes: out of array access
> Fixes:
> 18432/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMAV2_fuzzer-5675574936207360
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/utils.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 6cc770b1ea..75e7035b8a 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -694,6 +694,11 @@ int attribute_align_arg avcodec_open2(AVCodecContext
> *avctx, const AVCodec *code
>  ret = AVERROR(EINVAL);
>  goto free_and_end;
>  }
> +if (avctx->block_align < 0) {
> +av_log(avctx, AV_LOG_ERROR, "Invalid block align: %d\n",
> avctx->block_align);
> +ret = AVERROR(EINVAL);
> +goto free_and_end;
> +}
>
>  avctx->codec = codec;
>  if ((avctx->codec_type == AVMEDIA_TYPE_UNKNOWN || avctx->codec_type ==
> codec->type) &&
> --
> 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".