Re: [FFmpeg-devel] [PATCH, v2] lavc/qsvenc: Fix the memory leak for enc_ctrl.Payload

2019-05-21 Thread Fu, Linjie
> -Original Message-
> From: Li, Zhong
> Sent: Monday, April 29, 2019 17:00
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: RE: [FFmpeg-devel] [PATCH, v2] lavc/qsvenc: Fix the memory leak
> for enc_ctrl.Payload
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Linjie Fu
> > Sent: Monday, April 15, 2019 9:23 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie 
> > Subject: [FFmpeg-devel] [PATCH, v2] lavc/qsvenc: Fix the memory leak for
> > enc_ctrl.Payload
> >
> > frame->enc_ctrl.Payload is malloced in get_free_frame, directly memset
> > the whole structure of enc_ctrl to zero will cause the memory leak for
> > enc_ctrl.Payload.
> >
> > frame->enc_ctrl as a structure will be malloc and init to zero by
> > frame->calling
> > frame = av_mallocz(sizeof(*frame)), so the memset is redundant and can
> be
> > removed.
> >
> > Can be reproduced by #7830.
> 
> Patch LGTM now, but I can't see strong relationship between this patch and
> tikect #7830.
> IMHO this is a quite common issue even if you use qsv transcoding pipeline?

Yes, it's not strongly related with the issue. Remove this would be fine.
Thanks.

> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/qsvenc.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index
> > 5aa020d47b..19953bd4ea 100644
> > --- a/libavcodec/qsvenc.c
> > +++ b/libavcodec/qsvenc.c
> > @@ -1254,7 +1254,6 @@ static int encode_frame(AVCodecContext *avctx,
> > QSVEncContext *q,
> >  if (qsv_frame) {
> >  surf = _frame->surface;
> >  enc_ctrl = _frame->enc_ctrl;
> > -memset(enc_ctrl, 0, sizeof(mfxEncodeCtrl));
> >
> >  if (frame->pict_type == AV_PICTURE_TYPE_I) {
> >  enc_ctrl->FrameType = MFX_FRAMETYPE_I |
> > MFX_FRAMETYPE_REF;
> > --
> > 2.17.1

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

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

[FFmpeg-devel] [PATCH V1] doc/build_system: Document checkheaders/alltools and consistency fixes

2019-05-21 Thread Jun Zhao
From: Jun Zhao 

Document checkheaders/alltools and consistency fixes

Signed-off-by: Jun Zhao 
---
 doc/build_system.txt |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/build_system.txt b/doc/build_system.txt
index 325a9e8..9a12b3a 100644
--- a/doc/build_system.txt
+++ b/doc/build_system.txt
@@ -36,11 +36,11 @@ install
 examples
 Build all examples located in doc/examples.
 
-libavformat/output-example
-Build the libavformat basic example.
+checkheaders
+Check headers
 
-libswscale/swscale-test
-Build the swscale self-test (useful also as an example).
+alltools
+Build all tools in tools directory.
 
 config
 Reconfigure the project with the current configuration.
-- 
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 1/2] lavf/vf_vpp_qsv: add transpose support for QSV VPP

2019-05-21 Thread Fu, Linjie
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Monday, March 18, 2019 13:35
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Mark Thompson 
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavf/vf_vpp_qsv: add transpose
> support for QSV VPP
> 
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Mark Thompson
> > Sent: Sunday, March 17, 2019 21:59
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavf/vf_vpp_qsv: add transpose
> > support for QSV VPP
> >
> > On 15/03/2019 16:34, Linjie Fu wrote:
> > > Add transpose support for qsv_vpp:
> > > - rotation: [0, 3] support clockwise rotation of 0, 90, 180, 270;
> > > - mirror:   [0, 1] support horizontal mirroring;
> > >
> > > ffmpeg -hwaccel qsv -v verbose -c:v h264_qsv -i input.h264
> > > -vf 'format=qsv,vpp_qsv=rotation=1' -c:v h264_qsv output.h264
> > > ffmpeg -hwaccel qsv -v verbose -c:v h264_qsv -i input.h264
> > > -vf 'format=qsv,vpp_qsv=mirror=1' -c:v h264_qsv output.h264
> > > ffmpeg -hwaccel qsv -v verbose -c:v h264_qsv -i input.h264
> > > -vf 'format=qsv,vpp_qsv=rotation=2,vpp_qsv=mirror=1' -c:v h264_qsv
> > output.h264
> > >
> > > Signed-off-by: Linjie Fu 
> > > ---
> > >  libavfilter/vf_vpp_qsv.c | 45
> > ++--
> > >  1 file changed, 43 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
> > > index 41a9f38962..edbe944321 100644
> > > --- a/libavfilter/vf_vpp_qsv.c
> > > +++ b/libavfilter/vf_vpp_qsv.c
> > > @@ -41,7 +41,9 @@
> > >  #define FLAGS (AV_OPT_FLAG_VIDEO_PARAM |
> > AV_OPT_FLAG_FILTERING_PARAM)
> > >
> > >  /* number of video enhancement filters */
> > > -#define ENH_FILTERS_COUNT (5)
> > > +#define ENH_FILTERS_COUNT (7)
> > > +#define QSV_HAVE_ROTATION  QSV_VERSION_ATLEAST(1, 17)
> > > +#define QSV_HAVE_MIRRORING QSV_VERSION_ATLEAST(1, 19)
> > >
> > >  typedef struct VPPContext{
> > >  const AVClass *class;
> > > @@ -54,6 +56,8 @@ typedef struct VPPContext{
> > >  mfxExtVPPDenoise denoise_conf;
> > >  mfxExtVPPDetail detail_conf;
> > >  mfxExtVPPProcAmp procamp_conf;
> > > +mfxExtVPPRotation rotation_conf;
> > > +mfxExtVPPMirroring mirroring_conf;
> > >
> > >  int out_width;
> > >  int out_height;
> > > @@ -70,6 +74,9 @@ typedef struct VPPContext{
> > >  int crop_x;
> > >  int crop_y;
> > >
> > > +int rotation;   /* rotation mode : 0=0, 1=90, 2=180, 
> > > 3=270 */
> > > +int mirror; /* mirror mode : 0=off, 1=HORIZONTAL */
> > > +
> > >  /* param for the procamp */
> > >  intprocamp;/* enable procamp */
> > >  float  hue;
> > > @@ -95,6 +102,9 @@ static const AVOption options[] = {
> > >  { "contrast","ProcAmp contrast", OFFSET(contrast),
> > AV_OPT_TYPE_FLOAT,{ .dbl = 1.0 }, 0.0, 10.0, .flags = FLAGS},
> > >  { "brightness",  "ProcAmp brightness",   OFFSET(brightness),
> > AV_OPT_TYPE_FLOAT,{ .dbl = 0.0 }, -100.0, 100.0, .flags = FLAGS},
> > >
> > > +{ "rotation","clockwise rotation: 90 * [0, 3]", OFFSET(rotation),
> > AV_OPT_TYPE_INT,  { .i64 = 0 }, 0, 3, .flags = FLAGS},
> > > +{ "mirror",  "horizontal mirror [0, 1]",OFFSET(mirror),
> > AV_OPT_TYPE_INT,  { .i64 = 0 }, 0, 1, .flags = FLAGS},
> >
> > Please use the same names as other filters doing transpose/rotate
> > operations.
> >
> Is it acceptable updating the names into "rotate" and "hflip" separately?
> Or they should be combined into "transpose" like vaapi_transpose does?
> >
> > I think there should be something to make the default behaviour for the
> > cases where you would expect the axes to be swapped to do that.  It
> would
> > be surprising for rotating a portait 1080x1920 input to produce a squashed
> > 1080x1920 output rather than 1920x1080.
> 
> Thanks, will add FFSWAP(int, vpp->out_width, vpp->out_height) to swap
> width
> and height for clock/cclock rotation.

Ping for the updated patch?
https://patchwork.ffmpeg.org/patch/12351/

___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavfi/colorlevels: Add slice threading support

2019-05-21 Thread Li, Zhong
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Jun Zhao
> Sent: Tuesday, May 21, 2019 7:21 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Jun Zhao 
> Subject: [FFmpeg-devel] [PATCH V2] lavfi/colorlevels: Add slice threading
> support
> 
> From: Jun Zhao 
> 
> Add slice threading support, use the command like:
> 
> ./ffmpeg -i input -vf colorlevel with 1080p h264 clip, the fps from 39 fps to
> 79 fps in the local
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavfilter/vf_colorlevels.c |  125
> +++--
>  1 files changed, 106 insertions(+), 19 deletions(-)
> 
> diff --git a/libavfilter/vf_colorlevels.c b/libavfilter/vf_colorlevels.c index
> 5385a5e..68668e7 100644
> --- a/libavfilter/vf_colorlevels.c
> +++ b/libavfilter/vf_colorlevels.c
> @@ -105,6 +105,83 @@ static int config_input(AVFilterLink *inlink)
>  return 0;
>  }
> 
> +struct thread_data {
> +const uint8_t *srcrow;
> +uint8_t *dstrow;
> +int dst_linesize;
> +int src_linesize;
> +
> +double coeff;
> +uint8_t offset;
> +
> +int h;
> +
> +int imin;
> +int omin;
> +};
> +
> +static int colorlevel_slice_8(AVFilterContext *ctx, void *arg, int
> +jobnr, int nb_jobs) {
> +ColorLevelsContext *s = ctx->priv;
> +const struct thread_data *td = arg;
> +
> +int process_h = td->h;
> +const int slice_start = (process_h *  jobnr   ) / nb_jobs;
> +const int slice_end   = (process_h * (jobnr+1)) / nb_jobs;
> +int x, y;
> +const uint8_t *srcrow = td->srcrow;
> +uint8_t *dstrow = td->dstrow;
> +const int step = s->step;
> +const uint8_t offset = td->offset;
> +
> +int imin = td->imin;
> +int omin = td->omin;
> +double coeff = td->coeff;
> +
> +for (y = slice_start; y < slice_end; y++) {
> +const uint8_t *src = srcrow;
> +uint8_t *dst = dstrow;
> +
> +for (x = 0; x < s->linesize; x += step)
> +dst[x + offset] = av_clip_uint8((src[x + offset] - imin) * coeff
> + omin);
> +dstrow += td->dst_linesize;
> +srcrow += td->src_linesize;
> +}
> +
> +return 0;
> +}
> +
> +static int colorlevel_slice_16(AVFilterContext *ctx, void *arg, int
> +jobnr, int nb_jobs) {
> +ColorLevelsContext *s = ctx->priv;
> +const struct thread_data *td = arg;
> +
> +int process_h = td->h;
> +const int slice_start = (process_h *  jobnr   ) / nb_jobs;
> +const int slice_end   = (process_h * (jobnr+1)) / nb_jobs;
> +int x, y;
> +const uint8_t *srcrow = td->srcrow;
> +uint8_t *dstrow = td->dstrow;
> +const int step = s->step;
> +const uint8_t offset = td->offset;
> +
> +int imin = td->imin;
> +int omin = td->omin;
> +double coeff = td->coeff;
> +
> +for (y = slice_start; y < slice_end; y++) {
> +const uint16_t *src = (const uint16_t *)srcrow;
> +uint16_t *dst = (uint16_t *)dstrow;

Function colorlevel_slice_16() is same as colorlevel_slice_8 expect here to 
replace unit8_t to be unit16t.
Would better to define a template function to be reused.

> +for (x = 0; x < s->linesize; x += step)
> +dst[x + offset] = av_clip_uint8((src[x + offset] - imin) * coeff
> + omin);
> +dstrow += td->dst_linesize;
> +srcrow += td->src_linesize;
> +}
> +
> +return 0;
> +}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] lavc/qsvdec: reinit if the resolution changes little

2019-05-21 Thread Fu, Linjie
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Friday, February 22, 2019 10:40
> To: Li, Zhong ; FFmpeg development discussions and
> patches 
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvdec: reinit if the resolution
> changes little
> 
> > -Original Message-
> > From: Li, Zhong
> > Sent: Thursday, February 21, 2019 17:53
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Cc: Fu, Linjie 
> > Subject: RE: [FFmpeg-devel] [PATCH] lavc/qsvdec: reinit if the resolution
> > changes little
> >
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf
> > > Of Linjie Fu
> > > Sent: Wednesday, February 13, 2019 6:00 PM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Fu, Linjie 
> > > Subject: [FFmpeg-devel] [PATCH] lavc/qsvdec: reinit if the resolution
> > changes
> > > little
> > >
> > > Currently, resolution change detection is based on 16 alignment, small
> > > resolution changes (same after FFALIGN 16) in coded width or coded
> height
> > > will not trigger the reinit and will lead to a decode failure.
> > >
> > > Modify to use last_coded_width and last_coded_height to detect the
> small
> > > resolution change.
> > >
> > > Signed-off-by: Linjie Fu 
> >
> > Is it still needed if https://patchwork.ffmpeg.org/patch/12112/ applied?
> 
> Garbage still exists after applying the patch set.
> Will comment under patch 12112.

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

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

Re: [FFmpeg-devel] [PATCH V1] lavfi/lut: Add slice threading support

2019-05-21 Thread Song, Ruiling


> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of myp...@gmail.com
> Sent: Wednesday, May 22, 2019 11:14 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Jun Zhao 
> Subject: Re: [FFmpeg-devel] [PATCH V1] lavfi/lut: Add slice threading
> support
> 
> On Wed, May 22, 2019 at 11:03 AM Song, Ruiling 
> wrote:
> >
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > > Of Jun Zhao
> > > Sent: Wednesday, May 22, 2019 12:29 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Jun Zhao 
> > > Subject: [FFmpeg-devel] [PATCH V1] lavfi/lut: Add slice threading support
> > >
> > > From: Jun Zhao 
> > >
> > > Used the command for 1080p h264 clip as follow:
> > >
> > > a). ffmpeg -i input -vf lutyuv="u=128:v=128" -f null /dev/null
> > > b). ffmpeg -i input -vf lutrgb="g=0:b=0" -f null /dev/null
> > >
> > > after enabled the slice threading, the fps change from:
> > >
> > > a). 144fps to 258fps (lutyuv)
> > > b). 94fps  to 153fps (lutrgb)
> > >
> > > in Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
> > >
> > > Signed-off-by: Jun Zhao 
> > > ---
> > >  libavfilter/vf_lut.c |  328 +--
> 
> > > ---
> > >  1 files changed, 216 insertions(+), 112 deletions(-)
> > >
> > > diff --git a/libavfilter/vf_lut.c b/libavfilter/vf_lut.c
> > > index c815ddc..61550ee 100644
> > > --- a/libavfilter/vf_lut.c
> > > +++ b/libavfilter/vf_lut.c
> > > @@ -337,13 +337,194 @@ static int config_props(AVFilterLink *inlink)
> > >  return 0;
> > >  }
> > >
> > > +struct thread_data {
> > > +AVFrame *in;
> > > +AVFrame *out;
> > > +
> > > +int w;
> > > +int h;
> > > +};
> >
> > I think it's better to refine the patch to avoid duplicating code, the 
> > exiting
> source code has been copy-pasted too much.
> > Maybe we just need lut_packed() and lut_planar(). For 8/16 variation, I
> think it is easy to add one field( like "int is_16bit;")in thread_data to 
> solve it.
> Ha, in fact, they are come from origin code, and I noticed the code
> redundancy in origin code, as my plan, I plan to split with 2 steps:
> step 1: enabling the slice thread, it's will help to review + test (as
> this patch)
> step 2: refine the code redundancy, (the next round patch).
> 
>  So you want to combine step 1 and step 2 as one patch ? Thanks.
Yes, I don't see much benefit of split it into 2 steps. I prefer reviewing 
clean code.

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] lavfi/lut: Add slice threading support

2019-05-21 Thread myp...@gmail.com
On Wed, May 22, 2019 at 11:03 AM Song, Ruiling  wrote:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Jun Zhao
> > Sent: Wednesday, May 22, 2019 12:29 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Jun Zhao 
> > Subject: [FFmpeg-devel] [PATCH V1] lavfi/lut: Add slice threading support
> >
> > From: Jun Zhao 
> >
> > Used the command for 1080p h264 clip as follow:
> >
> > a). ffmpeg -i input -vf lutyuv="u=128:v=128" -f null /dev/null
> > b). ffmpeg -i input -vf lutrgb="g=0:b=0" -f null /dev/null
> >
> > after enabled the slice threading, the fps change from:
> >
> > a). 144fps to 258fps (lutyuv)
> > b). 94fps  to 153fps (lutrgb)
> >
> > in Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavfilter/vf_lut.c |  328 +--
> > ---
> >  1 files changed, 216 insertions(+), 112 deletions(-)
> >
> > diff --git a/libavfilter/vf_lut.c b/libavfilter/vf_lut.c
> > index c815ddc..61550ee 100644
> > --- a/libavfilter/vf_lut.c
> > +++ b/libavfilter/vf_lut.c
> > @@ -337,13 +337,194 @@ static int config_props(AVFilterLink *inlink)
> >  return 0;
> >  }
> >
> > +struct thread_data {
> > +AVFrame *in;
> > +AVFrame *out;
> > +
> > +int w;
> > +int h;
> > +};
>
> I think it's better to refine the patch to avoid duplicating code, the 
> exiting source code has been copy-pasted too much.
> Maybe we just need lut_packed() and lut_planar(). For 8/16 variation, I think 
> it is easy to add one field( like "int is_16bit;")in thread_data to solve it.
Ha, in fact, they are come from origin code, and I noticed the code
redundancy in origin code, as my plan, I plan to split with 2 steps:
step 1: enabling the slice thread, it's will help to review + test (as
this patch)
step 2: refine the code redundancy, (the next round patch).

 So you want to combine step 1 and step 2 as one 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 V1] lavfi/lut: Add slice threading support

2019-05-21 Thread Song, Ruiling


> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Jun Zhao
> Sent: Wednesday, May 22, 2019 12:29 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Jun Zhao 
> Subject: [FFmpeg-devel] [PATCH V1] lavfi/lut: Add slice threading support
> 
> From: Jun Zhao 
> 
> Used the command for 1080p h264 clip as follow:
> 
> a). ffmpeg -i input -vf lutyuv="u=128:v=128" -f null /dev/null
> b). ffmpeg -i input -vf lutrgb="g=0:b=0" -f null /dev/null
> 
> after enabled the slice threading, the fps change from:
> 
> a). 144fps to 258fps (lutyuv)
> b). 94fps  to 153fps (lutrgb)
> 
> in Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavfilter/vf_lut.c |  328 +--
> ---
>  1 files changed, 216 insertions(+), 112 deletions(-)
> 
> diff --git a/libavfilter/vf_lut.c b/libavfilter/vf_lut.c
> index c815ddc..61550ee 100644
> --- a/libavfilter/vf_lut.c
> +++ b/libavfilter/vf_lut.c
> @@ -337,13 +337,194 @@ static int config_props(AVFilterLink *inlink)
>  return 0;
>  }
> 
> +struct thread_data {
> +AVFrame *in;
> +AVFrame *out;
> +
> +int w;
> +int h;
> +};

I think it's better to refine the patch to avoid duplicating code, the exiting 
source code has been copy-pasted too much.
Maybe we just need lut_packed() and lut_planar(). For 8/16 variation, I think 
it is easy to add one field( like "int is_16bit;")in thread_data to solve it.

Ruiling
> +
> +/* packed, 16-bit */
> +static int lut_packed_16bits(AVFilterContext *ctx, void *arg, int jobnr, int

___
ffmpeg-devel mailing list
ffmpeg-devel@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] change for ROI interface/document

2019-05-21 Thread Guo, Yejun


> -Original Message-
> From: Guo, Yejun
> Sent: Thursday, May 09, 2019 10:08 AM
> To: FFmpeg development discussions and patches 
> Cc: Mark Thompson 
> Subject: RE: [FFmpeg-devel] [PATCH v2 2/6] lavu/frame: Expand ROI
> documentation
> 
> 
> 
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > Guo, Yejun
> > Sent: Thursday, April 04, 2019 2:45 PM
> > To: FFmpeg development discussions and patches
> 
> > Subject: Re: [FFmpeg-devel] [PATCH v2 2/6] lavu/frame: Expand ROI
> > documentation
> >
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > > Of Mark Thompson
> > > Sent: Wednesday, March 13, 2019 8:18 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: [FFmpeg-devel] [PATCH v2 2/6] lavu/frame: Expand ROI
> > > documentation
> > >
> > > Clarify and add examples for the behaviour of the quantisation offset,
> > > and define how multiple ranges should be handled.
> > > ---
> > >  libavutil/frame.h | 46 ++
> > >  1 file changed, 34 insertions(+), 12 deletions(-)
> >
> > Maybe we can first refine and push the first two patches?
> 
> hello, just a kind reminder,
> since it is an interface change, it would be better to handle the first two
> patches earlier.

