Re: [FFmpeg-devel] [PATCH 1/7] avcodec/vc1: Check for excessive resolution

[Paul B Mahol]

On Mon, Aug 19, 2019 at 8:17 AM Jean-Baptiste Kempf  wrote:

> You need to explain why. A "NAK" is not enough.
>
> 16k pixels x 16k is a large size already for vc1.
>

And for any other codecs


>
> On Sun, Aug 18, 2019, at 12:45, Paul B Mahol wrote:
> > NAK
> >
> > On Thu, Aug 15, 2019 at 11:51 PM Michael Niedermayer
> 
> > wrote:
> >
> > > Fixes: overflow in aspect ratio calculation
> > > Fixes: signed integer overflow: 393215 * 14594 cannot be represented in
> > > type 'int'
> > > Fixes:
> > >
> 15728/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMV3IMAGE_fuzzer-5661588893204480
> > >
> > > Found-by: continuous fuzzing process
> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by
> > > <
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by
> >:
> > > Michael Niedermayer 
> > > ---
> > >  libavcodec/vc1dec.c | 5 +
> > >  1 file changed, 5 insertions(+)
> > >
> > > diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c
> > > index 9519864c55..2636ea701f 100644
> > > --- a/libavcodec/vc1dec.c
> > > +++ b/libavcodec/vc1dec.c
> > > @@ -426,6 +426,11 @@ static av_cold int vc1_decode_init(AVCodecContext
> > > *avctx)
> > >  GetBitContext gb;
> > >  int ret;
> > >
> > > +if (avctx->width > 1 << 14 || avctx->height > 1 << 14) {
> > > +avpriv_request_sample(avctx, "Huge resolution");
> > > +return AVERROR_PATCHWELCOME;
> > > +}
> > > +
> > >  /* save the container output size for WMImage */
> > >  v->output_width  = avctx->width;
> > >  v->output_height = avctx->height;
> > > --
> > > 2.22.1
> > >
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > > To unsubscribe, visit link above, or email
> > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
> --
> Jean-Baptiste Kempf -  President
> +33 672 704 734
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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/7] avcodec/vc1: Check for excessive resolution

[Jean-Baptiste Kempf]

On Mon, Aug 19, 2019, at 09:45, Paul B Mahol wrote:
> On Mon, Aug 19, 2019 at 8:17 AM Jean-Baptiste Kempf  wrote:
> 
> > You need to explain why. A "NAK" is not enough.
> >
> > 16k pixels x 16k is a large size already for vc1.
> >
> 
> And for any other codecs

Sure.
In VLC we limit to 8k x 8k for all codecs.

But what is your counter-proposal?

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/7] avcodec/vc1: Check for excessive resolution

[Paul B Mahol]

On Mon, Aug 19, 2019 at 9:46 AM Jean-Baptiste Kempf  wrote:

>
>
> On Mon, Aug 19, 2019, at 09:45, Paul B Mahol wrote:
> > On Mon, Aug 19, 2019 at 8:17 AM Jean-Baptiste Kempf 
> wrote:
> >
> > > You need to explain why. A "NAK" is not enough.
> > >
> > > 16k pixels x 16k is a large size already for vc1.
> > >
> >
> > And for any other codecs
>
> Sure.
> In VLC we limit to 8k x 8k for all codecs.
>
> But what is your counter-proposal?
>
>
To leave this code as is.


> --
> Jean-Baptiste Kempf -  President
> +33 672 704 734
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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] [CALL] New FFmpeg developers meeting

[Liu Steven]

> 在 2019年8月19日，下午2:18，Jean-Baptiste Kempf  写道：
> 
> On Sat, Aug 17, 2019, at 11:48, Paul B Mahol wrote:
>> When and how to organize this?
> 
> You have the choice:
> - IBC
> - GSoC summit
> - VDD

And welcome to LiveVideoStack at China.

Jun Zhao, Zhong Li and some developers are here :D
> 
> Best,
> 
> -- 
> Jean-Baptiste Kempf -  President
> +33 672 704 734
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".



___
ffmpeg-devel 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/8] avcodec/cinepak: Require 1 bit per 4x4 block as minimum input

[Tomas Härdin]

sön 2019-08-18 klockan 19:04 +0200 skrev Michael Niedermayer:
> On Sun, Aug 18, 2019 at 02:49:39PM +0200, Tomas Härdin wrote:
> > sön 2019-08-18 klockan 14:18 +0200 skrev Michael Niedermayer:
> > > On Sun, Aug 18, 2019 at 01:40:01PM +0200, Tomas Härdin wrote:
> > > > sön 2019-08-18 klockan 12:19 +0200 skrev Michael Niedermayer:
> > > > > On Sun, Aug 18, 2019 at 12:00:45PM +0200, Paul B Mahol wrote:
> > > > > > On Sun, Aug 18, 2019 at 11:44 AM Michael Niedermayer 
> > > > > > 
> > > > > > > and yes i too wish there was a magic fix but i think most things 
> > > > > > > that
> > > > > > > look like magic fixes have a fatal flaw. But maybe iam missing 
> > > > > > > something
> > > > > > > in fact i hope that iam missing something and that there is a 
> > > > > > > magic fix
> > > > > > > 
> > > > > > 
> > > > > > Magic fix is enabling reference counted frames in fuzzer.
> > > > > 
> > > > > That is covered by the part below which you maybe did not read
> > > > > 
> > > > > > > PS: if you think of changing the API, i dont think its the API.
> > > > > > > I mean every user application will read the frames it receives, so
> > > > > > > even if inside the decoder we just return the same frame with 2 
> > > > > > > pixels
> > > > > > > different the user doesnt know this and has to read the whole 
> > > > > > > frame.
> > > > > > > The problem is moved around but its still there.
> > > > 
> > > > Copying is still slower than not copying. Enabling refcounting fixes
> > > > the timeout issue here, and will likely silence a whole bunch of false
> > > > positives for this class of files.
> > > 
> > > it makes probably sense to enable ref counting but we should
> > > immedeatly in the next or a previous commit make the fuzzer read the 
> > > frames
> > > from the  decoder. Thats what basically every user app would do.
> > > Otherwise we would have a bunch of issues closed and then reopened
> > > later.
> > 
> > Why should we care how much work the user does? We're fuzzing lavc
> > here, not user programs. Certain use cases are decode-only (ffprobe
> > -show_frames for example)
> 
> thats a valid point of view
> 
> The user though has few options if she gets many frames, she can just
> continue processing or stop, she doesnt know how (in)valid the stream is

This is way too abstract. Who is this user, specifically? If we were
talking about ffmpeg, handbrake, peertube or something else then we
could actually help them if they're using the API incorrectly. Worrying
about hypotheticals is a waste of time. You can't test them.

> OTOH libavcodec knows the codec bitstream, and can check various things
> 
> so just moving the responsibility to the user app would move it where
> its much harder to fix well
> That is currently, we could export all kinds of metadata about the
> amount of errors. Then a user app could decide what to do.
> It would become duplicated code between user apps though...

No one outside of forensics or satellite TV is going to care about
that, and if they do they can pay for it, and we can maintain tests for
it. It's not hard for a user to add checks like "if resolution > 3840 ×
 2160 then reject the file", which makes a lot of these fuzzy "anti-
DoS" patches pointless busywork. It just causes developer fatigue.

/Tomas

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

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

Re: [FFmpeg-devel] [PATCH 1/7] avcodec/vc1: Check for excessive resolution

[Tomas Härdin]

mån 2019-08-19 klockan 08:17 +0200 skrev Jean-Baptiste Kempf:
> You need to explain why. A "NAK" is not enough.
> 
> 16k pixels x 16k is a large size already for vc1.

Why not fix the calculation? 16K is a thing, and larger resolutions are
inevitable..

/Tomas

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

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

Re: [FFmpeg-devel] [PATCH v2 1/3] avfilter: add v360 filter

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Paul B Mahol
> Sent: Wednesday, August 14, 2019 5:38 PM
> To: FFmpeg development discussions and patches
> 
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/3] avfilter: add v360 filter
> 
> On Wed, Aug 14, 2019 at 9:01 AM Li, Zhong  wrote:
> 
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > > Of Eugene Lyapustin
> > > Sent: Wednesday, August 14, 2019 9:14 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: [FFmpeg-devel] [PATCH v2 1/3] avfilter: add v360 filter
> > >
> > > Signed-off-by: Eugene Lyapustin 
> > > ---
> > >  doc/filters.texi |  137 +++
> > >  libavfilter/Makefile |1 +
> > >  libavfilter/allfilters.c |1 +
> > >  libavfilter/vf_v360.c| 1847
> > > ++
> >
> > Probably you also want to update the Changelog?
> >
> 
> That is job for comitter.

Patch set merged but without changelog update. 
___
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] lavc/qsvdec: Replace current parser with MFXVideoDECODE_DecodeHeader()

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Li, Zhong
> Sent: Thursday, August 15, 2019 3:43 PM
> To: FFmpeg development discussions and patches
> 
> Cc: Rogozhkin, Dmitry V 
> Subject: Re: [FFmpeg-devel] [PATCH 3/6] lavc/qsvdec: Replace current parser
> with MFXVideoDECODE_DecodeHeader()
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Zhong Li
> > Sent: Tuesday, August 13, 2019 2:11 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Li, Zhong ; Rogozhkin, Dmitry V
> > 
> > Subject: [FFmpeg-devel] [PATCH 3/6] lavc/qsvdec: Replace current
> > parser with MFXVideoDECODE_DecodeHeader()
> >
> > Using MSDK parser can improve qsv decoder pass rate in some cases (E.g:
> > sps declares a wrong level_idc, smaller than it should be).
> > And it is necessary for adding new qsv decoders such as MJPEG and VP9
> > since current parser can't provide enough information.
> > Actually using MFXVideoDECODE_DecodeHeader() was disscussed at
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/175734.html and
> > merged as commit 1acb19d, but was overwritten when merged libav
> > patches
> > (commit: 1f26a23) without any explain.
> >
> > Split decode header from decode_init, and call it for everyframe to
> > detect format/resoultion change. It can fix some regression issues
> > such as hevc 10bits decoding.
> >
> > Signed-off-by: Zhong Li 
> > Signed-off-by: Dmitry Rogozhkin 
> > ---
> >  libavcodec/qsvdec.c   | 184
> > --
> >  libavcodec/qsvdec.h   |   2 +
> >  libavcodec/qsvdec_h2645.c |   1 +
> >  libavcodec/qsvdec_other.c |   1 +
> >  4 files changed, 100 insertions(+), 88 deletions(-)
> >
> > diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c index
> > 46aa2d6..7e48c83 100644
> > --- a/libavcodec/qsvdec.c
> > +++ b/libavcodec/qsvdec.c
> > @@ -147,19 +147,21 @@ static int check_dec_param(AVCodecContext
> > *avctx, QSVContext *q, mfxVideoParam *
> >  return 1;
> >  }
> >
> > -static int qsv_decode_init(AVCodecContext *avctx, QSVContext *q)
> > +static int qsv_decode_preinit(AVCodecContext *avctx, QSVContext *q,
> > +enum AVPixelFormat pix_fmt, mfxVideoParam *param)
> >  {
> > -const AVPixFmtDescriptor *desc;
> >  mfxSession session = NULL;
> >  int iopattern = 0;
> > -mfxVideoParam param = { 0 };
> > -int frame_width  = avctx->coded_width;
> > -int frame_height = avctx->coded_height;
> >  int ret;
> > +enum AVPixelFormat pix_fmts[3] = {
> > +AV_PIX_FMT_QSV, /* opaque format in case of video memory
> > output */
> > +pix_fmt,/* system memory format obtained from
> > bitstream parser */
> > +AV_PIX_FMT_NONE };
> >
> > -desc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
> > -if (!desc)
> > -return AVERROR_BUG;
> > +ret = ff_get_format(avctx, pix_fmts);
> > +if (ret < 0) {
> > +q->orig_pix_fmt = avctx->pix_fmt = AV_PIX_FMT_NONE;
> > +return ret;
> > +}
> >
> >  if (!q->async_fifo) {
> >  q->async_fifo = av_fifo_alloc(q->async_depth *
> > qsv_fifo_item_size()); @@ -197,54 +199,72 @@ static int
> > qsv_decode_init(AVCodecContext *avctx, QSVContext *q)
> >  return ret;
> >  }
> >
> > -ret = ff_qsv_codec_id_to_mfx(avctx->codec_id);
> > -if (ret < 0)
> > -return ret;
> > +param->IOPattern   = q->iopattern;
> > +param->AsyncDepth  = q->async_depth;
> > +param->ExtParam= q->ext_buffers;
> > +param->NumExtParam = q->nb_ext_buffers;
> >
> > -param.mfx.CodecId  = ret;
> > -param.mfx.CodecProfile = ff_qsv_profile_to_mfx(avctx->codec_id,
> > avctx->profile);
> > -param.mfx.CodecLevel   = ff_qsv_level_to_mfx(avctx->codec_id,
> > avctx->level);
> > -
> > -param.mfx.FrameInfo.BitDepthLuma   = desc->comp[0].depth;
> > -param.mfx.FrameInfo.BitDepthChroma = desc->comp[0].depth;
> > -param.mfx.FrameInfo.Shift  = desc->comp[0].depth > 8;
> > -param.mfx.FrameInfo.FourCC = q->fourcc;
> > -param.mfx.FrameInfo.Width  = frame_width;
> > -param.mfx.FrameInfo.Height = frame_height;
> > -param.mfx.FrameInfo.ChromaFormat   =
> > MFX_CHROMAFORMAT_YUV420;
> > -
> > -switch (avctx->field_order) {
> > -case AV_FIELD_PROGRESSIVE:
> > -param.mfx.FrameInfo.PicStruct =
> > MFX_PICSTRUCT_PROGRESSIVE;
> > -break;
> > -case AV_FIELD_TT:
> > -param.mfx.FrameInfo.PicStruct = MFX_PICSTRUCT_FIELD_TFF;
> > -break;
> > -case AV_FIELD_BB:
> > -param.mfx.FrameInfo.PicStruct = MFX_PICSTRUCT_FIELD_BFF;
> > -break;
> > -default:
> > -param.mfx.FrameInfo.PicStruct = MFX_PICSTRUCT_UNKNOWN;
> > -break;
> > -}
> > +return 0;
> > + }
> >
> > -param.IOPattern   = q->iopattern;
> > -param.AsyncDepth  = q->async_depth;
> > -param.ExtParam= q->ext_buffers;
> > -param.NumExtParam = q->nb_ext_buffers;
> > +static int qsv

Re: [FFmpeg-devel] [PATCH 1/7] avcodec/vc1: Check for excessive resolution

[Jean-Baptiste Kempf]

On Mon, Aug 19, 2019, at 11:02, Tomas Härdin wrote:
> mån 2019-08-19 klockan 08:17 +0200 skrev Jean-Baptiste Kempf:
> > You need to explain why. A "NAK" is not enough.
> > 
> > 16k pixels x 16k is a large size already for vc1.
> 
> Why not fix the calculation? 16K is a thing, and larger resolutions are
> inevitable..

16K is not 16K * 16K. Also, VC1 does not support those resolution.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/7] avcodec/vc1: Check for excessive resolution

[Tomas Härdin]

mån 2019-08-19 klockan 11:19 +0200 skrev Jean-Baptiste Kempf:
> 
> On Mon, Aug 19, 2019, at 11:02, Tomas Härdin wrote:
> > mån 2019-08-19 klockan 08:17 +0200 skrev Jean-Baptiste Kempf:
> > > You need to explain why. A "NAK" is not enough.
> > > 
> > > 16k pixels x 16k is a large size already for vc1.
> > 
> > Why not fix the calculation? 16K is a thing, and larger resolutions
> > are
> > inevitable..
> 
> 16K is not 16K * 16K. Also, VC1 does not support those resolution.

Why not use max_coded_width/height then? Seems vc1.c limits both to
[2,8192]

/Tomas

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

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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/alsdec: Limit maximum channels to 64

[Michael Niedermayer]

On Mon, Aug 19, 2019 at 07:41:43AM +0200, Thilo Borgmann wrote:
> Am 19.08.19 um 01:30 schrieb Michael Niedermayer:
> > There seems to be no limit in the specification and upto 64k could be stored
> > 64 is chooses as limit as thats also used for AAC and is what a int64 mask
> > can handle
> > 
> > An alternative to this patch would be a max_channels variable
> 
> There's a conformance file containing 512 channels, that should be the 
> default max value.

will apply with that value later

thanks

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

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA


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/3] avcodec/alsdec: Limit maximum channels to 64

[Michael Niedermayer]

On Mon, Aug 19, 2019 at 07:41:43AM +0200, Thilo Borgmann wrote:
> Am 19.08.19 um 01:30 schrieb Michael Niedermayer:
> > There seems to be no limit in the specification and upto 64k could be stored
> > 64 is chooses as limit as thats also used for AAC and is what a int64 mask
> > can handle
> > 
> > An alternative to this patch would be a max_channels variable
> 
> There's a conformance file containing 512 channels, that should be the 
> default max value.

can you add a fate test with that sample ?

thanks

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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 V1 5/5] lavf/hlsenc: free the old_filname to avoid memory leak

[Jun Zhao]

From: Jun Zhao 

free the old_filname to avoid memory leak in error handle
path.

Signed-off-by: Jun Zhao 
---
 libavformat/hlsenc.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index f6f9c81..9099c84 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2428,6 +2428,7 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 // if we're building a VOD playlist, skip writing the manifest 
multiple times, and just wait until the end
 if (hls->pl_type != PLAYLIST_TYPE_VOD) {
 if ((ret = hls_window(s, 0, vs)) < 0) {
+av_free(old_filename);
 return ret;
 }
 }
-- 
1.7.1

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

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

[FFmpeg-devel] [PATCH V1 2/5] lavfi/avfiltergraph: add check before free the format

[Jun Zhao]

From: Jun Zhao 

ff_merge_samplerates will be deallocate a or b in some case, so
add a check before free the format.

Signed-off-by: Jun Zhao 
---
 libavfilter/avfiltergraph.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c