imho, we'd better make the change before the ffmpeg 4.2 release (Michael 
mentioned the probable time next week).

> 
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@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] libavfilter/dnn_native: Add multiple activation functions in dnn native

2019-05-21 Thread Liu Steven


> 在 2019年5月21日,下午8:48,Guo, Yejun  写道:
> 
> 
> 
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>> Xuewei Meng
>> Sent: Tuesday, May 21, 2019 2:53 PM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: [FFmpeg-devel] [PATCH] libavfilter/dnn_native: Add multiple 
>> activation
>> functions in dnn native
>> 
>> Add "Leaky_relu" and "None" option in activation function.
>> 
>> Signed-off-by: Xuewei Meng 
>> ---
>> libavfilter/dnn_backend_native.c | 5 +
>> libavfilter/dnn_backend_native.h | 2 +-
>> 2 files changed, 6 insertions(+), 1 deletion(-)
> 
> LGTM
Pushed


Thanks
> 
>> 
>> diff --git a/libavfilter/dnn_backend_native.c 
>> b/libavfilter/dnn_backend_native.c
>> index fa3f20e4a2..3c8465a283 100644
>> --- a/libavfilter/dnn_backend_native.c
>> +++ b/libavfilter/dnn_backend_native.c
>> @@ -270,6 +270,11 @@ static void convolve(const float *input, float *output,
>> const ConvolutionalParam
>> break;
>> case SIGMOID:
>> output[n_filter] = 1.0f / (1.0f + 
>> exp(-output[n_filter]));
>> +break;
>> +case NONE:
>> +break;
>> +case LEAKY_RELU:
>> +output[n_filter] = FFMAX(output[n_filter], 0.0) + 0.2 *
>> FFMIN(output[n_filter], 0.0);
>> }
>> }
>> output += conv_params->output_num;
>> diff --git a/libavfilter/dnn_backend_native.h 
>> b/libavfilter/dnn_backend_native.h
>> index d70cd16387..7e4e943137 100644
>> --- a/libavfilter/dnn_backend_native.h
>> +++ b/libavfilter/dnn_backend_native.h
>> @@ -32,7 +32,7 @@
>> 
>> typedef enum {INPUT, CONV, DEPTH_TO_SPACE} DNNLayerType;
>> 
>> -typedef enum {RELU, TANH, SIGMOID} DNNActivationFunc;
>> +typedef enum {RELU, TANH, SIGMOID, NONE, LEAKY_RELU}
>> DNNActivationFunc;
>> 
>> typedef enum {VALID, SAME, SAME_CLAMP_TO_EDGE}
>> DNNConvPaddingParam;
>> 
>> --
>> 2.17.1
>> 
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".



___
ffmpeg-devel mailing list
ffmpeg-devel@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/2] doc/writing_filters: Use ff_filter_get_nb_threads() get number of threads

2019-05-21 Thread Jun Zhao
From: Jun Zhao 

ff_filter_get_nb_threads() respect AVFilterContext.nb_threads and
graph->nb_threads both, in most case, we perfer this API than using
ctx->graph->nb_threads directly.
---
 doc/writing_filters.txt |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/doc/writing_filters.txt b/doc/writing_filters.txt
index 98b9c6f..2e25cbe 100644
--- a/doc/writing_filters.txt
+++ b/doc/writing_filters.txt
@@ -389,7 +389,7 @@ distributor with something like this:
 
 td.in  = in;
 td.out = out;
-ctx->internal->execute(ctx, filter_slice, , NULL, FFMIN(outlink->h, 
ctx->graph->nb_threads));
+ctx->internal->execute(ctx, filter_slice, , NULL, FFMIN(outlink->h, 
ff_filter_get_nb_threads(ctx)));
 
 // ...
 
-- 
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/2] lavfi/lensfun: Use ff_filter_get_nb_threads() get number of threads

2019-05-21 Thread Jun Zhao
From: Jun Zhao 

ff_filter_get_nb_threads() respect AVFilterContext.nb_threads and
graph->nb_threads both, in most case, we perfer this API than using
ctx->graph->nb_threads directly.

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

diff --git a/libavfilter/vf_lensfun.c b/libavfilter/vf_lensfun.c
index 3b723dd..089121e 100644
--- a/libavfilter/vf_lensfun.c
+++ b/libavfilter/vf_lensfun.c
@@ -465,7 +465,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
vignetting_filter_slice,
_thread_data,
NULL,
-   FFMIN(outlink->h, ctx->graph->nb_threads));
+   FFMIN(outlink->h, 
ff_filter_get_nb_threads(ctx)));
 }
 
 if (lensfun->mode & (GEOMETRY_DISTORTION | SUBPIXEL_DISTORTION)) {
@@ -493,7 +493,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
distortion_correction_filter_slice,
_correction_thread_data,
NULL,
-   FFMIN(outlink->h, ctx->graph->nb_threads));
+   FFMIN(outlink->h, 
ff_filter_get_nb_threads(ctx)));
 
 av_frame_free();
 return ff_filter_frame(outlink, out);
-- 
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] lavc/vaapi_encode: disable ICQ mode when enabling low power

2019-05-21 Thread Li, Zhong
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Linjie Fu
> Sent: Wednesday, May 22, 2019 4:31 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie 
> Subject: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: disable ICQ mode
> when enabling low power
> 
> ICQ mode is not supported in low power mode and should be disabled.
> 
> For H264, Driver supports RC modes CQP, CBR, VBR, QVBR.
> For HEVC, Driver supports RC modes CQP, CBR, VBR, ICQ, QVBR.
> 
> ICQ is not exposed while working on low power mode for h264_vaapi, but
> will trigger issues for hevc_vaapi.
> 
> Signed-off-by: Linjie Fu 
> ---
> See https://github.com/intel/media-driver/issues/618 for details.
> And patch for HEVC low power(ICL+):
> https://github.com/intel-media-ci/ffmpeg/pull/42
> 
>  libavcodec/vaapi_encode.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c index
> 2dda451..55ab919 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1371,6 +1371,7 @@ static av_cold int
> vaapi_encode_init_rate_control(AVCodecContext *avctx)
>  // * If bitrate and maxrate are set and have the same value, try CBR.
>  // * If a bitrate is set, try AVBR, then VBR, then CBR.
>  // * If no bitrate is set, try ICQ, then CQP.
> +// * If low power is set, ICQ is not supported.
> 
>  #define TRY_RC_MODE(mode, fail) do { \
>  rc_mode = _encode_rc_modes[mode]; \ @@ -1405,7
> +1406,8 @@ static av_cold int
> vaapi_encode_init_rate_control(AVCodecContext *avctx)
>  TRY_RC_MODE(RC_MODE_QVBR, 0);
> 
>  if (avctx->global_quality > 0) {
> -TRY_RC_MODE(RC_MODE_ICQ, 0);
> +if (!ctx->low_power)
> +TRY_RC_MODE(RC_MODE_ICQ, 0);
>  TRY_RC_MODE(RC_MODE_CQP, 0);
>  }
> 
> @@ -1417,7 +1419,8 @@ static av_cold int
> vaapi_encode_init_rate_control(AVCodecContext *avctx)
>  TRY_RC_MODE(RC_MODE_VBR, 0);
>  TRY_RC_MODE(RC_MODE_CBR, 0);
>  } else {
> -TRY_RC_MODE(RC_MODE_ICQ, 0);
> +if (!ctx->low_power)
> +TRY_RC_MODE(RC_MODE_ICQ, 0);

Is it possible ICQ mode can be supported in future (new driver/HW version)? 
I would like to see avoid hard-coded workaround. 
If there is any driver limitation, would better to query driver capability 
firstly and then disable a feature if it is not supported.

___
ffmpeg-devel mailing list
ffmpeg-devel@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 04/11] cbs_mpeg2: Fix storage type for frame_centre_*_offset

2019-05-21 Thread James Almer
On 5/21/2019 10:04 PM, Andreas Rheinhardt wrote:
> The frame_centre_horizontal/vertical_offset values contained in picture
> display extensions are actually signed values (i.e. it is possible to
> indicate that the display device should add black bars/pillars).
> 
> The files sony-ct3.bs and tcela-6.bits (which are both used in fate
> tests for mpeg2_metadata) contain picture display extensions; the former
> even contains a negative frame_centre_vertical_offset. Fortunately, the
> old code did not damage the picture display extensions when one did a
> cycle of reading and writing. For the same reason the fate tests needn't
> be updated either.
> 
> Furthermore these fields now use the trace output for matrices.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/cbs_mpeg2.c | 20 
>  libavcodec/cbs_mpeg2.h |  4 ++--
>  libavcodec/cbs_mpeg2_syntax_template.c |  4 ++--
>  3 files changed, 24 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
> index 437eac88a3..de0ad8a043 100644
> --- a/libavcodec/cbs_mpeg2.c
> +++ b/libavcodec/cbs_mpeg2.c
> @@ -48,6 +48,8 @@
>  xui(width, name, current->name, 0, MAX_UINT_BITS(width), subs, 
> __VA_ARGS__)
>  #define uirs(width, name, subs, ...) \
>  xui(width, name, current->name, 1, MAX_UINT_BITS(width), subs, 
> __VA_ARGS__)
> +#define sis(width, name, subs, ...) \
> +xsi(width, name, current->name, subs, __VA_ARGS__)

For consistency's sake, add the two range parameters to xsi much like
you added them to xui in patch 2, instead of hardcoding a range inside
the macro.

>  
>  
>  #define READ
> @@ -62,6 +64,15 @@
>  var = value; \
>  } while (0)
>  
> +#define xsi(width, name, var, subs, ...) do { \
> +int32_t value; \
> +CHECK(ff_cbs_read_signed(ctx, rw, width, #name, \
> + SUBSCRIPTS(subs, __VA_ARGS__), , \
> + MIN_INT_BITS(width), \
> + MAX_INT_BITS(width))); \
> +var = value; \
> +} while (0)
> +
>  #define marker_bit() do { \
>  av_unused uint32_t one; \
>  CHECK(ff_cbs_read_unsigned(ctx, rw, 1, "marker_bit", NULL, , 1, 
> 1)); \
> @@ -81,6 +92,7 @@
>  #undef READWRITE
>  #undef RWContext
>  #undef xui
> +#undef xsi
>  #undef marker_bit
>  #undef nextbits
>  #undef infer
> @@ -96,6 +108,13 @@
>  var, range_min, range_max)); \
>  } while (0)
>  
> +#define xsi(width, name, var, subs, ...) do { \
> +CHECK(ff_cbs_write_signed(ctx, rw, width, #name, \
> +  SUBSCRIPTS(subs, __VA_ARGS__), var, \
> +  MIN_INT_BITS(width), \
> +  MAX_INT_BITS(width))); \
> +} while (0)
> +
>  #define marker_bit() do { \
>  CHECK(ff_cbs_write_unsigned(ctx, rw, 1, "marker_bit", NULL, 1, 1, 
> 1)); \
>  } while (0)
> @@ -117,6 +136,7 @@
>  #undef READWRITE
>  #undef RWContext
>  #undef xui
> +#undef xsi
>  #undef marker_bit
>  #undef nextbits
>  #undef infer
> diff --git a/libavcodec/cbs_mpeg2.h b/libavcodec/cbs_mpeg2.h
> index 7565695acb..11f93b9df8 100644
> --- a/libavcodec/cbs_mpeg2.h
> +++ b/libavcodec/cbs_mpeg2.h
> @@ -164,8 +164,8 @@ typedef struct MPEG2RawQuantMatrixExtension {
>  } MPEG2RawQuantMatrixExtension;
>  
>  typedef struct MPEG2RawPictureDisplayExtension {
> -uint16_t frame_centre_horizontal_offset[3];
> -uint16_t frame_centre_vertical_offset[3];
> +int16_t frame_centre_horizontal_offset[3];
> +int16_t frame_centre_vertical_offset[3];
>  } MPEG2RawPictureDisplayExtension;
>  
>  typedef struct MPEG2RawExtensionData {
> diff --git a/libavcodec/cbs_mpeg2_syntax_template.c 
> b/libavcodec/cbs_mpeg2_syntax_template.c
> index 87db0ad039..e34fa9495f 100644
> --- a/libavcodec/cbs_mpeg2_syntax_template.c
> +++ b/libavcodec/cbs_mpeg2_syntax_template.c
> @@ -303,9 +303,9 @@ static int 
> FUNC(picture_display_extension)(CodedBitstreamContext *ctx, RWContext
>  HEADER("Picture Display Extension");
>  
>  for (i = 0; i < mpeg2->number_of_frame_centre_offsets; i++) {
> -ui(16, frame_centre_horizontal_offset[i]);
> +sis(16, frame_centre_horizontal_offset[i], 1, i);
>  marker_bit();
> -ui(16, frame_centre_vertical_offset[i]);
> +sis(16, frame_centre_vertical_offset[i],   1, i);
>  marker_bit();
>  }
>  
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@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 02/11] cbs_mpeg2: Improve checks for invalid values

2019-05-21 Thread Andreas Rheinhardt
MPEG-2 contains several elements that mustn't be zero according to the
specifications: horizontal/vertical_size_value, aspect_ratio_information,
frame_rate_code, the quantiser matrices, the colour_description
elements, picture_coding_type, the f_code[r][s] values and
quantiser_scale_code. It is now checked that the invalid values don't
occur.

The colour_description elements are treated specially in this regard:
Given that there are files in the wild which use illegal values for the
colour_description elements (some of them created by mpeg2_metadata),
they will be corrected to the value meaning "unknown" (namely 2) during
reading. This has been done in such a way that trace_headers will
nevertheless report the original value, together with a message about
the fixup.

Furthermore, the trace_headers output of user_data has been beautified.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/cbs_mpeg2.c | 16 ---
 libavcodec/cbs_mpeg2_syntax_template.c | 64 --
 2 files changed, 50 insertions(+), 30 deletions(-)

diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index cdde68ea38..1d319e0947 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -41,20 +41,24 @@
 #define SUBSCRIPTS(subs, ...) (subs > 0 ? ((int[subs + 1]){ subs, __VA_ARGS__ 
}) : NULL)
 
 #define ui(width, name) \
-xui(width, name, current->name, 0)
+xui(width, name, current->name, 0, MAX_UINT_BITS(width), 0)
+#define uir(width, name) \
+xui(width, name, current->name, 1, MAX_UINT_BITS(width), 0)
 #define uis(width, name, subs, ...) \
-xui(width, name, current->name, subs, __VA_ARGS__)
+xui(width, name, current->name, 0, MAX_UINT_BITS(width), subs, 
__VA_ARGS__)
+#define uirs(width, name, subs, ...) \
+xui(width, name, current->name, 1, MAX_UINT_BITS(width), subs, 
__VA_ARGS__)
 
 
 #define READ
 #define READWRITE read
 #define RWContext GetBitContext
 
-#define xui(width, name, var, subs, ...) do { \
+#define xui(width, name, var, range_min, range_max, subs, ...) do { \
 uint32_t value = 0; \
 CHECK(ff_cbs_read_unsigned(ctx, rw, width, #name, \
SUBSCRIPTS(subs, __VA_ARGS__), \
-   , 0, (1 << width) - 1)); \
+   , range_min, range_max)); \
 var = value; \
 } while (0)
 
@@ -81,10 +85,10 @@
 #define READWRITE write
 #define RWContext PutBitContext
 
-#define xui(width, name, var, subs, ...) do { \
+#define xui(width, name, var, range_min, range_max, subs, ...) do { \
 CHECK(ff_cbs_write_unsigned(ctx, rw, width, #name, \
 SUBSCRIPTS(subs, __VA_ARGS__), \
-var, 0, (1 << width) - 1)); \
+var, range_min, range_max)); \
 } while (0)
 
 #define marker_bit() do { \
diff --git a/libavcodec/cbs_mpeg2_syntax_template.c 
b/libavcodec/cbs_mpeg2_syntax_template.c
index 10aaea7734..b9d53682fe 100644
--- a/libavcodec/cbs_mpeg2_syntax_template.c
+++ b/libavcodec/cbs_mpeg2_syntax_template.c
@@ -26,14 +26,14 @@ static int FUNC(sequence_header)(CodedBitstreamContext 
*ctx, RWContext *rw,
 
 ui(8,  sequence_header_code);
 
-ui(12, horizontal_size_value);
-ui(12, vertical_size_value);
+uir(12, horizontal_size_value);
+uir(12, vertical_size_value);
 
 mpeg2->horizontal_size = current->horizontal_size_value;
 mpeg2->vertical_size   = current->vertical_size_value;
 
-ui(4,  aspect_ratio_information);
-ui(4,  frame_rate_code);
+uir(4, aspect_ratio_information);
+uir(4, frame_rate_code);
 ui(18, bit_rate_value);
 
 marker_bit();
@@ -44,13 +44,13 @@ static int FUNC(sequence_header)(CodedBitstreamContext 
*ctx, RWContext *rw,
 ui(1, load_intra_quantiser_matrix);
 if (current->load_intra_quantiser_matrix) {
 for (i = 0; i < 64; i++)
-uis(8, intra_quantiser_matrix[i], 1, i);
+uirs(8, intra_quantiser_matrix[i], 1, i);
 }
 
 ui(1, load_non_intra_quantiser_matrix);
 if (current->load_non_intra_quantiser_matrix) {
 for (i = 0; i < 64; i++)
-uis(8, non_intra_quantiser_matrix[i], 1, i);
+uirs(8, non_intra_quantiser_matrix[i], 1, i);
 }
 
 return 0;
@@ -79,7 +79,7 @@ static int FUNC(user_data)(CodedBitstreamContext *ctx, 
RWContext *rw,
 #endif
 
 for (k = 0; k < current->user_data_length; k++)
-xui(8, user_data, current->user_data[k], 0);
+uis(8, user_data[k], 1, k);
 
 return 0;
 }
@@ -125,9 +125,25 @@ static int 
FUNC(sequence_display_extension)(CodedBitstreamContext *ctx, RWContex
 
 ui(1, colour_description);
 if (current->colour_description) {
-ui(8, colour_primaries);
-ui(8, transfer_characteristics);
-ui(8, matrix_coefficients);
+#ifdef READ
+#define READ_AND_PATCH(name) do { \
+ui(8, name); \
+if 

[FFmpeg-devel] [PATCH 03/11] mpeg2_metadata, cbs_mpeg2: Fix handling of colour_description

2019-05-21 Thread Andreas Rheinhardt
If a sequence display extension is read with colour_description equal to
zero, but a user wants to add one or more of the colour_description
elements, then the colour_description elements the user did not explicitly
request to be set are set to zero and not to the value equal to
unknown/unspecified (namely 2). A value of zero is not only inappropriate,
but explicitly forbidden. This is fixed by inferring the right default
values during the reading process if the elements are absent; moreover,
changing any of the colour_description elements to zero is now no longer
permitted.

Furthermore, if a sequence display extension has to be added, the
earlier code set some fields to their default value twice. This has been
changed, too.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/cbs_mpeg2.c | 15 +++
 libavcodec/cbs_mpeg2_syntax_template.c |  4 
 libavcodec/mpeg2_metadata_bsf.c| 18 --
 3 files changed, 31 insertions(+), 6 deletions(-)

diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index 1d319e0947..437eac88a3 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -71,6 +71,10 @@
 (get_bits_left(rw) >= width && \
  (var = show_bits(rw, width)) == (compare))
 
+#define infer(name, value) do { \
+current->name = value; \
+} while (0)
+
 #include "cbs_mpeg2_syntax_template.c"
 
 #undef READ
@@ -79,6 +83,7 @@
 #undef xui
 #undef marker_bit
 #undef nextbits
+#undef infer
 
 
 #define WRITE
@@ -97,6 +102,15 @@
 
 #define nextbits(width, compare, var) (var)
 
+#define infer(name, value) do { \
+if (current->name != (value)) { \
+av_log(ctx->log_ctx, AV_LOG_WARNING, "Warning: " \
+   "%s does not match inferred value: " \
+   "%"PRId64", but should be %"PRId64".\n", \
+   #name, (int64_t)current->name, (int64_t)(value)); \
+} \
+} while (0)
+
 #include "cbs_mpeg2_syntax_template.c"
 
 #undef READ
@@ -105,6 +119,7 @@
 #undef xui
 #undef marker_bit
 #undef nextbits
+#undef infer
 
 
 static void cbs_mpeg2_free_user_data(void *unit, uint8_t *content)
diff --git a/libavcodec/cbs_mpeg2_syntax_template.c 
b/libavcodec/cbs_mpeg2_syntax_template.c
index b9d53682fe..87db0ad039 100644
--- a/libavcodec/cbs_mpeg2_syntax_template.c
+++ b/libavcodec/cbs_mpeg2_syntax_template.c
@@ -144,6 +144,10 @@ static int 
FUNC(sequence_display_extension)(CodedBitstreamContext *ctx, RWContex
 uir(8, transfer_characteristics);
 uir(8, matrix_coefficients);
 #endif
+} else {
+infer(colour_primaries, 2);
+infer(transfer_characteristics, 2);
+infer(matrix_coefficients,  2);
 }
 
 ui(14, display_horizontal_size);
diff --git a/libavcodec/mpeg2_metadata_bsf.c b/libavcodec/mpeg2_metadata_bsf.c
index ba3a74afda..5aed41a008 100644
--- a/libavcodec/mpeg2_metadata_bsf.c
+++ b/libavcodec/mpeg2_metadata_bsf.c
@@ -147,18 +147,12 @@ static int mpeg2_metadata_update_fragment(AVBSFContext 
*bsf,
 
 if (ctx->colour_primaries >= 0)
 sde->colour_primaries = ctx->colour_primaries;
-else if (add_sde)
-sde->colour_primaries = 2;
 
 if (ctx->transfer_characteristics >= 0)
 sde->transfer_characteristics = ctx->transfer_characteristics;
-else if (add_sde)
-sde->transfer_characteristics = 2;
 
 if (ctx->matrix_coefficients >= 0)
 sde->matrix_coefficients = ctx->matrix_coefficients;
-else if (add_sde)
-sde->matrix_coefficients = 2;
 }
 }
 
@@ -229,6 +223,18 @@ static int mpeg2_metadata_init(AVBSFContext *bsf)
 CodedBitstreamFragment *frag = >fragment;
 int err;
 
+#define VALIDITY_CHECK(name) do { \
+if (!ctx->name) { \
+av_log(bsf, AV_LOG_ERROR, "The value 0 for %s is " \
+  "forbidden.\n", #name); \
+return AVERROR(EINVAL); \
+} \
+} while (0)
+VALIDITY_CHECK(colour_primaries);
+VALIDITY_CHECK(transfer_characteristics);
+VALIDITY_CHECK(matrix_coefficients);
+#undef VALIDITY_CHECK
+
 err = ff_cbs_init(>cbc, AV_CODEC_ID_MPEG2VIDEO, bsf);
 if (err < 0)
 return err;
-- 
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 07/11] cbs: Remove useless initializations

2019-05-21 Thread Andreas Rheinhardt
Up until now, a temporary variable was used and initialized every time a
value was read in CBS; if reading turned out to be successfull, this
value was overwritten (without having ever been looked at) with the
value read if reading was successfull; on failure the variable wasn't
touched either. Therefore these initializations can be and have been
removed.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/cbs_av1.c   | 14 +++---
 libavcodec/cbs_h2645.c |  8 
 libavcodec/cbs_jpeg.c  |  2 +-
 libavcodec/cbs_mpeg2.c |  2 +-
 libavcodec/cbs_vp9.c   |  8 
 5 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
index eb2d03ef43..e31fc0c411 100644
--- a/libavcodec/cbs_av1.c
+++ b/libavcodec/cbs_av1.c
@@ -574,7 +574,7 @@ static size_t cbs_av1_get_payload_bytes_left(GetBitContext 
*gbc)
 #define RWContext GetBitContext
 
 #define xf(width, name, var, range_min, range_max, subs, ...) do { \
-uint32_t value = range_min; \
+uint32_t value; \
 CHECK(ff_cbs_read_unsigned(ctx, rw, width, #name, \
SUBSCRIPTS(subs, __VA_ARGS__), \
, range_min, range_max)); \
@@ -582,7 +582,7 @@ static size_t cbs_av1_get_payload_bytes_left(GetBitContext 
*gbc)
 } while (0)
 
 #define xsu(width, name, var, subs, ...) do { \
-int32_t value = 0; \
+int32_t value; \
 CHECK(ff_cbs_read_signed(ctx, rw, width, #name, \
  SUBSCRIPTS(subs, __VA_ARGS__), , \
  MIN_INT_BITS(width), \
@@ -591,27 +591,27 @@ static size_t 
cbs_av1_get_payload_bytes_left(GetBitContext *gbc)
 } while (0)
 
 #define uvlc(name, range_min, range_max) do { \
-uint32_t value = range_min; \
+uint32_t value; \
 CHECK(cbs_av1_read_uvlc(ctx, rw, #name, \
 , range_min, range_max)); \
 current->name = value; \
 } while (0)
 
 #define ns(max_value, name, subs, ...) do { \
-uint32_t value = 0; \
+uint32_t value; \
 CHECK(cbs_av1_read_ns(ctx, rw, max_value, #name, \
   SUBSCRIPTS(subs, __VA_ARGS__), )); \
 current->name = value; \
 } while (0)
 
 #define increment(name, min, max) do { \
-uint32_t value = 0; \
+uint32_t value; \
 CHECK(cbs_av1_read_increment(ctx, rw, min, max, #name, )); \
 current->name = value; \
 } while (0)
 
 #define subexp(name, max, subs, ...) do { \
-uint32_t value = 0; \
+uint32_t value; \
 CHECK(cbs_av1_read_subexp(ctx, rw, max, #name, \
   SUBSCRIPTS(subs, __VA_ARGS__), )); \
 current->name = value; \
@@ -629,7 +629,7 @@ static size_t cbs_av1_get_payload_bytes_left(GetBitContext 
*gbc)
 } while (0)
 
 #define leb128(name) do { \
-uint64_t value = 0; \
+uint64_t value; \
 CHECK(cbs_av1_read_leb128(ctx, rw, #name, )); \
 current->name = value; \
 } while (0)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 319202fc48..8655d8015e 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -290,28 +290,28 @@ static int cbs_write_se_golomb(CodedBitstreamContext 
*ctx, PutBitContext *pbc,
 #define RWContext GetBitContext
 
 #define xu(width, name, var, range_min, range_max, subs, ...) do { \
-uint32_t value = range_min; \
+uint32_t value; \
 CHECK(ff_cbs_read_unsigned(ctx, rw, width, #name, \
SUBSCRIPTS(subs, __VA_ARGS__), \
, range_min, range_max)); \
 var = value; \
 } while (0)
 #define xue(name, var, range_min, range_max, subs, ...) do { \
-uint32_t value = range_min; \
+uint32_t value; \
 CHECK(cbs_read_ue_golomb(ctx, rw, #name, \
  SUBSCRIPTS(subs, __VA_ARGS__), \
  , range_min, range_max)); \
 var = value; \
 } while (0)
 #define xi(width, name, var, range_min, range_max, subs, ...) do { \
-int32_t value = range_min; \
+int32_t value; \
 CHECK(ff_cbs_read_signed(ctx, rw, width, #name, \
  SUBSCRIPTS(subs, __VA_ARGS__), \
  , range_min, range_max)); \
 var = value; \
 } while (0)
 #define xse(name, var, range_min, range_max, subs, ...) do { \
-int32_t value = range_min; \
+int32_t value; \
 CHECK(cbs_read_se_golomb(ctx, rw, #name, \
  SUBSCRIPTS(subs, __VA_ARGS__), \
  , range_min, range_max)); \
diff --git a/libavcodec/cbs_jpeg.c b/libavcodec/cbs_jpeg.c
index b74747cbbf..f7e5454d82 100644
--- a/libavcodec/cbs_jpeg.c
+++ b/libavcodec/cbs_jpeg.c
@@ -45,7 +45,7 @@
 #define FUNC(name) cbs_jpeg_read_ ## name
 
 

[FFmpeg-devel] [PATCH 11/11] cbs_mpeg2: Remove zero byte stuffing

2019-05-21 Thread Andreas Rheinhardt
Remove superfluous trailing zeros from slices. Because MPEG-2 slices
can end with zero bits a safe number of trailing zero bits is always
kept.

More explicitly, 6 + max{f_code[i][1] - 1, i = 0,1, f_code[i][1] != 0xf}
is an upper bound for the number of possible trailing zeros that are
part of the slice. Here f_code[i][1] is the relevant value of the
picture coding extension the slice belongs to and the maximum of the
empty set is zero.
It is this number of trailing zero bits that is actually kept.

That this is really an upper bound can be seen as follows:

a) Every slice actually ends with a macroblock.

b) If the last macroblock of a slice ends with a block(i) structure
with pattern_code[i] != 0, then the slice ends with an "End of block"
VLC code (namely the "End of block" code of the last block with
pattern_code[i] != 0).
These codes are 10 and 0110, so that in this case there is exactly one
trailing zero bit.

c) Otherwise, all pattern_code[i] are zero. In this case,
if macroblock_pattern is set for the last macroblock of the slice, then
by the definition of pattern_code[i] in 6.3.17.4 cbp (derived
according to table B.9) must be zero and also the
coded_block_pattern_1/2 (if existing) must consist of zeros alone. The
value zero for cbp is coded by   1 so that the maximum number of
trailing zeros in this case is the length of coded_block_pattern_1/2 which
have a length of two resp. six bits. So six trailing zero bits at most.

d) Otherwise, if the slice actually ends with the marker bit of the
last macroblock, then there are certainly no trailing zero bits at
all.

e) Otherwise, if the slice ends with a motion_vectors(s) structure
(with s = 0 or 1 -- it doesn't matter which one), then it ends with a
motion_vector(r,s) (r, s = 0, 1 -- it doesn't matter) structure. This
structure ends with motion_code[r][s][1] (always existing) potentially
followed by motion_residual[r][s][1] and dmvector[1]. If dmvector[1]
exists, and contains a bit different from 0, there is at most one
trailing zero bit; if dmvector[1] consists of zeros alone, its length
is one according to B.11. motion_residual[r][s][1] (if it exists) has
a length of f_code[s][1] - 1 bits and can consist of zero bits alone.
Given that the value 0xf for f_code indicates that there is no motion
vector of the mentioned type, the length of motion_residual[r][s][1] is
bounded by max{f_code[i][1] - 1, i=1,2, f_code[i][1] != 0xf}. The
motion_code[r][s][1] can end with at most five zero bits (see B.10)
and always contains a bit set to one, so that in this case there are
at most 5 + max{f_code[i][1] - 1, i=1,2, f_code[i][1] != 0xf} + 1
zero trailing bits.

f) Otherwise, if the last macroblock of the slice ends with a
quantiser_scale_code, then there are at most four trailing zero bits,
because quantiser_scale_code has a length of five bits and must not
attain the value zero.

g) Otherwise, the last macroblock ends with the macroblock_modes
syntax structure. The potentially existing dct_type at the end might
be a zero bit; the frame/field_motion_type isn't present here, because
otherwise we would have a motion_vectors(i) (i = 0 or 1 or both) syntax
structure, so that e) (or b)-d)) would have applied.
spatial_temporal_weight_code might entirely consist of two zero bits.
The macroblock_type VLC code always contains a 1 bit and ends with two
zero bits at most (see B.2-B.8 for this), so we have maximally 2+2+1
trailing zero bits.

The fate test cbs-mpeg2-sony-ct3 had to be adapted because the input
file contains trailing zeros that were stripped away; the filesize is
reduced from 135 KB to 117 KB. Of course, decoding the smaller output
still produces the same frames.
Most of these savings happen in between slices rather than after the
last slice: The chomp bitstream filter can only reduce the filesize
by 50 bytes.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/cbs_mpeg2.c| 26 --
 tests/ref/fate/cbs-mpeg2-sony-ct3 |  2 +-
 2 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index 2354f665cd..047f15e298 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -168,7 +168,7 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext 
*ctx,
 uint8_t *unit_data;
 uint32_t start_code = -1, next_start_code = -1;
 size_t unit_size;
-int err, i, unit_type;
+int err, i, unit_type, max_trailing_bits = 14;
 
 start = avpriv_find_start_code(frag->data, frag->data + frag->data_size,
_code);
@@ -185,10 +185,32 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext 
*ctx,
 unit_size = end - (start - 1);
 } else {
 // Unit runs from start to the beginning of the start code
-// pointed to by end (including any padding zeroes).
+// pointed to by end (preliminarily including any padding zeroes).
 unit_size = (end - 4) - (start - 

[FFmpeg-devel] [PATCH 10/11] cbs_mpeg2: Fix parsing of picture headers

2019-05-21 Thread Andreas Rheinhardt
MPEG-2 picture and slice headers can contain optional extra information;
both use the same syntax for their extra information. And cbs_mpeg2's
implementations of both were buggy until recently; the one for the
picture headers still is and this is fixed in this commit.

The extra information in picture headers has simply been forgotten.
This meant that if this extra information was present, it was discarded
during reading; and unfortunately writing created invalid bitstreams in
this case (an extra_bit_picture - the last set bit of the whole unit -
indicated that there would be a further byte of data, although the output
didn't contain said data).

This has been fixed; both types of extra information are now
parsed via the same code and essentially passed through.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/cbs_mpeg2.c | 31 +++-
 libavcodec/cbs_mpeg2.h | 12 +++--
 libavcodec/cbs_mpeg2_syntax_template.c | 66 +++---
 3 files changed, 66 insertions(+), 43 deletions(-)

diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index 97425aa706..2354f665cd 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -41,18 +41,18 @@
 #define SUBSCRIPTS(subs, ...) (subs > 0 ? ((int[subs + 1]){ subs, __VA_ARGS__ 
}) : NULL)
 
 #define ui(width, name) \