index a149f8f..2fe4f0b 100644
--- a/libavfilter/avfiltergraph.c
+++ b/libavfilter/avfiltergraph.c
@@ -419,8 +419,10 @@ static int can_merge_formats(AVFilterFormats *a_arg,
 av_freep(&ret);
 return 1;
 } else {
-av_freep(&a->formats);
-av_freep(&b->formats);
+if (a)
+av_freep(&a->formats);
+if (b)
+av_freep(&b->formats);
 av_freep(&a);
 av_freep(&b);
 return 0;
-- 
1.7.1

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

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

[FFmpeg-devel] [PATCH V1 1/5] lavfi/af_adeclick: fix double free after ff_filter_frame fail

[Jun Zhao]

From: Jun Zhao 

ff_filter_frame fail will free the frame, so we just returen after this
function fail.

Signed-off-by: Jun Zhao 
---
 libavfilter/af_adeclick.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libavfilter/af_adeclick.c b/libavfilter/af_adeclick.c
index 50eef74..2c42f97 100644
--- a/libavfilter/af_adeclick.c
+++ b/libavfilter/af_adeclick.c
@@ -592,7 +592,7 @@ static int filter_frame(AVFilterLink *inlink)
 
 ret = ff_filter_frame(outlink, out);
 if (ret < 0)
-goto fail;
+return ret;
 
 if (s->samples_left > 0) {
 s->samples_left -= s->hop_size;
-- 
1.7.1

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

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

[FFmpeg-devel] [PATCH V1 4/5] lavfi/dnn/dnn_backend_native: fix memory leak in error path

[Jun Zhao]

From: Jun Zhao 

fix memory leak in error path

Signed-off-by: Jun Zhao 
---
 libavfilter/dnn/dnn_backend_native.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/libavfilter/dnn/dnn_backend_native.c 
b/libavfilter/dnn/dnn_backend_native.c
index 7b489d0..2619463 100644
--- a/libavfilter/dnn/dnn_backend_native.c
+++ b/libavfilter/dnn/dnn_backend_native.c
@@ -183,6 +183,7 @@ DNNModel *ff_dnn_load_model_native(const char 
*model_filename)
 if (dnn_size > file_size || conv_params->input_num <= 0 ||
 conv_params->output_num <= 0 || conv_params->kernel_size <= 0){
 avio_closep(&model_file_context);
+av_freep(&conv_params);
 ff_dnn_free_model_native(&model);
 return NULL;
 }
@@ -190,6 +191,9 @@ DNNModel *ff_dnn_load_model_native(const char 
*model_filename)
 conv_params->biases = av_malloc(conv_params->output_num * 
sizeof(float));
 if (!conv_params->kernel || !conv_params->biases){
 avio_closep(&model_file_context);
+av_freep(&conv_params->kernel);
+av_freep(&conv_params->biases);
+av_freep(&conv_params);
 ff_dnn_free_model_native(&model);
 return NULL;
 }
-- 
1.7.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 V1 2/5] lavfi/avfiltergraph: add check before free the format

[Paul B Mahol]

LGTM

On Mon, Aug 19, 2019 at 3:08 PM Jun Zhao  wrote:

> From: Jun Zhao 
>
> ff_merge_samplerates will be deallocate a or b in some case, so
> add a check before free the format.
>
> Signed-off-by: Jun Zhao 
> ---
>  libavfilter/avfiltergraph.c |6 --
>  1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c
> index a149f8f..2fe4f0b 100644
> --- a/libavfilter/avfiltergraph.c
> +++ b/libavfilter/avfiltergraph.c
> @@ -419,8 +419,10 @@ static int can_merge_formats(AVFilterFormats *a_arg,
>  av_freep(&ret);
>  return 1;
>  } else {
> -av_freep(&a->formats);
> -av_freep(&b->formats);
> +if (a)
> +av_freep(&a->formats);
> +if (b)
> +av_freep(&b->formats);
>  av_freep(&a);
>  av_freep(&b);
>  return 0;
> --
> 1.7.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH V1 3/5] lavfi/dnn/dnn_backend_native: Refine the coding style

[Jun Zhao]

From: Jun Zhao 

We perfer the coding style like:

/* some stuff */
if (error) {
/* error handling */
return -(errorcode);
}
/* normal actions */
do_something()

Signed-off-by: Jun Zhao 
---
 libavfilter/dnn/dnn_backend_native.c |   24 +++-
 1 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/libavfilter/dnn/dnn_backend_native.c 
b/libavfilter/dnn/dnn_backend_native.c
index 09c583b..7b489d0 100644
--- a/libavfilter/dnn/dnn_backend_native.c
+++ b/libavfilter/dnn/dnn_backend_native.c
@@ -40,19 +40,17 @@ static DNNReturnType set_input_output_native(void *model, 
DNNInputData *input, c
 if (network->layers_num <= 0 || network->layers[0].type != INPUT){
 return DNN_ERROR;
 }
-else{
-input_params = (InputParams *)network->layers[0].params;
-input_params->width = cur_width = input->width;
-input_params->height = cur_height = input->height;
-input_params->channels = cur_channels = input->channels;
-if (input->data){
-av_freep(&input->data);
-}
-av_assert0(input->dt == DNN_FLOAT);
-network->layers[0].output = input->data = av_malloc(cur_height * 
cur_width * cur_channels * sizeof(float));
-if (!network->layers[0].output){
-return DNN_ERROR;
-}
+input_params = (InputParams *)network->layers[0].params;
+input_params->width = cur_width = input->width;
+input_params->height = cur_height = input->height;
+input_params->channels = cur_channels = input->channels;
+if (input->data){
+av_freep(&input->data);
+}
+av_assert0(input->dt == DNN_FLOAT);
+network->layers[0].output = input->data = av_malloc(cur_height * cur_width 
* cur_channels * sizeof(float));
+if (!network->layers[0].output){
+return DNN_ERROR;
 }
 
 for (layer = 1; layer < network->layers_num; ++layer){
-- 
1.7.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 V1 1/5] lavfi/af_adeclick: fix double free after ff_filter_frame fail

[Paul B Mahol]

LGTM

On Mon, Aug 19, 2019 at 3:08 PM Jun Zhao  wrote:

> From: Jun Zhao 
>
> ff_filter_frame fail will free the frame, so we just returen after this
> function fail.
>
> Signed-off-by: Jun Zhao 
> ---
>  libavfilter/af_adeclick.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libavfilter/af_adeclick.c b/libavfilter/af_adeclick.c
> index 50eef74..2c42f97 100644
> --- a/libavfilter/af_adeclick.c
> +++ b/libavfilter/af_adeclick.c
> @@ -592,7 +592,7 @@ static int filter_frame(AVFilterLink *inlink)
>
>  ret = ff_filter_frame(outlink, out);
>  if (ret < 0)
> -goto fail;
> +return ret;
>
>  if (s->samples_left > 0) {
>  s->samples_left -= s->hop_size;
> --
> 1.7.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avdevice/decklink: adjust for timecode lag

[Ilinca Tudose]

Hi Marton,

I want to confirm that we get correctly synced TCs when leaving out the
format_code parameter and using an ffmpeg build from head (not with Gyan's
patch). However, I was under the impression that we need the format_code so
that we can capture different content types, in the original format. For
example multiple frame rates or interlaced content. How would we set this
up if we are not using format_code? Is this identified automatically?

Thanks,
ilinca

On Sat, Aug 17, 2019 at 6:06 PM Gyan  wrote:

>
>
> On 17-08-2019 09:21 PM, Marton Balint wrote:
> >
> >
> > On Sat, 17 Aug 2019, Gyan wrote:
> >
> >>
> >>
> >> On 17-08-2019 08:42 PM, Marton Balint wrote:
> >>>
> >>>
> >>> On Wed, 14 Aug 2019, Marton Balint wrote:
> >>>
> 
> 
>  On Wed, 14 Aug 2019, Gyan wrote:
> 
> >
> >
> > On 09-08-2019 04:59 PM, Ilinca Tudose wrote:
> >> Hi Marton,
> >>
> >> The issue with the out of sync TC was reproducible on all tapes
> >> and decks
> >> that we tested. I don't have the exact number now, but a few
> >> dozens, less
> >> than 100. They all had between 7 and 17 frames out of sync. We
> >> were not
> >> able to obtain anything more in sync than 7 frames.
> >>
> >> The TC sync was tested by setting up the deck to "burn" the TC
> >> with the
> >> image while capturing the content with TC through ffmpeg. We then
> >> play the
> >> file in a player that supports timecodes and compare the
> >> burned-in TC with
> >> the one captured in the metadata.
> >>
> >> We used Decklink quad 2 and several Sony decks: J30, J3, JH3. We
> >> tested on
> >> multiple decks from each model and confirmed the issue was
> >> present + that
> >> Gyan's patch seemed to fix it. We have used several types of
> >> Betacam tapes
> >> and HDCAM tapes. I can not comment on whether this is the best
> >> solution,
> >> but can confirm it works.
> >>
> >> Let me know if you need more info.
> >>
> >> Thanks,
> >> ilinca
> >
> > Ping.
> 
>  Sorry, I need a bit more time to investigate.
> >>>
> >>> OK, I did a couple of tests myself for HD and SD pal signals, and it
> >>> seems to me if signal autodetection is used, so no format_code is
> >>> specified then timecode is readily available in the first frame. I
> >>> was using BlackMagic SDK 11.1 for testing by the way. Can you
> >>> confirm the same behaviour with your setup?
> >>
> >> So, were you able to reproduce the issue _with_  format_code specified?
> >
> > I was able to reproduce the part where after starting the capture the
> > decklink device records empty frames (with flag
> > bmdFrameHasNoInputSource set) for a couple of frames.
> >
> > I was not able to reproduce the part where the timecode was earlier or
> > later available then the first frame of the useful video signal.
>
> Ok, thanks. I'll get back when I have more info.
>
> 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".



-- 

---
Ilinca Tudose | Technical Solutions Consultant, Digitization Operations |
go/digitops 
Google Germany GmbH
Erika-Mann-Str. 33
80636 München

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Diese E-Mail ist
vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese
bitte nicht weiter, informieren Sie den Absender und löschen Sie die E-Mail
und alle Anhänge. Vielen Dank. This e-mail is confidential. If you are not
the right addressee please do not forward it, please inform the sender, and
please erase this e-mail including any attachments. Thanks. Der Inhalt
dieser E-Mail spiegelt den derzeitigen Stand der Verhandlungen wider und
dient als Basis für weitere Gespräche. Er soll keine rechtlich verbindliche
Verpflichtung begründen. Eine solche Verpflichtung wird allein durch einen
zwischen allen beteiligten Parteien abgeschlossenen, schriftlichen Vertrag
geschaffen. The above terms reflect a potential business arrangement, are
provided solely as a basis for further discussion, and are not intended to
be and do not constitute a legally binding obligation. No legally binding
obligations will be created, implied, or inferred until an agreement in
final form is executed in writing by all parties involved.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH V2 2/2] libavfilter/dnn/dnn_backend_tf: add tf.pad support for tensorflow backend with native model.

[Pedro Arthur]

Em qui, 15 de ago de 2019 às 23:41, Guo, Yejun  escreveu:
>
> Signed-off-by: Guo, Yejun 
> ---
>  libavfilter/dnn/dnn_backend_tf.c | 48 
> 
>  1 file changed, 19 insertions(+), 29 deletions(-)
>
> diff --git a/libavfilter/dnn/dnn_backend_tf.c 
> b/libavfilter/dnn/dnn_backend_tf.c
> index ca7434a..626fba9 100644
> --- a/libavfilter/dnn/dnn_backend_tf.c
> +++ b/libavfilter/dnn/dnn_backend_tf.c
> @@ -27,6 +27,7 @@
>  #include "dnn_backend_native.h"
>  #include "libavformat/avio.h"
>  #include "libavutil/avassert.h"
> +#include "dnn_backend_native_layer_pad.h"
>
>  #include 
>
> @@ -347,23 +348,8 @@ static DNNReturnType add_depth_to_space_layer(TFModel 
> *tf_model, TF_Operation **
>  return DNN_SUCCESS;
>  }
>
> -static int calculate_pad(const ConvolutionalNetwork *conv_network)
> -{
> -ConvolutionalParams *params;
> -int32_t layer;
> -int pad = 0;
> -
> -for (layer = 0; layer < conv_network->layers_num; ++layer){
> -if (conv_network->layers[layer].type == CONV){
> -params = (ConvolutionalParams 
> *)conv_network->layers[layer].params;
> -pad += params->kernel_size >> 1;
> -}
> -}
> -
> -return pad;
> -}
> -
> -static DNNReturnType add_pad_op(TFModel *tf_model, TF_Operation **cur_op, 
> const int32_t pad)
> +static DNNReturnType add_pad_layer(TFModel *tf_model, TF_Operation **cur_op,
> +  LayerPadParams *params, const 
> int layer)
>  {
>  TF_Operation *op;
>  TF_Tensor *tensor;
> @@ -372,16 +358,21 @@ static DNNReturnType add_pad_op(TFModel *tf_model, 
> TF_Operation **cur_op, const
>  int32_t *pads;
>  int64_t pads_shape[] = {4, 2};
>
> -input.index = 0;
> +char name_buffer[NAME_BUFFER_SIZE];
> +snprintf(name_buffer, NAME_BUFFER_SIZE, "pad%d", layer);
>
> -op_desc = TF_NewOperation(tf_model->graph, "Const", "pads");
> +op_desc = TF_NewOperation(tf_model->graph, "Const", name_buffer);
>  TF_SetAttrType(op_desc, "dtype", TF_INT32);
>  tensor = TF_AllocateTensor(TF_INT32, pads_shape, 2, 4 * 2 * 
> sizeof(int32_t));
>  pads = (int32_t *)TF_TensorData(tensor);
> -pads[0] = 0;   pads[1] = 0;
> -pads[2] = pad; pads[3] = pad;
> -pads[4] = pad; pads[5] = pad;
> -pads[6] = 0;   pads[7] = 0;
> +pads[0] = params->paddings[0][0];
> +pads[1] = params->paddings[0][1];
> +pads[2] = params->paddings[1][0];
> +pads[3] = params->paddings[1][1];
> +pads[4] = params->paddings[2][0];
> +pads[5] = params->paddings[2][1];
> +pads[6] = params->paddings[3][0];
> +pads[7] = params->paddings[3][1];
>  TF_SetAttrTensor(op_desc, "value", tensor, tf_model->status);
>  if (TF_GetCode(tf_model->status) != TF_OK){
>  return DNN_ERROR;
> @@ -393,6 +384,7 @@ static DNNReturnType add_pad_op(TFModel *tf_model, 
> TF_Operation **cur_op, const
>
>  op_desc = TF_NewOperation(tf_model->graph, "MirrorPad", "mirror_pad");
>  input.oper = *cur_op;
> +input.index = 0;
>  TF_AddInput(op_desc, input);
>  input.oper = op;
>  TF_AddInput(op_desc, input);
> @@ -418,7 +410,6 @@ static DNNReturnType load_native_model(TFModel *tf_model, 
> const char *model_file
>  int32_t *transpose_perm;
>  int64_t transpose_perm_shape[] = {4};
>  int64_t input_shape[] = {1, -1, -1, -1};
> -int32_t pad;
>  DNNReturnType layer_add_res;
>  DNNModel *native_model = NULL;
>  ConvolutionalNetwork *conv_network;
> @@ -429,7 +420,6 @@ static DNNReturnType load_native_model(TFModel *tf_model, 
> const char *model_file
>  }
>
>  conv_network = (ConvolutionalNetwork *)native_model->model;
> -pad = calculate_pad(conv_network);
>  tf_model->graph = TF_NewGraph();
>  tf_model->status = TF_NewStatus();
>
> @@ -448,10 +438,6 @@ static DNNReturnType load_native_model(TFModel 
> *tf_model, const char *model_file
>  CLEANUP_ON_ERROR(tf_model);
>  }
>
> -if (add_pad_op(tf_model, &op, pad) != DNN_SUCCESS){
> -CLEANUP_ON_ERROR(tf_model);
> -}
> -
>  op_desc = TF_NewOperation(tf_model->graph, "Const", "transpose_perm");
>  TF_SetAttrType(op_desc, "dtype", TF_INT32);
>  tensor = TF_AllocateTensor(TF_INT32, transpose_perm_shape, 1, 4 * 
> sizeof(int32_t));
> @@ -479,6 +465,10 @@ static DNNReturnType load_native_model(TFModel 
> *tf_model, const char *model_file
>  layer_add_res = add_depth_to_space_layer(tf_model, &op,
>   (DepthToSpaceParams 
> *)conv_network->layers[layer].params, layer);
>  break;
> +case MIRROR_PAD:
> +layer_add_res = add_pad_layer(tf_model, &op,
> +  (LayerPadParams 
> *)conv_network->layers[layer].params, layer);
> +break;
>  default:
>  CLEANUP_ON_ERROR(tf_model);
>  }
> --
> 2.7.4
>
LGTM.
Pushed, thanks.

> _

Re: [FFmpeg-devel] [PATCH V2 1/2] libavfilter/dnn/dnn_backend_tf: fix typo that variable uninitialized.

[Pedro Arthur]

Em qui, 15 de ago de 2019 às 23:40, Guo, Yejun  escreveu:
>
> if it is initialized randomly, the tensorflow lib will report
> error message such as:
> Attempt to add output -7920 of depth_to_space4 not in range [0, 1) to node 
> with type Identity
>
> Signed-off-by: Guo, Yejun 
> ---
>  libavfilter/dnn/dnn_backend_tf.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavfilter/dnn/dnn_backend_tf.c 
> b/libavfilter/dnn/dnn_backend_tf.c
> index ba959ae..ca7434a 100644
> --- a/libavfilter/dnn/dnn_backend_tf.c
> +++ b/libavfilter/dnn/dnn_backend_tf.c
> @@ -490,6 +490,7 @@ static DNNReturnType load_native_model(TFModel *tf_model, 
> const char *model_file
>
>  op_desc = TF_NewOperation(tf_model->graph, "Identity", "y");
>  input.oper = op;
> +input.index = 0;
>  TF_AddInput(op_desc, input);
>  TF_FinishOperation(op_desc, tf_model->status);
>  if (TF_GetCode(tf_model->status) != TF_OK){
> --
> 2.7.4
>
LGTM.
Pushed, 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".
___
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] FATE/dnn: let fate/dnn tests depend on ffmpeg static libraries

[Pedro Arthur]

Em sex, 16 de ago de 2019 às 11:20, Li, Zhong  escreveu:
>
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Guo, Yejun
> > Sent: Wednesday, August 7, 2019 10:44 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Guo, Yejun 
> > Subject: [FFmpeg-devel] [PATCH V2] FATE/dnn: let fate/dnn tests depend on
> > ffmpeg static libraries
> >
> > background:
> > DNN (deep neural network) is a sub module of libavfilter, and FATE/dnn is
> > unit test for the DNN module, one unit test for one dnn layer.
> > The unit tests are not based on the APIs exported by libavfilter, they just
> > directly call into the functions within DNN submodule.
> >
> > There is an issue when run the following command:
> > build$ ../ffmpeg/configure --disable-static --enable-shared make make
> > fate-dnn-layer-pad
> >
> > And part of error message:
> > tests/dnn/dnn-layer-pad-test.o: In function `test_with_mode_symmetric':
> > /work/media/ffmpeg/build/src/tests/dnn/dnn-layer-pad-test.c:73:
> > undefined reference to `dnn_execute_layer_pad'
> >
> > The root cause is that function dnn_execute_layer_pad is a LOCAL symbol in
> > libavfilter.so, and so the linker could not find it when build
> > dnn-layer-pad-test.
> > To check it, just run: readelf -s libavfilter/libavfilter.so | grep dnn
> >
> > So, add dependency in fate/dnn Makefile with ffmpeg static libraries.
> > This is the same method used in fate/checkasm
> >
> > Signed-off-by: Guo, Yejun 
> > ---
> >  tests/dnn/Makefile | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/tests/dnn/Makefile b/tests/dnn/Makefile index b2e6680..0e050ea
> > 100644
> > --- a/tests/dnn/Makefile
> > +++ b/tests/dnn/Makefile
> > @@ -4,8 +4,8 @@ DNNTESTOBJS  :=
> > $(DNNTESTOBJS:%=$(DNNTESTSDIR)%)
> > $(DNNTESTPROGS:%=$(DNNTESTSDIR)  DNNTESTPROGS :=
> > $(DNNTESTPROGS:%=$(DNNTESTSDIR)/%-test$(EXESUF))
> >  -include $(wildcard $(DNNTESTOBJS:.o=.d))
> >
> > -$(DNNTESTPROGS): %$(EXESUF): %.o $(FF_DEP_LIBS)
> > - $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^)
> > $(FF_EXTRALIBS) $(ELIBS)
> > +$(DNNTESTPROGS): %$(EXESUF): %.o $(FF_STATIC_DEP_LIBS)
> > + $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^)
> > +$(FF_STATIC_DEP_LIBS) $(ELIBS)
> >
> >  testclean::
> >   $(RM) $(addprefix $(DNNTESTSDIR)/,$(CLEANSUFFIXES)
> > *-test$(EXESUF))
> > --
> > 2.7.4
>
> LGTM && Verified
>
> IMHO this is a high priority patch since currently FATE is broken now if 
> build with dynamic link

Pushed, 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".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/alsdec: Limit maximum channels to 64

[Thilo Borgmann]

Am 19.08.19 um 14:27 schrieb Michael Niedermayer:
> On Mon, Aug 19, 2019 at 07:41:43AM +0200, Thilo Borgmann wrote:
>> Am 19.08.19 um 01:30 schrieb Michael Niedermayer:
>>> There seems to be no limit in the specification and upto 64k could be stored
>>> 64 is chooses as limit as thats also used for AAC and is what a int64 mask
>>> can handle
>>>
>>> An alternative to this patch would be a max_channels variable
>>
>> There's a conformance file containing 512 channels, that should be the 
>> default max value.
> 
> will apply with that value later

Decoding of that is already stopped via FF_SANE_NB_CHANNELS in lavc/internal.h.
That is currently set to 256U. I guess pushing that to 512U might already be 
enough without any change to single decoders?

Once fixed, I will add a FATE test for the 512 channel conformance file.

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

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

[FFmpeg-devel] [PATCH v7] avfilter/avf_aphasemeter: Add out-of-phase and mono detection

[Romane Lafon]

This patch extends aphasemeter to detect out of phase or mono sequences in
stereo streams, with its associated documentation.
From dce30e5a978ff5296fa1c0013bbd78fd27ecec2a Mon Sep 17 00:00:00 2001
From: Romane Lafon 
Date: Fri, 16 Aug 2019 14:14:11 +0200
Subject: [PATCH] avfilter/avf_aphasemeter: Add out-of-phase and mono detection

Signed-off-by: Romane Lafon 
---
 doc/filters.texi  |  33 ++
 libavfilter/avf_aphasemeter.c | 121 --
 2 files changed, 150 insertions(+), 4 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 01262d845e..5acd36a98c 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -20822,6 +20822,39 @@ Set color which will be used for drawing median phase. If color is
 Enable video output. Default is enabled.
 @end table
 
+@subsection phasing detection
+
+The filter also detects out of phase and mono sequences in stereo streams.
+It logs the sequence start, end and duration when it lasts longer or as long as the minimum set.
+
+The filter accepts the following options for this detection:
+
+@table @option
+@item phasing
+Enable mono and out of phase detection. Default is disabled.
+
+@item tolerance
+Set phase tolerance for mono detection, in amplitude ratio. Default is @code{0}.
+Allowed range is @code{[0, 1]}.
+
+@item angle
+Set angle threshold for out of phase detection, in degree. Default is @code{170}.
+Allowed range is @code{[0, 180]}.
+
+@item duration
+Set mono or out of phase duration until notification, expressed in seconds. Default is @code{2}.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Complete example with @command{ffmpeg} to detect 1 second of mono with 0.001 phase tolerance:
+@example
+ffmpeg -i stereo.wav -af aphasemeter=video=0:phasing=1:duration=1:tolerance=0.001 -f null -
+@end example
+@end itemize
+
 @section avectorscope
 
 Convert input audio to a video output, representing the audio vector
diff --git a/libavfilter/avf_aphasemeter.c b/libavfilter/avf_aphasemeter.c
index f497bc9969..b94cbbade6 100644
--- a/libavfilter/avf_aphasemeter.c
+++ b/libavfilter/avf_aphasemeter.c
@@ -28,26 +28,40 @@
 #include "libavutil/intreadwrite.h"
 #include "libavutil/opt.h"
 #include "libavutil/parseutils.h"
+#include "libavutil/timestamp.h"
 #include "avfilter.h"
 #include "formats.h"
 #include "audio.h"
 #include "video.h"
 #include "internal.h"
+#include "float.h"
 
 typedef struct AudioPhaseMeterContext {
 const AVClass *class;
 AVFrame *out;
 int do_video;
+int do_phasing_detection;
 int w, h;
 AVRational frame_rate;
 int contrast[4];
 uint8_t *mpc_str;
 uint8_t mpc[4];
 int draw_median_phase;
+int is_mono;
+int is_out_phase;
+int start_mono_presence;
+int start_out_phase_presence;
+float tolerance;
+float angle;
+float phase;
+float mono_idx[2];
+float out_phase_idx[2];
+double duration;
 } AudioPhaseMeterContext;
 
 #define OFFSET(x) offsetof(AudioPhaseMeterContext, x)
 #define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+#define get_duration(index) (index[1] - index[0])
 
 static const AVOption aphasemeter_options[] = {
 { "rate", "set video rate", OFFSET(frame_rate), AV_OPT_TYPE_VIDEO_RATE, {.str="25"}, 0, INT_MAX, FLAGS },
@@ -59,6 +73,10 @@ static const AVOption aphasemeter_options[] = {
 { "bc", "set blue contrast",  OFFSET(contrast[2]), AV_OPT_TYPE_INT, {.i64=1}, 0, 255, FLAGS },
 { "mpc", "set median phase color", OFFSET(mpc_str), AV_OPT_TYPE_STRING, {.str = "none"}, 0, 0, FLAGS },
 { "video", "set video output", OFFSET(do_video), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FLAGS },
+{ "phasing", "set mono and out-of-phase detection output", OFFSET(do_phasing_detection), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, FLAGS },
+{ "tolerance", "set phase tolerance for mono detection", OFFSET(tolerance), AV_OPT_TYPE_FLOAT, {.dbl = 0.}, 0, 1, FLAGS },
+{ "angle", "set angle threshold for out-of-phase detection", OFFSET(angle), AV_OPT_TYPE_FLOAT, {.dbl = 170.}, 90, 180, FLAGS },
+{ "duration", "set minimum mono or out-of-phase duration in seconds", OFFSET(duration), AV_OPT_TYPE_DOUBLE, {.dbl=2.}, 0, 24*60*60, FLAGS },
 { NULL }
 };
 
@@ -140,6 +158,21 @@ static inline int get_x(float phase, int w)
   return (phase + 1.) / 2. * (w - 1);
 }
 
+static inline float get_index(AVFilterLink *inlink, int64_t pts)
+{
+return atof(av_ts2timestr(pts, &inlink->time_base));
+}
+
+static inline void add_metadata(AVFrame *insamples, const char *key, float value)
+{
+char buf[128];
+char str[128];
+
+snprintf(str, sizeof(str), "%f", value);
+snprintf(buf, sizeof(buf), "lavfi.aphasemeter.%s", key);
+av_dict_set(&insamples->metadata, buf, str, 0);
+}
+
 static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 {
 AVFilterContext *ctx = inlink->dst;
@@ -154,6 +187,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 AVFrame *out;
 uint8_t *dst;
 int i

[FFmpeg-devel] [PATCH v1] lavf/hlsenc: refine the get_relative_url function to avoid extra malloc for relation path

[lance . lmwang]

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavformat/hlsenc.c  | 50 ++-
 libavformat/hlsplaylist.c |  4 ++--
 libavformat/hlsplaylist.h |  4 ++--
 3 files changed, 19 insertions(+), 39 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index f6f9c81..e5d7791 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1229,22 +1229,22 @@ static int hls_rename_temp_file(AVFormatContext *s, 
AVFormatContext *oc)
 return ret;
 }
 
-static int get_relative_url(const char *master_url, const char *media_url,
-char *rel_url, int rel_url_buf_size)
+static const char* get_relative_url(const char *master_url, const char 
*media_url)
 {
-char *p = NULL;
-int base_len = -1;
-p = strrchr(master_url, '/') ? strrchr(master_url, '/') :\
-strrchr(master_url, '\\');
+const char *p = strrchr(master_url, '/');
+size_t base_len = 0;
+
+if (!p) p = strrchr(master_url, '\\');
+
 if (p) {
-base_len = FFABS(p - master_url);
+base_len = p + 1 - master_url;
 if (av_strncasecmp(master_url, media_url, base_len)) {
 av_log(NULL, AV_LOG_WARNING, "Unable to find relative url\n");
-return AVERROR(EINVAL);
+return NULL;
 }
 }
-av_strlcpy(rel_url, &(media_url[base_len + 1]), rel_url_buf_size);
-return 0;
+
+return media_url + base_len;
 }
 
 static int64_t get_stream_bit_rate(AVStream *stream) {
@@ -1270,8 +1270,9 @@ static int create_master_playlist(AVFormatContext *s,
 AVStream *vid_st, *aud_st;
 AVDictionary *options = NULL;
 unsigned int i, j;
-int m3u8_name_size, ret, bandwidth;
-char *m3u8_rel_name = NULL, *ccgroup;
+int ret, bandwidth;
+const char *m3u8_rel_name = NULL;
+char *ccgroup;
 ClosedCaptionsStream *ccs;
 const char *proto = avio_find_protocol_name(hls->master_m3u8_url);
 int is_file_proto = proto && !strcmp(proto, "file");
@@ -1320,39 +1321,21 @@ static int create_master_playlist(AVFormatContext *s,
 if (vs->has_video || vs->has_subtitle || !vs->agroup)
 continue;
 
-m3u8_name_size = strlen(vs->m3u8_name) + 1;
-m3u8_rel_name = av_malloc(m3u8_name_size);
+m3u8_rel_name = get_relative_url(hls->master_m3u8_url, vs->m3u8_name);
 if (!m3u8_rel_name) {
-ret = AVERROR(ENOMEM);
-goto fail;
-}
-av_strlcpy(m3u8_rel_name, vs->m3u8_name, m3u8_name_size);
-ret = get_relative_url(hls->master_m3u8_url, vs->m3u8_name,
-   m3u8_rel_name, m3u8_name_size);
-if (ret < 0) {
 av_log(s, AV_LOG_ERROR, "Unable to find relative URL\n");
 goto fail;
 }
 
 ff_hls_write_audio_rendition(hls->m3u8_out, vs->agroup, m3u8_rel_name, 
vs->language, i, hls->has_default_key ? vs->is_default : 1);
-
-av_freep(&m3u8_rel_name);
 }
 
 /* For variant streams with video add #EXT-X-STREAM-INF tag with 
attributes*/
 for (i = 0; i < hls->nb_varstreams; i++) {
 vs = &(hls->var_streams[i]);
 
-m3u8_name_size = strlen(vs->m3u8_name) + 1;
-m3u8_rel_name = av_malloc(m3u8_name_size);
+m3u8_rel_name = get_relative_url(hls->master_m3u8_url, vs->m3u8_name);
 if (!m3u8_rel_name) {
-ret = AVERROR(ENOMEM);
-goto fail;
-}
-av_strlcpy(m3u8_rel_name, vs->m3u8_name, m3u8_name_size);
-ret = get_relative_url(hls->master_m3u8_url, vs->m3u8_name,
-   m3u8_rel_name, m3u8_name_size);
-if (ret < 0) {
 av_log(NULL, AV_LOG_ERROR, "Unable to find relative URL\n");
 goto fail;
 }
@@ -1421,13 +1404,10 @@ static int create_master_playlist(AVFormatContext *s,
  aud_st ? vs->agroup : NULL, 
vs->codec_attr, ccgroup);
 }
 }
-
-av_freep(&m3u8_rel_name);
 }
 fail:
 if(ret >=0)
 hls->master_m3u8_created = 1;
-av_freep(&m3u8_rel_name);
 hlsenc_io_close(s, &hls->m3u8_out, temp_filename);
 if (use_temp_file)
 ff_rename(temp_filename, hls->master_m3u8_url, s);
diff --git a/libavformat/hlsplaylist.c b/libavformat/hlsplaylist.c
index e8b5667..9cbd023 100644
--- a/libavformat/hlsplaylist.c
+++ b/libavformat/hlsplaylist.c
@@ -36,7 +36,7 @@ void ff_hls_write_playlist_version(AVIOContext *out, int 
version) {
 }
 
 void ff_hls_write_audio_rendition(AVIOContext *out, char *agroup,
-  char *filename, char *language, int name_id, 
int is_default) {
+  const char *filename, char *language, int 
name_id, int is_default) {
 if (!out || !agroup || !filename)
 return;
 
@@ -49,7 +49,7 @@ void ff_hls_write_audio_rendition(AVIOContext *out, char 
*agroup,
 }
 
 void ff_hls_write_stream_info(AVStream *st, AVIOContext *out,
-  

Re: [FFmpeg-devel] [PATCH] libavformat/mxfenc: Allow more bitrates for NTSC IMX50

[Thomas Mundt]

Am Fr., 16. Aug. 2019 um 23:31 Uhr schrieb Tomas Härdin :

> tor 2019-08-15 klockan 13:55 +0200 skrev Thomas Mundt:
> > Am Do., 15. Aug. 2019 um 11:01 Uhr schrieb Tomas Härdin <
> tjop...@acc.umu.se
> > > :
> > > ons 2019-08-14 klockan 22:18 +0200 skrev Thomas Mundt:
> > > > Hi Tomas,
> > > >
> > > > Am Mi., 14. Aug. 2019 um 12:42 Uhr schrieb Tomas Härdin <
> > > tjop...@acc.umu.se
> > > > > :
> > > > > tis 2019-08-13 klockan 22:03 +0200 skrev Thomas Mundt:
> > > > > > Hi,
> > > > > >
> > > > > > attached patch fixes ticket #8077.
> > > > > > Please comment.
> > > > >
> > > > > Probably OK, bitrates lower than 5000 are fine in D-10
> according to
> > > > > S356m.
> > > > >
> > > > > > } else if ((sc->video_bit_rate >= 4840) &&
> (sc->video_bit_rate <=
> > > > > > 5000) && (mxf->time_base.den != 25)) {
> > > > >
> > > > > You could drop the extra parentheses, else it should be fine.
> > > > >
> > > >
> > > > New patch attached.
> > >
> > > Looks OK. I'll push in a few days if no one else has any comments
> > >
> >
> > Thanks. Would you mind porting it to branches 4.1 and 4.2?
>
> I'm not quite sure what the process is for that. I have confirmed that
> the problem exists in 4.1 and 4.2 and that your patch fixes it.
>
> I think we also might want to put a note somewhere in the documentation
> how to make NTSC IMX50 files.
>

I can give you the parameters that I use for IMX50. Not sure if these are
the best. Got the intra matrix values from an original imx file.

NTSC: -c:v mpeg2video -pix_fmt yuv422p -aspect 16:9 -top 1 -flags
+ildct+ilme+low_delay -color_range tv -color_trc smpte170m -color_primaries
smpte170m -colorspace smpte170m -chroma_sample_location topleft
-signal_standard bt601 -dc 10 -intra_vlc 1 -non_linear_quant 1 -ps 1 -g 1
-qscale:v 1 -qmin 1 -qmax 12 -b:v 4841 -minrate 4841 -maxrate
4841 -bufsize 1668329 -rc_init_occupancy 1668329 -rc_min_vbv_use 1
-rc_max_vbv_use 1 -profile:v 0 -level:v 5 -intra_matrix
8,16,16,17,19,22,23,31,16,16,17,19,20,23,29,29,19,17,19,22,19,25,28,35,17,19,19,20,25,28,25,33,17,19,22,25,26,25,31,31,17,19,17,20,26,28,35,36,19,19,19,20,22,29,32,35,16,17,19,22,25,31,28,45

PAL: -c:v mpeg2video -pix_fmt yuv422p -aspect 16:9 -top 1 -flags
+ildct+ilme+low_delay -color_range tv -color_trc smpte170m -color_primaries
bt470bg -colorspace bt470bg -chroma_sample_location topleft
-signal_standard bt601 -dc 10 -intra_vlc 1 -non_linear_quant 1 -ps 1 -g 1
-qscale:v 1 -qmin 1 -qmax 12 -b:v 5000 -minrate 5000 -maxrate
5000 -bufsize 200 -rc_init_occupancy 200 -rc_min_vbv_use 1
-rc_max_vbv_use 1 -profile:v 0 -level:v 5 -intra_matrix
8,16,16,17,19,22,23,31,16,16,17,19,20,23,29,29,19,17,19,22,19,25,28,35,17,19,19,20,25,28,25,33,17,19,22,25,26,25,31,31,17,19,17,20,26,28,35,36,19,19,19,20,22,29,32,35,16,17,19,22,25,31,28,45

Regards,
Thomas
___
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] libavutil: AVEncodeInfo data structures

[Juan De León]

On Sat, Aug 17, 2019 at 7:00 AM Nicolas George  wrote:

> > +#define AV_ENCODE_INFO_MAX_BLOCKS 33177600
> > +
> > +static int init_encode_info_data(AVEncodeInfoFrame *info, unsigned int
> nb_blocks) {
> > +info->nb_blocks = nb_blocks;
> > +info->block_size = sizeof(AVEncodeInfoBlock);
> > +info->blocks_offset = offsetof(AVEncodeInfoFrame, blocks);
> > +
> > +for(int i = 0; i < AV_NUM_DATA_POINTERS; i++)
> > +info->plane_q[i] = -1;
> > +
> > +return 0;
> > +}
> > +
> > +AVEncodeInfoFrame *av_encode_info_alloc(unsigned int nb_blocks)
> > +{
> > +if (nb_blocks > AV_ENCODE_INFO_MAX_BLOCKS)
> > +return NULL;
> > +
> > +//AVEncodeInfoFrame already allocates size for one element of
> AVEncodeInfoBlock
>
> > +size_t size = sizeof(AVEncodeInfoFrame) +
> sizeof(AVEncodeInfoBlock)*FFMAX((int)(nb_blocks - 1), 0);
>
> (Commenting from my phone because urgent.)
> This line do not make sense to me. Can you explain the reason for the
> cast and how you avoid overflows?
>
In AVFrameEncodeInfo the block array is initialized as blocks[1], so when
allocating memory for the array we must consider 1 block is already
allocated.
nb_blocks can be 0, if it is unsigned the subtraction wraps it around to
UINT_MAX, the cast to int is to prevent that.
If this is confusing, I think it's better to change it to check for
nb_blocks > 0 and subtract 1.

Thanks

On Sat, Aug 17, 2019 at 7:00 AM Nicolas George  wrote:

> Juan De León (12019-08-16):
> > AVEncodeInfoFrame data structure to store as AVFrameSideData of type
> > AV_FRAME_DATA_ENCODE_INFO.
> > The structure stores quantization index for each plane, DC/AC deltas
> > for luma and chroma planes, and an array of AVEncodeInfoBlock type
> > denoting position, size, and delta quantizer for each block in the
> > frame.
> > Can be extended to support extraction of other block information.
> >
> > Signed-off-by: Juan De León 
> > ---
> >  libavutil/Makefile  |   2 +
> >  libavutil/encode_info.c |  68 +
> >  libavutil/encode_info.h | 110 
> >  libavutil/frame.c   |   1 +
> >  libavutil/frame.h   |   7 +++
> >  5 files changed, 188 insertions(+)
> >  create mode 100644 libavutil/encode_info.c
> >  create mode 100644 libavutil/encode_info.h
> >
> > diff --git a/libavutil/Makefile b/libavutil/Makefile
> > index 57e6e3d7e8..37cfb099e9 100644
> > --- a/libavutil/Makefile
> > +++ b/libavutil/Makefile
> > @@ -24,6 +24,7 @@ HEADERS = adler32.h
>  \
> >dict.h
> \
> >display.h
>  \
> >downmix_info.h
> \
> > +  encode_info.h
>  \
> >encryption_info.h
>  \
> >error.h
>  \
> >eval.h
> \
> > @@ -111,6 +112,7 @@ OBJS = adler32.o
> \
> > dict.o
>  \
> > display.o
> \
> > downmix_info.o
>  \
> > +   encode_info.o
> \
> > encryption_info.o
> \
> > error.o
> \
> > eval.o
>  \
> > diff --git a/libavutil/encode_info.c b/libavutil/encode_info.c
> > new file mode 100644
> > index 00..ec352a403b
> > --- /dev/null
> > +++ b/libavutil/encode_info.c
> > @@ -0,0 +1,68 @@
> > +/*
> > + * 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/encode_info.h"
> > +#include "libavutil/mem.h"
> > +
> > +// To prevent overflow, assumes max number = 1px blocks for 8k video.
> > +#define AV_ENCODE_INFO_MAX_BLOCKS 33177600
> > +
> > +static int init_encode_info_data(AVEncodeInfoFrame *info, unsigned int
> nb_blocks) {
> > +info->nb_blocks = nb_blocks;
> > +info->block_size = sizeof(AVEncodeInfoBlock);
> > +info->blocks_offset = offsetof(AVEncodeInfoFrame, blocks);
> > +
> > +for(int i = 0; i < AV_NUM_DATA_POINTERS; i++)
> > +info->plane_q[i] = -1;
> > +
> > +return 0;
> > +}
> > +
> > +AVEncodeInfoFrame *av_encode_info_alloc(unsigned int nb_blocks)
> > +{
> > +if (nb_blocks > AV_ENCODE_INFO_MAX_BLOCKS)
> > +return NULL;
> > +
> > +//AVEncodeInfoFrame already allocates size for one element of
> AVEncodeInfoBlock
>
> > +size_t size = sizeof(AVEncodeInfoFrame) +
> sizeof(AVEncodeInfoBlock)*FFMAX((i

[FFmpeg-devel] libavformat/mpegtsenc: new interleaved mux mode [v3]

[Andreas Håkon]

Hi,

This is the third version of my patch for an "interleaved MPEG-TS muxer".
This new version includes all recommendations and rebases the fix of the
incorrect PCR with multiple programs (fixed in collaboration with Marton 
Balint).

Supersedes: https://patchwork.ffmpeg.org/patch/13745/

How to check it:

(Note: I use for all the tests the file
https://samples.ffmpeg.org/HDTV/bshi01.tp
)

- By default the current behavior is selected. You can verify that this
patch doesn’t alter the original behavior with this simple test:

$ ffmpeg-original -i bshi01.tp \
  -c:v copy -c:a copy -c:d copy \
  -f mpegts -muxrate 22M bshi01-stock.ts

$ ffmpeg-patched -i bshi01.tp \
  -c:v copy -c:a copy -c:d copy \
  -f mpegts -muxrate 22M -mpegts_extra_mux 0 bshi01-new.ts

$ cmp -b bshi01-stock.ts bshi01-new.ts

So both files are identical. The patch therefore doesn’t introduce any
changes in the implementation of the sequential mode.

- To check the new interlaced mode you can perform this other test:

$ ffmpeg-patched -y -loglevel verbose -i bshi01.tp \
  -map "i:0x100" -c:0 copy \
  -map "i:0x110" -c:a:0 mp2 -ac:0 2 -ar:0 48000 -ab:0 384k \
  -map "i:0x130" -c:2 copy \
  -map "i:0x110" -c:3 copy \
  -map "i:0x100" -c:4 copy \
  -program title=Prog1:st=0:st=1:st=2 \
  -program title=Prog2:st=3:st=4 \
  -f mpegts -muxrate 44M -mpegts_extra_mux 1 bshi01-mode1.ts

$ ffmpeg-patched -y -loglevel verbose -i bshi01.tp \
  -map "i:0x100" -c:0 copy \
  -map "i:0x110" -c:a:0 mp2 -ac:0 2 -ar:0 48000 -ab:0 384k \
  -map "i:0x130" -c:2 copy \
  -map "i:0x110" -c:3 copy \
  -map "i:0x100" -c:4 copy \
  -program title=Prog1:st=0:st=1:st=2 \
  -program title=Prog2:st=3:st=4 \
  -f mpegts -muxrate 44M -mpegts_extra_mux 0 bshi01-mode0.ts

And you can observe:

a) The size of the files “bshi01-mode0.ts” and “bshi01-mode1.ts” is
almost the same. If you inspect the content, you can verify that the
difference is based solely on: a) an small increase in the number of
NULL packets in mode 1; b) a few new packets with only PCR and
not payload in the first video stream.

b) If you demux the three files to elemental streams, then you can
check that the content is identical. Using the linux package “tstools”
you can do this check:

$ ts2es -pid 256 bshi01-mode0.ts bshi01-mode0-256.m2v
$ ts2es -pid 260 bshi01-mode0.ts bshi01-mode0-260.m2v
$ ts2es -pid 257 bshi01-mode0.ts bshi01-mode0-257.mp2
$ ts2es -pid 259 bshi01-mode0.ts bshi01-mode0-259.aac

$ ts2es -pid 256 bshi01-mode1.ts bshi01-mode1-256.m2v
$ ts2es -pid 260 bshi01-mode1.ts bshi01-mode1-260.m2v
$ ts2es -pid 257 bshi01-mode1.ts bshi01-mode1-257.mp2
$ ts2es -pid 259 bshi01-mode1.ts bshi01-mode1-259.aac

c) If you look at the internal content of the files you can verify that
the original “bshi01.tp” file has all pids interlaced, but this isn’t true
for the file “bshi01-mode0.ts”. However, the file “bshi01-mode1.ts”
has an internal structure similar to that of the original file.
You can view the content using the well-known tool
“DVB Inspector” with the “Grid View” option.

These tests confirm the correctness of the implementation of this
new multiplexing mode.

Regards.
A.H.

---From 4636f83ca24e71fb807d48d3713bda6d3254938a Mon Sep 17 00:00:00 2001
From: Andreas Hakon 
Date: Mon, 19 Aug 2019 20:57:32 +0200
Subject: [PATCH] libavformat/mpegtsenc: interleaved mux mode [v3]

This patch implements a new optional "interleaved mux mode" in the MPEGTS muxer.
The strategy that implements the current mux (selected by default) is based on
writing full PES packages sequentially. This mode can be problematic when using
with DTV broadcasts, as some large video PES packets can delay the writing of
other elementary streams.
The new optional parameter "-mpegts_interleave_mux 1" enables another strategy.
Instead of writing all PES packets sequentially, the first TS packet of each PES
packet is written when the PES packet is started. But the rest of the PES data
will be written later, and interleaved between all the mux streams.
This new (optional) behavior has clear advantages when multiplexing multiple
programs with several video streams. And although this does not turn the
current implementation into a professional muxer, it brings the result closer
to what professional equipment does.

Example of use:

ffmpeg -i INPUT.ts \
  -map "i:0x100" -c:v:0 copy \
  -map "i:0x110" -c:a:0 copy \
  -map "i:0x100" -c:v:1 copy \
  -map "i:0x110" -c:a:1 copy \
  -program title=Prog1:st=0:st=1 \
  -program title=Prog2:st=2:st=3 \
  -f mpegts -muxrate 44M -mpegts_interleave_mux 1 OUTPUT.ts

Signed-off-by: Andreas Hakon 
---
 libavformat/mpegtsenc.c |  188 ++-
 1 file changed, 152 insertions(+), 36 deletions(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index d4dd4ab..dc1b68f 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -87,6 +87,7 @@ typedef struct MpegTSWrite {
 int64_t next_pcr;
 int mux_rate; ///< set to 1 when VBR
 int pes

Re: [FFmpeg-devel] [PATCHv2 5/6] avformat/mpegtsenc: fix PCR generation intervals

[Andreas Håkon]

Hi Marton,


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Friday, 16 de August de 2019 10:27, Andreas Håkon 
 wrote:

> Hi Marton,
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, 14 de August de 2019 23:31, Marton Balint c...@passwd.hu wrote:
>
> > I pushed this series, will post the patch which enables setting pcr period
> > for VBR.
>
> Great! I'll prepare my updated interleaved patch.
>

The patch for the interleaved muxing is done rebasing your code:
https://patchwork.ffmpeg.org/patch/14589/

Please, check it.
Regards.
A.H.

---

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

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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/alsdec: Limit maximum channels to 64

[Michael Niedermayer]

On Mon, Aug 19, 2019 at 05:09:37PM +0200, Thilo Borgmann wrote:
> Am 19.08.19 um 14:27 schrieb Michael Niedermayer:
> > On Mon, Aug 19, 2019 at 07:41:43AM +0200, Thilo Borgmann wrote:
> >> Am 19.08.19 um 01:30 schrieb Michael Niedermayer:
> >>> There seems to be no limit in the specification and upto 64k could be 
> >>> stored
> >>> 64 is chooses as limit as thats also used for AAC and is what a int64 mask
> >>> can handle
> >>>
> >>> An alternative to this patch would be a max_channels variable
> >>
> >> There's a conformance file containing 512 channels, that should be the 
> >> default max value.
> > 
> > will apply with that value later
> 
> Decoding of that is already stopped via FF_SANE_NB_CHANNELS in 
> lavc/internal.h.
> That is currently set to 256U. I guess pushing that to 512U might already be 
> enough without any change to single decoders?

the problem of out of memory is that the als decoder allocates some pretty
large things per channel. A check on channels needs to happen before
this.
The existing checks didnt achieve that.

I can of course post a patchset that uses FF_SANE_NB_CHANNELS in als and
bump it to the next number if people prefer this ?

Note though that increasing FF_SANE_NB_CHANNELS may also increase timeouts
in other decoders.


> 
> Once fixed, I will add a FATE test for the 512 channel conformance file.

thx

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

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


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 v3] libavformat: Add ZeroMQ as a protocol option

[Andriy Gelman]

Minor changes in v3: 
1. Removed tab character from as per feedback 
2. Removed unused timeout variable from ZMQContext 

Andriy
>From 66c11c12fcfa8a7fbb3c8c09d23c017992229a99 Mon Sep 17 00:00:00 2001
From: Andriy Gelman 
Date: Tue, 30 Jul 2019 14:39:32 -0400
Subject: [PATCH] libavformat: Add ZeroMQ as a protocol option

Currently multiple clients are only supported by using a multicast
destination address. An alternative is to stream to a server which
re-distributes the content. This commit adds ZeroMQ as a protocol
option, which allows multiple clients to connect to a single ffmpeg
instance.
---
 configure   |   2 +
 doc/general.texi|   1 +
 doc/protocols.texi  |  32 
 libavformat/Makefile|   1 +
 libavformat/libzmq.c| 158 
 libavformat/protocols.c |   1 +
 6 files changed, 195 insertions(+)
 create mode 100644 libavformat/libzmq.c

diff --git a/configure b/configure
index c09c842809..a4134024c2 100755
--- a/configure
+++ b/configure
@@ -3411,6 +3411,8 @@ libsrt_protocol_deps="libsrt"
 libsrt_protocol_select="network"
 libssh_protocol_deps="libssh"
 libtls_conflict="openssl gnutls mbedtls"
+libzmq_protocol_deps="libzmq"
+libzmq_protocol_select="network"
 
 # filters
 afftdn_filter_deps="avcodec"
diff --git a/doc/general.texi b/doc/general.texi
index 3c0c803449..b8e063268c 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1329,6 +1329,7 @@ performance on systems without hardware floating point 
support).
 @item TCP  @tab X
 @item TLS  @tab X
 @item UDP  @tab X
+@item ZMQ  @tab E
 @end multitable
 
 @code{X} means that the protocol is supported.
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 3e4e7af3d4..174eaacd0f 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1728,4 +1728,36 @@ Timeout in ms.
 Create the Unix socket in listening mode.
 @end table
 
+@section libzmq
+
+ZeroMQ asynchronous messaging library.
+
+This library supports unicast streaming to multiple clients without relying on
+an external server.
+
+The required syntax for streaming or connecting to a stream is:
+@example
+zmq:tcp://ip-address:port
+@end example
+
+Example:
+Create a localhost stream on port :
+@example
+ffmpeg -re -i input -f mpegts zmq:tcp://127.0.0.1:
+@end example
+
+Multiple clients may connect to the stream using:
+@example
+ffplay zmq:tcp://127.0.0.1:
+@end example
+
+Streaming to multiple clients is implemented using a ZMQ Pub-Sub pattern.
+The server binds to a port and publishes data. Clients connect to the
+server (IP address/port) and subscribe to the stream. The order in which
+the server and client start generally does not matter.
+
+ffmpeg must be compiled with the --enable-libzmq option to support
+this protocol option. See the compilation guide 
@url{https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu}
+for an example on how this option may be set.
+
 @c man end PROTOCOLS
diff --git a/libavformat/Makefile b/libavformat/Makefile
index a434b005a4..efa3a112ae 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -631,6 +631,7 @@ OBJS-$(CONFIG_LIBRTMPTE_PROTOCOL)+= librtmp.o
 OBJS-$(CONFIG_LIBSMBCLIENT_PROTOCOL) += libsmbclient.o
 OBJS-$(CONFIG_LIBSRT_PROTOCOL)   += libsrt.o
 OBJS-$(CONFIG_LIBSSH_PROTOCOL)   += libssh.o
+OBJS-$(CONFIG_LIBZMQ_PROTOCOL)   += libzmq.o
 
 # libavdevice dependencies
 OBJS-$(CONFIG_IEC61883_INDEV)+= dv.o
diff --git a/libavformat/libzmq.c b/libavformat/libzmq.c
new file mode 100644
index 00..ac35c01cf8
--- /dev/null
+++ b/libavformat/libzmq.c
@@ -0,0 +1,158 @@
+/*
+ * ZMQ URLProtocol
+ *
+ * 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 
+#include "url.h"
+#include "network.h"
+#include "libavutil/avstring.h"
+#include "libavutil/opt.h"
+
+typedef struct ZMQContext {
+const AVClass *class;
+void *context;
+void *socket;
+} ZMQContext;
+
+static const AVOption options[] = {
+{ NULL }
+};
+
+static int ff_zmq_open(URLContext *h, const char *uri, int flags)
+{
+int ret;
+ZMQContext *s   = h->priv_data;
+s->context  = zmq_ctx_new();
+h->is_streamed  = 1;
+
+av_strstart(uri, "zmq:", &uri);
+
+/*publish duri

Re: [FFmpeg-devel] [PATCH v2 1/3] avfilter: add v360 filter

[James Almer]

On 8/13/2019 10:14 PM, Eugene Lyapustin wrote:
> Signed-off-by: Eugene Lyapustin 
> ---
>  doc/filters.texi |  137 +++
>  libavfilter/Makefile |1 +
>  libavfilter/allfilters.c |1 +
>  libavfilter/vf_v360.c| 1847 ++
>  4 files changed, 1986 insertions(+)
>  create mode 100644 libavfilter/vf_v360.c
> 
> diff --git a/doc/filters.texi b/doc/filters.texi

Shouldn't this make use of the AVSphericalMapping frame side data if
available?
___
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]lavc/g729dec: Support decoding ACELP.KELVIN

[Carl Eugen Hoyos]

Hi!

Attached patch fixes tickets #4799 and #8081, thanks to Paul for his help.

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

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

diff --git a/Changelog b/Changelog
index 389ca6c4db..42c1d16207 100644
--- a/Changelog
+++ b/Changelog
@@ -1,6 +1,9 @@
 Entries are sorted chronologically from oldest to youngest within each release,
 releases are sorted from youngest to oldest.
 
+version :
+- support Sipro ACELP.KELVIN decoding
+
 version 4.2:
 - tpad filter
 - AV1 decoding support through libdav1d
diff --git a/configure b/configure
index c09c842809..fc073967b3 100755
--- a/configure
+++ b/configure
@@ -2635,6 +2635,7 @@ ac3_decoder_select="ac3_parser ac3dsp bswapdsp fmtconvert mdct"
 ac3_fixed_decoder_select="ac3_parser ac3dsp bswapdsp mdct"
 ac3_encoder_select="ac3dsp audiodsp mdct me_cmp"
 ac3_fixed_encoder_select="ac3dsp audiodsp mdct me_cmp"
+acelp_kelvin_decoder_select="g729_decoder"
 adpcm_g722_decoder_select="g722dsp"
 adpcm_g722_encoder_select="g722dsp"
 aic_decoder_select="golomb idctdsp"
diff --git a/doc/general.texi b/doc/general.texi
index 3c0c803449..d90588c63a 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1057,6 +1057,7 @@ following image formats are supported:
 @item AAC+   @tab  E  @tab  IX
 @tab encoding supported through external library libfdk-aac
 @item AC-3   @tab IX  @tab  IX
+@item ACELP.KELVIN   @tab @tab  X
 @item ADPCM 4X Movie @tab @tab  X
 @item APDCM Yamaha AICA  @tab @tab  X
 @item ADPCM CDROM XA @tab @tab  X
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index d2f9a39ce5..5936cdc467 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -32,6 +32,7 @@
 extern AVCodec ff_a64multi_encoder;
 extern AVCodec ff_a64multi5_encoder;
 extern AVCodec ff_aasc_decoder;
+extern AVCodec ff_acelp_kelvin_decoder;
 extern AVCodec ff_aic_decoder;
 extern AVCodec ff_alias_pix_encoder;
 extern AVCodec ff_alias_pix_decoder;
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index d234271c5b..7ec4014d8b 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -629,6 +629,7 @@ enum AVCodecID {
 AV_CODEC_ID_ON2AVC,
 AV_CODEC_ID_DSS_SP,
 AV_CODEC_ID_CODEC2,
+AV_CODEC_ID_ACELP_KELVIN,
 
 AV_CODEC_ID_FFWAVESYNTH = 0x15800,
 AV_CODEC_ID_SONIC,
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 4d033c20ff..716e278b93 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -2834,6 +2834,12 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("codec2 (very low bitrate speech codec)"),
 .props = AV_CODEC_PROP_LOSSY,
 },
+{
+.id= AV_CODEC_ID_ACELP_KELVIN,
+.name  = "ACELP.KELVIN",
+.long_name = NULL_IF_CONFIG_SMALL("Sipro ACELP.KELVIN"),
+.props = AV_CODEC_PROP_LOSSY,
+},
 {
 .id= AV_CODEC_ID_FFWAVESYNTH,
 .type  = AVMEDIA_TYPE_AUDIO,
diff --git a/libavcodec/g729_parser.c b/libavcodec/g729_parser.c
index 9982dbfffc..5a57025d62 100644
--- a/libavcodec/g729_parser.c
+++ b/libavcodec/g729_parser.c
@@ -45,9 +45,10 @@ static int g729_parse(AVCodecParserContext *s1, AVCodecContext *avctx,
 int next;
 
 if (!s->block_size) {
-av_assert1(avctx->codec_id == AV_CODEC_ID_G729);
 /* FIXME: replace this heuristic block_size with more precise estimate */
 s->block_size = (avctx->bit_rate < 8000) ? G729D_6K4_BLOCK_SIZE : G729_8K_BLOCK_SIZE;
+if (avctx->codec_id == AV_CODEC_ID_ACELP_KELVIN)
+s->block_size++;
 s->block_size *= avctx->channels;
 s->duration   = avctx->frame_size;
 }
@@ -76,7 +77,7 @@ static int g729_parse(AVCodecParserContext *s1, AVCodecContext *avctx,
 }
 
 AVCodecParser ff_g729_parser = {
-.codec_ids  = { AV_CODEC_ID_G729 },
+.codec_ids  = { AV_CODEC_ID_G729, AV_CODEC_ID_ACELP_KELVIN },
 .priv_data_size = sizeof(G729ParseContext),
 .parser_parse   = g729_parse,
 .parser_close   = ff_parse_close,
diff --git a/libavcodec/g729dec.c b/libavcodec/g729dec.c
index 2e4756b805..5a5da5b03c 100644
--- a/libavcodec/g729dec.c
+++ b/libavcodec/g729dec.c
@@ -424,7 +424,7 @@ static int decode_frame(AVCodecContext *avctx, void *data, int *got_frame_ptr,

[FFmpeg-devel] [PATCH v2 1/8] avformat/utils: Fix memleaks

[Andreas Rheinhardt]

ff_read_packet had several potential memleaks:
1. If av_packet_make_refcounted fails, it means that the packet is not
refcounted, but it could nevertheless carry side data and therefore
needs to be unreferenced.
2. If a packet happens to have an illegal stream index (i.e. one that
does not correspond to a stream), it should nevertheless be
unreferenced.
3. If putting a packet on a packet list fails, it wasn't unreferenced.

Furthermore, read_frame_internal leaked a packet's (side) data if a
context update was required and failed.

Signed-off-by: Andreas Rheinhardt 
---
The two memleaks in read_frame_internal have been added in v2.

 libavformat/utils.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index b57e680089..564be02334 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -873,8 +873,10 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
 }
 
 err = av_packet_make_refcounted(pkt);
-if (err < 0)
+if (err < 0) {
+av_packet_unref(pkt);
 return err;
+}
 
 if ((s->flags & AVFMT_FLAG_DISCARD_CORRUPT) &&
 (pkt->flags & AV_PKT_FLAG_CORRUPT)) {
@@ -887,6 +889,7 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
 
 if (pkt->stream_index >= (unsigned)s->nb_streams) {
 av_log(s, AV_LOG_ERROR, "Invalid stream index %d\n", 
pkt->stream_index);
+av_packet_unref(pkt);
 continue;
 }
 
@@ -917,8 +920,10 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
 err = ff_packet_list_put(&s->internal->raw_packet_buffer,
  &s->internal->raw_packet_buffer_end,
  pkt, 0);
-if (err)
+if (err < 0) {
+av_packet_unref(pkt);
 return err;
+}
 s->internal->raw_packet_buffer_remaining_size -= pkt->size;
 
 if ((err = probe_codec(s, st, pkt)) < 0)
@@ -1611,15 +1616,19 @@ static int read_frame_internal(AVFormatContext *s, 
AVPacket *pkt)
 }
 
 ret = avcodec_parameters_to_context(st->internal->avctx, 
st->codecpar);
-if (ret < 0)
+if (ret < 0) {
+av_packet_unref(&cur_pkt);
 return ret;
+}
 
 #if FF_API_LAVF_AVCTX
 FF_DISABLE_DEPRECATION_WARNINGS
 /* update deprecated public codec context */
 ret = avcodec_parameters_to_context(st->codec, st->codecpar);
-if (ret < 0)
+if (ret < 0) {
+av_packet_unref(&cur_pkt);
 return ret;
+}
 FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 
-- 
2.21.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 4/8] avformat/utils: Move the reference to the packet list

[Andreas Rheinhardt]

Up until now, ff_packet_list_put had a flaw: When it moved a packet to
the list (meaning, when it ought to move the reference to the packet
list instead of creating a new one via av_packet_ref), it did not reset
the original packet, confusing the ownership of the data in the packet.
This has been done because some callers of this function were not
compatible with resetting the packet.

This commit changes these callers and fixes this flaw. In order to
indicate that the ownership of the packet has moved to the packet list,
pointers to constant AVPackets are used whenever the target of the
pointer might already be owned by the packet list.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/utils.c | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index b93d80588d..bae2f9e0db 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -460,10 +460,7 @@ int ff_packet_list_put(AVPacketList **packet_buffer,
 return ret;
 }
 } else {
-// TODO: Adapt callers in this file so the line below can use
-//   av_packet_move_ref() to effectively move the reference
-//   to the list.
-pktl->pkt = *pkt;
+av_packet_move_ref(&pktl->pkt, pkt);
 }
 
 if (*packet_buffer)
@@ -835,6 +832,7 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
 
 for (;;) {
 AVPacketList *pktl = s->internal->raw_packet_buffer;
+const AVPacket *pkt1;
 
 if (pktl) {
 st = s->streams[pktl->pkt.stream_index];
@@ -923,9 +921,10 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
 av_packet_unref(pkt);
 return err;
 }
-s->internal->raw_packet_buffer_remaining_size -= pkt->size;
+pkt1 = &s->internal->raw_packet_buffer_end->pkt;
+s->internal->raw_packet_buffer_remaining_size -= pkt1->size;
 
-if ((err = probe_codec(s, st, pkt)) < 0)
+if ((err = probe_codec(s, st, pkt1)) < 0)
 return err;
 }
 }
@@ -3028,8 +3027,8 @@ static int has_codec_parameters(AVStream *st, const char 
**errmsg_ptr)
 }
 
 /* returns 1 or 0 if or if not decoded data was returned, or a negative error 
*/
-static int try_decode_frame(AVFormatContext *s, AVStream *st, AVPacket *avpkt,
-AVDictionary **options)
+static int try_decode_frame(AVFormatContext *s, AVStream *st,
+const AVPacket *avpkt, AVDictionary **options)
 {
 AVCodecContext *avctx = st->internal->avctx;
 const AVCodec *codec;
@@ -3521,7 +3520,7 @@ fail:
 return ret;
 }
 
-static int extract_extradata(AVStream *st, AVPacket *pkt)
+static int extract_extradata(AVStream *st, const AVPacket *pkt)
 {
 AVStreamInternal *sti = st->internal;
 AVPacket *pkt_ref;
@@ -3584,7 +3583,7 @@ int avformat_find_stream_info(AVFormatContext *ic, 
AVDictionary **options)
 int64_t read_size;
 AVStream *st;
 AVCodecContext *avctx;
-AVPacket pkt1, *pkt;
+AVPacket pkt1;
 int64_t old_offset  = avio_tell(ic->pb);
 // new streams might appear, no options for those
 int orig_nb_streams = ic->nb_streams;
@@ -3703,6 +3702,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 
 read_size = 0;
 for (;;) {
+const AVPacket *pkt;
 int analyzed_all_streams;
 if (ff_check_interrupt(&ic->interrupt_callback)) {
 ret = AVERROR_EXIT;
@@ -3796,14 +3796,16 @@ FF_ENABLE_DEPRECATION_WARNINGS
 break;
 }
 
-pkt = &pkt1;
-
 if (!(ic->flags & AVFMT_FLAG_NOBUFFER)) {
 ret = ff_packet_list_put(&ic->internal->packet_buffer,
  &ic->internal->packet_buffer_end,
- pkt, 0);
+ &pkt1, 0);
 if (ret < 0)
 goto find_stream_info_err;
+
+pkt = &ic->internal->packet_buffer_end->pkt;
+} else {
+pkt = &pkt1;
 }
 
 st = ic->streams[pkt->stream_index];
@@ -3881,7 +3883,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
limit,
t, pkt->stream_index);
 if (ic->flags & AVFMT_FLAG_NOBUFFER)
-av_packet_unref(pkt);
+av_packet_unref(&pkt1);
 break;
 }
 if (pkt->duration) {
@@ -3918,7 +3920,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
  (options && i < orig_nb_streams) ? &options[i] : 
NULL);
 
 if (ic->flags & AVFMT_FLAG_NOBUFFER)
-av_packet_unref(pkt);
+av_packet_unref(&pkt1);
 
 st->codec_info_nb_frames++;
 count++;
-- 
2.21.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.or

[FFmpeg-devel] [PATCH v2 6/8] avformat/utils: Don't create unnecessary references

[Andreas Rheinhardt]

When AVFMT_FLAG_GENPTS is set, av_read_frame would put a reference to a
packet in the packet list (via av_packet_ref) and then immediately
thereafter unreference the original packet. This has been changed to
move the reference instead. Given that the packet originated from
read_frame_internal, it is already reference counted*, so that the
outcome of the new code is equivalent to the old code.

*: Packets from read_frame_internal either come directly from
ff_read_packet or from parse_packet; the latter makes sure that the
packet is reference counted. Packets from the former have been either
directly read or come from the raw_packet_buffer. The directly read
packets have been made refcounted and the other packets originate either
from directly read ones or from attached pics which are inserted into
the packet list via av_packet_ref.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/utils.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 96c02bb7fc..db0f53869f 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1847,10 +1847,11 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
 
 ret = ff_packet_list_put(&s->internal->packet_buffer,
  &s->internal->packet_buffer_end,
- pkt, FF_PACKETLIST_FLAG_REF_PACKET);
-av_packet_unref(pkt);
-if (ret < 0)
+ pkt, 0);
+if (ret < 0) {
+av_packet_unref(pkt);
 return ret;
+}
 }
 
 return_packet:
-- 
2.21.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 7/8] avformat/utils: Remove unnecessary packet copies

[Andreas Rheinhardt]

Up until now, read_frame_internal in avformat/utils.c uses a spare
packet on the stack that serves no real purpose: At no point in this
function is there a need for another packet besides the packet destined
for output:
1. If the packet doesn't need a parser, but is output as is, the content
of the spare packet (that at this point contains a freshly read packet)
is simply copied into the output packet (via simple assignment, not
av_packet_move_ref, thereby confusing ownership).
2. If the packet needs parsing, the spare packet will be reset after
parsing and any packets resulting from the packet read will be put into
a packet list; the output packet is not used here at all.
3. If the stream should be discarded, the spare packet will be
unreferenced; the output packet is not used here at all.

Therefore the spare packet and the copies can be removed in priniple.
In practice, one more thing needs to be taken care of: If ff_read_packet
failed, this did not affect the output packet, now it does. This
potential problem is solved by making sure that ff_read_packet always
resets the output packet in case of errors.

Signed-off-by: Andreas Rheinhardt 
---
Side note: This skip_to_keyframe stuff which is touched in this commit
has been introduced in 4a95876f to be able to drop non-keyframes after
the parser in case the keyframes are wrongly marked in the file. But the
parser returns packets by putting them in the packet queue and not by
returning them via its pkt parameter, so that st->skip_to_keyframe will
never be unset and no packet will be dropped because of it for a stream
that gets parsed. It actually only works ("works" means that an error
message will be displayed for a broken file where the keyframes are not
correctly marked) for the file for which it was intended (the one from
issue 1003) by accident. Maybe it should be removed altogether?

 libavformat/utils.c | 51 ++---
 1 file changed, 25 insertions(+), 26 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index db0f53869f..d6d615b690 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -830,6 +830,10 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
 int ret, i, err;
 AVStream *st;
 
+pkt->data = NULL;
+pkt->size = 0;
+av_init_packet(pkt);
+
 for (;;) {
 AVPacketList *pktl = s->internal->raw_packet_buffer;
 const AVPacket *pkt1;
@@ -847,11 +851,11 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
 }
 }
 
-pkt->data = NULL;
-pkt->size = 0;
-av_init_packet(pkt);
 ret = s->iformat->read_packet(s, pkt);
 if (ret < 0) {
+pkt->data = NULL;
+pkt->size = 0;
+av_init_packet(pkt);
 /* Some demuxers return FFERROR_REDO when they consume
data and discard it (ignored streams, junk, extradata).
We must re-call the demuxer to get the real packet. */
@@ -1579,10 +1583,9 @@ static int read_frame_internal(AVFormatContext *s, 
AVPacket *pkt)
 
 while (!got_packet && !s->internal->parse_queue) {
 AVStream *st;
-AVPacket cur_pkt;
 
 /* read next packet */
-ret = ff_read_packet(s, &cur_pkt);
+ret = ff_read_packet(s, pkt);
 if (ret < 0) {
 if (ret == AVERROR(EAGAIN))
 return ret;
@@ -1597,7 +1600,7 @@ static int read_frame_internal(AVFormatContext *s, 
AVPacket *pkt)
 break;
 }
 ret = 0;
-st  = s->streams[cur_pkt.stream_index];
+st  = s->streams[pkt->stream_index];
 
 /* update context if required */
 if (st->internal->need_context_update) {
@@ -1615,7 +1618,7 @@ static int read_frame_internal(AVFormatContext *s, 
AVPacket *pkt)
 
 ret = avcodec_parameters_to_context(st->internal->avctx, 
st->codecpar);
 if (ret < 0) {
-av_packet_unref(&cur_pkt);
+av_packet_unref(pkt);
 return ret;
 }
 
@@ -1624,7 +1627,7 @@ FF_DISABLE_DEPRECATION_WARNINGS
 /* update deprecated public codec context */
 ret = avcodec_parameters_to_context(st->codec, st->codecpar);
 if (ret < 0) {
-av_packet_unref(&cur_pkt);
+av_packet_unref(pkt);
 return ret;
 }
 FF_ENABLE_DEPRECATION_WARNINGS
@@ -1633,23 +1636,23 @@ FF_ENABLE_DEPRECATION_WARNINGS
 st->internal->need_context_update = 0;
 }
 
-if (cur_pkt.pts != AV_NOPTS_VALUE &&
-cur_pkt.dts != AV_NOPTS_VALUE &&
-cur_pkt.pts < cur_pkt.dts) {
+if (pkt->pts != AV_NOPTS_VALUE &&
+pkt->dts != AV_NOPTS_VALUE &&
+pkt->pts < pkt->dts) {
 av_log(s, AV_LOG_WARNING,
"Invalid timestamps stream=%d, pts=%s, dts=%s, size=%d\n",
-   cur_pkt.stream_index,
-   a

[FFmpeg-devel] [PATCH v2 8/8] avformat/utils: Remove unnecessary initializations

[Andreas Rheinhardt]

Up until now, read_frame_internal always initialized the packet it
received. But since the recent changes to ff_read_packet, this is no
longer needed: If the parsing queue is initially empty upon entering
read_frame_internal, the packet will now either contain content upon
success or be blank upon failure of ff_read_packet. If the parsing
queue is initially not empty, the packet will be overwritten with the
oldest one from the parsing queue.

Similarly, it is unnecessary to initialize ret.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/utils.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index d6d615b690..a81d1e6ca2 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1576,11 +1576,9 @@ static int64_t ts_to_samples(AVStream *st, int64_t ts)
 
 static int read_frame_internal(AVFormatContext *s, AVPacket *pkt)
 {
-int ret = 0, i, got_packet = 0;
+int ret, i, got_packet = 0;
 AVDictionary *metadata = NULL;
 
-av_init_packet(pkt);
-
 while (!got_packet && !s->internal->parse_queue) {
 AVStream *st;
 
-- 
2.21.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 5/8] avformat/utils: Fix memleaks II

[Andreas Rheinhardt]

Up until now, avformat_find_stream_info had a potential for memleaks:
When everything is fine, it read packets and (depending upon whether
AVFMT_FLAG_NOBUFFER was set) put them in a packet list or unreferenced
them when they were no longer needed. But upon failure, said packets
would leak if they were not already on the packet list. This patch fixes
this.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/utils.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index bae2f9e0db..96c02bb7fc 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -3801,7 +3801,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
  &ic->internal->packet_buffer_end,
  &pkt1, 0);
 if (ret < 0)
-goto find_stream_info_err;
+goto unref_then_goto_end;
 
 pkt = &ic->internal->packet_buffer_end->pkt;
 } else {
@@ -3816,7 +3816,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 if (!st->internal->avctx_inited) {
 ret = avcodec_parameters_to_context(avctx, st->codecpar);
 if (ret < 0)
-goto find_stream_info_err;
+goto unref_then_goto_end;
 st->internal->avctx_inited = 1;
 }
 
@@ -3904,7 +3904,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 if (!st->internal->avctx->extradata) {
 ret = extract_extradata(st, pkt);
 if (ret < 0)
-goto find_stream_info_err;
+goto unref_then_goto_end;
 }
 
 /* If still no information, we try to open the codec and to
@@ -4180,6 +4180,10 @@ find_stream_info_err:
 av_log(ic, AV_LOG_DEBUG, "After avformat_find_stream_info() pos: 
%"PRId64" bytes read:%"PRId64" seeks:%d frames:%d\n",
avio_tell(ic->pb), ic->pb->bytes_read, ic->pb->seek_count, 
count);
 return ret;
+
+unref_then_goto_end:
+av_packet_unref(&pkt1);
+goto find_stream_info_err;
 }
 
 AVProgram *av_find_program_from_stream(AVFormatContext *ic, AVProgram *last, 
int s)
-- 
2.21.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/8] avformat/internal: Improve documentation of ff_packet_list_get

[Andreas Rheinhardt]

The documentation of ff_packet_list_get currently didn't match the
actual usage:
1. It said that the destination packet is supposed to be initialized.
But this makes no sense given that it will be overwritten completely and
flacenc, mp3enc and ttaenc ignored this.
2. ff_packet_list_get returns an int, although it can't fail in case the
packet list is not empty (for which there is an assert). Again, several
callers didn't check for any return value.
In both cases, the documentation has been adapted to match actual usage.

Signed-off-by: Andreas Rheinhardt 
---
No changes since last time.

 libavformat/internal.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavformat/internal.h b/libavformat/internal.h
index d6a039c497..163587f416 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -773,13 +773,16 @@ int ff_packet_list_put(AVPacketList **head, AVPacketList 
**tail,
 
 /**
  * Remove the oldest AVPacket in the list and return it.
+ * The behaviour is undefined if the packet list is empty.
  *
  * @note The pkt will be overwritten completely. The caller owns the
  *   packet and must unref it by itself.
  *
  * @param head List head element
  * @param tail List tail element
- * @param pkt  Pointer to an initialized AVPacket struct
+ * @param pkt  Pointer to an AVPacket struct
+ * @return 0 on success. Success is guaranteed
+ * if the packet list is not empty.
  */
 int ff_packet_list_get(AVPacketList **head, AVPacketList **tail,
AVPacket *pkt);
-- 
2.21.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/8] avformat/utils: Preserve integrity of linked list

[Andreas Rheinhardt]

1. Instead of relying on ff_packet_list_get to get the oldest element in
an AVPacketList, ff_read_packet used its own ad-hoc code. Said code
forgot to set the end of the list to NULL if the last element of the
list has been removed, thereby leaving the list in an inconsistent state.
2. Furthermore, if the list was not empty, the oldest element of the
list would always be copied into another packet structure before it was
known whether the oldest entry of the list would be removed. This makes
the ownership confusing and potentially copies unnecessarily.

Both of these issues have been fixed. ff_packet_list_get is used now.

Signed-off-by: Andreas Rheinhardt 
---
No changes since last time.

 libavformat/utils.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 564be02334..b93d80588d 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -837,15 +837,14 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
 AVPacketList *pktl = s->internal->raw_packet_buffer;
 
 if (pktl) {
-*pkt = pktl->pkt;
-st   = s->streams[pkt->stream_index];
+st = s->streams[pktl->pkt.stream_index];
 if (s->internal->raw_packet_buffer_remaining_size <= 0)
 if ((err = probe_codec(s, st, NULL)) < 0)
 return err;
 if (st->request_probe <= 0) {
-s->internal->raw_packet_buffer = pktl->next;
+ff_packet_list_get(&s->internal->raw_packet_buffer,
+   &s->internal->raw_packet_buffer_end, pkt);
 s->internal->raw_packet_buffer_remaining_size += pkt->size;
-av_free(pktl);
 return 0;
 }
 }
-- 
2.21.0

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

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

Re: [FFmpeg-devel] [PATCH 1/3] avformat/utils: Fix memleaks

[Andreas Rheinhardt]

Andreas Rheinhardt:
> ff_read_packet had several potential memleaks:
> 1. If av_packet_make_refcounted fails, it means that the packet is not
> refcounted, but it could nevertheless carry side data and therefore
> needs to be unreferenced.
> 2. If a packet happens to have an illegal stream index (i.e. one that
> does not correspond to a stream), it should nevertheless be
> unreferenced.
> 3. If putting a packet on a packet list fails, it wasn't unreferenced.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
This patchset has been superseded by
https://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248560.html.

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

[James Almer]

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

Copy instead the code from decode_nal_units() in h264dec.c, which checks
first with the complete NAL, and then calls
ff_h264_decode_seq_parameter_set() with the ignore_truncation parameter
set to 1 as a last resort.
___
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] hevc_mp4toannexb: Insert correct parameter sets before IRAP

[Michael Niedermayer]

On Sun, Aug 18, 2019 at 10:37:57PM -0400, Andriy Gelman wrote:
[...]
> diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
> index 559c3898bc..46f130f4d1 100644
> --- a/tests/fate/hevc.mak
> +++ b/tests/fate/hevc.mak
> @@ -238,7 +238,7 @@ FATE_HEVC-$(call ALLYES, HEVC_DEMUXER MOV_DEMUXER 
> HEVC_MP4TOANNEXB_BSF MOV_MUXER
>  fate-hevc-bsf-mp4toannexb: tests/data/hevc-mp4.mov
>  fate-hevc-bsf-mp4toannexb: CMD = md5 -i 
> $(TARGET_PATH)/tests/data/hevc-mp4.mov -c:v copy -fflags +bitexact -f hevc
>  fate-hevc-bsf-mp4toannexb: CMP = oneline
> -fate-hevc-bsf-mp4toannexb: REF = 1873662a3af1848c37e4eb25722c8df9
> +fate-hevc-bsf-mp4toannexb: REF = d41d8cd98f00b204e9800998ecf8427e

is it intended that this is empty ?
touch zero
 md5sum zero
d41d8cd98f00b204e9800998ecf8427e  zero

thanks

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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 1/3] libavutil: AVEncodeInfo data structures

[Juan De León]

AVEncodeInfoFrame data structure to store as AVFrameSideData of type
AV_FRAME_DATA_ENCODE_INFO.
The structure stores quantization index for each plane, DC/AC deltas
for luma and chroma planes, and an array of AVEncodeInfoBlock type
denoting position, size, and delta quantizer for each block in the
frame.
Can be extended to support extraction of other block information.

Signed-off-by: Juan De León 
---
 libavutil/Makefile  |   2 +
 libavutil/encode_info.c |  70 +
 libavutil/encode_info.h | 110 
 libavutil/frame.c   |   1 +
 libavutil/frame.h   |   7 +++
 5 files changed, 190 insertions(+)
 create mode 100644 libavutil/encode_info.c
 create mode 100644 libavutil/encode_info.h

diff --git a/libavutil/Makefile b/libavutil/Makefile
index 57e6e3d7e8..37cfb099e9 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -24,6 +24,7 @@ HEADERS = adler32.h   
  \
   dict.h\
   display.h \
   downmix_info.h\
+  encode_info.h \
   encryption_info.h \
   error.h   \
   eval.h\
@@ -111,6 +112,7 @@ OBJS = adler32.o
\
dict.o   \
display.o\
downmix_info.o   \
+   encode_info.o\
encryption_info.o\
error.o  \
eval.o   \
diff --git a/libavutil/encode_info.c b/libavutil/encode_info.c
new file mode 100644
index 00..348f7cda29
--- /dev/null
+++ b/libavutil/encode_info.c
@@ -0,0 +1,70 @@
+/*
+ * 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/encode_info.h"
+#include "libavutil/mem.h"
+
+// To prevent overflow, assumes max number = 1px blocks for 8k video.
+#define AV_ENCODE_INFO_MAX_BLOCKS 33177600
+
+static int init_encode_info_data(AVEncodeInfoFrame *info, unsigned int 
nb_blocks) {
+info->nb_blocks = nb_blocks;
+info->block_size = sizeof(AVEncodeInfoBlock);
+info->blocks_offset = offsetof(AVEncodeInfoFrame, blocks);
+
+for(int i = 0; i < AV_NUM_DATA_POINTERS; i++)
+info->plane_q[i] = -1;
+
+return 0;
+}
+
+AVEncodeInfoFrame *av_encode_info_alloc(unsigned int nb_blocks)
+{
+if (nb_blocks > AV_ENCODE_INFO_MAX_BLOCKS)
+return NULL;
+
+//AVEncodeInfoFrame already allocates size for one element of 
AVEncodeInfoBlock
+size_t size = sizeof(AVEncodeInfoFrame) +
+  sizeof(AVEncodeInfoBlock)*(!nb_blocks ? 0 : nb_blocks - 1);
+AVEncodeInfoFrame *ptr = av_mallocz(size);
+if (!ptr)
+return NULL;
+
+init_encode_info_data(ptr, nb_blocks);
+
+return ptr;
+}
+
+AVEncodeInfoFrame *av_encode_info_create_side_data(AVFrame *frame, unsigned 
int nb_blocks)
+{
+if (nb_blocks > AV_ENCODE_INFO_MAX_BLOCKS)
+return NULL;
+
+size_t size = sizeof(AVEncodeInfoFrame) +
+  sizeof(AVEncodeInfoBlock)*(!nb_blocks ? 0 : nb_blocks - 1);
+AVFrameSideData *sd = av_frame_new_side_data(frame,
+ AV_FRAME_DATA_ENCODE_INFO,
+ size);
+if (!sd)
+return NULL;
+
+memset(sd->data, 0, size);
+init_encode_info_data((AVEncodeInfoFrame*)sd->data, nb_blocks);
+
+return (AVEncodeInfoFrame*)sd->data;
+}
diff --git a/libavutil/encode_info.h b/libavutil/encode_info.h
new file mode 100644
index 00..354411b9e1
--- /dev/null
+++ b/libavutil/encode_info.h
@@ -0,0 +1,110 @@
+/*
+ * This file is part o

[FFmpeg-devel] [PATCH 2/3] libavcodec: extractqp changes for h264 decoder

[Juan De León]

Added extractqp flag as an argument to the -debug flag to enable qp extraction
for the h264 decoder using AVEncodeInfo as AVFrameSideData.

Signed-off-by: Juan De León 
---
 libavcodec/avcodec.h   |  1 +
 libavcodec/h264dec.c   | 40 ++
 libavcodec/options_table.h |  1 +
 3 files changed, 42 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index d234271c5b..9e3185720a 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2671,6 +2671,7 @@ typedef struct AVCodecContext {
 #endif
 #define FF_DEBUG_BUFFERS 0x8000
 #define FF_DEBUG_THREADS 0x0001
+#define FF_DEBUG_EXTRACTQP   0x0002
 #define FF_DEBUG_GREEN_MD0x0080
 #define FF_DEBUG_NOMC0x0100
 
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 8d1bd16a8e..1edbfde65e 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -28,6 +28,7 @@
 #define UNCHECKED_BITSTREAM_READER 1
 
 #include "libavutil/avassert.h"
+#include "libavutil/encode_info.h"
 #include "libavutil/display.h"
 #include "libavutil/imgutils.h"
 #include "libavutil/opt.h"
@@ -906,6 +907,45 @@ static int finalize_frame(H264Context *h, AVFrame *dst, 
H264Picture *out, int *g
   f->format, f->width, f->height>>1);
 }
 
+if (h->avctx->debug & FF_DEBUG_EXTRACTQP) {
+int mb_height = h->height / 16;
+int mb_width = h->width / 16;
+int mb_xy = mb_width * mb_height;
+const PPS *pps = (const PPS*)h->ps.pps;
+
+AVEncodeInfoFrame *encode_info = 
av_encode_info_create_side_data(out->f, mb_xy);
+if (!encode_info) {
+av_log(h->avctx, AV_LOG_ERROR, "Failed to allocate encode info 
in side data\n");
+return AVERROR(ENOMEM);
+}
+
+encode_info->plane_q[0] = pps->init_qp; //base Y qp
+if (pps->chroma_qp_index_offset[0] != 0) {
+encode_info->plane_q[1] = pps->init_qp + 
pps->chroma_qp_index_offset[0];
+}
+if (pps->chroma_qp_diff != 0) {
+encode_info->plane_q[2] = pps->init_qp + 
pps->chroma_qp_index_offset[1];
+}
+
+// loop allocate qp
+int qs_index, mb_y, mb_x;
+int idx = 0;
+AVEncodeInfoBlock *block;
+for (mb_y = 0; mb_y < mb_height; mb_y++) {
+for (mb_x = 0; mb_x < mb_width; mb_x++) {
+qs_index = mb_x + mb_y * h->mb_stride; //qscale table index
+
+block = av_encode_info_get_block(encode_info, idx);
+block->src_x = mb_x * 16 - h->crop_left;
+block->src_y = mb_y * 16 - h->crop_top;
+block->w = block->h = 16;
+
+block->delta_q = out->qscale_table[qs_index] - 
pps->init_qp;
+idx++;
+}
+}
+}
+
 ret = output_frame(h, dst, out);
 if (ret < 0)
 return ret;
diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index 4a266eca16..e0e78a69c5 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_table.h
@@ -219,6 +219,7 @@ static const AVOption avcodec_options[] = {
 {"buffers", "picture buffer allocations", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_DEBUG_BUFFERS }, INT_MIN, INT_MAX, V|D, "debug"},
 {"thread_ops", "threading operations", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_DEBUG_THREADS }, INT_MIN, INT_MAX, V|A|D, "debug"},
 {"nomc", "skip motion compensation", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_DEBUG_NOMC }, INT_MIN, INT_MAX, V|A|D, "debug"},
+{"extractqp", "enable QP extraction per frame", 0, AV_OPT_TYPE_CONST, {.i64 = 
FF_DEBUG_EXTRACTQP }, INT_MIN, INT_MAX, V|D, "debug"},
 {"dia_size", "diamond type & size for motion estimation", OFFSET(dia_size), 
AV_OPT_TYPE_INT, {.i64 = DEFAULT }, INT_MIN, INT_MAX, V|E},
 {"last_pred", "amount of motion predictors from the previous frame", 
OFFSET(last_predictor_count), AV_OPT_TYPE_INT, {.i64 = DEFAULT }, INT_MIN, 
INT_MAX, V|E},
 #if FF_API_PRIVATE_OPT
-- 
2.23.0.rc1.153.gdeed80330f-goog

___
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 0/3] AVEncodeInfo and extractqp changes

[Juan De León]

Proposed changes to use AVEncodeInfoFrame and AVencodeInfoBlock
data types as AVFrameSideData, including the changes tothe h264
decoder as well as a filter to output the data extracted.

Filter can be called using:
ffmpeg -debug extractqp -i  -lavfi extractqp=extractqp.log -f null -

More options in filters.texi, libx264 has to be enabled.

doc/filters.texi   |  40 ++
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/vf_extractqp.c | 243 
+
 4 files changed, 285 insertions(+)

libavcodec/avcodec.h   |  1 +
 libavcodec/h264dec.c   | 40 
 libavcodec/options_table.h |  1 +
 3 files changed, 42 insertions(+)

libavutil/Makefile  |   2 ++
 libavutil/encode_info.c |  70 
+
 libavutil/encode_info.h | 110 

 libavutil/frame.c   |   1 +
 libavutil/frame.h   |   7 +++
 5 files changed, 190 insertions(+)



___
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] libavutil: AVEncodeInfo data structures

[Nicolas George]

Juan De León (12019-08-19):
> > > +size_t size = sizeof(AVEncodeInfoFrame) +
> > sizeof(AVEncodeInfoBlock)*FFMAX((int)(nb_blocks - 1), 0);
> >
> > (Commenting from my phone because urgent.)
> > This line do not make sense to me. Can you explain the reason for the
> > cast and how you avoid overflows?
> >
> In AVFrameEncodeInfo the block array is initialized as blocks[1], so when
> allocating memory for the array we must consider 1 block is already
> allocated.
> nb_blocks can be 0, if it is unsigned the subtraction wraps it around to
> UINT_MAX, the cast to int is to prevent that.

The cast to int does not prevent the wrap, because the wrap happens
before the cast. All the cast does is cause an undefined behaviour,
which will in practice yield -1, but then you multiply by a sizeof,
which is unsigned.

> If this is confusing, I think it's better to change it to check for
> nb_blocks > 0 and subtract 1.

Indeed, it is the simplest clean solution. You can do that by swapping
the FFMAX and the subtraction. As it is, the FFMAX does nothing anyway.

Or you can dispense with the FFMAX entirey: sizeof(info) - sizeof(block)
+ n * sizeof(block). It result in allocating an incomplete info
structure, which I think is fine because nothing will access the missing
part.

In any case, you need to check that neither the multiplication nor the
division overflow. And you need to do it beforehand.

Regards,

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

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

[FFmpeg-devel] [PATCH 3/3] libavfilter: extractqp filter

[Juan De León]

Extracts quantization parameters data from AVEncodeInfoFrame side data,
if available, then calculates min/max/avg and outputs the results in a log file.

Signed-off-by: Juan De León 
---
 doc/filters.texi   |  40 ++
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/vf_extractqp.c | 243 +
 4 files changed, 285 insertions(+)
 create mode 100644 libavfilter/vf_extractqp.c

diff --git a/doc/filters.texi b/doc/filters.texi
index e081cdc7bc..46a82b147a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -9607,6 +9607,46 @@ ffmpeg -i video.avi -filter_complex 
'extractplanes=y+u+v[y][u][v]' -map '[y]' y.
 @end example
 @end itemize
 
+@section extractqp
+
+Extracts Quantization Parameters from @code{AVFrameSideData} and calculates 
min/max/avg QP.
+
+QP extraction must be enabled with the option @code{-debug extractqp} before 
decoding the stream and calling the filter.
+
+The filter accepts the following options:
+@table @option
+@item stats_file, f
+If specified, the filter will use the named file to output the QP data. If set 
to '-' the data is sent to standard output.
+@item log
+If specificed, sets the log level for the output out of three options 
(defaults to frame):
+@table @samp
+@item frame
+Default log level. Outputs min/max/avg per frame.
+@item block
+Outputs qp data for every block in each frame.
+@item all
+Outputs min/max/avg and block data per frame.
+@end table
+@end table
+
+Supported decoders:
+@itemize
+@item x264
+@end itemize
+
+@subsection Examples
+
+@itemize
+@item Get QP min/max/avg and store it in QP.log
+@example
+ffmpeg -debug extractqp -i  -lavfi  extractqp="stats_file=QP.log" -f 
null -
+@end example
+@item Output only block data
+@example
+ffmpeg -debug extractqp -i  -lavfi  
extractqp="stats_file=QP.log:log=block" -f null -
+@end example
+@end itemize
+
 @section elbg
 
 Apply a posterize effect using the ELBG (Enhanced LBG) algorithm.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index efc7bbb153..5944558c14 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -231,6 +231,7 @@ OBJS-$(CONFIG_EROSION_FILTER)+= 
vf_neighbor.o
 OBJS-$(CONFIG_EROSION_OPENCL_FILTER) += vf_neighbor_opencl.o opencl.o \
 opencl/neighbor.o
 OBJS-$(CONFIG_EXTRACTPLANES_FILTER)  += vf_extractplanes.o
+OBJS-$(CONFIG_EXTRACTQP_FILTER)  += vf_extractqp.o
 OBJS-$(CONFIG_FADE_FILTER)   += vf_fade.o
 OBJS-$(CONFIG_FFTDNOIZ_FILTER)   += vf_fftdnoiz.o
 OBJS-$(CONFIG_FFTFILT_FILTER)+= vf_fftfilt.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index abd726d616..93ea25401a 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -217,6 +217,7 @@ extern AVFilter ff_vf_eq;
 extern AVFilter ff_vf_erosion;
 extern AVFilter ff_vf_erosion_opencl;
 extern AVFilter ff_vf_extractplanes;
+extern AVFilter ff_vf_extractqp;
 extern AVFilter ff_vf_fade;
 extern AVFilter ff_vf_fftdnoiz;
 extern AVFilter ff_vf_fftfilt;
diff --git a/libavfilter/vf_extractqp.c b/libavfilter/vf_extractqp.c
new file mode 100644
index 00..67a1770849
--- /dev/null
+++ b/libavfilter/vf_extractqp.c
@@ -0,0 +1,243 @@
+/*
+ * 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 
+#include 
+
+#include "libavutil/frame.h"
+#include "libavutil/avstring.h"
+#include "libavutil/opt.h"
+#include "libavutil/encode_info.h"
+#include "libavfilter/avfilter.h"
+#include "libavfilter/internal.h"
+#include "libavfilter/video.h"
+#include "libavformat/avio.h"
+
+// Output flags
+#define EXTRACTQP_LOG_FRAME (1<<0)
+#define EXTRACTQP_LOG_BLOCK (1<<1)
+
+typedef struct ExtractQPContext {
+const AVClass *class;
+int log_level, nb_frames;
+int frame_w, frame_h;
+AVEncodeInfoFrame *frame_info;
+int min_q, max_q;
+double avg_q;
+FILE *stats_file;
+char *stats_file_str;
+AVIOContext *avio_context;
+} ExtractQPContext;
+
+#define OFFSET(x) offsetof(ExtractQPContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+
+static const AVOption extractqp_options[] = {
+{ "stats_file", "Set file to store QP information", 
OFFSET(

Re: [FFmpeg-devel] [PATCH V1 4/5] lavfi/dnn/dnn_backend_native: fix memory leak in error path

[Guo, Yejun]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Jun Zhao
> Sent: Monday, August 19, 2019 9:01 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Jun Zhao 
> Subject: [FFmpeg-devel] [PATCH V1 4/5] lavfi/dnn/dnn_backend_native: fix
> memory leak in error path
> 
> From: Jun Zhao 
> 
> fix memory leak in error path
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavfilter/dnn/dnn_backend_native.c |4 
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/libavfilter/dnn/dnn_backend_native.c
> b/libavfilter/dnn/dnn_backend_native.c
> index 7b489d0..2619463 100644
> --- a/libavfilter/dnn/dnn_backend_native.c
> +++ b/libavfilter/dnn/dnn_backend_native.c
> @@ -183,6 +183,7 @@ DNNModel *ff_dnn_load_model_native(const char
> *model_filename)
>  if (dnn_size > file_size || conv_params->input_num <= 0 ||
>  conv_params->output_num <= 0 ||
> conv_params->kernel_size <= 0){
>  avio_closep(&model_file_context);
> +av_freep(&conv_params);
>  ff_dnn_free_model_native(&model);
>  return NULL;
>  }
> @@ -190,6 +191,9 @@ DNNModel *ff_dnn_load_model_native(const char
> *model_filename)
>  conv_params->biases = av_malloc(conv_params->output_num
> * sizeof(float));
>  if (!conv_params->kernel || !conv_params->biases){
>  avio_closep(&model_file_context);
> +av_freep(&conv_params->kernel);
> +av_freep(&conv_params->biases);
> +av_freep(&conv_params);
>  ff_dnn_free_model_native(&model);
>  return NULL;
>  }

LGTM, thanks.

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

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

Re: [FFmpeg-devel] [PATCH V1 3/5] lavfi/dnn/dnn_backend_native: Refine the coding style

[Guo, Yejun]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Jun Zhao
> Sent: Monday, August 19, 2019 9:01 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Jun Zhao 
> Subject: [FFmpeg-devel] [PATCH V1 3/5] lavfi/dnn/dnn_backend_native: Refine
> the coding style
> 
> From: Jun Zhao 
> 
> We perfer the coding style like:
> 
> /* some stuff */
> if (error) {
> /* error handling */
> return -(errorcode);
> }
> /* normal actions */
> do_something()

as mentioned in 
http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/247887.html, I've finished
some more patches at https://github.com/guoyejun/ffmpeg/commits/dnn0809 waiting 
for send out set by set.

The next patch I plan to send is 
https://github.com/guoyejun/ffmpeg/commit/02567319a640bb3d150917dfc6cf5e047a4bb776,
which includes the changes in this patch, and it includes more changes to 
support operand concept in native mode.

It would be convenient for me to not split that patch, could this patch be 
ignored? thanks.

> 
> Signed-off-by: Jun Zhao 
> ---
>  libavfilter/dnn/dnn_backend_native.c |   24 +++-
>  1 files changed, 11 insertions(+), 13 deletions(-)
> 
> diff --git a/libavfilter/dnn/dnn_backend_native.c
> b/libavfilter/dnn/dnn_backend_native.c
> index 09c583b..7b489d0 100644
> --- a/libavfilter/dnn/dnn_backend_native.c
> +++ b/libavfilter/dnn/dnn_backend_native.c
> @@ -40,19 +40,17 @@ static DNNReturnType set_input_output_native(void
> *model, DNNInputData *input, c
>  if (network->layers_num <= 0 || network->layers[0].type != INPUT){
>  return DNN_ERROR;
>  }
> -else{
> -input_params = (InputParams *)network->layers[0].params;
> -input_params->width = cur_width = input->width;
> -input_params->height = cur_height = input->height;
> -input_params->channels = cur_channels = input->channels;
> -if (input->data){
> -av_freep(&input->data);
> -}
> -av_assert0(input->dt == DNN_FLOAT);
> -network->layers[0].output = input->data = av_malloc(cur_height *
> cur_width * cur_channels * sizeof(float));
> -if (!network->layers[0].output){
> -return DNN_ERROR;
> -}
> +input_params = (InputParams *)network->layers[0].params;
> +input_params->width = cur_width = input->width;
> +input_params->height = cur_height = input->height;
> +input_params->channels = cur_channels = input->channels;
> +if (input->data){
> +av_freep(&input->data);
> +}
> +av_assert0(input->dt == DNN_FLOAT);
> +network->layers[0].output = input->data = av_malloc(cur_height *
> cur_width * cur_channels * sizeof(float));
> +if (!network->layers[0].output){
> +return DNN_ERROR;
>  }
> 
>  for (layer = 1; layer < network->layers_num; ++layer){
> --
> 1.7.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

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

[Nikolas Bowe]

Fixes "Invalid data found when processing input" on some JPEGs.

Some large extensionless JPEGs can get probe score collisions.
eg
$ ffprobe -loglevel trace  /tmp/foo
[NULL @ 0x55c130ab04c0] Opening '/tmp/foo' for reading
[file @ 0x55c130ab0f40] Setting default whitelist 'file,crypto'
Probing jpeg_pipe score:6 size:2048
Probing jpeg_pipe score:6 size:4096
Probing jpeg_pipe score:6 size:8192
Probing jpeg_pipe score:6 size:16384
Probing jpeg_pipe score:25 size:32768
Probing jpeg_pipe score:25 size:65536
Probing jpeg_pipe score:25 size:131072
Probing jpeg_pipe score:25 size:262144
Probing jpeg_pipe score:25 size:524288
Probing mpeg score:25 size:1048576
Probing jpeg_pipe score:25 size:1048576
[AVIOContext @ 0x55c130ab9300] Statistics: 1048576 bytes read, 0 seeks
/tmp/foo: Invalid data found when processing input

This patch fixes this by bumping the score in the start-of-scan data.
---
Fixes adsadasda
asd


 libavformat/img2dec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index f8b4a655a5..cb582f97cb 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -767,7 +767,7 @@ static int jpeg_probe(const AVProbeData *p)
 if (state == EOI)
 return AVPROBE_SCORE_EXTENSION + 1;
 if (state == SOS)
-return AVPROBE_SCORE_EXTENSION / 2;
+return AVPROBE_SCORE_EXTENSION / 2 + 1;
 return AVPROBE_SCORE_EXTENSION / 8;
 }
 
-- 
2.23.0.rc1.153.gdeed80330f-goog

___
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 v1] lavf/hlsenc: fix one warning: unused variable 'filename' [-Wunused-variable]

[Liu Steven]

> 在 2019年8月19日，上午11:14，Liu Steven  写道：
> 
> 
> 
>> 在 2019年8月19日，上午9:42，lance.lmw...@gmail.com 写道：
>> 
>> From: Limin Wang 
>> 
>> Signed-off-by: Limin Wang 
>> ---
>> libavformat/hlsenc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index f6f9c8161d..149b2a3bd0 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -1571,7 +1571,7 @@ static int hls_start(AVFormatContext *s, VariantStream 
>> *vs)
>>AVDictionary *options = NULL;
>>const char *proto = NULL;
>>int use_temp_file = 0;
>> -char *filename, iv_string[KEYSIZE*2 + 1];
>> +char iv_string[KEYSIZE*2 + 1];
>>int err = 0;
>> 
>>if (c->flags & HLS_SINGLE_FILE) {
>> -- 
>> 2.21.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".
> 
> 
> LGTM
Applied

> 
> 
> 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 V1 5/5] lavf/hlsenc: free the old_filname to avoid memory leak

[Liu Steven]

> 在 2019年8月19日，下午9:01，Jun Zhao  写道：
> 
> From: Jun Zhao 
> 
> free the old_filname to avoid memory leak in error handle
> path.
> 
> Signed-off-by: Jun Zhao 
> ---
> libavformat/hlsenc.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index f6f9c81..9099c84 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2428,6 +2428,7 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
> // if we're building a VOD playlist, skip writing the manifest 
> multiple times, and just wait until the end
> if (hls->pl_type != PLAYLIST_TYPE_VOD) {
> if ((ret = hls_window(s, 0, vs)) < 0) {
> +av_free(old_filename);
> return ret;
> }
> }
> -- 
> 1.7.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".

LGTM  applied


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

[Jun Li]

On Mon, Aug 19, 2019 at 3:45 PM James Almer  wrote:

> On 8/18/2019 10:41 PM, Jun Li wrote:
> > Fix #6591
> > The content has no rbsp_stop_one_bit for ending the SPS, that
> > causes the decoding SPS failure, results decoding frame failure as well.
> > The patch is just adding a retry with complete NALU.
> > ---
> >  libavcodec/h264_parse.c | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
> > index ac31f54e07..a2267a0610 100644
> > --- a/libavcodec/h264_parse.c
> > +++ b/libavcodec/h264_parse.c
> > @@ -376,8 +376,14 @@ static int decode_extradata_ps(const uint8_t *data,
> int size, H264ParamSets *ps,
> >  switch (nal->type) {
> >  case H264_NAL_SPS:
> >  ret = ff_h264_decode_seq_parameter_set(&nal->gb, logctx,
> ps, 0);
> > -if (ret < 0)
> > -goto fail;
> > +if (ret < 0) {
> > +GetBitContext tmp_gb = nal->gb;
> > +av_log(logctx, AV_LOG_DEBUG,
> > +   "SPS decoding failure (maybe missing
> rbsp_stop_one_bit), trying again with the complete NAL\n");
> > +init_get_bits8(&tmp_gb, nal->raw_data + 1,
> nal->raw_size - 1);
> > +if ((ret = ff_h264_decode_seq_parameter_set(&tmp_gb,
> logctx, ps, 0)) < 0)
> > +goto fail;
> > +}
> >  break;
> >  case H264_NAL_PPS:
> >  ret = ff_h264_decode_picture_parameter_set(&nal->gb,
> logctx, ps,
>
> Copy instead the code from decode_nal_units() in h264dec.c, which checks
> first with the complete NAL, and then calls
> ff_h264_decode_seq_parameter_set() with the ignore_truncation parameter
> set to 1 as a last resort.
>

Hi James,
My first try was set the ignore_truncation to 1 but then found that
decode_nal_units is already handling this using a different approach.
So I just copied the code here, but without last try ignore_truncation=1.

Are you suggesting modifying the commit message or comment identifying the
code is copied from decide_nal_units, or extract them to one function and
reuse two places ?

-Jun


> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
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 v1] avcodec/h264_parse: retry decoding SPS with complete NAL

[James Almer]

On 8/19/2019 10:39 PM, Jun Li wrote:
> On Mon, Aug 19, 2019 at 3:45 PM James Almer  wrote:
> 
>> On 8/18/2019 10:41 PM, Jun Li wrote:
>>> Fix #6591
>>> The content has no rbsp_stop_one_bit for ending the SPS, that
>>> causes the decoding SPS failure, results decoding frame failure as well.
>>> The patch is just adding a retry with complete NALU.
>>> ---
>>>  libavcodec/h264_parse.c | 10 --
>>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
>>> index ac31f54e07..a2267a0610 100644
>>> --- a/libavcodec/h264_parse.c
>>> +++ b/libavcodec/h264_parse.c
>>> @@ -376,8 +376,14 @@ static int decode_extradata_ps(const uint8_t *data,
>> int size, H264ParamSets *ps,
>>>  switch (nal->type) {
>>>  case H264_NAL_SPS:
>>>  ret = ff_h264_decode_seq_parameter_set(&nal->gb, logctx,
>> ps, 0);
>>> -if (ret < 0)
>>> -goto fail;
>>> +if (ret < 0) {
>>> +GetBitContext tmp_gb = nal->gb;
>>> +av_log(logctx, AV_LOG_DEBUG,
>>> +   "SPS decoding failure (maybe missing
>> rbsp_stop_one_bit), trying again with the complete NAL\n");
>>> +init_get_bits8(&tmp_gb, nal->raw_data + 1,
>> nal->raw_size - 1);
>>> +if ((ret = ff_h264_decode_seq_parameter_set(&tmp_gb,
>> logctx, ps, 0)) < 0)
>>> +goto fail;
>>> +}
>>>  break;
>>>  case H264_NAL_PPS:
>>>  ret = ff_h264_decode_picture_parameter_set(&nal->gb,
>> logctx, ps,
>>
>> Copy instead the code from decode_nal_units() in h264dec.c, which checks
>> first with the complete NAL, and then calls
>> ff_h264_decode_seq_parameter_set() with the ignore_truncation parameter
>> set to 1 as a last resort.
>>
> 
> Hi James,
> My first try was set the ignore_truncation to 1 but then found that
> decode_nal_units is already handling this using a different approach.
> So I just copied the code here, but without last try ignore_truncation=1.
> 
> Are you suggesting modifying the commit message or comment identifying the
> code is copied from decide_nal_units, or extract them to one function and
> reuse two places ?

My suggestion was to copy the decode_nal_units approach here including
the last try ignore_truncation=1 call.

> 
> -Jun
> 
> 
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> 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 V1 2/5] lavfi/avfiltergraph: add check before free the format

[myp...@gmail.com]

On Mon, Aug 19, 2019 at 9:09 PM Paul B Mahol  wrote:
>
> LGTM
>

Will apply, 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 V1 1/5] lavfi/af_adeclick: fix double free after ff_filter_frame fail

[myp...@gmail.com]

On Mon, Aug 19, 2019 at 9:14 PM Paul B Mahol  wrote:
>
> LGTM
>
Will apply, 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 V1 4/5] lavfi/dnn/dnn_backend_native: fix memory leak in error path

[myp...@gmail.com]

On Tue, Aug 20, 2019 at 9:14 AM Guo, Yejun  wrote:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > Jun Zhao
> > Sent: Monday, August 19, 2019 9:01 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Jun Zhao 
> > Subject: [FFmpeg-devel] [PATCH V1 4/5] lavfi/dnn/dnn_backend_native: fix
> > memory leak in error path
> >
> > From: Jun Zhao 
> >
> > fix memory leak in error path
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavfilter/dnn/dnn_backend_native.c |4 
> >  1 files changed, 4 insertions(+), 0 deletions(-)
> >
> > diff --git a/libavfilter/dnn/dnn_backend_native.c
> > b/libavfilter/dnn/dnn_backend_native.c
> > index 7b489d0..2619463 100644
> > --- a/libavfilter/dnn/dnn_backend_native.c
> > +++ b/libavfilter/dnn/dnn_backend_native.c
> > @@ -183,6 +183,7 @@ DNNModel *ff_dnn_load_model_native(const char
> > *model_filename)
> >  if (dnn_size > file_size || conv_params->input_num <= 0 ||
> >  conv_params->output_num <= 0 ||
> > conv_params->kernel_size <= 0){
> >  avio_closep(&model_file_context);
> > +av_freep(&conv_params);
> >  ff_dnn_free_model_native(&model);
> >  return NULL;
> >  }
> > @@ -190,6 +191,9 @@ DNNModel *ff_dnn_load_model_native(const char
> > *model_filename)
> >  conv_params->biases = av_malloc(conv_params->output_num
> > * sizeof(float));
> >  if (!conv_params->kernel || !conv_params->biases){
> >  avio_closep(&model_file_context);
> > +av_freep(&conv_params->kernel);
> > +av_freep(&conv_params->biases);
> > +av_freep(&conv_params);
> >  ff_dnn_free_model_native(&model);
> >  return NULL;
> >  }
>
> LGTM, thanks.
>
Will apply, 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 V1 3/5] lavfi/dnn/dnn_backend_native: Refine the coding style

[myp...@gmail.com]

On Tue, Aug 20, 2019 at 9:31 AM Guo, Yejun  wrote:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > Jun Zhao
> > Sent: Monday, August 19, 2019 9:01 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Jun Zhao 
> > Subject: [FFmpeg-devel] [PATCH V1 3/5] lavfi/dnn/dnn_backend_native: Refine
> > the coding style
> >
> > From: Jun Zhao 
> >
> > We perfer the coding style like:
> >
> > /* some stuff */
> > if (error) {
> > /* error handling */
> > return -(errorcode);
> > }
> > /* normal actions */
> > do_something()
>
> as mentioned in 
> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/247887.html, I've 
> finished
> some more patches at https://github.com/guoyejun/ffmpeg/commits/dnn0809 
> waiting for send out set by set.
>
> The next patch I plan to send is 
> https://github.com/guoyejun/ffmpeg/commit/02567319a640bb3d150917dfc6cf5e047a4bb776,
> which includes the changes in this patch, and it includes more changes to 
> support operand concept in native mode.
>
> It would be convenient for me to not split that patch, could this patch be 
> ignored? thanks.
>
Please continue this patch set, will hold on this patch. 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] avformat: Fix probing on some JPEGs

[Carl Eugen Hoyos]

Am Di., 20. Aug. 2019 um 03:37 Uhr schrieb Nikolas Bowe
:
>
> Fixes "Invalid data found when processing input" on some JPEGs.
>
> Some large extensionless JPEGs can get probe score collisions.
> eg
> $ ffprobe -loglevel trace  /tmp/foo
> [NULL @ 0x55c130ab04c0] Opening '/tmp/foo' for reading
> [file @ 0x55c130ab0f40] Setting default whitelist 'file,crypto'
> Probing jpeg_pipe score:6 size:2048
> Probing jpeg_pipe score:6 size:4096
> Probing jpeg_pipe score:6 size:8192
> Probing jpeg_pipe score:6 size:16384
> Probing jpeg_pipe score:25 size:32768
> Probing jpeg_pipe score:25 size:65536
> Probing jpeg_pipe score:25 size:131072
> Probing jpeg_pipe score:25 size:262144
> Probing jpeg_pipe score:25 size:524288
> Probing mpeg score:25 size:1048576
> Probing jpeg_pipe score:25 size:1048576
> [AVIOContext @ 0x55c130ab9300] Statistics: 1048576 bytes read, 0 seeks
> /tmp/foo: Invalid data found when processing input
>
> This patch fixes this by bumping the score in the start-of-scan data.
> ---
> Fixes adsadasda
> asd
>
>
>  libavformat/img2dec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> index f8b4a655a5..cb582f97cb 100644
> --- a/libavformat/img2dec.c
> +++ b/libavformat/img2dec.c
> @@ -767,7 +767,7 @@ static int jpeg_probe(const AVProbeData *p)
>  if (state == EOI)
>  return AVPROBE_SCORE_EXTENSION + 1;
>  if (state == SOS)
> -return AVPROBE_SCORE_EXTENSION / 2;
> +return AVPROBE_SCORE_EXTENSION / 2 + 1;

This score would mean that mjpeg can never be detected.
I suspect you have to reduce one of the demuxers to "- 1".

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

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

[FFmpeg-devel] [PATCH v2] avcodec/h264_parse: retry decoding SPS with complete NAL

[Jun Li]

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

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

diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
index ac31f54e07..ea7a958dd9 100644
--- a/libavcodec/h264_parse.c
+++ b/libavcodec/h264_parse.c
@@ -376,8 +376,15 @@ static int decode_extradata_ps(const uint8_t *data, int 
size, H264ParamSets *ps,
 switch (nal->type) {
 case H264_NAL_SPS:
 ret = ff_h264_decode_seq_parameter_set(&nal->gb, logctx, ps, 0);
-if (ret < 0)
-goto fail;
+if (ret < 0) {
+GetBitContext tmp_gb = nal->gb;
+av_log(logctx, AV_LOG_DEBUG,
+   "SPS decoding failure, trying again with the complete 
NAL\n");
+init_get_bits8(&tmp_gb, nal->raw_data + 1, nal->raw_size - 1);
+if ((ret = ff_h264_decode_seq_parameter_set(&tmp_gb, logctx, 
ps, 0)) < 0 &&
+(ret = ff_h264_decode_seq_parameter_set(&tmp_gb, logctx, 
ps, 1)) < 0)
+goto fail;
+}
 break;
 case H264_NAL_PPS:
 ret = ff_h264_decode_picture_parameter_set(&nal->gb, logctx, ps,
-- 
2.17.1

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

[Jun Li]

On Mon, Aug 19, 2019 at 6:55 PM James Almer  wrote:

> On 8/19/2019 10:39 PM, Jun Li wrote:
> > On Mon, Aug 19, 2019 at 3:45 PM James Almer  wrote:
> >
> >> On 8/18/2019 10:41 PM, Jun Li wrote:
> >>> Fix #6591
> >>> The content has no rbsp_stop_one_bit for ending the SPS, that
> >>> causes the decoding SPS failure, results decoding frame failure as
> well.
> >>> The patch is just adding a retry with complete NALU.
> >>> ---
> >>>  libavcodec/h264_parse.c | 10 --
> >>>  1 file changed, 8 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
> >>> index ac31f54e07..a2267a0610 100644
> >>> --- a/libavcodec/h264_parse.c
> >>> +++ b/libavcodec/h264_parse.c
> >>> @@ -376,8 +376,14 @@ static int decode_extradata_ps(const uint8_t
> *data,
> >> int size, H264ParamSets *ps,
> >>>  switch (nal->type) {
> >>>  case H264_NAL_SPS:
> >>>  ret = ff_h264_decode_seq_parameter_set(&nal->gb, logctx,
> >> ps, 0);
> >>> -if (ret < 0)
> >>> -goto fail;
> >>> +if (ret < 0) {
> >>> +GetBitContext tmp_gb = nal->gb;
> >>> +av_log(logctx, AV_LOG_DEBUG,
> >>> +   "SPS decoding failure (maybe missing
> >> rbsp_stop_one_bit), trying again with the complete NAL\n");
> >>> +init_get_bits8(&tmp_gb, nal->raw_data + 1,
> >> nal->raw_size - 1);
> >>> +if ((ret = ff_h264_decode_seq_parameter_set(&tmp_gb,
> >> logctx, ps, 0)) < 0)
> >>> +goto fail;
> >>> +}
> >>>  break;
> >>>  case H264_NAL_PPS:
> >>>  ret = ff_h264_decode_picture_parameter_set(&nal->gb,
> >> logctx, ps,
> >>
> >> Copy instead the code from decode_nal_units() in h264dec.c, which checks
> >> first with the complete NAL, and then calls
> >> ff_h264_decode_seq_parameter_set() with the ignore_truncation parameter
> >> set to 1 as a last resort.
> >>
> >
> > Hi James,
> > My first try was set the ignore_truncation to 1 but then found that
> > decode_nal_units is already handling this using a different approach.
> > So I just copied the code here, but without last try ignore_truncation=1.
> >
> > Are you suggesting modifying the commit message or comment identifying
> the
> > code is copied from decide_nal_units, or extract them to one function and
> > reuse two places ?
>
> My suggestion was to copy the decode_nal_units approach here including
> the last try ignore_truncation=1 call.


Thanks for the input, I updated version 2 accordingly.
https://patchwork.ffmpeg.org/patch/14604/


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

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

Re: [FFmpeg-devel] [PATCH v2] hevc_mp4toannexb: Insert correct parameter sets before IRAP

[Andriy Gelman]

On Tue, 20. Aug 01:01, Michael Niedermayer wrote:
> On Sun, Aug 18, 2019 at 10:37:57PM -0400, Andriy Gelman wrote:
> [...]
> > diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
> > index 559c3898bc..46f130f4d1 100644
> > --- a/tests/fate/hevc.mak
> > +++ b/tests/fate/hevc.mak
> > @@ -238,7 +238,7 @@ FATE_HEVC-$(call ALLYES, HEVC_DEMUXER MOV_DEMUXER 
> > HEVC_MP4TOANNEXB_BSF MOV_MUXER
> >  fate-hevc-bsf-mp4toannexb: tests/data/hevc-mp4.mov
> >  fate-hevc-bsf-mp4toannexb: CMD = md5 -i 
> > $(TARGET_PATH)/tests/data/hevc-mp4.mov -c:v copy -fflags +bitexact -f hevc
> >  fate-hevc-bsf-mp4toannexb: CMP = oneline
> > -fate-hevc-bsf-mp4toannexb: REF = 1873662a3af1848c37e4eb25722c8df9
> > +fate-hevc-bsf-mp4toannexb: REF = d41d8cd98f00b204e9800998ecf8427e
> 
> is it intended that this is empty ?
> touch zero
>  md5sum zero
> d41d8cd98f00b204e9800998ecf8427e  zero

Sorry, the correct value should be 2e9f6a1b7dd8c7a6fd465622af06626b
I'll update this in the next iteration

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 v2 5/8] avformat/utils: Fix memleaks II

[myp...@gmail.com]

On Tue, Aug 20, 2019 at 6:11 AM Andreas Rheinhardt
 wrote:
>
> Up until now, avformat_find_stream_info had a potential for memleaks:
> When everything is fine, it read packets and (depending upon whether
> AVFMT_FLAG_NOBUFFER was set) put them in a packet list or unreferenced
> them when they were no longer needed. But upon failure, said packets
> would leak if they were not already on the packet list. This patch fixes
> this.
>
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/utils.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index bae2f9e0db..96c02bb7fc 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -3801,7 +3801,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>   &ic->internal->packet_buffer_end,
>   &pkt1, 0);
>  if (ret < 0)
> -goto find_stream_info_err;
> +goto unref_then_goto_end;
>
>  pkt = &ic->internal->packet_buffer_end->pkt;
>  } else {
> @@ -3816,7 +3816,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  if (!st->internal->avctx_inited) {
>  ret = avcodec_parameters_to_context(avctx, st->codecpar);
>  if (ret < 0)
> -goto find_stream_info_err;
> +goto unref_then_goto_end;
>  st->internal->avctx_inited = 1;
>  }
>
> @@ -3904,7 +3904,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  if (!st->internal->avctx->extradata) {
>  ret = extract_extradata(st, pkt);
>  if (ret < 0)
> -goto find_stream_info_err;
> +goto unref_then_goto_end;
>  }
>
>  /* If still no information, we try to open the codec and to
> @@ -4180,6 +4180,10 @@ find_stream_info_err:
>  av_log(ic, AV_LOG_DEBUG, "After avformat_find_stream_info() pos: 
> %"PRId64" bytes read:%"PRId64" seeks:%d frames:%d\n",
> avio_tell(ic->pb), ic->pb->bytes_read, ic->pb->seek_count, 
> count);
>  return ret;
> +
> +unref_then_goto_end:
> +av_packet_unref(&pkt1);
> +goto find_stream_info_err;
goto follow a goto, you can just add av_packet_unref(&pkt1) before
jump to the label find_stream_info_err.
>  }
>
___
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] [CALL] New FFmpeg developers meeting

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Jean-Baptiste Kempf
> Sent: Monday, August 19, 2019 2:18 PM
> To: ffmpeg-devel 
> Subject: Re: [FFmpeg-devel] [CALL] New FFmpeg developers meeting
> 
> On Sat, Aug 17, 2019, at 11:48, Paul B Mahol wrote:
> > When and how to organize this?
> 
> You have the choice:
> - IBC
> - GSoC summit
> - VDD

Have the conference time and place been decided for this year's VDD?
___
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 5/8] avformat/utils: Fix memleaks II

[Andreas Rheinhardt]

myp...@gmail.com:
> On Tue, Aug 20, 2019 at 6:11 AM Andreas Rheinhardt
>  wrote:
>>
>> Up until now, avformat_find_stream_info had a potential for memleaks:
>> When everything is fine, it read packets and (depending upon whether
>> AVFMT_FLAG_NOBUFFER was set) put them in a packet list or unreferenced
>> them when they were no longer needed. But upon failure, said packets
>> would leak if they were not already on the packet list. This patch fixes
>> this.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  libavformat/utils.c | 10 +++---
>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>> index bae2f9e0db..96c02bb7fc 100644
>> --- a/libavformat/utils.c
>> +++ b/libavformat/utils.c
>> @@ -3801,7 +3801,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>>   &ic->internal->packet_buffer_end,
>>   &pkt1, 0);
>>  if (ret < 0)
>> -goto find_stream_info_err;
>> +goto unref_then_goto_end;
>>
>>  pkt = &ic->internal->packet_buffer_end->pkt;
>>  } else {
>> @@ -3816,7 +3816,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>>  if (!st->internal->avctx_inited) {
>>  ret = avcodec_parameters_to_context(avctx, st->codecpar);
>>  if (ret < 0)
>> -goto find_stream_info_err;
>> +goto unref_then_goto_end;
>>  st->internal->avctx_inited = 1;
>>  }
>>
>> @@ -3904,7 +3904,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>>  if (!st->internal->avctx->extradata) {
>>  ret = extract_extradata(st, pkt);
>>  if (ret < 0)
>> -goto find_stream_info_err;
>> +goto unref_then_goto_end;
>>  }
>>
>>  /* If still no information, we try to open the codec and to
>> @@ -4180,6 +4180,10 @@ find_stream_info_err:
>>  av_log(ic, AV_LOG_DEBUG, "After avformat_find_stream_info() pos: 
>> %"PRId64" bytes read:%"PRId64" seeks:%d frames:%d\n",
>> avio_tell(ic->pb), ic->pb->bytes_read, ic->pb->seek_count, 
>> count);
>>  return ret;
>> +
>> +unref_then_goto_end:
>> +av_packet_unref(&pkt1);
>> +goto find_stream_info_err;
> goto follow a goto, you can just add av_packet_unref(&pkt1) before
> jump to the label find_stream_info_err.

But then I'd have to add three av_packet_unref.

- 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] avdevice/decklink: adjust for timecode lag

[Gyan]

On 19-08-2019 07:15 PM, Ilinca Tudose wrote:

Hi Marton,

I want to confirm that we get correctly synced TCs when leaving out the
format_code parameter and using an ffmpeg build from head (not with Gyan's
patch). However, I was under the impression that we need the format_code so
that we can capture different content types, in the original format. For
example multiple frame rates or interlaced content. How would we set this
up if we are not using format_code? Is this identified automatically?


A couple of follow-up Qs:

Is auto-detection available for all Decklink devices?

For those for which it is available, are there any edge cases in which 
it sets inaccurate mode?


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