-xui(width, name, current->name, 0, MAX_UINT_BITS(width), 0)
+xui(width, #name, current->name, 0, MAX_UINT_BITS(width), 0)
 #define uir(width, name) \
-xui(width, name, current->name, 1, MAX_UINT_BITS(width), 0)
+xui(width, #name, current->name, 1, MAX_UINT_BITS(width), 0)
 #define uis(width, name, subs, ...) \
-xui(width, name, current->name, 0, MAX_UINT_BITS(width), subs, 
__VA_ARGS__)
+xui(width, #name, current->name, 0, MAX_UINT_BITS(width), subs, 
__VA_ARGS__)
 #define uirs(width, name, subs, ...) \
-xui(width, name, current->name, 1, MAX_UINT_BITS(width), subs, 
__VA_ARGS__)
+xui(width, #name, current->name, 1, MAX_UINT_BITS(width), subs, 
__VA_ARGS__)
 #define sis(width, name, subs, ...) \
-xsi(width, name, current->name, subs, __VA_ARGS__)
+xsi(width, #name, current->name, subs, __VA_ARGS__)
 
 #define marker_bit() \
-bit(marker_bit, 1)
+bit("marker_bit", 1)
 #define bit(name, value) do { \
 av_unused uint32_t bit = value; \
 xui(1, name, bit, value, value, 0); \
@@ -65,7 +65,7 @@
 
 #define xui(width, name, var, range_min, range_max, subs, ...) do { \
 uint32_t value; \
-CHECK(ff_cbs_read_unsigned(ctx, rw, width, #name, \
+CHECK(ff_cbs_read_unsigned(ctx, rw, width, name, \
SUBSCRIPTS(subs, __VA_ARGS__), \
, range_min, range_max)); \
 var = value; \
@@ -73,7 +73,7 @@
 
 #define xsi(width, name, var, subs, ...) do { \
 int32_t value; \
-CHECK(ff_cbs_read_signed(ctx, rw, width, #name, \
+CHECK(ff_cbs_read_signed(ctx, rw, width, name, \
  SUBSCRIPTS(subs, __VA_ARGS__), , \
  MIN_INT_BITS(width), \
  MAX_INT_BITS(width))); \
@@ -104,13 +104,13 @@
 #define RWContext PutBitContext
 
 #define xui(width, name, var, range_min, range_max, subs, ...) do { \
-CHECK(ff_cbs_write_unsigned(ctx, rw, width, #name, \
+CHECK(ff_cbs_write_unsigned(ctx, rw, width, name, \
 SUBSCRIPTS(subs, __VA_ARGS__), \
 var, range_min, range_max)); \
 } while (0)
 
 #define xsi(width, name, var, subs, ...) do { \
-CHECK(ff_cbs_write_signed(ctx, rw, width, #name, \
+CHECK(ff_cbs_write_signed(ctx, rw, width, name, \
   SUBSCRIPTS(subs, __VA_ARGS__), var, \
   MIN_INT_BITS(width), \
   MAX_INT_BITS(width))); \
@@ -138,6 +138,13 @@
 #undef infer
 
 
+static void cbs_mpeg2_free_picture_header(void *unit, uint8_t *content)
+{
+MPEG2RawPictureHeader *picture = (MPEG2RawPictureHeader*)content;
+av_buffer_unref(>extra_information_picture.extra_information_ref);
+av_free(content);
+}
+
 static void cbs_mpeg2_free_user_data(void *unit, uint8_t *content)
 {
 MPEG2RawUserData *user = (MPEG2RawUserData*)content;
@@ -148,7 +155,7 @@ static void cbs_mpeg2_free_user_data(void *unit, uint8_t 
*content)
 static void cbs_mpeg2_free_slice(void *unit, uint8_t *content)
 {
 MPEG2RawSlice *slice = (MPEG2RawSlice*)content;
-av_buffer_unref(>header.extra_information_ref);
+
av_buffer_unref(>header.extra_information_slice.extra_information_ref);
 av_buffer_unref(>data_ref);
 av_free(content);
 }
@@ -251,7 +258,7 @@ static int cbs_mpeg2_read_unit(CodedBitstreamContext *ctx,
 } \
 break;
 START(MPEG2_START_PICTURE,   MPEG2RawPictureHeader,
-

[FFmpeg-devel] [PATCH 09/11] cbs_mpeg2: Fix parsing of slice headers

2019-05-21 Thread Andreas Rheinhardt
1. The extra information in slice headers was parsed incorrectly:
In the first reading pass to derive the length of the extra information,
one should look at bits n, n + 9, n + 18, ... and check whether they
equal one (further extra information) or zero (end of extra information),
but instead bits n, n + 8, n + 16, ... were inspected. The second pass
of reading (where the length is already known and the bytes between the
length-determining bits are copied into a buffer) did not record what
was in bits n, n + 9, n + 18, ..., presuming they equal one. And during
writing, the bytes in the buffer are interleaved with set bits and
written. This means that if the detected length of the extra information
was greater than the real length, the output was corrupted. Fortunately
no sample is known that made use of this mechanism: The extra information
in slices is still marked as reserved in the specifications. cbs_mpeg2
is now ready in case this changes.

2. Furthermore, the buffer is now padded and slightly different, but
very similar code for reading resp. writing has been replaced by code
used for both. This was made possible by a new macro, the equivalent
to cbs_h2645's fixed().

3. These changes also made it possible to remove the extra_bit_slice
element from the MPEG2RawSliceHeader structure. Said element was always
zero except when the detected length of the extra information was less
than the real length.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/cbs_mpeg2.c | 18 +++---
 libavcodec/cbs_mpeg2.h |  2 --
 libavcodec/cbs_mpeg2_syntax_template.c | 16 +---
 3 files changed, 12 insertions(+), 24 deletions(-)

diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index 0110dc0e03..97425aa706 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -51,6 +51,13 @@
 #define sis(width, name, subs, ...) \
 xsi(width, name, current->name, subs, __VA_ARGS__)
 
+#define marker_bit() \
+bit(marker_bit, 1)
+#define bit(name, value) do { \
+av_unused uint32_t bit = value; \
+xui(1, name, bit, value, value, 0); \
+} while (0)
+
 
 #define READ
 #define READWRITE read
@@ -73,11 +80,6 @@
 var = value; \
 } while (0)
 
-#define marker_bit() do { \
-av_unused uint32_t one; \
-CHECK(ff_cbs_read_unsigned(ctx, rw, 1, "marker_bit", NULL, , 1, 
1)); \
-} while (0)
-
 #define nextbits(width, compare, var) \
 (get_bits_left(rw) >= width && \
  (var = show_bits(rw, width)) == (compare))
@@ -93,7 +95,6 @@
 #undef RWContext
 #undef xui
 #undef xsi
-#undef marker_bit
 #undef nextbits
 #undef infer
 
@@ -115,10 +116,6 @@
   MAX_INT_BITS(width))); \
 } while (0)
 
-#define marker_bit() do { \
-CHECK(ff_cbs_write_unsigned(ctx, rw, 1, "marker_bit", NULL, 1, 1, 1)); 
\
-} while (0)
-
 #define nextbits(width, compare, var) (var)
 
 #define infer(name, value) do { \
@@ -137,7 +134,6 @@
 #undef RWContext
 #undef xui
 #undef xsi
-#undef marker_bit
 #undef nextbits
 #undef infer
 
diff --git a/libavcodec/cbs_mpeg2.h b/libavcodec/cbs_mpeg2.h
index 11f93b9df8..db5ebc56ea 100644
--- a/libavcodec/cbs_mpeg2.h
+++ b/libavcodec/cbs_mpeg2.h
@@ -194,8 +194,6 @@ typedef struct MPEG2RawSliceHeader {
 uint8_t slice_picture_id_enable;
 uint8_t slice_picture_id;
 
-uint8_t extra_bit_slice;
-
 size_t extra_information_length;
 uint8_t *extra_information;
 AVBufferRef *extra_information_ref;
diff --git a/libavcodec/cbs_mpeg2_syntax_template.c 
b/libavcodec/cbs_mpeg2_syntax_template.c
index d9ef480f39..1f2d2497c3 100644
--- a/libavcodec/cbs_mpeg2_syntax_template.c
+++ b/libavcodec/cbs_mpeg2_syntax_template.c
@@ -377,31 +377,25 @@ static int FUNC(slice_header)(CodedBitstreamContext *ctx, 
RWContext *rw,
 uint8_t bit;
 start = *rw;
 for (k = 0; nextbits(1, 1, bit); k++)
-skip_bits(rw, 8);
+skip_bits(rw, 1 + 8);
 current->extra_information_length = k;
 if (k > 0) {
 *rw = start;
 current->extra_information_ref =
-av_buffer_alloc(current->extra_information_length);
+av_buffer_allocz(k + AV_INPUT_BUFFER_PADDING_SIZE);
 if (!current->extra_information_ref)
 return AVERROR(ENOMEM);
 current->extra_information = 
current->extra_information_ref->data;
-for (k = 0; k < current->extra_information_length; k++) {
-xui(1, extra_bit_slice, bit, 1, 1, 0);
-xui(8, extra_information_slice[k],
-current->extra_information[k], 0, 255, 1, k);
-}
 }
-#else
+#endif
 for (k = 0; k < current->extra_information_length; k++) {
-xui(1, extra_bit_slice, 1, 1, 1, 0);
+bit(extra_bit_slice, 1);
 

[FFmpeg-devel] [PATCH 08/11] avcodec/cbs_mpeg2: fix leak of extra_information_slice buffer in cbs_mpeg2_read_slice_header()

2019-05-21 Thread Andreas Rheinhardt
From: James Almer 

cbs_mpeg2_free_slice() calls av_buffer_unref() on extra_information_ref,
meaning allocating with av_malloc() was not the intention.

Signed-off-by: James Almer 
---
 libavcodec/cbs_mpeg2_syntax_template.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavcodec/cbs_mpeg2_syntax_template.c 
b/libavcodec/cbs_mpeg2_syntax_template.c
index aa2544bc8a..d9ef480f39 100644
--- a/libavcodec/cbs_mpeg2_syntax_template.c
+++ b/libavcodec/cbs_mpeg2_syntax_template.c
@@ -381,10 +381,11 @@ static int FUNC(slice_header)(CodedBitstreamContext *ctx, 
RWContext *rw,
 current->extra_information_length = k;
 if (k > 0) {
 *rw = start;
-current->extra_information =
-av_malloc(current->extra_information_length);
-if (!current->extra_information)
+current->extra_information_ref =
+av_buffer_alloc(current->extra_information_length);
+if (!current->extra_information_ref)
 return AVERROR(ENOMEM);
+current->extra_information = 
current->extra_information_ref->data;
 for (k = 0; k < current->extra_information_length; k++) {
 xui(1, extra_bit_slice, bit, 1, 1, 0);
 xui(8, extra_information_slice[k],
-- 
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 04/11] cbs_mpeg2: Fix storage type for frame_centre_*_offset

2019-05-21 Thread Andreas Rheinhardt
The frame_centre_horizontal/vertical_offset values contained in picture
display extensions are actually signed values (i.e. it is possible to
indicate that the display device should add black bars/pillars).

The files sony-ct3.bs and tcela-6.bits (which are both used in fate
tests for mpeg2_metadata) contain picture display extensions; the former
even contains a negative frame_centre_vertical_offset. Fortunately, the
old code did not damage the picture display extensions when one did a
cycle of reading and writing. For the same reason the fate tests needn't
be updated either.

Furthermore these fields now use the trace output for matrices.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/cbs_mpeg2.c | 20 
 libavcodec/cbs_mpeg2.h |  4 ++--
 libavcodec/cbs_mpeg2_syntax_template.c |  4 ++--
 3 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index 437eac88a3..de0ad8a043 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -48,6 +48,8 @@
 xui(width, name, current->name, 0, MAX_UINT_BITS(width), subs, 
__VA_ARGS__)
 #define uirs(width, name, subs, ...) \
 xui(width, name, current->name, 1, MAX_UINT_BITS(width), subs, 
__VA_ARGS__)
+#define sis(width, name, subs, ...) \
+xsi(width, name, current->name, subs, __VA_ARGS__)
 
 
 #define READ
@@ -62,6 +64,15 @@
 var = value; \
 } while (0)
 
+#define xsi(width, name, var, subs, ...) do { \
+int32_t value; \
+CHECK(ff_cbs_read_signed(ctx, rw, width, #name, \
+ SUBSCRIPTS(subs, __VA_ARGS__), , \
+ MIN_INT_BITS(width), \
+ MAX_INT_BITS(width))); \
+var = value; \
+} while (0)
+
 #define marker_bit() do { \
 av_unused uint32_t one; \
 CHECK(ff_cbs_read_unsigned(ctx, rw, 1, "marker_bit", NULL, , 1, 
1)); \
@@ -81,6 +92,7 @@
 #undef READWRITE
 #undef RWContext
 #undef xui
+#undef xsi
 #undef marker_bit
 #undef nextbits
 #undef infer
@@ -96,6 +108,13 @@
 var, range_min, range_max)); \
 } while (0)
 
+#define xsi(width, name, var, subs, ...) do { \
+CHECK(ff_cbs_write_signed(ctx, rw, width, #name, \
+  SUBSCRIPTS(subs, __VA_ARGS__), var, \
+  MIN_INT_BITS(width), \
+  MAX_INT_BITS(width))); \
+} while (0)
+
 #define marker_bit() do { \
 CHECK(ff_cbs_write_unsigned(ctx, rw, 1, "marker_bit", NULL, 1, 1, 1)); 
\
 } while (0)
@@ -117,6 +136,7 @@
 #undef READWRITE
 #undef RWContext
 #undef xui
+#undef xsi
 #undef marker_bit
 #undef nextbits
 #undef infer
diff --git a/libavcodec/cbs_mpeg2.h b/libavcodec/cbs_mpeg2.h
index 7565695acb..11f93b9df8 100644
--- a/libavcodec/cbs_mpeg2.h
+++ b/libavcodec/cbs_mpeg2.h
@@ -164,8 +164,8 @@ typedef struct MPEG2RawQuantMatrixExtension {
 } MPEG2RawQuantMatrixExtension;
 
 typedef struct MPEG2RawPictureDisplayExtension {
-uint16_t frame_centre_horizontal_offset[3];
-uint16_t frame_centre_vertical_offset[3];
+int16_t frame_centre_horizontal_offset[3];
+int16_t frame_centre_vertical_offset[3];
 } MPEG2RawPictureDisplayExtension;
 
 typedef struct MPEG2RawExtensionData {
diff --git a/libavcodec/cbs_mpeg2_syntax_template.c 
b/libavcodec/cbs_mpeg2_syntax_template.c
index 87db0ad039..e34fa9495f 100644
--- a/libavcodec/cbs_mpeg2_syntax_template.c
+++ b/libavcodec/cbs_mpeg2_syntax_template.c
@@ -303,9 +303,9 @@ static int 
FUNC(picture_display_extension)(CodedBitstreamContext *ctx, RWContext
 HEADER("Picture Display Extension");
 
 for (i = 0; i < mpeg2->number_of_frame_centre_offsets; i++) {
-ui(16, frame_centre_horizontal_offset[i]);
+sis(16, frame_centre_horizontal_offset[i], 1, i);
 marker_bit();
-ui(16, frame_centre_vertical_offset[i]);
+sis(16, frame_centre_vertical_offset[i],   1, i);
 marker_bit();
 }
 
-- 
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 06/11] cbs, cbs_mpeg2, cbs_jpeg: Don't av_freep local variables

2019-05-21 Thread Andreas Rheinhardt
There is no danger of leaving dangling pointers behind, as the lifespan
of local variables (including pointers passed (by value) as function
arguments) ends anyway as soon as we exit their scope.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/cbs.c   | 2 +-
 libavcodec/cbs_jpeg.c  | 8 
 libavcodec/cbs_mpeg2.c | 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index 0260ba6f67..fc2246970e 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -97,7 +97,7 @@ int ff_cbs_init(CodedBitstreamContext **ctx_ptr,
 
 ctx->priv_data = av_mallocz(ctx->codec->priv_data_size);
 if (!ctx->priv_data) {
-av_freep();
+av_free(ctx);
 return AVERROR(ENOMEM);
 }
 
diff --git a/libavcodec/cbs_jpeg.c b/libavcodec/cbs_jpeg.c
index 5a72f0e2e7..b74747cbbf 100644
--- a/libavcodec/cbs_jpeg.c
+++ b/libavcodec/cbs_jpeg.c
@@ -86,21 +86,21 @@ static void cbs_jpeg_free_application_data(void *unit, 
uint8_t *content)
 {
 JPEGRawApplicationData *ad = (JPEGRawApplicationData*)content;
 av_buffer_unref(>Ap_ref);
-av_freep();
+av_free(content);
 }
 
 static void cbs_jpeg_free_comment(void *unit, uint8_t *content)
 {
 JPEGRawComment *comment = (JPEGRawComment*)content;
 av_buffer_unref(>Cm_ref);
-av_freep();
+av_free(content);
 }
 
 static void cbs_jpeg_free_scan(void *unit, uint8_t *content)
 {
 JPEGRawScan *scan = (JPEGRawScan*)content;
 av_buffer_unref(>data_ref);
-av_freep();
+av_free(content);
 }
 
 static int cbs_jpeg_split_fragment(CodedBitstreamContext *ctx,
@@ -227,7 +227,7 @@ static int cbs_jpeg_split_fragment(CodedBitstreamContext 
*ctx,
   data, data_size, data_ref);
 if (err < 0) {
 if (!data_ref)
-av_freep();
+av_free(data);
 return err;
 }
 
diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index 4f89435c9d..df2e818f07 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -146,7 +146,7 @@ static void cbs_mpeg2_free_user_data(void *unit, uint8_t 
*content)
 {
 MPEG2RawUserData *user = (MPEG2RawUserData*)content;
 av_buffer_unref(>user_data_ref);
-av_freep();
+av_free(content);
 }
 
 static void cbs_mpeg2_free_slice(void *unit, uint8_t *content)
@@ -154,7 +154,7 @@ static void cbs_mpeg2_free_slice(void *unit, uint8_t 
*content)
 MPEG2RawSlice *slice = (MPEG2RawSlice*)content;
 av_buffer_unref(>header.extra_information_ref);
 av_buffer_unref(>data_ref);
-av_freep();
+av_free(content);
 }
 
 static int cbs_mpeg2_split_fragment(CodedBitstreamContext *ctx,
-- 
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 05/11] cbs_mpeg2: Correct error codes

2019-05-21 Thread Andreas Rheinhardt
Up until now, things that are merely unsupported by cbs_mpeg2 have been
declared to be invalid input. This has been changed.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/cbs_mpeg2.c | 4 +---
 libavcodec/cbs_mpeg2_syntax_template.c | 4 ++--
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index de0ad8a043..4f89435c9d 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -266,9 +266,7 @@ static int cbs_mpeg2_read_unit(CodedBitstreamContext *ctx,
group_of_pictures_header, NULL);
 #undef START
 default:
-av_log(ctx->log_ctx, AV_LOG_ERROR, "Unknown start code 
%02"PRIx32".\n",
-   unit->type);
-return AVERROR_INVALIDDATA;
+return AVERROR(ENOSYS);
 }
 }
 
diff --git a/libavcodec/cbs_mpeg2_syntax_template.c 
b/libavcodec/cbs_mpeg2_syntax_template.c
index e34fa9495f..aa2544bc8a 100644
--- a/libavcodec/cbs_mpeg2_syntax_template.c
+++ b/libavcodec/cbs_mpeg2_syntax_template.c
@@ -339,9 +339,9 @@ static int FUNC(extension_data)(CodedBitstreamContext *ctx, 
RWContext *rw,
 return FUNC(picture_coding_extension)
 (ctx, rw, >data.picture_coding);
 default:
-av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid extension ID %d.\n",
+av_log(ctx->log_ctx, AV_LOG_ERROR, "Extension ID %d not supported.\n",
current->extension_start_code_identifier);
-return AVERROR_INVALIDDATA;
+return AVERROR_PATCHWELCOME;
 }
 }
 
-- 
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 01/11] cbs_mpeg2: Correct and use enum values

2019-05-21 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/cbs_mpeg2.c | 30 +++---
 libavcodec/cbs_mpeg2.h |  2 +-
 libavcodec/cbs_mpeg2_syntax_template.c | 10 -
 3 files changed, 23 insertions(+), 19 deletions(-)

diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index 8b8b266563..cdde68ea38 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -215,13 +215,16 @@ static int cbs_mpeg2_read_unit(CodedBitstreamContext *ctx,
 return err; \
 } \
 break;
-START(0x00, MPEG2RawPictureHeader,  picture_header,  NULL);
-START(0xb2, MPEG2RawUserData,   user_data,
-_mpeg2_free_user_data);
-START(0xb3, MPEG2RawSequenceHeader, sequence_header, NULL);
-START(0xb5, MPEG2RawExtensionData,  extension_data,  NULL);
-START(0xb8, MPEG2RawGroupOfPicturesHeader,
-   group_of_pictures_header, NULL);
+START(MPEG2_START_PICTURE,   MPEG2RawPictureHeader,
+picture_header,  NULL);
+START(MPEG2_START_USER_DATA, MPEG2RawUserData,
+ user_data, _mpeg2_free_user_data);
+START(MPEG2_START_SEQUENCE_HEADER, MPEG2RawSequenceHeader,
+sequence_header, NULL);
+START(MPEG2_START_EXTENSION, MPEG2RawExtensionData,
+extension_data,  NULL);
+START(MPEG2_START_GROUP, MPEG2RawGroupOfPicturesHeader,
+   group_of_pictures_header, NULL);
 #undef START
 default:
 av_log(ctx->log_ctx, AV_LOG_ERROR, "Unknown start code 
%02"PRIx32".\n",
@@ -244,11 +247,12 @@ static int cbs_mpeg2_write_header(CodedBitstreamContext 
*ctx,
 case start_code: \
 err = cbs_mpeg2_write_ ## func(ctx, pbc, unit->content); \
 break;
-START(0x00, MPEG2RawPictureHeader,  picture_header);
-START(0xb2, MPEG2RawUserData,   user_data);
-START(0xb3, MPEG2RawSequenceHeader, sequence_header);
-START(0xb5, MPEG2RawExtensionData,  extension_data);
-START(0xb8, MPEG2RawGroupOfPicturesHeader, group_of_pictures_header);
+START(MPEG2_START_PICTURE, MPEG2RawPictureHeader,  
picture_header);
+START(MPEG2_START_USER_DATA,   MPEG2RawUserData,   user_data);
+START(MPEG2_START_SEQUENCE_HEADER, MPEG2RawSequenceHeader, 
sequence_header);
+START(MPEG2_START_EXTENSION,   MPEG2RawExtensionData,  
extension_data);
+START(MPEG2_START_GROUP,   MPEG2RawGroupOfPicturesHeader,
+ 
group_of_pictures_header);
 #undef START
 default:
 av_log(ctx->log_ctx, AV_LOG_ERROR, "Write unimplemented for start "
@@ -331,7 +335,7 @@ static int cbs_mpeg2_write_unit(CodedBitstreamContext *ctx,
 
 init_put_bits(, priv->write_buffer, priv->write_buffer_size);
 
-if (unit->type >= 0x01 && unit->type <= 0xaf)
+if (MPEG2_START_IS_SLICE(unit->type))
 err = cbs_mpeg2_write_slice(ctx, unit, );
 else
 err = cbs_mpeg2_write_header(ctx, unit, );
diff --git a/libavcodec/cbs_mpeg2.h b/libavcodec/cbs_mpeg2.h
index 92caa99dc1..7565695acb 100644
--- a/libavcodec/cbs_mpeg2.h
+++ b/libavcodec/cbs_mpeg2.h
@@ -51,7 +51,7 @@ enum {
 MPEG2_EXTENSION_PICTURE_CODING= 0x8,
 MPEG2_EXTENSION_PICTURE_SPATIAL_SCALABLE  = 0x9,
 MPEG2_EXTENSION_PICTURE_TEMPORAL_SCALABLE = 0xa,
-MPEG2_EXTENSION_CAMAERA_PARAMETERS= 0xb,
+MPEG2_EXTENSION_CAMERA_PARAMETERS = 0xb,
 MPEG2_EXTENSION_ITU_T = 0xc,
 };
 
diff --git a/libavcodec/cbs_mpeg2_syntax_template.c 
b/libavcodec/cbs_mpeg2_syntax_template.c
index 88cf453b17..10aaea7734 100644
--- a/libavcodec/cbs_mpeg2_syntax_template.c
+++ b/libavcodec/cbs_mpeg2_syntax_template.c
@@ -303,19 +303,19 @@ static int FUNC(extension_data)(CodedBitstreamContext 
*ctx, RWContext *rw,
 ui(4, extension_start_code_identifier);
 
 switch (current->extension_start_code_identifier) {
-case 1:
+case MPEG2_EXTENSION_SEQUENCE:
 return FUNC(sequence_extension)
 (ctx, rw, >data.sequence);
-case 2:
+case MPEG2_EXTENSION_SEQUENCE_DISPLAY:
 return FUNC(sequence_display_extension)
 (ctx, rw, >data.sequence_display);
-case 3:
+case MPEG2_EXTENSION_QUANT_MATRIX:
 return FUNC(quant_matrix_extension)
 (ctx, rw, >data.quant_matrix);
-case 7:
+case MPEG2_EXTENSION_PICTURE_DISPLAY:
 return FUNC(picture_display_extension)
 (ctx, rw, >data.picture_display);
-case 8:
+case MPEG2_EXTENSION_PICTURE_CODING:
 return FUNC(picture_coding_extension)
   

[FFmpeg-devel] [PATCH 00/11 v3] cbs (mostly MPEG-2) patches

2019-05-21 Thread Andreas Rheinhardt
Hello,

this patchset is an updated and expanded version of my patchset [1] from
April. Changes include:

1. I have found more elements in MPEG-2 with forbidden values. And it
was always zero that was forbidden. Therefore the macro for ranges has
been simplified to simply disallow the value 0.
2. colour_description elements with the forbidden value zero will be
automatically patched to 2 (meaning unknown) during reading.
3. The frame_centre_vertical/horizontal_offset elements in picture
display extensions are actually signed. I have fixed this. The
sample sony-ct3.bs (part of the fate suite and already used for a test
for cbs_mpeg2) actually has a negative frame_centre_vertical_offset
entry.
4. All over cbs, reading involved useless initializations. They have
been removed.
5. Not only the extra information that can be part of picture headers is
parsed wrongly, but also the extra information from slice headers: The
wrong number of bits were skipped when deriving the number of extra
information bytes. If extra information in slice headers had been used
in the wild, the output would have been corrupted after a roundtrip
through cbs_mpeg2.
6. The picture headers are now parsed correctly; i.e. the extra
information is passed through. Although there are already defined
structures for the extra information in picture headers, no attempt has
been made to actually decompose it.
7. And finally I add a patch to remove zero byte stuffing in MPEG-2. The
situation here is more complicated than H2645, because some trailing
zero bits can be part of a slice. Nevertheless, it is possible to
derive an upper bound for the number of such trailing zero bits so
that it is possible to strip some trailing zeroes away.

I have also added James' patch regarding the memleak in
extra_information_slice.

- Andreas


[1] https://ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242964.html

Andreas Rheinhardt (10):
  cbs_mpeg2: Correct and use enum values
  cbs_mpeg2: Improve checks for invalid values
  mpeg2_metadata, cbs_mpeg2: Fix handling of colour_description
  cbs_mpeg2: Fix storage type for frame_centre_*_offset
  cbs_mpeg2: Correct error codes
  cbs, cbs_mpeg2, cbs_jpeg: Don't av_freep local variables
  cbs: Remove useless initializations
  cbs_mpeg2: Fix parsing of slice headers
  cbs_mpeg2: Fix parsing of picture headers
  cbs_mpeg2: Remove zero byte stuffing

James Almer (1):
  avcodec/cbs_mpeg2: fix leak of extra_information_slice buffer in
cbs_mpeg2_read_slice_header()

 libavcodec/cbs.c   |   2 +-
 libavcodec/cbs_av1.c   |  14 +--
 libavcodec/cbs_h2645.c |   8 +-
 libavcodec/cbs_jpeg.c  |  10 +-
 libavcodec/cbs_mpeg2.c | 140 +--
 libavcodec/cbs_mpeg2.h |  20 ++--
 libavcodec/cbs_mpeg2_syntax_template.c | 149 +++--
 libavcodec/cbs_vp9.c   |   8 +-
 libavcodec/mpeg2_metadata_bsf.c|  18 ++-
 tests/ref/fate/cbs-mpeg2-sony-ct3  |   2 +-
 10 files changed, 236 insertions(+), 135 deletions(-)

-- 
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] avfilter/f_loop: do not loop if loop size is 0

2019-05-21 Thread Alexander Strasser
Hi!

On 2019-05-20 20:51 +0200, Marton Balint wrote:
>
> On Mon, 20 May 2019, Gyan wrote:
>
> > On 20-05-2019 02:18 AM, Marton Balint wrote:
> > >
> > > On Sun, 19 May 2019, Paul B Mahol wrote:
> > >
> > > > On 5/19/19, Marton Balint  wrote:
> > > > >
> > > > > On Sun, 19 May 2019, Paul B Mahol wrote:
> > > > >
> > > > > > On 5/19/19, Marton Balint  wrote:
> > > > > > > Fixes infinte loop with -vf loop=loop=1.
> > > > > > >
> > > > > > > Possible regression since 
> > > > > > > ef1aadffc785b48ed62c45d954289e754f43ef46.
> > > > > > >
> > > > > > > Signed-off-by: Marton Balint 
> > > > > > > ---
> > > > > > >  libavfilter/f_loop.c | 2 +-
> > > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/libavfilter/f_loop.c b/libavfilter/f_loop.c
> > > > > > > index d9d55f9837..3da753dd1e 100644
> > > > > > > --- a/libavfilter/f_loop.c
> > > > > > > +++ b/libavfilter/f_loop.c
> > > > > > > @@ -343,7 +343,7 @@ static int activate(AVFilterContext *ctx)
> > > > > > >
> > > > > > >  FF_FILTER_FORWARD_STATUS_BACK(outlink, inlink);
> > > > > > >
> > > > > > > -    if (!s->eof && (s->nb_frames < s->size || !s->loop)) {
> > > > > > > +    if (!s->eof && (s->nb_frames < s->size ||
> > > > > > > !s->loop || !s->size)) {
> > > > > > >  ret = ff_inlink_consume_frame(inlink, );
> > > > > > >  if (ret < 0)
> > > > > > >  return ret;
> > > > > > > --
> > > > > >
> > > > > > I think better fix is to change default and minimal
> > > > > > allowed loop size to
> > > > > > 1.
> > > > > > Does that sounds ok to you?
> > > > >
> > > > > Well, looping the whole length of the input would be more
> > > > > intuitive to me
> > > > > as the default.
> > > >
> > > > That would require infinite memory.
> > >
> > > So as the reverse filter. As long as it is properly documented that
> > > the looped stuff is kept in memory so the user should not use this
> > > for long clips, then I think it is fine.
> >
> > I disagree. Yes, for loop with only loop specified, it would be
> > intuitive to loop the whole stream, but relying on users to exercise due
> > diligence can't be counted upon. We're talking about a scenario where
> > the user hasn't bothered to specify the size variable because they don't
> > know or don't care or are sloppy. They won't take heed of the
> > documentation until the command fails. The defaults should be robust
> > against lax use.
>
> Fair enough, although I never liked the idea that we make the tool less
> handy because we target unexperienced users.

FWIW, I guess the default behaviour of looping the complete input is much
better from a user perspective.

The typical users that have a need to loop a small clip will probably not
want to spefify a size in frames and will probably not really understand
why they need to specify one.

The typical users that want to loop a particular number of frames,
potentially at given offset into the specified input will probably read
the manual and in turn quickly find and use the size and/or start
options.


> Anyway, I don't have strong feelings about this, maybe my patch has the
> benefit of keeping existing behaviour (which is similar to how aloop works)
> in contrast to what paul suggested, but I don't really mind Paul's or Bela's
> solution either.

I have no strong feelings either, but it seems the behaviour
implemented by your patch seems ato fit more into the overall
situation too.


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

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

[FFmpeg-devel] [PATCH] avcodec/diracdec: Fix integer overflow in global_mv()

2019-05-21 Thread Michael Niedermayer
Fixes: signed integer overflow: 16384 * 196607 cannot be represented in type 
'int'
Fixes: 
14810/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5091232683917312

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

diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c
index a5bb6d5f34..643e3a7753 100644
--- a/libavcodec/diracdec.c
+++ b/libavcodec/diracdec.c
@@ -1433,8 +1433,8 @@ static void global_mv(DiracContext *s, DiracBlock *block, 
int x, int y, int ref)
 int *c  = s->globalmc[ref].perspective;
 
 int64_t m   = (1> (ez+ep);
 block->u.mv[ref][1] = (my + (1<<(ez+ep))) >> (ez+ep);
-- 
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] lavc/videotoolboxenc: Fix compilation for IOS < 11.0 and OSX, < 10.13

2019-05-21 Thread Jan Ekström
Hi,

On Tue, May 14, 2019 at 4:16 PM Thilo Borgmann  wrote:
>
> $Subject
>
> Tested compilation only, sanity test actually using it appreciated.
>

Thanks for the patch. To be completely fair, this is not to fix
compilation for specific target systems, but rather to fix compilation
on older SDKs (building with newer SDKs you can still build aiming for
macOS starting from 10.9, for example).

I didn't notice a patch landed on the encoder side that utilized the
defines without further checking/ifdefs. Too bad. I think I
specifically didn't yet merge the full/limited range patch on the
decoder side due to related reasons.

I did notice that VLC just re-defined these enum values themselves to
stop needing to have ifdefs depending on which SDK is being utilized
(https://github.com/videolan/vlc/commit/1b7e1c4bfcda375e2d4e657135aeaf3732e44af2#diff-a11cdb805d111956af60619d7dfa022bR735).
I wonder if we should have a helper header that would re-define these
enum values with their name. That way the code would look correct, and
the resulting binary has the same features independent of the SDK it
had been built under.

What would be the opinion of people on a solution like this?

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2 06/11] cbs: Add support functions for handling unit content references

2019-05-21 Thread James Almer
On 5/20/2019 8:02 PM, Mark Thompson wrote:
> Use the unit type table to determine what we need to do to clone the
> internals of the unit content when making copies for refcounting or
> writeability.  (This will still fail for units with complex content
> if they do not have a defined clone function.)
> 
> Setup and naming from a patch by Andreas Rheinhardt
> , but with the implementation
> changed to use the unit type information if possible rather than
> requiring a codec-specific function.
> ---
>  libavcodec/cbs.c  | 168 ++
>  libavcodec/cbs.h  |  23 ++
>  libavcodec/cbs_internal.h |   1 +
>  3 files changed, 192 insertions(+)
> 
> diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
> index 1963d86133..9fc8e1eb47 100644
> --- a/libavcodec/cbs.c
> +++ b/libavcodec/cbs.c
> @@ -816,3 +816,171 @@ int ff_cbs_alloc_unit_content2(CodedBitstreamContext 
> *ctx,
>  
>  return 0;
>  }
> +
> +static int cbs_clone_unit_content(AVBufferRef **clone_ref,
> +  CodedBitstreamUnit *unit,
> +  const CodedBitstreamUnitTypeDescriptor 
> *desc)
> +{
> +uint8_t *src, *copy;
> +void **src_ptr, **copy_ptr;

Why use void if you're going to cast these to uint8_t everywhere?

> +AVBufferRef **src_buf, **copy_buf;
> +int err, i;
> +
> +av_assert0(unit->type == desc->unit_type);
> +av_assert0(unit->content);
> +src = unit->content;
> +
> +copy = av_malloc(desc->content_size);
> +if (!copy) {
> +err = AVERROR(ENOMEM);
> +goto fail;
> +}
> +memcpy(copy, src, desc->content_size);
> +
> +for (i = 0; i < desc->nb_ref_offsets; i++) {
> +src_ptr  = (void**)(src + desc->ref_offsets[i]);
> +src_buf  = (AVBufferRef**)(src_ptr + 1);
> +copy_ptr = (void**)(copy + desc->ref_offsets[i]);
> +copy_buf = (AVBufferRef**)(copy_ptr + 1);
> +
> +if (!*src_ptr) {
> +av_assert0(!*src_buf);
> +continue;
> +}
> +if (!*src_buf) {
> +// We can't handle a non-refcounted pointer here - we don't
> +// have enough information to handle whatever structure lies
> +// at the other end of it.
> +err = AVERROR(EINVAL);
> +goto fail;
> +}
> +
> +// src_ptr is required to point somewhere inside src_buf.  If it
> +// doesn't, there is a bug somewhere.
> +av_assert0((uint8_t*)*src_ptr >= (*src_buf)->data &&
> +   (uint8_t*)*src_ptr <  (*src_buf)->data + 
> (*src_buf)->size);
> +
> +*copy_buf = av_buffer_ref(*src_buf);
> +if (!*copy_buf) {
> +err = AVERROR(ENOMEM);
> +goto fail;
> +}
> +
> +err = av_buffer_make_writable(copy_buf);
> +if (err < 0) {
> +av_buffer_unref(copy_buf);
> +goto fail;
> +}

Maybe instead of buffer_ref + make_writable, just do a buffer_alloc +
memcpy. It should be faster and only requires one failure check.

> +
> +*copy_ptr = (*copy_buf)->data +
> +((uint8_t*)*src_ptr - (*src_buf)->data);
> +}
> +
> +*clone_ref = av_buffer_create(copy, desc->content_size,
> +  desc->content_free ? desc->content_free :
> +  cbs_default_free_unit_content,
> +  (void*)desc, 0);
> +if (!*clone_ref)
> +goto fail;
> +
> +return 0;
> +
> +fail:
> +for (--i; i >= 0; i--)
> +av_buffer_unref((AVBufferRef**)(copy + desc->ref_offsets[i]));
> +av_freep();
> +*clone_ref = NULL;
> +return err;
> +}
> +
> +int ff_cbs_make_unit_refcounted(CodedBitstreamContext *ctx,
> +CodedBitstreamUnit *unit)
> +{
> +const CodedBitstreamUnitTypeDescriptor *desc;
> +AVBufferRef *ref;
> +int err;
> +
> +if (unit->content_ref)
> +return 0;
> +
> +desc = cbs_find_unit_type_desc(ctx, unit);
> +if (!desc)
> +return AVERROR(ENOSYS);
> +
> +switch (desc->content_type) {
> +case CBS_CONTENT_TYPE_POD:
> +ref = av_buffer_alloc(desc->content_size);
> +if (!ref)
> +return AVERROR(ENOMEM);
> +memcpy(ref->data, unit->content, desc->content_size);
> +err = 0;
> +break;
> +
> +case CBS_CONTENT_TYPE_INTERNAL_REFS:
> +err = cbs_clone_unit_content(, unit, desc);
> +break;
> +
> +case CBS_CONTENT_TYPE_COMPLEX:
> +if (!desc->content_clone)
> +return AVERROR_PATCHWELCOME;
> +err = desc->content_clone(, unit);
> +break;
> +
> +default:
> +av_assert0(0 && "Invalid content type.");
> +}
> +
> +if (err < 0)
> +return err;
> +
> +av_buffer_unref(>content_ref);
> +unit->content_ref = ref;
> +unit->content = ref->data;
> +return 0;
> +}
> +
> +int 

Re: [FFmpeg-devel] [PATCHv4] VP4 video decoder

2019-05-21 Thread James Almer
On 5/21/2019 3:42 PM, Carl Eugen Hoyos wrote:
> Am Di., 21. Mai 2019 um 09:45 Uhr schrieb Peter Ross :
> 
>> diff --git a/configure b/configure
>> index 9b4305cf0d..61eb774116 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2825,6 +2825,7 @@ vc1image_decoder_select="vc1_decoder"
>>  vorbis_decoder_select="mdct"
>>  vorbis_encoder_select="audio_frame_queue mdct"
>>  vp3_decoder_select="hpeldsp vp3dsp videodsp"
>> +vp4_decoder_select="vp3_decoder"
>>  vp5_decoder_select="h264chroma hpeldsp videodsp vp3dsp vp56dsp"
>>  vp6_decoder_select="h264chroma hpeldsp huffman videodsp vp3dsp vp56dsp"
>>  vp6a_decoder_select="vp6_decoder"
> 
>> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
>> index edccd73037..d76f392f1e 100644
>> --- a/libavcodec/Makefile
>> +++ b/libavcodec/Makefile
>> @@ -663,6 +663,7 @@ OBJS-$(CONFIG_VORBIS_DECODER)  += vorbisdec.o 
>> vorbisdsp.o vorbis.o \
>>  OBJS-$(CONFIG_VORBIS_ENCODER)  += vorbisenc.o vorbis.o \
>>vorbis_data.o
>>  OBJS-$(CONFIG_VP3_DECODER) += vp3.o
>> +OBJS-$(CONFIG_VP4_DECODER) += vp3.o
> 
> Imo, exactly one of these hunks should be committed.

The configure one. It would then be the same as with the Theora decoder.

> 
> Do you know if the claim on Wikipedia that "VP4" was only an encoder
> (for VP3) was true for the actual sold software or if Wikipedia is just
> wrong?
> 
> Thank you, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@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] web/download: set realistic release schedule

2019-05-21 Thread Lou Logan
On Mon, May 20, 2019, at 11:00 AM, Lou Logan wrote:
> Major releases have been every 6 months approximately; not every 3 months.
> 
> Signed-off-by: Lou Logan 
> ---
>  src/download | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] [PATCHv4] VP4 video decoder

2019-05-21 Thread Reimar Döffinger
On Tue, May 21, 2019 at 05:44:20PM +1000, Peter Ross wrote:
> +if (bits < 0x100) {
> +skip_bits(gb, 1);
> +} else if (bits < 0x180) {
> +skip_bits(gb, 2);
> +v += 1;
> +}
> +#define body(n) { \
> +skip_bits(gb, 2 + n); \
> +v += (1 << n) + get_bits(gb, n); }
> +#define else_if(thresh, n) else if (bits < thresh) body(n)

Not sure I think the defines are great for readability,
but if you want to fully encode the logic, you could go for
e.g.
#define else_if(n) else if (bits < (0x200 - (0x80 >> n))) body(n)
Also as to the earlier discussed early bailout for the +257 case:
it seems sensible values can't really be larger than yuv_macroblock_count
and I think FFmpeg has defines for maximum frame width/height that
you could thus use to have a non-arbitrary bailout value?

> +has_partial = 0;
> +bit = get_bits1(gb);
> +current_run = vp4_read_mb_value(gb);
> +
> +for (i = 0; i < s->yuv_macroblock_count; i++) {
> +if (!current_run) {
> +bit ^= 1;
> +current_run = vp4_read_mb_value(gb);
> +}
> +s->superblock_coding[i] = 2 * bit;
> +has_partial |= bit == 0;
> +current_run--;
> +}

This code doesn't quite look right to me.
For both of the vp4_read_mb_value weird stuff
seems to happen when it returns 0,
in the first case it directly flips bit
and reads a new value, which is stupid wasteful
encoding, in the second case current_run underflows
on current_run--, which is undefined behaviour
- or at least weird?

Except for that, isn't that the same as
   bit = get_bits1(gb);
   for (i = 0; i < s->yuv_macroblock_count; ) {
   current_run = vp4_read_mb_value(gb);
   if (current_run > s->yuv_macroblock_count - i) -> report error?
   if (current_run == 0) current_run = s->yuv_macroblock_count - i; // 
maybe??
   memset(s->superblock_coding + i, 2*bit, current_run);
   has_partial |= bit == 0;
   i += current_run;
   bit ^= 1;
   }

Hm, admittedly this doesn't really make much
sense as you can't apply this trick to the has_partial
case.
But still maybe the current_run too large and 0
cases could be clarified at least.

> +int mb_y = 2 * sb_y + (((j >> 1) + j) & 1);

Is ^ potentially clearer than + here?

> +for (k = 0; k < 4; k++) {
> +if (BLOCK_X >= fragment_width || BLOCK_Y >= 
> fragment_height)
> +continue;
> +fragment = s->fragment_start[plane] + BLOCK_Y * 
> fragment_width + BLOCK_X;
> +
> +coded = pattern & (1 << (3 - k));

coded = pattern & (8 >> k);
maybe?

> +if (last_motion < 0)
> +v = -v;
> +return v;

I'd probably be partial to using ?: here, but your decision.

> +if (coding_mode == 2) { /* VP4 */
> +motion_x[0] = vp4_get_mv(s, gb, 0, 
> last_gold_motion_x);
> +motion_y[0] = vp4_get_mv(s, gb, 1, 
> last_gold_motion_y);
> +last_gold_motion_x = motion_x[0];
> +last_gold_motion_y = motion_y[0];

Could write as
last_gold_motion_x =
motion_x[0] = vp4_get_mv(s, gb, 0, last_gold_motion_x);
I think?
But no strong opinion either.

> @@ -1012,8 +1214,8 @@ static int unpack_vlcs(Vp3DecodeContext *s, 
> GetBitContext *gb,
>  bits_to_get = coeff_get_bits[token];
>  if (bits_to_get)
>  bits_to_get = get_bits(gb, bits_to_get);
> -coeff = coeff_tables[token][bits_to_get];
>
> +coeff = coeff_tables[token][bits_to_get];

cosmetic?

> +eob_run = eob_run_base[token];
> +if (eob_run_get_bits[token])
[...]
> +zero_run = zero_run_base[token];
> +if (zero_run_get_bits[token])

If _run_base and _run_get_bits are always used together like this,
wouldn't it for readability and cache locality be better to
make it an array of structs so they are next to each other in memory?

> +vp4_dc_predictor_reset(_pred[j * 6 + i + 7]);
> +s->dc_pred_row[sb_x * 4 + i] = dc_pred[25 + i];
> +dc_pred[6 * i] = dc_pred[6 * i + 4];

If there's an easy way to make those constants like 6, 7 and 25
more obvious that might be a good idea.

> +if (dc_pred[idx - 6].type == type) {
> +dc += dc_pred[idx - 6].dc;
> +count++;
> +}
> +
> +if (dc_pred[idx + 6].type == type) {
> +dc += dc_pred[idx + 6].dc;
> +count++;
> +}
> +
> +if (count != 2 && dc_pred[idx - 1].type == type) {
> +dc += dc_pred[idx - 1].dc;
> +count++;
> +}
> +
> +if (count != 2 && dc_pred[idx + 1].type == type) {
> +dc += dc_pred[idx + 1].dc;
> +count++;
> +}

Maybe do dc_pred += idx at the start and then
only dc_pred[-6], dc_pred[6] etc?

> +#define loop_stride 12
> +uint8_t loop[12 * loop_stride];

Hm, at 144 bytes, might it make 

Re: [FFmpeg-devel] [PATCHv4] VP4 video decoder

2019-05-21 Thread Reimar Döffinger
On Tue, May 21, 2019 at 11:15:03AM -0300, James Almer wrote:
> > I have a feeling this loop should have a stop condition like v <
> > SOME_LARGE_VALUE, say INT_MAX-255 or yuv_macroblock_count, to reject
> > corrupt/malicious files and not cause undefined behavior
>
> Using get_bits_left(gb) would be better than an arbitrary large value.

It seems the original comment wasn't preserved, but get_bits_left
is fairly pointless because the 0-padding will cause loop exit
anyway.
Also get_bits_left wouldn't address the point that a 2GB input frame
of all-1s from the right position would here end up reading 2GB
9 bits at a time.
Overflow by my calculations would only happen after > 500 GB,
so not sure that's a worry.
But depending on the contexts in which this function is used,
there might be obvious limits for v, in which case an early
exit would make sense (even when not, runs > 250 bytes can
likely safely assumed broken).
___
ffmpeg-devel mailing list
ffmpeg-devel@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] [PATCHv4] VP4 video decoder

2019-05-21 Thread Carl Eugen Hoyos
Am Di., 21. Mai 2019 um 09:45 Uhr schrieb Peter Ross :

> diff --git a/configure b/configure
> index 9b4305cf0d..61eb774116 100755
> --- a/configure
> +++ b/configure
> @@ -2825,6 +2825,7 @@ vc1image_decoder_select="vc1_decoder"
>  vorbis_decoder_select="mdct"
>  vorbis_encoder_select="audio_frame_queue mdct"
>  vp3_decoder_select="hpeldsp vp3dsp videodsp"
> +vp4_decoder_select="vp3_decoder"
>  vp5_decoder_select="h264chroma hpeldsp videodsp vp3dsp vp56dsp"
>  vp6_decoder_select="h264chroma hpeldsp huffman videodsp vp3dsp vp56dsp"
>  vp6a_decoder_select="vp6_decoder"

> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index edccd73037..d76f392f1e 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -663,6 +663,7 @@ OBJS-$(CONFIG_VORBIS_DECODER)  += vorbisdec.o 
> vorbisdsp.o vorbis.o \
>  OBJS-$(CONFIG_VORBIS_ENCODER)  += vorbisenc.o vorbis.o \
>vorbis_data.o
>  OBJS-$(CONFIG_VP3_DECODER) += vp3.o
> +OBJS-$(CONFIG_VP4_DECODER) += vp3.o

Imo, exactly one of these hunks should be committed.

Do you know if the claim on Wikipedia that "VP4" was only an encoder
(for VP3) was true for the actual sold software or if Wikipedia is just
wrong?

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

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

Re: [FFmpeg-devel] [PATCHv4] VP4 video decoder

2019-05-21 Thread Carl Eugen Hoyos
Am Di., 21. Mai 2019 um 19:18 Uhr schrieb Lynne :
>
> May 21, 2019, 8:44 AM by pr...@xvid.org :
>
> > ---
> >
> > what's changed:
> > * apply #if CONFIG_VP4_DECODER around large vp4 code blocks
> > * improved vp4_read_mb_value thanks to reminars suggestions
> > * improved configure vp3_decoder_select
> >
> >
> > Changelog   |1 +
> > configure   |1 +
> > doc/general.texi|2 +
> > libavcodec/Makefile |1 +
> > libavcodec/allcodecs.c  |1 +
> > libavcodec/avcodec.h|1 +
> > libavcodec/codec_desc.c |7 +
> > libavcodec/vp3.c|  746 ++--
> > libavcodec/vp4data.h| 1186 +++
> > 9 files changed, 1911 insertions(+), 35 deletions(-)
> > create mode 100644 libavcodec/vp4data.h
> >
>
> Just remove CONFIG_VP4_DECODER and make it part of the vp3 decoder.

Wasn't this explicitly requested in an earlier review?
(And it is common within FFmpeg)

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

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

Re: [FFmpeg-devel] [PATCH 1/4] avcodec: add siren audio decoder

2019-05-21 Thread Reimar Döffinger
On Tue, May 21, 2019 at 04:51:19PM +0200, Moritz Barsnick wrote:
> (It only matters on hardware which requires double precision software
> emulation, but if explicitly using float, make sure to stick to float.)

It's a best practice regardless of emulation or not.
Even x86 has for example much better division performance
for float than double, and where auto-parallelization might
be possible it can make an even larger speed difference.
Just remembering the appropriate suffix is usually simpler
than thinking whether it might be performance-relevant or not.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] [PATCHv4] VP4 video decoder

2019-05-21 Thread Lynne
May 21, 2019, 8:44 AM by pr...@xvid.org :

> ---
>
> what's changed:
> * apply #if CONFIG_VP4_DECODER around large vp4 code blocks
> * improved vp4_read_mb_value thanks to reminars suggestions
> * improved configure vp3_decoder_select
>
>
> Changelog   |1 +
> configure   |1 +
> doc/general.texi|2 +
> libavcodec/Makefile |1 +
> libavcodec/allcodecs.c  |1 +
> libavcodec/avcodec.h|1 +
> libavcodec/codec_desc.c |7 +
> libavcodec/vp3.c|  746 ++--
> libavcodec/vp4data.h| 1186 +++
> 9 files changed, 1911 insertions(+), 35 deletions(-)
> create mode 100644 libavcodec/vp4data.h
>

Just remove CONFIG_VP4_DECODER and make it part of the vp3 decoder.
Its unnecessary and the tables aren't big at all.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavfi/lut: Add slice threading support

2019-05-21 Thread Jun Zhao
From: Jun Zhao 

Used the command for 1080p h264 clip as follow:

a). ffmpeg -i input -vf lutyuv="u=128:v=128" -f null /dev/null
b). ffmpeg -i input -vf lutrgb="g=0:b=0" -f null /dev/null

after enabled the slice threading, the fps change from:

a). 144fps to 258fps (lutyuv)
b). 94fps  to 153fps (lutrgb)

in Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz

Signed-off-by: Jun Zhao 
---
 libavfilter/vf_lut.c |  328 +-
 1 files changed, 216 insertions(+), 112 deletions(-)

diff --git a/libavfilter/vf_lut.c b/libavfilter/vf_lut.c
index c815ddc..61550ee 100644
--- a/libavfilter/vf_lut.c
+++ b/libavfilter/vf_lut.c
@@ -337,13 +337,194 @@ static int config_props(AVFilterLink *inlink)
 return 0;
 }
 
+struct thread_data {
+AVFrame *in;
+AVFrame *out;
+
+int w;
+int h;
+};
+
+/* packed, 16-bit */
+static int lut_packed_16bits(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs)
+{
+LutContext *s = ctx->priv;
+const struct thread_data *td = arg;
+
+uint16_t *inrow, *outrow, *inrow0, *outrow0;
+int i, j;
+const int w = td->w;
+const int h = td->h;
+AVFrame *in = td->in;
+AVFrame *out = td->out;
+const uint16_t (*tab)[256*256] = (const uint16_t (*)[256*256])s->lut;
+const int in_linesize  =  in->linesize[0] / 2;
+const int out_linesize = out->linesize[0] / 2;
+const int step = s->step;
+
+const int slice_start = (h *  jobnr   ) / nb_jobs;
+const int slice_end   = (h * (jobnr+1)) / nb_jobs;
+
+inrow0  = (uint16_t *)in ->data[0];
+outrow0 = (uint16_t *)out->data[0];
+
+for (i = slice_start; i < slice_end; i++) {
+inrow  = inrow0 + i * in_linesize;
+outrow = outrow0 + i * out_linesize;
+for (j = 0; j < w; j++) {
+
+switch (step) {
+#if HAVE_BIGENDIAN
+case 4:  outrow[3] = av_bswap16(tab[3][av_bswap16(inrow[3])]); // 
Fall-through
+case 3:  outrow[2] = av_bswap16(tab[2][av_bswap16(inrow[2])]); // 
Fall-through
+case 2:  outrow[1] = av_bswap16(tab[1][av_bswap16(inrow[1])]); // 
Fall-through
+default: outrow[0] = av_bswap16(tab[0][av_bswap16(inrow[0])]);
+#else
+case 4:  outrow[3] = tab[3][inrow[3]]; // Fall-through
+case 3:  outrow[2] = tab[2][inrow[2]]; // Fall-through
+case 2:  outrow[1] = tab[1][inrow[1]]; // Fall-through
+default: outrow[0] = tab[0][inrow[0]];
+#endif
+}
+outrow += step;
+inrow  += step;
+}
+}
+
+return 0;
+}
+
+/* packed, 16-bit */
+static int lut_packed_8bits(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs)
+{
+LutContext *s = ctx->priv;
+const struct thread_data *td = arg;
+
+uint8_t *inrow, *outrow, *inrow0, *outrow0;
+int i, j;
+const int w = td->w;
+const int h = td->h;
+AVFrame *in = td->in;
+AVFrame *out = td->out;
+const uint16_t (*tab)[256*256] = (const uint16_t (*)[256*256])s->lut;
+const int in_linesize  =  in->linesize[0];
+const int out_linesize = out->linesize[0];
+const int step = s->step;
+
+const int slice_start = (h *  jobnr   ) / nb_jobs;
+const int slice_end   = (h * (jobnr+1)) / nb_jobs;
+
+inrow0  = in ->data[0];
+outrow0 = out->data[0];
+
+for (i = slice_start; i < slice_end; i++) {
+inrow  = inrow0 + i * in_linesize;
+outrow = outrow0 + i * out_linesize;
+for (j = 0; j < w; j++) {
+switch (step) {
+case 4:  outrow[3] = tab[3][inrow[3]]; // Fall-through
+case 3:  outrow[2] = tab[2][inrow[2]]; // Fall-through
+case 2:  outrow[1] = tab[1][inrow[1]]; // Fall-through
+default: outrow[0] = tab[0][inrow[0]];
+}
+outrow += step;
+inrow  += step;
+}
+}
+
+return 0;
+}
+
+
+static int lut_planar_16bits(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs)
+{
+// planar >8 bit depth
+LutContext *s = ctx->priv;
+const struct thread_data *td = arg;
+
+uint16_t *inrow, *outrow;
+int i, j, plane;
+
+AVFrame *in = td->in;
+AVFrame *out = td->out;
+
+for (plane = 0; plane < 4 && in->data[plane] && in->linesize[plane]; 
plane++) {
+int vsub = plane == 1 || plane == 2 ? s->vsub : 0;
+int hsub = plane == 1 || plane == 2 ? s->hsub : 0;
+int h = AV_CEIL_RSHIFT(td->h, vsub);
+int w = AV_CEIL_RSHIFT(td->w, hsub);
+const uint16_t *tab = s->lut[plane];
+const int in_linesize  =  in->linesize[plane] / 2;
+const int out_linesize = out->linesize[plane] / 2;
+
+const int slice_start = (h *  jobnr   ) / nb_jobs;
+const int slice_end   = (h * (jobnr+1)) / nb_jobs;
+
+inrow  = (uint16_t *)(in ->data[plane] + slice_start * in_linesize);
+outrow = (uint16_t *)(out->data[plane] + slice_start * out_linesize);
+
+for (i = slice_start; i < slice_end; i++) {
+

Re: [FFmpeg-devel] [PATCH v4] libavformat/mpegtsenc: Add minimal support for ATSC PSIP tables

2019-05-21 Thread Phil Burr
This patch has a bit more restructuring to consolidate the ATSC specific
fields.  I fixed some bugs where a few fields were set incorrectly.
Specifically, the MGT transmits the length of each table it describes and
so each table it describes is pre-populated.  Testing last night involved
taking an OTA ATSC broadcast, remuxing with ffmpeg and transmitting to a TV
for two hours.

On Tue, May 21, 2019 at 8:40 AM Phillip Burr  wrote:

> Minimal support for ATSC PSIP tables.  Does not support STT or
> EIT tables and so is not compliant with terrestrial ATSC.
> ATSC tables are not created by default, and will only be transmitted
> if either "atsc_name" or "atsc_channel" metadata is supplied.
>
> Signed-off-by: Phillip Burr 
> ---
>  doc/muxers.texi |  33 ++-
>  libavformat/mpegts.h|   8 +
>  libavformat/mpegtsenc.c | 468 
>  3 files changed, 415 insertions(+), 94 deletions(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 83ae017d6c..dd68eec362 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1500,10 +1500,35 @@ MPEG transport stream muxer.
>
>  This muxer implements ISO 13818-1 and part of ETSI EN 300 468.
>
> -The recognized metadata settings in mpegts muxer are
> @code{service_provider}
> -and @code{service_name}. If they are not set the default for
> -@code{service_provider} is @samp{FFmpeg} and the default for
> -@code{service_name} is @samp{Service01}.
> +@subsection Metadata
> +
> +The recognized metadata settings in this muxer are:
> +
> +@table @option
> +@item service_name @var{string}
> +Set the @code{service_provider}.  Default is @samp{FFmpeg}.
> +
> +@item service_name @var{string}
> +Set the @code{service_name}. Default is @samp{Service01}.
> +
> +@item atsc_name @var{string}
> +Set the @code{atsc_name} for the stream.  This is the ATSC short
> +channel name for the stream.
> +
> +@item atsc_channel @var{string}
> +Set the @code{atsc_channel} virtual channel for the stream.  This
> +is parsed as @samp{Channel[.SubChannel]} format where the subchannel
> +is optional and defaults to @code{1}.
> +
> +@end table
> +
> +ATSC tables will @emph{not} be generated unless either @code{atsc_name}
> +or @code{atsc_channel} are provided @emph{and} @code{muxrate} is provided.
> +In the event that either @code{atsc_name} or @code{atsc_channel} is
> provided
> +but not both, the default for @code{atsc_name} is @samp{FFmpeg}
> +and the default for @code{atsc_channel} is @samp{1.1}.
> +ATSC tables generated include @code{MGT} and @code{TVCT} tables but are
> lacking the mandatory
> +@code{STT}, @code{EIT0}, @code{EIT1}, @code{EIT2} and @code{EIT3} tables
> needed for terrestrial ATC compliance.
>
>  @subsection Options
>
> diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
> index 272e2be4f7..ca6943b1ba 100644
> --- a/libavformat/mpegts.h
> +++ b/libavformat/mpegts.h
> @@ -35,12 +35,20 @@
>  /* pids */
>  #define PAT_PID 0x
>  #define SDT_PID 0x0011
> +#define ATSC_PID0x1ffb
>
>  /* table ids */
>  #define PAT_TID   0x00
>  #define PMT_TID   0x02
>  #define M4OD_TID  0x05
>  #define SDT_TID   0x42
> +#define MGT_TID   0xc7
> +#define TVCT_TID  0xc8
> +#define CVCT_TID  0xc9
> +#define RRT_TID   0xca
> +#define EIT_TID   0xcb
> +#define ETT_TID   0xcc
> +#define STT_TID   0xcd
>
>  #define STREAM_TYPE_VIDEO_MPEG1 0x01
>  #define STREAM_TYPE_VIDEO_MPEG2 0x02
> diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
> index fc0ea225c6..335ff254d8 100644
> --- a/libavformat/mpegtsenc.c
> +++ b/libavformat/mpegtsenc.c
> @@ -56,12 +56,40 @@ typedef struct MpegTSService {
>  int sid;   /* service ID */
>  uint8_t name[256];
>  uint8_t provider_name[256];
> +
> +uint16_t atsc_name[7]; /* ATSC VCT fields */
> +int atsc_mj_channel;
> +int atsc_mn_channel;
> +
>  int pcr_pid;
>  int pcr_packet_count;
>  int pcr_packet_period;
>  AVProgram *program;
>  } MpegTSService;
>
> +/* The section length is 12 bits. The first 2 are set to 0, the remaining
> + * 10 bits should not exceed 1021. */
> +#define SECTION_LENGTH 1020
> +
> +typedef struct MpegTSAtsc {
> +int enabled;
> +int regenerate;
> +
> +MpegTSSection section; /* ATSC tables */
> +
> +int mgt_packet_count;
> +int mgt_packet_period;
> +int tvct_packet_count;
> +int tvct_packet_period;
> +int64_t last_mgt_ts;
> +int64_t last_tvct_ts;
> +
> +uint32_t tvct_length;
> +uint32_t mgt_length;
> +uint8_t tvct_data[SECTION_LENGTH];
> +uint8_t mgt_data[SECTION_LENGTH];
> +} MpegTSAtsc;
> +
>  // service_type values as defined in ETSI 300 468
>  enum {
>  MPEGTS_SERVICE_TYPE_DIGITAL_TV   = 0x01,
> @@ -78,6 +106,7 @@ typedef struct MpegTSWrite {
>  MpegTSSection pat; /* MPEG-2 PAT table */
>  MpegTSSection sdt; /* MPEG-2 SDT table context */
>  MpegTSService **services;
> +MpegTSAtsc atsc;
>  int 

Re: [FFmpeg-devel] [PATCH 1/4] avcodec: add siren audio decoder

2019-05-21 Thread Moritz Barsnick
On Thu, May 16, 2019 at 12:51:46 +0200, Lynne wrote:
> > +#define STEPSIZE0.3010299957
>
> Just hardcode this in the powf call.

With an appended 'f'.

> > +const float scale = 1.0f;

> const float scale = 1.0 / 32768;

1.0f, but it doesn't matter here, as the preprocessor reduces it to
float (alledgedly).

> > +s->deviation_inverse[i] = 1.f / s->standard_deviation[i];
>
> Nit: 1.0 instead of 1.f

No, 1.f or 1.0f. Otherwise, it promotes the division to a double
precision operation before casting back to the left hand side float.

(It only matters on hardware which requires double precision software
emulation, but if explicitly using float, make sure to stick to float.)

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

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

[FFmpeg-devel] [PATCH v4] libavformat/mpegtsenc: Add minimal support for ATSC PSIP tables

2019-05-21 Thread Phillip Burr
Minimal support for ATSC PSIP tables.  Does not support STT or
EIT tables and so is not compliant with terrestrial ATSC.
ATSC tables are not created by default, and will only be transmitted
if either "atsc_name" or "atsc_channel" metadata is supplied.

Signed-off-by: Phillip Burr 
---
 doc/muxers.texi |  33 ++-
 libavformat/mpegts.h|   8 +
 libavformat/mpegtsenc.c | 468 
 3 files changed, 415 insertions(+), 94 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 83ae017d6c..dd68eec362 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1500,10 +1500,35 @@ MPEG transport stream muxer.
 
 This muxer implements ISO 13818-1 and part of ETSI EN 300 468.
 
-The recognized metadata settings in mpegts muxer are @code{service_provider}
-and @code{service_name}. If they are not set the default for
-@code{service_provider} is @samp{FFmpeg} and the default for
-@code{service_name} is @samp{Service01}.
+@subsection Metadata
+
+The recognized metadata settings in this muxer are:
+
+@table @option
+@item service_name @var{string}
+Set the @code{service_provider}.  Default is @samp{FFmpeg}.
+
+@item service_name @var{string}
+Set the @code{service_name}. Default is @samp{Service01}.
+
+@item atsc_name @var{string}
+Set the @code{atsc_name} for the stream.  This is the ATSC short
+channel name for the stream.
+
+@item atsc_channel @var{string}
+Set the @code{atsc_channel} virtual channel for the stream.  This
+is parsed as @samp{Channel[.SubChannel]} format where the subchannel
+is optional and defaults to @code{1}.
+
+@end table
+
+ATSC tables will @emph{not} be generated unless either @code{atsc_name}
+or @code{atsc_channel} are provided @emph{and} @code{muxrate} is provided.
+In the event that either @code{atsc_name} or @code{atsc_channel} is provided
+but not both, the default for @code{atsc_name} is @samp{FFmpeg}
+and the default for @code{atsc_channel} is @samp{1.1}.
+ATSC tables generated include @code{MGT} and @code{TVCT} tables but are 
lacking the mandatory
+@code{STT}, @code{EIT0}, @code{EIT1}, @code{EIT2} and @code{EIT3} tables 
needed for terrestrial ATC compliance.
 
 @subsection Options
 
diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
index 272e2be4f7..ca6943b1ba 100644
--- a/libavformat/mpegts.h
+++ b/libavformat/mpegts.h
@@ -35,12 +35,20 @@
 /* pids */
 #define PAT_PID 0x
 #define SDT_PID 0x0011
+#define ATSC_PID0x1ffb
 
 /* table ids */
 #define PAT_TID   0x00
 #define PMT_TID   0x02
 #define M4OD_TID  0x05
 #define SDT_TID   0x42
+#define MGT_TID   0xc7
+#define TVCT_TID  0xc8
+#define CVCT_TID  0xc9
+#define RRT_TID   0xca
+#define EIT_TID   0xcb
+#define ETT_TID   0xcc
+#define STT_TID   0xcd
 
 #define STREAM_TYPE_VIDEO_MPEG1 0x01
 #define STREAM_TYPE_VIDEO_MPEG2 0x02
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index fc0ea225c6..335ff254d8 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -56,12 +56,40 @@ typedef struct MpegTSService {
 int sid;   /* service ID */
 uint8_t name[256];
 uint8_t provider_name[256];
+
+uint16_t atsc_name[7]; /* ATSC VCT fields */
+int atsc_mj_channel;
+int atsc_mn_channel;
+
 int pcr_pid;
 int pcr_packet_count;
 int pcr_packet_period;
 AVProgram *program;
 } MpegTSService;
 
+/* The section length is 12 bits. The first 2 are set to 0, the remaining
+ * 10 bits should not exceed 1021. */
+#define SECTION_LENGTH 1020
+
+typedef struct MpegTSAtsc {
+int enabled;
+int regenerate;
+
+MpegTSSection section; /* ATSC tables */
+
+int mgt_packet_count;
+int mgt_packet_period;
+int tvct_packet_count;
+int tvct_packet_period;
+int64_t last_mgt_ts;
+int64_t last_tvct_ts;
+
+uint32_t tvct_length;
+uint32_t mgt_length;
+uint8_t tvct_data[SECTION_LENGTH];
+uint8_t mgt_data[SECTION_LENGTH];
+} MpegTSAtsc;
+
 // service_type values as defined in ETSI 300 468
 enum {
 MPEGTS_SERVICE_TYPE_DIGITAL_TV   = 0x01,
@@ -78,6 +106,7 @@ typedef struct MpegTSWrite {
 MpegTSSection pat; /* MPEG-2 PAT table */
 MpegTSSection sdt; /* MPEG-2 SDT table context */
 MpegTSService **services;
+MpegTSAtsc atsc;
 int sdt_packet_count;
 int sdt_packet_period;
 int pat_packet_count;
@@ -121,10 +150,6 @@ typedef struct MpegTSWrite {
 #define DEFAULT_PES_HEADER_FREQ  16
 #define DEFAULT_PES_PAYLOAD_SIZE ((DEFAULT_PES_HEADER_FREQ - 1) * 184 + 170)
 
-/* The section length is 12 bits. The first 2 are set to 0, the remaining
- * 10 bits should not exceed 1021. */
-#define SECTION_LENGTH 1020
-
 /* NOTE: 4 bytes must be left at the end for the crc32 */
 static void mpegts_write_section(MpegTSSection *s, uint8_t *buf, int len)
 {
@@ -189,14 +214,24 @@ static inline void put16(uint8_t **q_ptr, int val)
 *q_ptr = q;
 }
 
+static inline void put32(uint8_t **q_ptr, int val)
+{
+uint8_t *q;
+

Re: [FFmpeg-devel] [PATCHv4] VP4 video decoder

2019-05-21 Thread James Almer
On 5/21/2019 6:34 AM, Tomas Härdin wrote:
> tis 2019-05-21 klockan 17:44 +1000 skrev Peter Ross:
>> ---
>>
>> what's changed:
>> * apply #if CONFIG_VP4_DECODER around large vp4 code blocks
>> * improved vp4_read_mb_value thanks to reminars suggestions
>> * improved configure vp3_decoder_select
>>
>> [...]
>>  
>> +#define BLOCK_X (2 * mb_x + (k & 1))
>> +#define BLOCK_Y (2 * mb_y + (k >> 1))
>> +
>> +#if CONFIG_VP4_DECODER
>> +static int vp4_read_mb_value(GetBitContext *gb)
>> +{
>> +int v = 1;
>> +int bits = show_bits(gb, 9);
> 
> This call to show_bits() looks unnecessary
> 
>> +while ((bits = show_bits(gb, 9)) == 0x1ff) {
>> +skip_bits(gb, 9);
>> +v += 256;
>> +}
> 
> I have a feeling this loop should have a stop condition like v <
> SOME_LARGE_VALUE, say INT_MAX-255 or yuv_macroblock_count, to reject
> corrupt/malicious files and not cause undefined behavior

Using get_bits_left(gb) would be better than an arbitrary large value.
___
ffmpeg-devel mailing list
ffmpeg-devel@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/segment: populate empty outer stream extradata from packet

2019-05-21 Thread Gyan

Fixes playback in QT for me.

Gyan
From 3b7c51ebb8e26aafe27170e1c8e969b854c985ff Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Tue, 21 May 2019 17:15:54 +0530
Subject: [PATCH] avformat/segment: populate empty outer stream extradata from
 packet

At present, if the outer stream extradata is empty but first packet
has extradata as a side data element, then only the first segment's
muxer instance may be able to extract this side data and use it.
For all other segments, extradata in packet side data could be missing
and generated segments may be invalid or unplayable in some apps
e.g. for an ADTS AAC stream segmented to MP4, the adtstoasc BSF will
add extradata to the first packet. The MOV muxer for the first segment
will add this to codecpar for the inner stream and write
Decoder Specific Information within the esds box. For other segments,
their esds' will not have this decSpecificInfo and they can't be opened
in Quicktime player or by services like nginx-vod-module.
---
 libavformat/segment.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/libavformat/segment.c b/libavformat/segment.c
index 90004600bd..6e37707f9f 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -859,6 +859,20 @@ static int seg_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 if (!seg->avf || !seg->avf->pb)
 return AVERROR(EINVAL);
 
+if (!st->codecpar->extradata_size) {
+int pkt_extradata_size = 0;
+uint8_t *pkt_extradata = av_packet_get_side_data(pkt, 
AV_PKT_DATA_NEW_EXTRADATA, _extradata_size);
+if (pkt_extradata && pkt_extradata_size > 0) {
+ret = ff_alloc_extradata(st->codecpar, pkt_extradata_size);
+if (ret < 0) {
+av_log(s, AV_LOG_WARNING, "Unable to add extradata to stream. 
Output segments may be invalid.\n");
+goto calc_times;
+}
+memcpy(st->codecpar->extradata, pkt_extradata, pkt_extradata_size);
+st->codecpar->extradata_size = pkt_extradata_size;
+}
+}
+
 calc_times:
 if (seg->times) {
 end_pts = seg->segment_count < seg->nb_times ?
-- 
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] libavfilter/dnn_native: Add multiple activation functions in dnn native

2019-05-21 Thread Guo, Yejun


> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Xuewei Meng
> Sent: Tuesday, May 21, 2019 2:53 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH] libavfilter/dnn_native: Add multiple 
> activation
> functions in dnn native
> 
> Add "Leaky_relu" and "None" option in activation function.
> 
> Signed-off-by: Xuewei Meng 
> ---
>  libavfilter/dnn_backend_native.c | 5 +
>  libavfilter/dnn_backend_native.h | 2 +-
>  2 files changed, 6 insertions(+), 1 deletion(-)

LGTM

> 
> diff --git a/libavfilter/dnn_backend_native.c 
> b/libavfilter/dnn_backend_native.c
> index fa3f20e4a2..3c8465a283 100644
> --- a/libavfilter/dnn_backend_native.c
> +++ b/libavfilter/dnn_backend_native.c
> @@ -270,6 +270,11 @@ static void convolve(const float *input, float *output,
> const ConvolutionalParam
>  break;
>  case SIGMOID:
>  output[n_filter] = 1.0f / (1.0f + 
> exp(-output[n_filter]));
> +break;
> +case NONE:
> +break;
> +case LEAKY_RELU:
> +output[n_filter] = FFMAX(output[n_filter], 0.0) + 0.2 *
> FFMIN(output[n_filter], 0.0);
>  }
>  }
>  output += conv_params->output_num;
> diff --git a/libavfilter/dnn_backend_native.h 
> b/libavfilter/dnn_backend_native.h
> index d70cd16387..7e4e943137 100644
> --- a/libavfilter/dnn_backend_native.h
> +++ b/libavfilter/dnn_backend_native.h
> @@ -32,7 +32,7 @@
> 
>  typedef enum {INPUT, CONV, DEPTH_TO_SPACE} DNNLayerType;
> 
> -typedef enum {RELU, TANH, SIGMOID} DNNActivationFunc;
> +typedef enum {RELU, TANH, SIGMOID, NONE, LEAKY_RELU}
> DNNActivationFunc;
> 
>  typedef enum {VALID, SAME, SAME_CLAMP_TO_EDGE}
> DNNConvPaddingParam;
> 
> --
> 2.17.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH V2] lavfi/colorlevels: Add slice threading support

2019-05-21 Thread Jun Zhao
From: Jun Zhao 

Add slice threading support, use the command like:

./ffmpeg -i input -vf colorlevel with 1080p h264 clip, the fps
from 39 fps to 79 fps in the local

Signed-off-by: Jun Zhao 
---
 libavfilter/vf_colorlevels.c |  125 +++--
 1 files changed, 106 insertions(+), 19 deletions(-)

diff --git a/libavfilter/vf_colorlevels.c b/libavfilter/vf_colorlevels.c
index 5385a5e..68668e7 100644
--- a/libavfilter/vf_colorlevels.c
+++ b/libavfilter/vf_colorlevels.c
@@ -105,6 +105,83 @@ static int config_input(AVFilterLink *inlink)
 return 0;
 }
 
+struct thread_data {
+const uint8_t *srcrow;
+uint8_t *dstrow;
+int dst_linesize;
+int src_linesize;
+
+double coeff;
+uint8_t offset;
+
+int h;
+
+int imin;
+int omin;
+};
+
+static int colorlevel_slice_8(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs)
+{
+ColorLevelsContext *s = ctx->priv;
+const struct thread_data *td = arg;
+
+int process_h = td->h;
+const int slice_start = (process_h *  jobnr   ) / nb_jobs;
+const int slice_end   = (process_h * (jobnr+1)) / nb_jobs;
+int x, y;
+const uint8_t *srcrow = td->srcrow;
+uint8_t *dstrow = td->dstrow;
+const int step = s->step;
+const uint8_t offset = td->offset;
+
+int imin = td->imin;
+int omin = td->omin;
+double coeff = td->coeff;
+
+for (y = slice_start; y < slice_end; y++) {
+const uint8_t *src = srcrow;
+uint8_t *dst = dstrow;
+
+for (x = 0; x < s->linesize; x += step)
+dst[x + offset] = av_clip_uint8((src[x + offset] - imin) * coeff + 
omin);
+dstrow += td->dst_linesize;
+srcrow += td->src_linesize;
+}
+
+return 0;
+}
+
+static int colorlevel_slice_16(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs)
+{
+ColorLevelsContext *s = ctx->priv;
+const struct thread_data *td = arg;
+
+int process_h = td->h;
+const int slice_start = (process_h *  jobnr   ) / nb_jobs;
+const int slice_end   = (process_h * (jobnr+1)) / nb_jobs;
+int x, y;
+const uint8_t *srcrow = td->srcrow;
+uint8_t *dstrow = td->dstrow;
+const int step = s->step;
+const uint8_t offset = td->offset;
+
+int imin = td->imin;
+int omin = td->omin;
+double coeff = td->coeff;
+
+for (y = slice_start; y < slice_end; y++) {
+const uint16_t *src = (const uint16_t *)srcrow;
+uint16_t *dst = (uint16_t *)dstrow;
+
+for (x = 0; x < s->linesize; x += step)
+dst[x + offset] = av_clip_uint8((src[x + offset] - imin) * coeff + 
omin);
+dstrow += td->dst_linesize;
+srcrow += td->src_linesize;
+}
+
+return 0;
+}
+
 static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 {
 AVFilterContext *ctx = inlink->dst;
@@ -137,6 +214,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 int omin = lrint(r->out_min * UINT8_MAX);
 int omax = lrint(r->out_max * UINT8_MAX);
 double coeff;
+struct thread_data td;
 
 if (imin < 0) {
 imin = UINT8_MAX;
@@ -162,15 +240,19 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 
 srcrow = in->data[0];
 coeff = (omax - omin) / (double)(imax - imin);
-for (y = 0; y < inlink->h; y++) {
-const uint8_t *src = srcrow;
-uint8_t *dst = dstrow;
-
-for (x = 0; x < s->linesize; x += step)
-dst[x + offset] = av_clip_uint8((src[x + offset] - imin) * 
coeff + omin);
-dstrow += out->linesize[0];
-srcrow += in->linesize[0];
-}
+
+td.srcrow= srcrow;
+td.dstrow= dstrow;
+td.dst_linesize  = out->linesize[0];
+td.src_linesize  = in->linesize[0];
+td.coeff = coeff;
+td.offset= offset;
+td.h = inlink->h;
+td.imin  = imin;
+td.omin  = omin;
+
+ctx->internal->execute(ctx, colorlevel_slice_8, , NULL,
+   FFMIN(inlink->h, 
ff_filter_get_nb_threads(ctx)));
 }
 break;
 case 2:
@@ -184,6 +266,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 int omin = lrint(r->out_min * UINT16_MAX);
 int omax = lrint(r->out_max * UINT16_MAX);
 double coeff;
+struct thread_data td;
 
 if (imin < 0) {
 imin = UINT16_MAX;
@@ -209,15 +292,19 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 
 srcrow = in->data[0];
 coeff = (omax - omin) / (double)(imax - imin);
-for (y = 0; y < inlink->h; y++) {
-const uint16_t *src = (const uint16_t*)srcrow;
-uint16_t *dst = (uint16_t *)dstrow;
-
-for (x = 0; x < s->linesize; x 

[FFmpeg-devel] [PATCH V3] lavfi/colorlevels: Add slice threading support

2019-05-21 Thread Jun Zhao
From: Jun Zhao 

Add slice threading support, use the command like:

./ffmpeg -i input -vf colorlevels -f null /dev/null

with 1080p h264 clip, the fps from 39 fps to 79 fps
in the local(Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz)

Signed-off-by: Jun Zhao 
---
 libavfilter/vf_colorlevels.c |  121 +++---
 1 files changed, 102 insertions(+), 19 deletions(-)

diff --git a/libavfilter/vf_colorlevels.c b/libavfilter/vf_colorlevels.c
index 5385a5e..c3b7137 100644
--- a/libavfilter/vf_colorlevels.c
+++ b/libavfilter/vf_colorlevels.c
@@ -105,6 +105,79 @@ static int config_input(AVFilterLink *inlink)
 return 0;
 }
 
+struct thread_data {
+const uint8_t *srcrow;
+uint8_t *dstrow;
+int dst_linesize;
+int src_linesize;
+
+double coeff;
+uint8_t offset;
+
+int h;
+
+int imin;
+int omin;
+};
+
+static int colorlevel_slice_8(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs)
+{
+ColorLevelsContext *s = ctx->priv;
+const struct thread_data *td = arg;
+
+int process_h = td->h;
+const int slice_start = (process_h *  jobnr   ) / nb_jobs;
+const int slice_end   = (process_h * (jobnr+1)) / nb_jobs;
+int x, y;
+const uint8_t *srcrow = td->srcrow;
+uint8_t *dstrow = td->dstrow;
+const int step = s->step;
+const uint8_t offset = td->offset;
+
+int imin = td->imin;
+int omin = td->omin;
+double coeff = td->coeff;
+
+for (y = slice_start; y < slice_end; y++) {
+const uint8_t *src = srcrow + y * td->src_linesize;
+uint8_t *dst = dstrow + y * td->dst_linesize;
+
+for (x = 0; x < s->linesize; x += step)
+dst[x + offset] = av_clip_uint8((src[x + offset] - imin) * coeff + 
omin);
+}
+
+return 0;
+}
+
+static int colorlevel_slice_16(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs)
+{
+ColorLevelsContext *s = ctx->priv;
+const struct thread_data *td = arg;
+
+int process_h = td->h;
+const int slice_start = (process_h *  jobnr   ) / nb_jobs;
+const int slice_end   = (process_h * (jobnr+1)) / nb_jobs;
+int x, y;
+const uint8_t *srcrow = td->srcrow;
+uint8_t *dstrow = td->dstrow;
+const int step = s->step;
+const uint8_t offset = td->offset;
+
+int imin = td->imin;
+int omin = td->omin;
+double coeff = td->coeff;
+
+for (y = slice_start; y < slice_end; y++) {
+const uint16_t *src = (const uint16_t *)(srcrow + y * 
td->src_linesize);
+uint16_t *dst = (uint16_t *)(dstrow + y * td->dst_linesize);
+
+for (x = 0; x < s->linesize; x += step)
+dst[x + offset] = av_clip_uint8((src[x + offset] - imin) * coeff + 
omin);
+}
+
+return 0;
+}
+
 static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 {
 AVFilterContext *ctx = inlink->dst;
@@ -137,6 +210,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 int omin = lrint(r->out_min * UINT8_MAX);
 int omax = lrint(r->out_max * UINT8_MAX);
 double coeff;
+struct thread_data td;
 
 if (imin < 0) {
 imin = UINT8_MAX;
@@ -162,15 +236,19 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 
 srcrow = in->data[0];
 coeff = (omax - omin) / (double)(imax - imin);
-for (y = 0; y < inlink->h; y++) {
-const uint8_t *src = srcrow;
-uint8_t *dst = dstrow;
-
-for (x = 0; x < s->linesize; x += step)
-dst[x + offset] = av_clip_uint8((src[x + offset] - imin) * 
coeff + omin);
-dstrow += out->linesize[0];
-srcrow += in->linesize[0];
-}
+
+td.srcrow= srcrow;
+td.dstrow= dstrow;
+td.dst_linesize  = out->linesize[0];
+td.src_linesize  = in->linesize[0];
+td.coeff = coeff;
+td.offset= offset;
+td.h = inlink->h;
+td.imin  = imin;
+td.omin  = omin;
+
+ctx->internal->execute(ctx, colorlevel_slice_8, , NULL,
+   FFMIN(inlink->h, 
ff_filter_get_nb_threads(ctx)));
 }
 break;
 case 2:
@@ -184,6 +262,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 int omin = lrint(r->out_min * UINT16_MAX);
 int omax = lrint(r->out_max * UINT16_MAX);
 double coeff;
+struct thread_data td;
 
 if (imin < 0) {
 imin = UINT16_MAX;
@@ -209,15 +288,19 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 
 srcrow = in->data[0];
 coeff = (omax - omin) / (double)(imax - imin);
-for (y = 0; y < inlink->h; y++) {
-const uint16_t *src = (const uint16_t*)srcrow;
-uint16_t *dst = (uint16_t *)dstrow;
-
-for (x = 0; x < 

Re: [FFmpeg-devel] [PATCH] lavfi/colorlevels: Add slice threading support

2019-05-21 Thread myp...@gmail.com
On Tue, May 21, 2019 at 9:49 AM Jun Zhao  wrote:
>
> From: Jun Zhao 
>
> Add slice threading support, use the command like:
>
> ./ffmpeg -i input -vf colorlevel with 1080p h264 clip, the fps
> from 39 fps to 79 fps in the local
>
> Signed-off-by: Jun Zhao 
> ---
>  libavfilter/vf_colorlevels.c |  125 +++--
>  1 files changed, 106 insertions(+), 19 deletions(-)
>
> diff --git a/libavfilter/vf_colorlevels.c b/libavfilter/vf_colorlevels.c
> index 5385a5e..68668e7 100644
> --- a/libavfilter/vf_colorlevels.c
> +++ b/libavfilter/vf_colorlevels.c
> @@ -105,6 +105,83 @@ static int config_input(AVFilterLink *inlink)
>  return 0;
>  }
>
> +struct thread_data {
> +const uint8_t *srcrow;
> +uint8_t *dstrow;
> +int dst_linesize;
> +int src_linesize;
> +
> +double coeff;
> +uint8_t offset;
> +
> +int h;
> +
> +int imin;
> +int omin;
> +};
> +
> +static int colorlevel_slice_8(AVFilterContext *ctx, void *arg, int jobnr, 
> int nb_jobs)
> +{
> +ColorLevelsContext *s = ctx->priv;
> +const struct thread_data *td = arg;
> +
> +int process_h = td->h;
> +const int slice_start = (process_h *  jobnr   ) / nb_jobs;
> +const int slice_end   = (process_h * (jobnr+1)) / nb_jobs;
> +int x, y;
> +const uint8_t *srcrow = td->srcrow;
> +uint8_t *dstrow = td->dstrow;
> +const int step = s->step;
> +const uint8_t offset = td->offset;
> +
> +int imin = td->imin;
> +int omin = td->omin;
> +double coeff = td->coeff;
> +
> +for (y = slice_start; y < slice_end; y++) {
> +const uint8_t *src = srcrow;
> +uint8_t *dst = dstrow;
> +
> +for (x = 0; x < s->linesize; x += step)
> +dst[x + offset] = av_clip_uint8((src[x + offset] - imin) * coeff 
> + omin);
> +dstrow += td->dst_linesize;
> +srcrow += td->src_linesize;
> +}
> +
> +return 0;
> +}
> +
> +static int colorlevel_slice_16(AVFilterContext *ctx, void *arg, int jobnr, 
> int nb_jobs)
> +{
> +ColorLevelsContext *s = ctx->priv;
> +const struct thread_data *td = arg;
> +
> +int process_h = td->h;
> +const int slice_start = (process_h *  jobnr   ) / nb_jobs;
> +const int slice_end   = (process_h * (jobnr+1)) / nb_jobs;
> +int x, y;
> +const uint8_t *srcrow = td->srcrow;
> +uint8_t *dstrow = td->dstrow;
> +const int step = s->step;
> +const uint8_t offset = td->offset;
> +
> +int imin = td->imin;
> +int omin = td->omin;
> +double coeff = td->coeff;
> +
> +for (y = slice_start; y < slice_end; y++) {
> +const uint16_t *src = (const uint16_t *)srcrow;
> +uint16_t *dst = (uint16_t *)dstrow;
> +
> +for (x = 0; x < s->linesize; x += step)
> +dst[x + offset] = av_clip_uint8((src[x + offset] - imin) * coeff 
> + omin);
> +dstrow += td->dst_linesize;
> +srcrow += td->src_linesize;
> +}
> +
> +return 0;
> +}
> +
>  static int filter_frame(AVFilterLink *inlink, AVFrame *in)
>  {
>  AVFilterContext *ctx = inlink->dst;
> @@ -137,6 +214,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
>  int omin = lrint(r->out_min * UINT8_MAX);
>  int omax = lrint(r->out_max * UINT8_MAX);
>  double coeff;
> +struct thread_data td;
>
>  if (imin < 0) {
>  imin = UINT8_MAX;
> @@ -162,15 +240,19 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
> *in)
>
>  srcrow = in->data[0];
>  coeff = (omax - omin) / (double)(imax - imin);
> -for (y = 0; y < inlink->h; y++) {
> -const uint8_t *src = srcrow;
> -uint8_t *dst = dstrow;
> -
> -for (x = 0; x < s->linesize; x += step)
> -dst[x + offset] = av_clip_uint8((src[x + offset] - imin) 
> * coeff + omin);
> -dstrow += out->linesize[0];
> -srcrow += in->linesize[0];
> -}
> +
> +td.srcrow= srcrow;
> +td.dstrow= dstrow;
> +td.dst_linesize  = out->linesize[0];
> +td.src_linesize  = in->linesize[0];
> +td.coeff = coeff;
> +td.offset= offset;
> +td.h = inlink->h;
> +td.imin  = imin;
> +td.omin  = omin;
> +
> +ctx->internal->execute(ctx, colorlevel_slice_8, , NULL,
> +   FFMIN(inlink->h, 
> ff_filter_get_nb_threads(ctx)));
>  }
>  break;
>  case 2:
> @@ -184,6 +266,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
>  int omin = lrint(r->out_min * UINT16_MAX);
>  int omax = lrint(r->out_max * UINT16_MAX);
>  double coeff;
> +struct thread_data td;
>
>  if (imin < 0) {
>  imin = UINT16_MAX;
> @@ -209,15 +292,19 @@ static int 

Re: [FFmpeg-devel] [PATCHv4] VP4 video decoder

2019-05-21 Thread Tomas Härdin
tis 2019-05-21 klockan 17:44 +1000 skrev Peter Ross:
> ---
> 
> what's changed:
> * apply #if CONFIG_VP4_DECODER around large vp4 code blocks
> * improved vp4_read_mb_value thanks to reminars suggestions
> * improved configure vp3_decoder_select
> 
> [...]
>  
> +#define BLOCK_X (2 * mb_x + (k & 1))
> +#define BLOCK_Y (2 * mb_y + (k >> 1))
> +
> +#if CONFIG_VP4_DECODER
> +static int vp4_read_mb_value(GetBitContext *gb)
> +{
> +int v = 1;
> +int bits = show_bits(gb, 9);

This call to show_bits() looks unnecessary

> +while ((bits = show_bits(gb, 9)) == 0x1ff) {
> +skip_bits(gb, 9);
> +v += 256;
> +}

I have a feeling this loop should have a stop condition like v <
SOME_LARGE_VALUE, say INT_MAX-255 or yuv_macroblock_count, to reject
corrupt/malicious files and not cause undefined behavior

> +if (bits < 0x100) {
> +skip_bits(gb, 1);
> +} else if (bits < 0x180) {
> +skip_bits(gb, 2);
> +v += 1;
> +}
> +#define body(n) { \
> +skip_bits(gb, 2 + n); \
> +v += (1 << n) + get_bits(gb, n); }
> +#define else_if(thresh, n) else if (bits < thresh) body(n)
> +else_if(0x1c0, 1)
> +else_if(0x1e0, 2)
> +else_if(0x1f0, 3)
> +else_if(0x1f8, 4)
> +else_if(0x1fc, 5)
> +else_if(0x1fe, 6)
> +else body(7)
> +#undef body
> +#undef else_if
> +return v;
> +}

> @@ -1012,8 +1214,8 @@ static int unpack_vlcs(Vp3DecodeContext *s, 
> GetBitContext *gb,
>  bits_to_get = coeff_get_bits[token];
>  if (bits_to_get)
>  bits_to_get = get_bits(gb, bits_to_get);
> -coeff = coeff_tables[token][bits_to_get];
>  
> +coeff = coeff_tables[token][bits_to_get];

Stray hunk

> +#if CONFIG_VP4_DECODER
> +if (s->version >= 2) {
> +int mb_height, mb_width;
> +int mb_width_mul, mb_width_div, mb_height_mul, mb_height_div;
> +
> +mb_height = get_bits(, 8);
> +mb_width  = get_bits(, 8);
> +if (mb_height != s->macroblock_height ||
> +mb_width != s->macroblock_width)
> +av_log(s->avctx, AV_LOG_WARNING, "VP4 header: Warning, 
> macroblock dimension mismatch");
> +
> +mb_width_mul = get_bits(, 5);
> +mb_width_div = get_bits(, 3);
> +mb_height_mul = get_bits(, 5);
> +mb_height_div = get_bits(, 3);
> +if (mb_width_mul != 1 || mb_width_div != 1 || mb_height_mul 
> != 1 || mb_height_div != 1)
> +  av_log(s->avctx, AV_LOG_WARNING, "VP4 header: Warning, 
> unexpected macroblock dimension multipler/divider");
> +
> +if (get_bits(, 2))
> +av_log(s->avctx, AV_LOG_WARNING, "VP4 header: Warning, 
> unknown bits set");

Maybe these should be errors and/or requests for samples? It macroblock
count changes that may indicate a resolution change

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

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

[FFmpeg-devel] [PATCH] lavc/vaapi_encode: disable ICQ mode when enabling low power

2019-05-21 Thread Linjie Fu
ICQ mode is not supported in low power mode and should be disabled.

For H264, Driver supports RC modes CQP, CBR, VBR, QVBR.
For HEVC, Driver supports RC modes CQP, CBR, VBR, ICQ, QVBR.

ICQ is not exposed while working on low power mode for h264_vaapi, but
will trigger issues for hevc_vaapi.

Signed-off-by: Linjie Fu 
---
See https://github.com/intel/media-driver/issues/618 for details.
And patch for HEVC low power(ICL+): 
https://github.com/intel-media-ci/ffmpeg/pull/42

 libavcodec/vaapi_encode.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 2dda451..55ab919 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1371,6 +1371,7 @@ static av_cold int 
vaapi_encode_init_rate_control(AVCodecContext *avctx)
 // * If bitrate and maxrate are set and have the same value, try CBR.
 // * If a bitrate is set, try AVBR, then VBR, then CBR.
 // * If no bitrate is set, try ICQ, then CQP.
+// * If low power is set, ICQ is not supported.
 
 #define TRY_RC_MODE(mode, fail) do { \
 rc_mode = _encode_rc_modes[mode]; \
@@ -1405,7 +1406,8 @@ static av_cold int 
vaapi_encode_init_rate_control(AVCodecContext *avctx)
 TRY_RC_MODE(RC_MODE_QVBR, 0);
 
 if (avctx->global_quality > 0) {
-TRY_RC_MODE(RC_MODE_ICQ, 0);
+if (!ctx->low_power)
+TRY_RC_MODE(RC_MODE_ICQ, 0);
 TRY_RC_MODE(RC_MODE_CQP, 0);
 }
 
@@ -1417,7 +1419,8 @@ static av_cold int 
vaapi_encode_init_rate_control(AVCodecContext *avctx)
 TRY_RC_MODE(RC_MODE_VBR, 0);
 TRY_RC_MODE(RC_MODE_CBR, 0);
 } else {
-TRY_RC_MODE(RC_MODE_ICQ, 0);
+if (!ctx->low_power)
+TRY_RC_MODE(RC_MODE_ICQ, 0);
 TRY_RC_MODE(RC_MODE_CQP, 0);
 }
 
-- 
2.7.4

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

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

Re: [FFmpeg-devel] [PATCH v1] lavf/mov: Fix timestamp rescale on sidx atom

2019-05-21 Thread Jun Li
On Thu, May 16, 2019 at 1:00 AM Jun Li  wrote:

>
>
> On Sun, May 12, 2019 at 7:44 PM Jun Li  wrote:
>
>>
>>
>> On Fri, May 10, 2019 at 7:25 PM Jun Li  wrote:
>>
>>>
>>> On Thu, May 9, 2019 at 2:08 AM Jun Li  wrote:
>>>
 Fix #5090
 Fix the timestamp rescale issue, from sidx timebase to
 stream's timebase.
 ---
  libavformat/mov.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/libavformat/mov.c b/libavformat/mov.c
 index 78f692872b..d058855e6c 100644
 --- a/libavformat/mov.c
 +++ b/libavformat/mov.c
 @@ -5017,7 +5017,7 @@ static int mov_read_sidx(MOVContext *c,
 AVIOContext *pb, MOVAtom atom)
  return AVERROR_PATCHWELCOME;
  }
  avio_rb32(pb); // sap_flags
 -timestamp = av_rescale_q(pts, st->time_base, timescale);
 +timestamp = av_rescale_q(pts, timescale, st->time_base);

  index = update_frag_index(c, offset);
  frag_stream_info = get_frag_stream_info(>frag_index, index,
 track_id);
 --
 2.17.1

>>>
>>> Ping
>>>
>>
>> This change is for fix the issue of calculating sidx_pts.
>> Sidx box has "earliest_presentation_time", used as pts of  the referent
>> track, sidx also has timescale field.
>> So the operation should convert from sidx's timescale to track's
>> timescale, this patch is for addressing this, as well as fixing #5090.
>>
>> Of course this is based on my understanding, so please correct me if I am
>> wrong. Thanks !
>>
>>
> Ping.
> I believe this is a bug and triggered whenever sidx box's timescale is
> different from track's timescale.
> Created this kind of content and verified that ffplay couldn't play while
> VLC plays well.
> Then I checked VLC's implementation:
>
> https://github.com/videolan/vlc/blob/5609c1b41d6fbca6323103619c6139caf7bc9e6e/modules/demux/mp4/mp4.c#L4735
>
> Hope someone could help to have a review ? Thanks ! :)
>
> Best Regards,
> -Jun
>
>
>> Best Regards,
>> Jun
>>
>
Ping x 3
___
ffmpeg-devel mailing list
ffmpeg-devel@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] [PATCHv4] VP4 video decoder

2019-05-21 Thread Peter Ross
---

what's changed:
* apply #if CONFIG_VP4_DECODER around large vp4 code blocks
* improved vp4_read_mb_value thanks to reminars suggestions
* improved configure vp3_decoder_select


 Changelog   |1 +
 configure   |1 +
 doc/general.texi|2 +
 libavcodec/Makefile |1 +
 libavcodec/allcodecs.c  |1 +
 libavcodec/avcodec.h|1 +
 libavcodec/codec_desc.c |7 +
 libavcodec/vp3.c|  746 ++--
 libavcodec/vp4data.h| 1186 +++
 9 files changed, 1911 insertions(+), 35 deletions(-)
 create mode 100644 libavcodec/vp4data.h

diff --git a/Changelog b/Changelog
index e6b209ae0a..1c4e02d3aa 100644
--- a/Changelog
+++ b/Changelog
@@ -30,6 +30,7 @@ version :
 - colorhold filter
 - xmedian filter
 - asr filter
+- VP4 video decoder
 
 
 version 4.1:
diff --git a/configure b/configure
index 9b4305cf0d..61eb774116 100755
--- a/configure
+++ b/configure
@@ -2825,6 +2825,7 @@ vc1image_decoder_select="vc1_decoder"
 vorbis_decoder_select="mdct"
 vorbis_encoder_select="audio_frame_queue mdct"
 vp3_decoder_select="hpeldsp vp3dsp videodsp"
+vp4_decoder_select="vp3_decoder"
 vp5_decoder_select="h264chroma hpeldsp videodsp vp3dsp vp56dsp"
 vp6_decoder_select="h264chroma hpeldsp huffman videodsp vp3dsp vp56dsp"
 vp6a_decoder_select="vp6_decoder"
diff --git a/doc/general.texi b/doc/general.texi
index ec437230e3..ed3cdfcf99 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -944,6 +944,8 @@ following image formats are supported:
 @tab Video encoding used in NuppelVideo files.
 @item On2 VP3@tab @tab  X
 @tab still experimental
+@item On2 VP4@tab @tab  X
+@tab fourcc: VP40
 @item On2 VP5@tab @tab  X
 @tab fourcc: VP50
 @item On2 VP6@tab @tab  X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index edccd73037..d76f392f1e 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -663,6 +663,7 @@ OBJS-$(CONFIG_VORBIS_DECODER)  += vorbisdec.o 
vorbisdsp.o vorbis.o \
 OBJS-$(CONFIG_VORBIS_ENCODER)  += vorbisenc.o vorbis.o \
   vorbis_data.o
 OBJS-$(CONFIG_VP3_DECODER) += vp3.o
+OBJS-$(CONFIG_VP4_DECODER) += vp3.o
 OBJS-$(CONFIG_VP5_DECODER) += vp5.o vp56.o vp56data.o vp56rac.o
 OBJS-$(CONFIG_VP6_DECODER) += vp6.o vp56.o vp56data.o \
   vp6dsp.o vp56rac.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 6178d31b5c..d2f9a39ce5 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -330,6 +330,7 @@ extern AVCodec ff_vcr1_decoder;
 extern AVCodec ff_vmdvideo_decoder;
 extern AVCodec ff_vmnc_decoder;
 extern AVCodec ff_vp3_decoder;
+extern AVCodec ff_vp4_decoder;
 extern AVCodec ff_vp5_decoder;
 extern AVCodec ff_vp6_decoder;
 extern AVCodec ff_vp6a_decoder;
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index b749946633..586bbbca4e 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -456,6 +456,7 @@ enum AVCodecID {
 AV_CODEC_ID_ARBC,
 AV_CODEC_ID_AGM,
 AV_CODEC_ID_LSCR,
+AV_CODEC_ID_VP4,
 
 /* various PCM "codecs" */
 AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the 
start of audio codecs
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 621b16e160..4d033c20ff 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1719,6 +1719,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("LEAD Screen Capture"),
 .props = AV_CODEC_PROP_LOSSY,
 },
+{
+.id= AV_CODEC_ID_VP4,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "vp4",
+.long_name = NULL_IF_CONFIG_SMALL("On2 VP4"),
+.props = AV_CODEC_PROP_LOSSY,
+},
 
 /* various PCM "codecs" */
 {
diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
index b248c90413..5fe2c2477c 100644
--- a/libavcodec/vp3.c
+++ b/libavcodec/vp3.c
@@ -1,5 +1,6 @@
 /*
  * Copyright (C) 2003-2004 The FFmpeg project
+ * Copyright (C) 2019 Peter Ross
  *
  * This file is part of FFmpeg.
  *
@@ -20,7 +21,7 @@
 
 /**
  * @file
- * On2 VP3 Video Decoder
+ * On2 VP3/VP4 Video Decoder
  *
  * VP3 Video Decoder by Mike Melanson (mike at multimedia.cx)
  * For more information about the VP3 coding process, visit:
@@ -43,6 +44,7 @@
 #include "thread.h"
 #include "videodsp.h"
 #include "vp3data.h"
+#include "vp4data.h"
 #include "vp3dsp.h"
 #include "xiph.h"
 
@@ -127,6 +129,30 @@ static const uint8_t hilbert_offset[16][2] = {
 { 3, 1 }, { 2, 1 }, { 2, 0 }, { 3, 0 }
 };
 
+enum {
+VP4_DC_INTRA  = 0,
+VP4_DC_INTER  = 1,
+VP4_DC_GOLDEN = 2,
+NB_VP4_DC_TYPES,
+VP4_DC_UNDEFINED = NB_VP4_DC_TYPES
+};
+
+static const uint8_t vp4_pred_block_type_map[8] = {
+[MODE_INTER_NO_MV]  = 

[FFmpeg-devel] [PATCH] libavfilter/dnn_native: Add multiple activation functions in dnn native

2019-05-21 Thread Xuewei Meng
Add "Leaky_relu" and "None" option in activation function.

Signed-off-by: Xuewei Meng 
---
 libavfilter/dnn_backend_native.c | 5 +
 libavfilter/dnn_backend_native.h | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavfilter/dnn_backend_native.c b/libavfilter/dnn_backend_native.c
index fa3f20e4a2..3c8465a283 100644
--- a/libavfilter/dnn_backend_native.c
+++ b/libavfilter/dnn_backend_native.c
@@ -270,6 +270,11 @@ static void convolve(const float *input, float *output, 
const ConvolutionalParam
 break;
 case SIGMOID:
 output[n_filter] = 1.0f / (1.0f + exp(-output[n_filter]));
+break;
+case NONE:
+break;
+case LEAKY_RELU:
+output[n_filter] = FFMAX(output[n_filter], 0.0) + 0.2 * 
FFMIN(output[n_filter], 0.0);
 }
 }
 output += conv_params->output_num;
diff --git a/libavfilter/dnn_backend_native.h b/libavfilter/dnn_backend_native.h
index d70cd16387..7e4e943137 100644
--- a/libavfilter/dnn_backend_native.h
+++ b/libavfilter/dnn_backend_native.h
@@ -32,7 +32,7 @@
 
 typedef enum {INPUT, CONV, DEPTH_TO_SPACE} DNNLayerType;
 
-typedef enum {RELU, TANH, SIGMOID} DNNActivationFunc;
+typedef enum {RELU, TANH, SIGMOID, NONE, LEAKY_RELU} DNNActivationFunc;
 
 typedef enum {VALID, SAME, SAME_CLAMP_TO_EDGE} DNNConvPaddingParam;
 
-- 
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".