date:20161110

On 11 November 2016 at 02:25, James Almer  wrote:

> On 11/10/2016 1:17 PM, Rostislav Pehlivanov wrote:
> > This is meant to be applied on top of my previous patch which
> > split PVQ into celt_pvq.c and made opus_celt.h
> >
> > Essentially nothing has been changed other than renaming CeltFrame
> > to CeltBlock (CeltFrame had absolutely nothing at all to do with
> > a frame) and CeltContext to CeltFrame.
> > 3 variables have been put in CeltFrame as they make more sense
> > there rather than being passed around as arguments.
> > The coefficients have been moved to the CeltBlock structure
> > (why the hell were they in CeltContext and not in CeltFrame??).
> >
> > Now the encoder would be able to use the exact context the decoder
> > uses (plus a couple of extra fields in there).
> >
> > FATE passes, no slowdowns, etc.
> >
> > Signed-off-by: Rostislav Pehlivanov 
> > ---
> >  libavcodec/opus.h  |  14 +-
> >  libavcodec/opus_celt.c | 719 +-
> ---
> >  libavcodec/opus_celt.h |  82 +++---
> >  libavcodec/opus_pvq.c  |  50 ++--
> >  libavcodec/opus_pvq.h  |   8 +-
> >  libavcodec/opus_rc.c   |  12 +-
> >  libavcodec/opus_rc.h   |   6 +-
> >  libavcodec/opusdec.c   |   1 +
> >  8 files changed, 449 insertions(+), 443 deletions(-)
> >
> > diff --git a/libavcodec/opus.h b/libavcodec/opus.h
> > index be04249..e8d13df 100644
> > --- a/libavcodec/opus.h
> > +++ b/libavcodec/opus.h
> > @@ -75,7 +75,7 @@ enum OpusBandwidth {
> >
> >  typedef struct SilkContext SilkContext;
> >
> > -typedef struct CeltContext CeltContext;
> > +typedef struct CeltFrame CeltFrame;
>
> [...]
>
> > diff --git a/libavcodec/opus_celt.h b/libavcodec/opus_celt.h
> > index 8a15c8d..5bce8fc 100644
> > --- a/libavcodec/opus_celt.h
> > +++ b/libavcodec/opus_celt.h
> > @@ -37,7 +37,16 @@ enum CeltSpread {
> >  CELT_SPREAD_AGGRESSIVE
> >  };
> >
> > -typedef struct CeltFrame {
> > +enum CeltBlockSize {
> > +CELT_BLOCK_120,
> > +CELT_BLOCK_240,
> > +CELT_BLOCK_480,
> > +CELT_BLOCK_960,
> > +
> > +CELT_BLOCK_NB
> > +};
> > +
> > +typedef struct CeltBlock {
> >  float energy[CELT_MAX_BANDS];
> >  float prev_energy[2][CELT_MAX_BANDS];
> >
> > @@ -45,50 +54,46 @@ typedef struct CeltFrame {
> >
> >  /* buffer for mdct output + postfilter */
> >  DECLARE_ALIGNED(32, float, buf)[2048];
> > +DECLARE_ALIGNED(32, float, coeffs)[CELT_MAX_FRAME_SIZE];
> >
> >  /* postfilter parameters */
> > -int pf_period_new;
> > +int   pf_period_new;
> >  float pf_gains_new[3];
> > -int pf_period;
> > +int   pf_period;
> >  float pf_gains[3];
> > -int pf_period_old;
> > +int   pf_period_old;
> >  float pf_gains_old[3];
> >
> > -float deemph_coeff;
> > -} CeltFrame;
> > +float emph_coeff;
> > +} CeltBlock;
> >
> > -struct CeltContext {
> > +typedef struct CeltFrame {
>
> You're typedefing CeltFrame again here. Keep it the same as CeltContext
> used to be.
>

Fixed locally


>
> >  // constant values that do not change during context lifetime
> > -AVCodecContext*avctx;
> > -IMDCT15Context*imdct[4];
> > -AVFloatDSPContext  *dsp;
> > +AVCodecContext  *avctx;
> > +IMDCT15Context  *imdct[4];
> > +AVFloatDSPContext   *dsp;
>
> Leave cosmetics for another patch, so actual changes are easier to review.
>
>
Cosmetics is what the entire patch is about. As I said, the only changes
apart from cosmetics is moving the coefficients to the CeltBlock structure
and adding 2 new variables. I'll split the patch though.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Make the process of uuid-xmp atom faster.

2016-11-10 Thread Chen Meng

Ya. It’s really annoying everyone using patchwork. (So lng text.) I’m 
trying to fix it.
Please use my name, Chen Meng, if nothing changed in a short time.

2016-11-11 10:36 GMT+08:00 Chen Meng :
---
 libavformat/mov.c | 32 ++--
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9ec7d03..436c234 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4549,24 +4549,28 @@ static int mov_read_uuid(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 } else if (!memcmp(uuid, uuid_xmp, sizeof(uuid))) {
 uint8_t *buffer;
 size_t len = atom.size - sizeof(uuid);
-
-buffer = av_mallocz(len + 1);
-if (!buffer) {
-return AVERROR(ENOMEM);
-}
-ret = avio_read(pb, buffer, len);
-if (ret < 0) {
-av_free(buffer);
-return ret;
-} else if (ret != len) {
-av_free(buffer);
-return AVERROR_INVALIDDATA;
-}
 if (c->export_xmp) {
+buffer = av_mallocz(len + 1);
+if (!buffer) {
+return AVERROR(ENOMEM);
+}
+ret = avio_read(pb, buffer, len);
+if (ret < 0) {
+av_free(buffer);
+return ret;
+} else if (ret != len) {
+av_free(buffer);
+return AVERROR_INVALIDDATA;
+}
 buffer[len] = '\0';
 av_dict_set(>fc->metadata, "xmp", buffer, 0);
+av_free(buffer);
+} else {
+// skip all uuid atom, which makes it fast for long uuid-xmp file
+ret = avio_skip(pb, len);
+if (ret < 0)
+return ret;
 }
-av_free(buffer);
 }
 return 0;
 }
--
2.10.2
LGTM,   Except Submitter name used GBK at 
https://patchwork.ffmpeg.org/project/ffmpeg/list/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel





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

Re: [FFmpeg-devel] [PATCH] Make the process of uuid-xmp atom faster.

2016-11-10 Thread Steven Liu

2016-11-11 10:36 GMT+08:00 Chen Meng :

> ---
>  libavformat/mov.c | 32 ++--
>  1 file changed, 18 insertions(+), 14 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 9ec7d03..436c234 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -4549,24 +4549,28 @@ static int mov_read_uuid(MOVContext *c,
> AVIOContext *pb, MOVAtom atom)
>  } else if (!memcmp(uuid, uuid_xmp, sizeof(uuid))) {
>  uint8_t *buffer;
>  size_t len = atom.size - sizeof(uuid);
> -
> -buffer = av_mallocz(len + 1);
> -if (!buffer) {
> -return AVERROR(ENOMEM);
> -}
> -ret = avio_read(pb, buffer, len);
> -if (ret < 0) {
> -av_free(buffer);
> -return ret;
> -} else if (ret != len) {
> -av_free(buffer);
> -return AVERROR_INVALIDDATA;
> -}
>  if (c->export_xmp) {
> +buffer = av_mallocz(len + 1);
> +if (!buffer) {
> +return AVERROR(ENOMEM);
> +}
> +ret = avio_read(pb, buffer, len);
> +if (ret < 0) {
> +av_free(buffer);
> +return ret;
> +} else if (ret != len) {
> +av_free(buffer);
> +return AVERROR_INVALIDDATA;
> +}
>  buffer[len] = '\0';
>  av_dict_set(>fc->metadata, "xmp", buffer, 0);
> +av_free(buffer);
> +} else {
> +// skip all uuid atom, which makes it fast for long uuid-xmp
> file
> +ret = avio_skip(pb, len);
> +if (ret < 0)
> +return ret;
>  }
> -av_free(buffer);
>  }
>  return 0;
>  }
> --
> 2.10.2
>
> LGTM,   Except Submitter name used GBK at
https://patchwork.ffmpeg.org/project/ffmpeg/list/

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

Re: [FFmpeg-devel] [PATCH 2/3] lavfi/loudnorm: add an internal libebur128 library

2016-11-10 Thread Kyle Swanson

On Thu, Nov 10, 2016 at 4:16 PM, Marton Balint  wrote:
>
> On Thu, 10 Nov 2016, Kyle Swanson wrote:
>
>> On Tue, Nov 8, 2016 at 9:39 AM, Kyle Swanson  wrote:
>>
>> These patches look good to me. If we're going to do this, we really
>> need to keep the true peak mode in the libebur128 port. This is a huge
>> part of the R128 spec, and it's important that it stays in. Of course
>> redundant code is bad, so we'll need to update f_ebur128 as well
>> (which has a true peak requirement.) I already have a patch for
>> f_ebur128. Marton, it might be easier for you to update the patch to
>> include true peak mode but I could do it as well. It'd be interesting
>> to benchmark the libebur128 FIR resampler vs. swresample.
>
>
> I'd rather push the patch as it is, then if you are interested, you can
> start working on true peak. OK?

Cool, patch is attached. Resampling here is done via libswresample.

>
> Since true peak calculation is so entirely different from loudness
> calculation, you might also create a separate API/Context for it. Just
> beacuse both loudness measurement and true peak is referenced in EBU R128
> recommendation, we don't necessarily have to use the same API for them. For
> example, for true peak measurement, you might want to specify the
> oversampling factor, but not the channel layout...
>
> Regards,
>
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


0001-avfilter-ebur128-add-true-peak-mode.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Make the process of uuid-xmp atom faster.

2016-11-10 Thread Chen Meng

---
 libavformat/mov.c | 32 ++--
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9ec7d03..436c234 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4549,24 +4549,28 @@ static int mov_read_uuid(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 } else if (!memcmp(uuid, uuid_xmp, sizeof(uuid))) {
 uint8_t *buffer;
 size_t len = atom.size - sizeof(uuid);
-
-buffer = av_mallocz(len + 1);
-if (!buffer) {
-return AVERROR(ENOMEM);
-}
-ret = avio_read(pb, buffer, len);
-if (ret < 0) {
-av_free(buffer);
-return ret;
-} else if (ret != len) {
-av_free(buffer);
-return AVERROR_INVALIDDATA;
-}
 if (c->export_xmp) {
+buffer = av_mallocz(len + 1);
+if (!buffer) {
+return AVERROR(ENOMEM);
+}
+ret = avio_read(pb, buffer, len);
+if (ret < 0) {
+av_free(buffer);
+return ret;
+} else if (ret != len) {
+av_free(buffer);
+return AVERROR_INVALIDDATA;
+}
 buffer[len] = '\0';
 av_dict_set(>fc->metadata, "xmp", buffer, 0);
+av_free(buffer);
+} else {
+// skip all uuid atom, which makes it fast for long uuid-xmp file
+ret = avio_skip(pb, len);
+if (ret < 0)
+return ret;
 }
-av_free(buffer);
 }
 return 0;
 }
-- 
2.10.2

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

Re: [FFmpeg-devel] [PATCH] opus_celt: rename structures to better names and reorganize them

2016-11-10 Thread James Almer

On 11/10/2016 1:17 PM, Rostislav Pehlivanov wrote:
> This is meant to be applied on top of my previous patch which
> split PVQ into celt_pvq.c and made opus_celt.h
> 
> Essentially nothing has been changed other than renaming CeltFrame
> to CeltBlock (CeltFrame had absolutely nothing at all to do with
> a frame) and CeltContext to CeltFrame.
> 3 variables have been put in CeltFrame as they make more sense
> there rather than being passed around as arguments.
> The coefficients have been moved to the CeltBlock structure
> (why the hell were they in CeltContext and not in CeltFrame??).
> 
> Now the encoder would be able to use the exact context the decoder
> uses (plus a couple of extra fields in there).
> 
> FATE passes, no slowdowns, etc.
> 
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/opus.h  |  14 +-
>  libavcodec/opus_celt.c | 719 
> +
>  libavcodec/opus_celt.h |  82 +++---
>  libavcodec/opus_pvq.c  |  50 ++--
>  libavcodec/opus_pvq.h  |   8 +-
>  libavcodec/opus_rc.c   |  12 +-
>  libavcodec/opus_rc.h   |   6 +-
>  libavcodec/opusdec.c   |   1 +
>  8 files changed, 449 insertions(+), 443 deletions(-)
> 
> diff --git a/libavcodec/opus.h b/libavcodec/opus.h
> index be04249..e8d13df 100644
> --- a/libavcodec/opus.h
> +++ b/libavcodec/opus.h
> @@ -75,7 +75,7 @@ enum OpusBandwidth {
>  
>  typedef struct SilkContext SilkContext;
>  
> -typedef struct CeltContext CeltContext;
> +typedef struct CeltFrame CeltFrame;

[...]

> diff --git a/libavcodec/opus_celt.h b/libavcodec/opus_celt.h
> index 8a15c8d..5bce8fc 100644
> --- a/libavcodec/opus_celt.h
> +++ b/libavcodec/opus_celt.h
> @@ -37,7 +37,16 @@ enum CeltSpread {
>  CELT_SPREAD_AGGRESSIVE
>  };
>  
> -typedef struct CeltFrame {
> +enum CeltBlockSize {
> +CELT_BLOCK_120,
> +CELT_BLOCK_240,
> +CELT_BLOCK_480,
> +CELT_BLOCK_960,
> +
> +CELT_BLOCK_NB
> +};
> +
> +typedef struct CeltBlock {
>  float energy[CELT_MAX_BANDS];
>  float prev_energy[2][CELT_MAX_BANDS];
>  
> @@ -45,50 +54,46 @@ typedef struct CeltFrame {
>  
>  /* buffer for mdct output + postfilter */
>  DECLARE_ALIGNED(32, float, buf)[2048];
> +DECLARE_ALIGNED(32, float, coeffs)[CELT_MAX_FRAME_SIZE];
>  
>  /* postfilter parameters */
> -int pf_period_new;
> +int   pf_period_new;
>  float pf_gains_new[3];
> -int pf_period;
> +int   pf_period;
>  float pf_gains[3];
> -int pf_period_old;
> +int   pf_period_old;
>  float pf_gains_old[3];
>  
> -float deemph_coeff;
> -} CeltFrame;
> +float emph_coeff;
> +} CeltBlock;
>  
> -struct CeltContext {
> +typedef struct CeltFrame {

You're typedefing CeltFrame again here. Keep it the same as CeltContext used to 
be.

>  // constant values that do not change during context lifetime
> -AVCodecContext*avctx;
> -IMDCT15Context*imdct[4];
> -AVFloatDSPContext  *dsp;
> +AVCodecContext  *avctx;
> +IMDCT15Context  *imdct[4];
> +AVFloatDSPContext   *dsp;

Leave cosmetics for another patch, so actual changes are easier to review.

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

[FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: fix the hevc vaapi encoder output shaking issue.

2016-11-10 Thread Jun Zhao

From 5db0b2cd0930ed88d853114f13b69a80a44d9c4c Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Fri, 11 Nov 2016 10:04:53 +0800
Subject: [PATCH] lavc/vaapi_encode_h265: fix the hevc vaapi encoder output
 shaking issue.

the max_num_reorder_pics/max_dec_pic_buffering_minus in vps/sps are incorrect.

merge libav commit 314b421dd8910ebed7a8d419a0dbea239a00044e
vaapi_encode: Decide on GOP setup before initialising sequence 
parameters

merge libav commit b8cac1e83066aa87e8402c146c81b77a11b5eec3
vaapi_h265: Fix buffering parameters

Merged-by: Wang, Yi A 
Merged-by: Jun Zhao 
---
 libavcodec/vaapi_encode.c  | 13 ++---
 libavcodec/vaapi_encode_h265.c |  8 
 2 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 21a8656..233f749 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1181,6 +1181,12 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx,
 ctx->decode_delay = 1;
 ctx->output_order = - ctx->output_delay - 1;
 
+// Currently we never generate I frames, only IDR.
+ctx->i_per_idr = 0;
+ctx->p_per_i = ((avctx->gop_size + avctx->max_b_frames) /
+(avctx->max_b_frames + 1));
+ctx->b_per_p = avctx->max_b_frames;
+
 if (ctx->codec->sequence_params_size > 0) {
 ctx->codec_sequence_params =
 av_mallocz(ctx->codec->sequence_params_size);
@@ -1206,13 +1212,6 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx,
 goto fail;
 }
 }
-
-// All I are IDR for now.
-ctx->i_per_idr = 0;
-ctx->p_per_i = ((avctx->gop_size + avctx->max_b_frames) /
-(avctx->max_b_frames + 1));
-ctx->b_per_p = avctx->max_b_frames;
-
 // This should be configurable somehow.  (Needs testing on a machine
 // where it actually overlaps properly, though.)
 ctx->issue_mode = ISSUE_MODE_MAXIMISE_THROUGHPUT;
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 45f6f6d..33de041 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -897,12 +897,12 @@ static int 
vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
 
 mseq->log2_max_pic_order_cnt_lsb_minus4 = 8;
 mseq->vps_sub_layer_ordering_info_present_flag = 0;
-mseq->vps_max_dec_pic_buffering_minus1[0] = 1;
-mseq->vps_max_num_reorder_pics[0] = ctx->b_per_p;
+mseq->vps_max_dec_pic_buffering_minus1[0] = (avctx->max_b_frames > 0) 
+ 1;
+mseq->vps_max_num_reorder_pics[0] = (avctx->max_b_frames > 0);
 mseq->vps_max_latency_increase_plus1[0]   = 0;
 mseq->sps_sub_layer_ordering_info_present_flag = 0;
-mseq->sps_max_dec_pic_buffering_minus1[0] = 1;
-mseq->sps_max_num_reorder_pics[0] = ctx->b_per_p;
+mseq->sps_max_dec_pic_buffering_minus1[0] = (avctx->max_b_frames > 0) 
+ 1;
+mseq->sps_max_num_reorder_pics[0] = (avctx->max_b_frames > 0);
 mseq->sps_max_latency_increase_plus1[0]   = 0;
 
 mseq->vps_timing_info_present_flag = 1;
-- 
1.8.3.1

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

Re: [FFmpeg-devel] [PATCH] pnmdec: make sure v is capped by maxval

On Thu, Nov 10, 2016 at 08:52:29PM +0100, Andreas Cadhalpun wrote:
> On 10.11.2016 02:26, Michael Niedermayer wrote:
> > On Wed, Nov 09, 2016 at 10:46:03PM +0100, Andreas Cadhalpun wrote:
> >>  pnmdec.c |4 
> >>  1 file changed, 4 insertions(+)
> >> a970cb981be02ea692d0bf2e68976077f14f2de3  
> >> 0001-pnmdec-make-sure-v-is-capped-by-maxval.patch
> >> From f315a3cfe35377a2638dc2294200a288408dc784 Mon Sep 17 00:00:00 2001
> >> From: Andreas Cadhalpun 
> >> Date: Wed, 9 Nov 2016 01:09:35 +0100
> >> Subject: [PATCH] pnmdec: make sure v is capped by maxval
> >>
> >> Otherwise put_bits can be called with a value that doesn't fit in the
> >> sample_len, causing an assertion failure.
> >> ---
> >>  libavcodec/pnmdec.c | 4 
> >>  1 file changed, 4 insertions(+)
> >>
> >> diff --git a/libavcodec/pnmdec.c b/libavcodec/pnmdec.c
> >> index ca97cc3..0f6a895 100644
> >> --- a/libavcodec/pnmdec.c
> >> +++ b/libavcodec/pnmdec.c
> >> @@ -144,6 +144,10 @@ static int pnm_decode_frame(AVCodecContext *avctx, 
> >> void *data,
> >>  } else {
> >>  /* read a sequence of digits */
> >>  do {
> >> +if (v > (INT_MAX - c) / 10 || 10 * v + c > 
> >> s->maxval) {
> >> +av_log(avctx, AV_LOG_ERROR, "value 10 * 
> >> %d + %d larger than maxval %d\n", v, c, s->maxval);
> >> +return AVERROR_INVALIDDATA;
> >> +}
> > 
> > this test should nt be inside the loop
> > you can try to benchmark with START/STOP_TIMER to see what effect
> > this has (i didnt try but i expect it to be bad), this is the
> > innermost loop of the decoder
> > 
> > you can just unroll the loop by 5, thats the max number of iterations
> > i think, which avoids the overflow
> > it also should make the code faster
> 
> Done, new patch attached.
> 
> > iam reading in man ppm and others:
> > "The maximum color value (Maxval), again in ASCII decimal.  Must be less 
> > than 65536"
> 
> Indeed, I'll send a separate match limiting maxval.
> 
> Best regards,
> Andreas
> 

>  pnmdec.c |   10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 0dd61abddc422dd2ac37356f8271822d7e801b8e  
> 0001-pnmdec-make-sure-v-is-capped-by-maxval.patch
> From 2d402d8a38223b8c3c58d3e71e734932c9bdadae Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun 
> Date: Wed, 9 Nov 2016 01:09:35 +0100
> Subject: [PATCH] pnmdec: make sure v is capped by maxval
> 
> Otherwise put_bits can be called with a value that doesn't fit in the
> sample_len, causing an assertion failure.

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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

Re: [FFmpeg-devel] [PATCH] smvjpegdec: make sure cur_frame is not negative

On Thu, Nov 10, 2016 at 10:14:04PM +0100, Andreas Cadhalpun wrote:
> This fixes a heap-buffer-overflow detected by AddressSanitizer.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/smvjpegdec.c | 4 
>  1 file changed, 4 insertions(+)

LGTM

thx

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

[FFmpeg-devel] [PATCH] doc/ffmpeg: add documentation for the disposition option

2016-11-10 Thread Simon Thelen

Signed-off-by: Simon Thelen 
---
 doc/ffmpeg.texi | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index fd8a0c1..4b159fd 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -357,6 +357,40 @@ To set the language of the first audio stream:
 ffmpeg -i INPUT -metadata:s:a:0 language=eng OUTPUT
 @end example
 
+@item -disposition[:stream_specifier] @var{value} (@emph{output,per-stream})
+Sets the disposition for a stream.
+
+This option overrides the disposition copied from the input stream. It is also
+possible to delete the disposition by setting it to 0.
+
+The following dispositions are recognized:
+@table @option
+@item default
+@item dub
+@item original
+@item comment
+@item lyrics
+@item karaoke
+@item forced
+@item hearing_impaired
+@item visual_impaired
+@item clean_effects
+@item captions
+@item descriptions
+@item metadata
+@end table
+
+For example, to make the second audio stream the default stream:
+@example
+ffmpeg -i in.mkv -disposition:a:1 default out.mkv
+@end example
+
+To make the second subtitle stream the default stream and remove the default
+disposition from the first subtitle stream:
+@example
+ffmpeg -i INPUT -disposition:s:0 0 -disposition:s:1 default OUTPUT
+@end example
+
 @item -program 
[title=@var{title}:][program_num=@var{program_num}:]st=@var{stream}[:st=@var{stream}...]
 (@emph{output})
 
 Creates a program with the specified @var{title}, @var{program_num} and adds 
the specified
-- 
2.10.2

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

Re: [FFmpeg-devel] [PATCH] pnm: limit maxval to UINT16_MAX

On Thu, Nov 10, 2016 at 08:54:37PM +0100, Andreas Cadhalpun wrote:
> From 'man ppm': The maximum color value (Maxval), again in ASCII decimal.
> Must be less than 65536.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/pnm.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

should be ok (unless someone extended this format to larger values)

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

You can kill me, but you cannot change the truth.


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

Re: [FFmpeg-devel] [PATCH] doc/encoders: add documentation for the Hap encoder

2016-11-10 Thread Lou Logan

On Thu, 10 Nov 2016 23:09:52 +0100, Martin Vignali wrote:
> 
> lgtm

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

Re: [FFmpeg-devel] TR-03 implementation

2016-11-10 Thread Carl Eugen Hoyos

2016-11-10 20:44 GMT+01:00 Éloi Bail :

> We would like to contribute to FFmpeg by adding the support of those pixel
> formats and thus make FFmpeg usable for the next generation of
> broadcasting products.

Sounds like a great idea to me.

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

Re: [FFmpeg-devel] TR-03 implementation

Hi

On Thu, Nov 10, 2016 at 08:33:12PM +, Rostislav Pehlivanov wrote:
> On 10 November 2016 at 19:44, Éloi Bail 
> wrote:
> 
> > Hi all,
> >
> > Media broadcasters tend to move on carriage of live professional media
> > over IP. A group has been set up to recommend a standard for that, and
> > they produced the TR-03. It is only a recommendation, but it should be
> > close enough to what the SMPTE will adopt to start working on it.
> >
> > Radio Canada/CBC, a major Canadian broadcaster, wants to make FFmpeg
> > compatible with TR-03 and SMTPE future standard.
> >
> > Video pixel format is defined in RFC4175 (4.3. Payload Data) for YCbCr
> > format video. According to the discussion we had on #ffmpeg-devel
> > yesterday, lots of those pixel formats are not supported in FFmpeg.
> > These pixel formats are designed to group together all the samples of a
> > pixel group.
> >
> >
> Conversions and the formats already exist in another repository:
> https://github.com/kierank/ffmpeg-sdi

why have these changes not been submitted to ffmpeg-devel ?
These changes from a very quick look, look clean


[...]

> Don't try to help. Don't waste your or our time getting the existing
> conversions mainlined. Actually don't waste anyone's time at all. FFmpeg
> CANNOT support TR03.
> RFC4175 requires the ability to process huge amounts of packets which
> exceeds a gigabit per second. Let's do some math: since the packet sizes
> are 1475 bytes, this equates to around 200 000 packets per second for
> 1080i25. At which point the network stack built into most operating systems
> starts to fail and drop packets due to its inefficiency. Kernel bypassing
> is needed to do this properly in realtime. Only FreeBSD has the kernel
> bypassing framework complete in the kernel. For other OSes you need to use
> an out of tree third party kernel module. And not to mention that ffmpeg's
> RTP demuxer doesn't work all too well at all and will probably bottleneck
> the hell out of everything.

everything at some point couldnt be done easily.

I remember how decoding mp3 audio in realtime in software was
considered hard
and how decoding mpeg-2 in realtime impossible, still shortly after
that, there were software players that could do it.
I remember how people said breaking that old analouge videocrypt
requires speialized hardware (FPGAs) and be only crap quality and is
impossible oterwise.
Well i wrote my own code to decrypt it on my own average computer
back then in similar (bad) quality and color

also computers get faster every year, something impossible today
without specialized hw and kernel will be possible tomorrow

also whatever the resolution and framerate that can be supported today
the same code will do better on tomorrows hardware and kernel



> 
> So no. TR03 cannot fit into FFmpeg unless you use uselessly low resolutions
> and framerates and break everything RTP could do. No amount of "BUT I NEED
> THIS!!!11!1!!" will help you to even get kernel bypassing into mainline.
> And no amount of "BUT I NEED THIS!!!1!1!!!" will help you to rewrite the
> entire bloody ffmpeg RTP demuxer and break the few things it can do just to
> support TR03.
> 

> If you make up some bad TR03 implementation and try to post it here I will
> NAK the living hell out of it. So don't even think about it.

Noone should want a bad implementation.
We should write or merge a good implementation.
And if it cannot be done in the API or architecture then we should
fix or improve it.
If we dont want to do it, we should not stop others from doing it

But above all, lets NOT send people away, lets work together to solve
problems and make the implementation the way we prefer it. Be that
more on the fast side or more on the clean side or a compromise or ...


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

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


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

Re: [FFmpeg-devel] TR-03 implementation

On 10 November 2016 at 21:59, Michael Niedermayer 
wrote:

> On Thu, Nov 10, 2016 at 08:33:12PM +, Rostislav Pehlivanov wrote:
> > On 10 November 2016 at 19:44, Éloi Bail 
> > wrote:
> >
> > > Hi all,
> > >
> > > Media broadcasters tend to move on carriage of live professional media
> > > over IP. A group has been set up to recommend a standard for that, and
> > > they produced the TR-03. It is only a recommendation, but it should be
> > > close enough to what the SMPTE will adopt to start working on it.
> > >
> > > Radio Canada/CBC, a major Canadian broadcaster, wants to make FFmpeg
> > > compatible with TR-03 and SMTPE future standard.
> > >
> > > Video pixel format is defined in RFC4175 (4.3. Payload Data) for YCbCr
> > > format video. According to the discussion we had on #ffmpeg-devel
> > > yesterday, lots of those pixel formats are not supported in FFmpeg.
> > > These pixel formats are designed to group together all the samples of a
> > > pixel group.
> > >
> > >
> > Conversions and the formats already exist in another repository:
> > https://github.com/kierank/ffmpeg-sdi
> > Explaining what pixel packing formats are to us is like preaching to the
> > choir.
> >
> >
> > > A solution would be to repack the samples into a compatible format, eg.
> > > planar. Repacking samples seems not to be an appropriate solution
> > > because it has an impact on performance, specially dealing with high
> > > resolution uncompressed streams.
> > >
> > > We would like to contribute to FFmpeg by adding the support of those
> pixel
> > > formats and thus make FFmpeg usable for the next generation of
> > > broadcasting products.
> > >
> >
> > This paragraph almost made me vomit and use swear words in this email. We
> > don't need more broadcasting shit in ffmpeg.
>
> please try to stay polite.
> this tone of this mail is definitly not how you should reply to
> someone wanting to contribute and asking a question about it
>
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In a rich man's house there is no place to spit but his face.
> -- Diogenes of Sinope
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
Sorry, I was very hasty and didn't pick my words right. I didn't mean to
offend anyone nor to start a war.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavfi/loudnorm: add an internal libebur128 library

2016-11-10 Thread Marton Balint



On Thu, 10 Nov 2016, Kyle Swanson wrote:


On Tue, Nov 8, 2016 at 9:39 AM, Kyle Swanson  wrote:

These patches look good to me. If we're going to do this, we really
need to keep the true peak mode in the libebur128 port. This is a huge
part of the R128 spec, and it's important that it stays in. Of course
redundant code is bad, so we'll need to update f_ebur128 as well
(which has a true peak requirement.) I already have a patch for
f_ebur128. Marton, it might be easier for you to update the patch to
include true peak mode but I could do it as well. It'd be interesting
to benchmark the libebur128 FIR resampler vs. swresample.


I'd rather push the patch as it is, then if you are interested, you can 
start working on true peak. OK?


Since true peak calculation is so entirely different from loudness 
calculation, you might also create a separate API/Context for it. 
Just beacuse both loudness measurement and true peak is referenced in EBU 
R128 recommendation, we don't necessarily have to use the same API for 
them. For example, for true peak measurement, you might want to specify 
the oversampling factor, but not the channel layout...


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] TR-03 implementation

On Thu, Nov 10, 2016 at 08:33:12PM +, Rostislav Pehlivanov wrote:
> On 10 November 2016 at 19:44, Éloi Bail 
> wrote:
> 
> > Hi all,
> >
> > Media broadcasters tend to move on carriage of live professional media
> > over IP. A group has been set up to recommend a standard for that, and
> > they produced the TR-03. It is only a recommendation, but it should be
> > close enough to what the SMPTE will adopt to start working on it.
> >
> > Radio Canada/CBC, a major Canadian broadcaster, wants to make FFmpeg
> > compatible with TR-03 and SMTPE future standard.
> >
> > Video pixel format is defined in RFC4175 (4.3. Payload Data) for YCbCr
> > format video. According to the discussion we had on #ffmpeg-devel
> > yesterday, lots of those pixel formats are not supported in FFmpeg.
> > These pixel formats are designed to group together all the samples of a
> > pixel group.
> >
> >
> Conversions and the formats already exist in another repository:
> https://github.com/kierank/ffmpeg-sdi
> Explaining what pixel packing formats are to us is like preaching to the
> choir.
> 
> 
> > A solution would be to repack the samples into a compatible format, eg.
> > planar. Repacking samples seems not to be an appropriate solution
> > because it has an impact on performance, specially dealing with high
> > resolution uncompressed streams.
> >
> > We would like to contribute to FFmpeg by adding the support of those pixel
> > formats and thus make FFmpeg usable for the next generation of
> > broadcasting products.
> >
> 
> This paragraph almost made me vomit and use swear words in this email. We
> don't need more broadcasting shit in ffmpeg.

please try to stay polite.
this tone of this mail is definitly not how you should reply to
someone wanting to contribute and asking a question about it


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

[FFmpeg-devel] [PATCH] sbgdec: prevent NULL pointer access

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/sbgdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/sbgdec.c b/libavformat/sbgdec.c
index bb020d7..cbedd12 100644
--- a/libavformat/sbgdec.c
+++ b/libavformat/sbgdec.c
@@ -927,7 +927,7 @@ static void expand_timestamps(void *log, struct sbg_script 
*s)
 }
 }
 if (s->start_ts == AV_NOPTS_VALUE)
-s->start_ts = s->opt_start_at_first ? s->tseq[0].ts.t : now;
+s->start_ts = (s->opt_start_at_first && s->tseq) ? s->tseq[0].ts.t : 
now;
 s->end_ts = s->opt_duration ? s->start_ts + s->opt_duration :
 AV_NOPTS_VALUE; /* may be overridden later by -E option */
 cur_ts = now;
-- 
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] TR-03 implementation

2016-11-10 Thread Kieran Kunhya

>
> sure, ffmpeg has support for many pixel formats and adding more
> pixfmts is not a problem.
>
> my best answer would be to look at commits which add other pixel
> formats and just follow how they were added to libswscale. make some
> fate tests, and it should be done.
>
> hopefully you have test samples made of these pixfmts you want to add.
> that makes testing for us easier, as we can test on multiple cpu
> arch's to make sure the code is safe and works.
>

Sorry Compn, nothing personal here, but you are responding exactly in the
way I thought you would and why I even wrote that certain people would
encourage in spite of the technical issues.

You don't understand the complexity of this problem either. The pixel
formats are the least of his problems. Samples don't exist, it's not a file
based format, it's a network stream etc. Please listen to what Ros and I
said, we worked on this painfully for months.

Regards,
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] TR-03 implementation

2016-11-10 Thread compn

On Thu, 10 Nov 2016 14:44:44 -0500 (EST)
Éloi Bail  wrote:

> We would like to contribute to FFmpeg by adding the support of those
> pixel formats and thus make FFmpeg usable for the next generation of 
> broadcasting products. 
> 
> Could you tell us if our contribution would make sense and eventually 
> advise us on the best way to address that ? 

sure, ffmpeg has support for many pixel formats and adding more
pixfmts is not a problem.

my best answer would be to look at commits which add other pixel
formats and just follow how they were added to libswscale. make some
fate tests, and it should be done.

hopefully you have test samples made of these pixfmts you want to add.
that makes testing for us easier, as we can test on multiple cpu
arch's to make sure the code is safe and works.

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

[FFmpeg-devel] [PATCH] smvjpegdec: make sure cur_frame is not negative

This fixes a heap-buffer-overflow detected by AddressSanitizer.

Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/smvjpegdec.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/smvjpegdec.c b/libavcodec/smvjpegdec.c
index 9057e86..e319e57 100644
--- a/libavcodec/smvjpegdec.c
+++ b/libavcodec/smvjpegdec.c
@@ -152,6 +152,10 @@ static int smvjpeg_decode_frame(AVCodecContext *avctx, 
void *data, int *data_siz
 
 cur_frame = avpkt->pts % s->frames_per_jpeg;
 
+/* cur_frame is later used to calculate the buffer offset, so it mustn't 
be negative */
+if (cur_frame < 0)
+cur_frame += s->frames_per_jpeg;
+
 /* Are we at the start of a block? */
 if (!cur_frame) {
 av_frame_unref(mjpeg_data);
-- 
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] icodec: correctly check avio_read return value

On 10.11.2016 21:14, Michael Niedermayer wrote:
> On Wed, Nov 09, 2016 at 08:56:00PM +0100, Andreas Cadhalpun wrote:
>>  icodec.c |8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>> 04c12ac83fea7b911f4050c547b77d1c48e9228b  
>> 0001-icodec-correctly-check-avio_read-return-value.patch
>> From 31f78a6d2906de4ee69e472aced5fef3af709b9a Mon Sep 17 00:00:00 2001
>> From: Andreas Cadhalpun 
>> Date: Tue, 8 Nov 2016 23:29:28 +0100
>> Subject: [PATCH] icodec: correctly check avio_read return value
>>
>> It can read less than the requested amount, in which case buf contains
>> uninitialized data, causing problems like segmentation faults later on.
>>
>> Also make sure that image->size is positive, so that it can't match a
>> negative error code.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavformat/icodec.c | 8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavformat/icodec.c b/libavformat/icodec.c
>> index 8019a35..c273bf6 100644
>> --- a/libavformat/icodec.c
>> +++ b/libavformat/icodec.c
> 
> should be ok

Pushed.

Best regards,
Andreas

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

Re: [FFmpeg-devel] TR-03 implementation

2016-11-10 Thread Kieran Kunhya

>
> The only thing which may fit would the UYVY 10bit format. But good luck
> getting the conversions adapted to libswscale. I certainly won't help you
> other than discourage you from doing it considering it is absolutely
> useless since absolutely nothing else uses that format and also it would
> cost you your sanity.
>

There is no UYVY 10-bit pixel format (word-aligned) in TR-03.

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

Re: [FFmpeg-devel] TR-03 implementation

On 10 November 2016 at 19:44, Éloi Bail 
wrote:

> Hi all,
>
> Media broadcasters tend to move on carriage of live professional media
> over IP. A group has been set up to recommend a standard for that, and
> they produced the TR-03. It is only a recommendation, but it should be
> close enough to what the SMPTE will adopt to start working on it.
>
> Radio Canada/CBC, a major Canadian broadcaster, wants to make FFmpeg
> compatible with TR-03 and SMTPE future standard.
>
> Video pixel format is defined in RFC4175 (4.3. Payload Data) for YCbCr
> format video. According to the discussion we had on #ffmpeg-devel
> yesterday, lots of those pixel formats are not supported in FFmpeg.
> These pixel formats are designed to group together all the samples of a
> pixel group.
>
>
Conversions and the formats already exist in another repository:
https://github.com/kierank/ffmpeg-sdi
Explaining what pixel packing formats are to us is like preaching to the
choir.

> A solution would be to repack the samples into a compatible format, eg.
> planar. Repacking samples seems not to be an appropriate solution
> because it has an impact on performance, specially dealing with high
> resolution uncompressed streams.
>
> We would like to contribute to FFmpeg by adding the support of those pixel
> formats and thus make FFmpeg usable for the next generation of
> broadcasting products.
>

This paragraph almost made me vomit and use swear words in this email. We
don't need more broadcasting shit in ffmpeg.

>
> Could you tell us if our contribution would make sense and eventually
> advise us on the best way to address that ?
>
>
Sure:

Don't try to help. Don't waste your or our time getting the existing
conversions mainlined. Actually don't waste anyone's time at all. FFmpeg
CANNOT support TR03.
RFC4175 requires the ability to process huge amounts of packets which
exceeds a gigabit per second. Let's do some math: since the packet sizes
are 1475 bytes, this equates to around 200 000 packets per second for
1080i25. At which point the network stack built into most operating systems
starts to fail and drop packets due to its inefficiency. Kernel bypassing
is needed to do this properly in realtime. Only FreeBSD has the kernel
bypassing framework complete in the kernel. For other OSes you need to use
an out of tree third party kernel module. And not to mention that ffmpeg's
RTP demuxer doesn't work all too well at all and will probably bottleneck
the hell out of everything.

So no. TR03 cannot fit into FFmpeg unless you use uselessly low resolutions
and framerates and break everything RTP could do. No amount of "BUT I NEED
THIS!!!11!1!!" will help you to even get kernel bypassing into mainline.
And no amount of "BUT I NEED THIS!!!1!1!!!" will help you to rewrite the
entire bloody ffmpeg RTP demuxer and break the few things it can do just to
support TR03.

If you make up some bad TR03 implementation and try to post it here I will
NAK the living hell out of it. So don't even think about it.

The only thing which may fit would the UYVY 10bit format. But good luck
getting the conversions adapted to libswscale. I certainly won't help you
other than discourage you from doing it considering it is absolutely
useless since absolutely nothing else uses that format and also it would
cost you your sanity.

Now, the best advice I can give you is to talk to kierank privately on IRC
about TR03 since I know he had to deal with it.. Or to make your own
implementation up since the conversions I linked above are LGPL'd and you
could use them.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] TR-03 implementation

2016-11-10 Thread Kieran Kunhya

Hello,


> We would like to contribute to FFmpeg by adding the support of those pixel
> formats and thus make FFmpeg usable for the next generation of
> broadcasting products.
>

So as someone who has been working on this for 6+ months this won't work,
the Gbit/s of data coming in over the network is far too high for FFmpeg to
handle. This isn't a 10mbit/s RTMP webcast, this is a LOT of data, requires
heavy tuning and optimisation of the network stack (of which FFmpeg's is
very very limited). FFmpeg was "designed" for files, the network layer has
been hacked on (e.g why raw UDP capture has a special thread but RTP
doesn't).

That said some people in the community will encourage you to do it because
they don't understand the complexity of the problem and it is why FFmpeg is
full of broken things and has a bad name in the professional world.


> Could you tell us if our contribution would make sense and eventually
> advise us on the best way to address that ?


We implemented the unpacking in our repository here:
github.com/kierank/ffmpeg-sdi

We are porting it to upipe: upipe.org
Upipe is a much better place for these things (event loop, non-blocking io,
control of thread placement, latency control etc)

If you do try to attempt this you'll find that capture might work,
certainly playback will not work.

Regards,
Kieran Kunhya
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] icodec: correctly check avio_read return value

On Wed, Nov 09, 2016 at 08:56:00PM +0100, Andreas Cadhalpun wrote:
> On 09.11.2016 02:31, Michael Niedermayer wrote:
> > On Tue, Nov 08, 2016 at 11:36:58PM +0100, Andreas Cadhalpun wrote:
> >> It can read less than the requested amount, in which case buf contains
> >> uninitialized data, causing problems like segmentation faults later on.
> >>
> >> Signed-off-by: Andreas Cadhalpun 
> >> ---
> >>  libavformat/icodec.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavformat/icodec.c b/libavformat/icodec.c
> >> index 8019a35..aad1416 100644
> >> --- a/libavformat/icodec.c
> >> +++ b/libavformat/icodec.c
> >> @@ -174,8 +174,8 @@ static int read_packet(AVFormatContext *s, AVPacket 
> >> *pkt)
> >>  bytestream_put_le16(, 0);
> >>  bytestream_put_le32(, 0);
> >>  
> >> -if ((ret = avio_read(pb, buf, image->size)) < 0)
> >> -return ret;
> >> +if ((ret = avio_read(pb, buf, image->size)) != image->size)
> >> +return ret < 0 ? ret : AVERROR_INVALIDDATA;
> > 
> > is anything checking size to be positive ?
> > if not it could be matching an error code i think
> 
> I've added a check to make sure that size is positive. New patch attached.
> 
> Best regards,
> Andreas
> 

>  icodec.c |8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 04c12ac83fea7b911f4050c547b77d1c48e9228b  
> 0001-icodec-correctly-check-avio_read-return-value.patch
> From 31f78a6d2906de4ee69e472aced5fef3af709b9a Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun 
> Date: Tue, 8 Nov 2016 23:29:28 +0100
> Subject: [PATCH] icodec: correctly check avio_read return value
> 
> It can read less than the requested amount, in which case buf contains
> uninitialized data, causing problems like segmentation faults later on.
> 
> Also make sure that image->size is positive, so that it can't match a
> negative error code.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/icodec.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/icodec.c b/libavformat/icodec.c
> index 8019a35..c273bf6 100644
> --- a/libavformat/icodec.c
> +++ b/libavformat/icodec.c

should be ok

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.


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

Re: [FFmpeg-devel] [PATCH] dvbsubdec: fix division by zero in compute_default_clut

On 10.11.2016 17:42, Michael Niedermayer wrote:
> On Wed, Nov 09, 2016 at 08:52:54PM +0100, Andreas Cadhalpun wrote:
>>  dvbsubdec.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 10b117a15971daf75d61efe486b961d3cc59d480  
>> 0001-dvbsubdec-fix-division-by-zero-in-compute_default_cl.patch
>> From 436318575abf482e1ea144f651c47bc2730e41a2 Mon Sep 17 00:00:00 2001
>> From: Andreas Cadhalpun 
>> Date: Tue, 8 Nov 2016 22:32:42 +0100
>> Subject: [PATCH] dvbsubdec: fix division by zero in compute_default_clut
>>
>> This problem was introduced in commit
>> 4b90dcb8493552c17a811c8b1e6538dae4061f9d.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/dvbsubdec.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> LGTM

Pushed.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] proresdec_lgpl: explicitly check coff[3] against slice_data_size

On 10.11.2016 14:38, Michael Niedermayer wrote:
> On Wed, Nov 09, 2016 at 11:56:36PM +0100, Andreas Cadhalpun wrote:
>> The implicit checks via v_data_size and a_data_size don't work in the case
>> '(hdr_size > 7) && !ctx->alpha_info'.
>>
>> This fixes segmentation faults due to invalid reads.
>>
>> This problem was introduced in commit
>> 547c2f002a87f4412a83c23b0d60364be5e7ce58.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/proresdec_lgpl.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> LGTM

Pushed.

Best regards,
Andreas

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

[FFmpeg-devel] [PATCH] pnm: limit maxval to UINT16_MAX

From 'man ppm': The maximum color value (Maxval), again in ASCII decimal.
Must be less than 65536.

Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/pnm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavcodec/pnm.c b/libavcodec/pnm.c
index 1675959..4753923 100644
--- a/libavcodec/pnm.c
+++ b/libavcodec/pnm.c
@@ -107,7 +107,8 @@ int ff_pnm_decode_header(AVCodecContext *avctx, PNMContext 
* const s)
 }
 }
 /* check that all tags are present */
-if (w <= 0 || h <= 0 || maxval <= 0 || depth <= 0 || tuple_type[0] == 
'\0' || av_image_check_size(w, h, 0, avctx) || s->bytestream >= 
s->bytestream_end)
+if (w <= 0 || h <= 0 || maxval <= 0 || maxval > UINT16_MAX || depth <= 
0 || tuple_type[0] == '\0' ||
+av_image_check_size(w, h, 0, avctx) || s->bytestream >= 
s->bytestream_end)
 return AVERROR_INVALIDDATA;
 
 avctx->width  = w;
@@ -159,7 +160,7 @@ int ff_pnm_decode_header(AVCodecContext *avctx, PNMContext 
* const s)
 if (avctx->pix_fmt != AV_PIX_FMT_MONOWHITE && avctx->pix_fmt != 
AV_PIX_FMT_MONOBLACK) {
 pnm_get(s, buf1, sizeof(buf1));
 s->maxval = atoi(buf1);
-if (s->maxval <= 0) {
+if (s->maxval <= 0 || s->maxval > UINT16_MAX) {
 av_log(avctx, AV_LOG_ERROR, "Invalid maxval: %d\n", s->maxval);
 s->maxval = 255;
 }
-- 
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] pnmdec: make sure v is capped by maxval

On 10.11.2016 02:26, Michael Niedermayer wrote:
> On Wed, Nov 09, 2016 at 10:46:03PM +0100, Andreas Cadhalpun wrote:
>>  pnmdec.c |4 
>>  1 file changed, 4 insertions(+)
>> a970cb981be02ea692d0bf2e68976077f14f2de3  
>> 0001-pnmdec-make-sure-v-is-capped-by-maxval.patch
>> From f315a3cfe35377a2638dc2294200a288408dc784 Mon Sep 17 00:00:00 2001
>> From: Andreas Cadhalpun 
>> Date: Wed, 9 Nov 2016 01:09:35 +0100
>> Subject: [PATCH] pnmdec: make sure v is capped by maxval
>>
>> Otherwise put_bits can be called with a value that doesn't fit in the
>> sample_len, causing an assertion failure.
>> ---
>>  libavcodec/pnmdec.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/libavcodec/pnmdec.c b/libavcodec/pnmdec.c
>> index ca97cc3..0f6a895 100644
>> --- a/libavcodec/pnmdec.c
>> +++ b/libavcodec/pnmdec.c
>> @@ -144,6 +144,10 @@ static int pnm_decode_frame(AVCodecContext *avctx, void 
>> *data,
>>  } else {
>>  /* read a sequence of digits */
>>  do {
>> +if (v > (INT_MAX - c) / 10 || 10 * v + c > 
>> s->maxval) {
>> +av_log(avctx, AV_LOG_ERROR, "value 10 * %d 
>> + %d larger than maxval %d\n", v, c, s->maxval);
>> +return AVERROR_INVALIDDATA;
>> +}
> 
> this test should nt be inside the loop
> you can try to benchmark with START/STOP_TIMER to see what effect
> this has (i didnt try but i expect it to be bad), this is the
> innermost loop of the decoder
> 
> you can just unroll the loop by 5, thats the max number of iterations
> i think, which avoids the overflow
> it also should make the code faster

Done, new patch attached.

> iam reading in man ppm and others:
> "The maximum color value (Maxval), again in ASCII decimal.  Must be less than 
> 65536"

Indeed, I'll send a separate match limiting maxval.

Best regards,
Andreas

>From 2d402d8a38223b8c3c58d3e71e734932c9bdadae Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun 
Date: Wed, 9 Nov 2016 01:09:35 +0100
Subject: [PATCH] pnmdec: make sure v is capped by maxval

Otherwise put_bits can be called with a value that doesn't fit in the
sample_len, causing an assertion failure.
---
 libavcodec/pnmdec.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/libavcodec/pnmdec.c b/libavcodec/pnmdec.c
index ca97cc3..958c5e4 100644
--- a/libavcodec/pnmdec.c
+++ b/libavcodec/pnmdec.c
@@ -43,7 +43,7 @@ static int pnm_decode_frame(AVCodecContext *avctx, void *data,
 int buf_size = avpkt->size;
 PNMContext * const s = avctx->priv_data;
 AVFrame * const p= data;
-int i, j, n, linesize, h, upgrade = 0, is_mono = 0;
+int i, j, k, n, linesize, h, upgrade = 0, is_mono = 0;
 unsigned char *ptr;
 int components, sample_len, ret;
 
@@ -143,10 +143,14 @@ static int pnm_decode_frame(AVCodecContext *avctx, void *data,
 v = (*s->bytestream++)&1;
 } else {
 /* read a sequence of digits */
-do {
+for (k = 0; k < 5 && c <= 9; k += 1) {
 v = 10*v + c;
 c = (*s->bytestream++) - '0';
-} while (c <= 9);
+}
+if (v > s->maxval) {
+av_log(avctx, AV_LOG_ERROR, "value %d larger than maxval %d\n", v, s->maxval);
+return AVERROR_INVALIDDATA;
+}
 }
 if (sample_len == 16) {
 ((uint16_t*)ptr)[j] = (((1<maxval>>1))/s->maxval;
-- 
2.10.2

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

[FFmpeg-devel] TR-03 implementation

2016-11-10 Thread Éloi Bail

Hi all,

Media broadcasters tend to move on carriage of live professional media
over IP. A group has been set up to recommend a standard for that, and
they produced the TR-03. It is only a recommendation, but it should be
close enough to what the SMPTE will adopt to start working on it.

Radio Canada/CBC, a major Canadian broadcaster, wants to make FFmpeg
compatible with TR-03 and SMTPE future standard.

Video pixel format is defined in RFC4175 (4.3. Payload Data) for YCbCr
format video. According to the discussion we had on #ffmpeg-devel
yesterday, lots of those pixel formats are not supported in FFmpeg.
These pixel formats are designed to group together all the samples of a
pixel group.

A solution would be to repack the samples into a compatible format, eg.
planar. Repacking samples seems not to be an appropriate solution
because it has an impact on performance, specially dealing with high
resolution uncompressed streams.

We would like to contribute to FFmpeg by adding the support of those pixel
formats and thus make FFmpeg usable for the next generation of
broadcasting products.

Could you tell us if our contribution would make sense and eventually
advise us on the best way to address that ?

Best,

Eloi

[1]
http://www.videoservicesforum.org/download/technical_recommendations/VSF_TR-03_DRAFT_2015-10-19.pdf

[2] https://tools.ietf.org/html/rfc4175
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2 v2] avformat/matroskaenc: write updated STREAMINFO metadata for FLAC streams if available

2016-11-10 Thread James Almer

FLAC streams originating from the FLAC encoder send updated and more
complete STREAMINFO metadata as part of the last packet, so write that
to CodecPrivate instead of the incomplete one available in extradata
during init.

Signed-off-by: James Almer 
---
Now actually working on a per-track basis instead of only for one.

 libavformat/matroskaenc.c | 50 +++
 1 file changed, 50 insertions(+)

diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index fb5591d..25ceeb2 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -93,6 +93,7 @@ typedef struct mkv_cues {
 typedef struct mkv_track {
 int write_dts;
 int has_cue;
+int64_t codecpriv_offset;
 int64_t ts_offset;
 } mkv_track;
 
@@ -1272,6 +1273,7 @@ static int mkv_write_track(AVFormatContext *s, 
MatroskaMuxContext *mkv,
 }
 
 if (mkv->mode != MODE_WEBM || par->codec_id != AV_CODEC_ID_WEBVTT) {
+mkv->tracks[i].codecpriv_offset = avio_tell(pb);
 ret = mkv_write_codecprivate(s, pb, par, native_id, qt_id);
 if (ret < 0)
 return ret;
@@ -2097,6 +2099,50 @@ static void mkv_start_new_cluster(AVFormatContext *s, 
AVPacket *pkt)
 avio_flush(s->pb);
 }
 
+static int mkv_check_new_extra_data(AVFormatContext *s, AVPacket *pkt)
+{
+MatroskaMuxContext *mkv = s->priv_data;
+mkv_track *track= >tracks[pkt->stream_index];
+AVCodecParameters *par  = s->streams[pkt->stream_index]->codecpar;
+uint8_t *side_data;
+int side_data_size = 0, ret;
+
+side_data = av_packet_get_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
+ _data_size);
+
+switch (par->codec_id) {
+case AV_CODEC_ID_FLAC:
+if (side_data_size && s->pb->seekable) {
+AVCodecParameters *codecpriv_par;
+int64_t curpos;
+if (side_data_size != par->extradata_size) {
+av_log(s, AV_LOG_ERROR, "Invalid FLAC STREAMINFO metadata for 
output stream %d\n",
+   pkt->stream_index);
+return AVERROR(EINVAL);
+}
+codecpriv_par = avcodec_parameters_alloc();
+if (!codecpriv_par)
+return AVERROR(ENOMEM);
+ret = avcodec_parameters_copy(codecpriv_par, par);
+if (ret < 0)
+return ret;
+memcpy(codecpriv_par->extradata, side_data, side_data_size);
+curpos = avio_tell(mkv->tracks_bc);
+avio_seek(mkv->tracks_bc, track->codecpriv_offset, SEEK_SET);
+mkv_write_codecprivate(s, mkv->tracks_bc, codecpriv_par, 1, 0);
+avio_seek(mkv->tracks_bc, curpos, SEEK_SET);
+avcodec_parameters_free(_par);
+}
+break;
+default:
+if (side_data_size)
+av_log(s, AV_LOG_DEBUG, "Ignoring new extradata in a packet for 
stream %d.\n", pkt->stream_index);
+break;
+}
+
+return 0;
+}
+
 static int mkv_write_packet_internal(AVFormatContext *s, AVPacket *pkt, int 
add_cue)
 {
 MatroskaMuxContext *mkv = s->priv_data;
@@ -2189,6 +2235,10 @@ static int mkv_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 int ret;
 int start_new_cluster;
 
+ret = mkv_check_new_extra_data(s, pkt);
+if (ret < 0)
+return ret;
+
 if (mkv->tracks[pkt->stream_index].write_dts)
 cluster_time = pkt->dts - mkv->cluster_pts;
 else
-- 
2.10.1

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

Re: [FFmpeg-devel] [PATCH 1/2] img2: added support for %t output pattern

2016-11-10 Thread Roger Pack

On 11/1/16, James Almer  wrote:
> On 11/1/2016 6:43 PM, James Almer wrote:
>> On 10/25/2016 9:38 PM, Roger Pack wrote:
>>> From e8cac5c7de18766ce0f8f286f7dc140b82129df2 Mon Sep 17 00:00:00 2001
>>> From: rogerdpack 
>>> Date: Tue, 25 Oct 2016 18:33:12 -0600
>>> Subject: [PATCH 1/2] img2 encoder: allow %t in filename, based on patch
>>> from
>>>  Yuval Adam
>>>
>>> Signed-off-by: rogerdpack 
>>> ---
>>>  doc/muxers.texi| 13 +
>>>  libavformat/avformat.h |  3 ++-
>>>  libavformat/hlsenc.c   |  6 +++---
>>>  libavformat/img2enc.c  |  6 --
>>>  libavformat/utils.c| 42 ++
>>>  5 files changed, 60 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>>> index 0d856db..0c3a198 100644
>>> --- a/doc/muxers.texi
>>> +++ b/doc/muxers.texi
>>> @@ -619,6 +619,12 @@ If the pattern contains "%d" or "%0@var{N}d", the
>>> first filename of
>>>  the file list specified will contain the number 1, all the following
>>>  numbers will be sequential.
>>>
>>> +If the pattern contains "%t", the frame's timestamps will be inserted
>>> +in the filename like "00.00.00.000" for hours, minutes, seconds,
>>> +and milliseconds.
>>> +
>>> +The "%t" and "%d" patterns may be used simultaneously.
>>> +
>>>  The pattern may contain a suffix which is used to automatically
>>>  determine the format of the image files to write.
>>>
>>> @@ -664,6 +670,13 @@ can be used:
>>>  ffmpeg -f v4l2 -r 1 -i /dev/video0 -f image2 -strftime 1
>>> "%Y-%m-%d_%H-%M-%S.jpg"
>>>  @end example
>>>
>>> +The following example uses the timestamp parameter to generate one
>>> +image file per video frame from the input, and name it including its
>>> original
>>> +timestamp.
>>> +@example
>>> +ffmpeg -i in.avi -vsync vfr -copyts img-%t.jpg
>>> +@end example
>>> +
>>>  @subsection Options
>>>
>>>  @table @option
>>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>>> index f9f4d72..7f39698 100644
>>> --- a/libavformat/avformat.h
>>> +++ b/libavformat/avformat.h
>>> @@ -2780,10 +2780,11 @@ void av_dump_format(AVFormatContext *ic,
>>>   * @param path numbered sequence string
>>>   * @param number frame number
>>>   * @param flags AV_FRAME_FILENAME_FLAGS_*
>>> + * @param ts frame timestamp in AV_TIME_BASE fractional seconds.
>>>   * @return 0 if OK, -1 on format error
>>>   */
>>>  int av_get_frame_filename2(char *buf, int buf_size,
>>> -  const char *path, int number, int flags);
>>> +  const char *path, int number, int flags,
>>> int64_t ts);
>>
>> Uhh, what? did you just break API modifying a public function?
>>
>
> For the record, this was reverted.
>
> Shouldn't be hard to solve, i think. Just add a new ff_get_frame_filename()
> function to internal.h with this new signature, at least for now and for
> this
> feature, to avoid adding a third public function doing the same thing unless
> absolutely necessary.

OK see attached.  Wasn't sure if I should duplicate docs or not, feel
free to modify.
Cheers!
-roger-


0001-img2-encoder-allow-t-in-filepattern-based-on-patch-f.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] fate: Add h264 and hevc extradata reload tests

2016-11-10 Thread Vittorio Giovara

On Wed, Nov 9, 2016 at 4:11 AM, Michael Niedermayer
 wrote:
> On Tue, Nov 08, 2016 at 10:39:41PM -0500, Vittorio Giovara wrote:
>> On Tue, Nov 8, 2016 at 7:15 PM, Michael Niedermayer
>>  wrote:
>> > On Tue, Nov 08, 2016 at 05:03:28PM -0500, Vittorio Giovara wrote:
>> >> ---
>> >> Samples available at
>> >> - 
>> >> https://www.dropbox.com/s/gkswnubzy6e6rgg/h264-extradata-reload-multi-stsd.mov?dl=0
>> >> - 
>> >> https://www.dropbox.com/s/djfvoqgu2z9zrqu/hevc-extradata-reload-multi-stsd.mov?dl=0
>> >> They need to be renamed without the codec tag and placed in the 
>> >> appropriate
>> >> directory in fate.
>> >> Please CC.
>> >> Vittorio
>> >>
>> >>  tests/fate/h264.mak  |  5 +
>> >>  tests/fate/hevc.mak  |  5 +
>> >>  tests/ref/fate/h264-extradata-reload | 13 +
>> >>  tests/ref/fate/hevc-extradata-reload | 13 +
>> >>  4 files changed, 36 insertions(+)
>> >>  create mode 100644 tests/ref/fate/h264-extradata-reload
>> >>  create mode 100644 tests/ref/fate/hevc-extradata-reload
>> >
>> > doesnt seem to pass here
>> >
>> > --- ./tests/ref/fate/hevc-extradata-reload  2016-11-08 
>> > 23:33:06.888177493 +0100
>> > +++ tests/data/fate/hevc-extradata-reload   2016-11-09 
>> > 01:09:12.080298952 +0100
>> > @@ -9,5 +9,5 @@
>> >  #stream#, dts,pts, duration, size, hash
>> >  0,  0,  0,1,24576, 
>> > 0d01217c5d1ec6799643fc7d75ba2337
>> >  0,  1,  1,1,24576, 
>> > f73d9cca9b4c1765d0ead242c3f0c339
>> > -0,  2,  2,1,24576, 
>> > 39a8714d763c623ae7f6faae34e107d1
>> > -0,  3,  3,1,24576, 
>> > 5db2600aa268b4fd28b64ab28a096f32
>> > +0,  2,  2,1,24576, 
>> > aea8b931d694e38ffa54ea4c88e04491
>> > +0,  3,  3,1,24576, 
>> > 9d8f6a78c1bae37eabcab29295fd02a8
>>
>> Oh yeah, I ran the hashes with asm and optimizations disabled, if I do
>> enable them I get the new hashes too.
>> I tried to output the raw images but I can't see any difference, so
>> suspect there could be a lingering issue somewhere in the asm. Would
>> you be able to look into it?
>
> i would but my todo list is too long and growing, maybe someone else
> can help ?

I see, maybe the HEVC part could be stripped out and only the h264
test could be added?
It's good to test multiple stsd for h264 only anyway.

Off topic, what's the status of "mov: Evaluate the movie display
matrix"? I haven't received any more comments.
Please CC.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/alsdec: allow for predictor orders higher than block length which is valid in ALS.

2016-11-10 Thread Thilo Borgmann

Am 10.11.16 um 12:47 schrieb Michael Niedermayer:
> On Thu, Nov 10, 2016 at 12:39:24PM +0100, Michael Niedermayer wrote:
>> On Wed, Nov 09, 2016 at 08:02:41PM +0100, Thilo Borgmann wrote:
>>> Hi,
>>>
>>> fixes ticket #5297 reverting an old commit.
>>>
>>> -Thilo
>>
>>>  alsdec.c |6 +-
>>>  1 file changed, 1 insertion(+), 5 deletions(-)
>>> 82dc6f263e8a3f35e5321f355a61b2f3304f531d  
>>> 0001-lavc-alsdec-allow-for-predictor-orders-higher-than-b.patch
>>> From 50f62f88696d1401d93c552d52fe1b9c396f8a00 Mon Sep 17 00:00:00 2001
>>> From: Thilo Borgmann 
>>> Date: Wed, 9 Nov 2016 20:00:02 +0100
>>> Subject: [PATCH] lavc/alsdec: allow for predictor orders higher than block
>>>  length which is valid in ALS.
>>>
>>> Reverts: 18f94df8af04f2c02a25a7dec512289feff6517f
>>> Fixes ticket #5297
>>> ---
>>>  libavcodec/alsdec.c | 6 +-
>>>  1 file changed, 1 insertion(+), 5 deletions(-)
>>
>> this causes segfautlts:

Thanks will have another look!

-Thilo

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

Re: [FFmpeg-devel] [PATCH 2/3] lavfi/loudnorm: add an internal libebur128 library

2016-11-10 Thread Paul B Mahol

On 11/10/16, Hendrik Leppkes  wrote:
> On Thu, Nov 10, 2016 at 5:32 PM, Kyle Swanson  wrote:
>> On Tue, Nov 8, 2016 at 9:39 AM, Kyle Swanson  wrote:
>>> On Mon, Nov 7, 2016 at 6:00 PM, Marton Balint  wrote:

 On Fri, 4 Nov 2016, Marton Balint wrote:

>
> On Thu, 3 Nov 2016, Hendrik Leppkes wrote:
>
>> On Mon, Oct 17, 2016 at 5:20 PM, Moritz Barsnick 
>> wrote:
>>>
>>> On Mon, Oct 17, 2016 at 17:09:15 +0200, wm4 wrote:

 Does this copy parts of libebur128 to FFmpeg?
 Why?
>>>
>>>
>>> There was a long discussion regarding this patch:
>>>
>>> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-April/192668.html
>>>
>>> (in summary: "please don't require yet another small external
>>> library,
>>> rather port it to ffmpeg and maintain it") leading to this one:
>>>
>>
>> The generic idea was not to just copy/paste an external library into
>> internal code, but extend the ebur128 code we already have - at least
>> that way we get code written by one of our maintainers, code he knows
>> and can properly maintain.
>
>
> I copied the external library because we needed an API. The way the
> internals work, I used the library code because it was simply easier,
> than
> factoring out f_ebur128 stuff, also there are some features which
> f_ebur128.c does not have (variable sample rate support), and there was
> the
> licensing issue GPL v.s. LGPL.
>
>> If you just copy the implementation of a library, you might as well
>> just use that library - thats what it exists for. Why do we want to
>> increase the maintenance burden of our project when other people (ie.
>> the authors of libebur128) are already doing it as well?
>
>
> In general I agree with people who think that for small code, it is
> better
> to integrate it into our codebase, because
> - it can benefit from features we already have (e.g. resampling)
> - makes it easier for developers to work on features based on this
> - code gets more review than code in a small 3rd party library
> - code and/or improvements have stronger requirements performance-wise
> - code is better audited (Coverity, etc)
>
> Yes, some additional maintenance burden is the price we pay for this,
> which is IMHO in this case is acceptable.
>

 Is it fine to apply, or we should put this to a vote?
>>>
>>> Give me another day to review the patch. Meant look at this last weekend.
>>
>> These patches look good to me. If we're going to do this, we really
>> need to keep the true peak mode in the libebur128 port. This is a huge
>> part of the R128 spec, and it's important that it stays in. Of course
>> redundant code is bad, so we'll need to update f_ebur128 as well
>> (which has a true peak requirement.) I already have a patch for
>> f_ebur128. Marton, it might be easier for you to update the patch to
>> include true peak mode but I could do it as well. It'd be interesting
>> to benchmark the libebur128 FIR resampler vs. swresample.
>
> If this gets re-added, please make it use our resampler unless there
> are good technical reasons against that (algorithm wise).
> Keeping an extra small resampler just for some measurements seems like
> something that can be surely avoided.

Yes, I also agree. Is such small resampler really needed?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/utils.c: Make sure skip_samples never goes negative.

On Thu, Nov 10, 2016 at 01:30:34PM +, Derek Buitenhuis wrote:
> On 11/4/2016 10:31 PM, Sasi Inguva wrote:
> > -avctx->internal->skip_samples -= frame->nb_samples;
> > +avctx->internal->skip_samples = FFMAX(0, 
> > avctx->internal->skip_samples - frame->nb_samples);
> 
> LGTM.

applied

thx

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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Fallback to finding non-keyframe in fix_index, if keyframe search fails.

On Thu, Nov 10, 2016 at 01:27:51PM +, Derek Buitenhuis wrote:
> On 11/9/2016 6:51 PM, Sasi Inguva wrote:
> > Signed-off-by: Sasi Inguva 
> > ---
> >  libavformat/mov.c   |  41 
> >  tests/fate/mov.mak  |   6 +-
> >  tests/ref/fate/mp4-init-nonkeyframe | 120 
> > 
> >  3 files changed, 155 insertions(+), 12 deletions(-)
> >  create mode 100644 tests/ref/fate/mp4-init-nonkeyframe
> 
> Seems OK.

applied

thx

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

Re: [FFmpeg-devel] [PATCH] dvbsubdec: fix division by zero in compute_default_clut

On Wed, Nov 09, 2016 at 08:52:54PM +0100, Andreas Cadhalpun wrote:
> On 09.11.2016 02:27, Michael Niedermayer wrote:
> > On Tue, Nov 08, 2016 at 10:36:01PM +0100, Andreas Cadhalpun wrote:
> >> Since the loop goes down to i = 0 the number of iterations (variable
> >> count) is the original i, not i - 1.
> >> In the case of i originally being 1, this miscalculation resulted in
> >> a division by zero.
> >>
> >> This problem was introduced in commit
> >> 4b90dcb8493552c17a811c8b1e6538dae4061f9d.
> >>
> >> Signed-off-by: Andreas Cadhalpun 
> >> ---
> >>  libavcodec/dvbsubdec.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavcodec/dvbsubdec.c b/libavcodec/dvbsubdec.c
> >> index e9f4765..31898ea 100644
> >> --- a/libavcodec/dvbsubdec.c
> >> +++ b/libavcodec/dvbsubdec.c
> >> @@ -810,7 +810,7 @@ static void compute_default_clut(AVSubtitleRect *rect, 
> >> int w, int h)
> >>  list_inv[ i ] = bestv;
> >>  }
> >>  
> >> -count = i - 1;
> >> +count = i;
> >>  for (i--; i>=0; i--) {
> >>  int v = i*255/count;
> >>  AV_WN32(rect->data[1] + 4*list_inv[i], RGBA(v/2,v,v/2,v));
> > 
> > with this a 2 color text would be 50% and 100% transparent
> > it should be transparent background and opaque text,
> > count = FFMAX(i - 1, 1);
> > seems better to me
> 
> OK, patch doing that is attached.
> 
> Best regards,
> Andreas
> 

>  dvbsubdec.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 10b117a15971daf75d61efe486b961d3cc59d480  
> 0001-dvbsubdec-fix-division-by-zero-in-compute_default_cl.patch
> From 436318575abf482e1ea144f651c47bc2730e41a2 Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun 
> Date: Tue, 8 Nov 2016 22:32:42 +0100
> Subject: [PATCH] dvbsubdec: fix division by zero in compute_default_clut
> 
> This problem was introduced in commit
> 4b90dcb8493552c17a811c8b1e6538dae4061f9d.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/dvbsubdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.


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

Re: [FFmpeg-devel] [PATCH] opus_celt: move quantization and band decoding to opus_pvq.c

On 10 November 2016 at 15:23, James Almer  wrote:

> On 11/10/2016 2:01 AM, Rostislav Pehlivanov wrote:
> > On 10 November 2016 at 03:13, Rostislav Pehlivanov 
> >  wrote:
> >
> >> A huge amount can be reused by the encoder, as the only thing
> >> which needs to be done would be to add a 10 line celt_icwrsi,
> >> a wrapper around it (celt_alg_quant) and templating the
> >> ff_celt_decode_band to replace entropy decoding functions
> >> with entropy encoding.
> >>
> >> There is no performance loss but in fact a performance gain of
> >> nearly 6% which is caused by the compiler being able to optimize
> >> the decoding more efficiently.
> >>
> >> This commit also removes a redundant declaration (ff_celt_window2
> >> was already defined in opus.h but was not removed with the commit
> >> which split the tables away to opustab.h).
> >>
> >> Signed-off-by: Rostislav Pehlivanov 
> >> ---
> >>  libavcodec/Makefile|   2 +-
> >>  libavcodec/opus.h  |  12 -
> >>  libavcodec/opus_celt.c | 828 +-
> >> ---
> >>  libavcodec/opus_celt.h | 103 ++
> >>  libavcodec/opus_pvq.c  | 729 ++
> +
> >>  libavcodec/opus_pvq.h  |  65 
> >>  libavcodec/opusdec.c   |   1 +
> >>  7 files changed, 910 insertions(+), 830 deletions(-)
> >>  create mode 100644 libavcodec/opus_celt.h
> >>  create mode 100644 libavcodec/opus_pvq.c
> >>  create mode 100644 libavcodec/opus_pvq.h
> >
> >
> > Actually, I don't like how the CELT decoder now has an exposed state. I
> > think the names the
> > CELT decoder uses for/in its contexts are confusing. So I'll remove
> > opus_celt.h and instead
> > give ff_celt_decode_band a pointer to the remaining bits, the TF change
> and
> > the IS flag
> > manually rather than as a context. That way it would be less painful to
> > template
> > the function for the encoder.
> >
> > Changed that locally.
>
> That kinda change requires a new patch. Anyone reviewing this may not
> get the correct idea of what you locally changed and intend to push
> otherwise.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Yeah, nevermind that, patch is good as it is.
Changing the decoder was much less painful than I thought it would be.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavfi/loudnorm: add an internal libebur128 library

2016-11-10 Thread Kyle Swanson

On Tue, Nov 8, 2016 at 9:39 AM, Kyle Swanson  wrote:
> On Mon, Nov 7, 2016 at 6:00 PM, Marton Balint  wrote:
>>
>> On Fri, 4 Nov 2016, Marton Balint wrote:
>>
>>>
>>> On Thu, 3 Nov 2016, Hendrik Leppkes wrote:
>>>
 On Mon, Oct 17, 2016 at 5:20 PM, Moritz Barsnick 
 wrote:
>
> On Mon, Oct 17, 2016 at 17:09:15 +0200, wm4 wrote:
>>
>> Does this copy parts of libebur128 to FFmpeg?
>> Why?
>
>
> There was a long discussion regarding this patch:
>
> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-April/192668.html
>
> (in summary: "please don't require yet another small external library,
> rather port it to ffmpeg and maintain it") leading to this one:
>

 The generic idea was not to just copy/paste an external library into
 internal code, but extend the ebur128 code we already have - at least
 that way we get code written by one of our maintainers, code he knows
 and can properly maintain.
>>>
>>>
>>> I copied the external library because we needed an API. The way the
>>> internals work, I used the library code because it was simply easier, than
>>> factoring out f_ebur128 stuff, also there are some features which
>>> f_ebur128.c does not have (variable sample rate support), and there was the
>>> licensing issue GPL v.s. LGPL.
>>>
 If you just copy the implementation of a library, you might as well
 just use that library - thats what it exists for. Why do we want to
 increase the maintenance burden of our project when other people (ie.
 the authors of libebur128) are already doing it as well?
>>>
>>>
>>> In general I agree with people who think that for small code, it is better
>>> to integrate it into our codebase, because
>>> - it can benefit from features we already have (e.g. resampling)
>>> - makes it easier for developers to work on features based on this
>>> - code gets more review than code in a small 3rd party library
>>> - code and/or improvements have stronger requirements performance-wise
>>> - code is better audited (Coverity, etc)
>>>
>>> Yes, some additional maintenance burden is the price we pay for this,
>>> which is IMHO in this case is acceptable.
>>>
>>
>> Is it fine to apply, or we should put this to a vote?
>
> Give me another day to review the patch. Meant look at this last weekend.

These patches look good to me. If we're going to do this, we really
need to keep the true peak mode in the libebur128 port. This is a huge
part of the R128 spec, and it's important that it stays in. Of course
redundant code is bad, so we'll need to update f_ebur128 as well
(which has a true peak requirement.) I already have a patch for
f_ebur128. Marton, it might be easier for you to update the patch to
include true peak mode but I could do it as well. It'd be interesting
to benchmark the libebur128 FIR resampler vs. swresample.

Also, this port is only like ~670 lines of C plus a header. It makes
sense to port it to FFmpeg instead of linking it. Also, on my systems
(osx, linux) af_loudnorm is ~5x faster then it was when libebur128 was
dynamically linked.

Thanks,
Kyle

>
>>
>> Thanks,
>>
>> Marton
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] mov: extract stsd vendor field in metadata.

On Wed, Nov 09, 2016 at 04:42:35PM -0800, Zhenni Huang wrote:
> Also updates fate ref for rgb24-mkv as the output video will contain the
> new metadata field and have different md5sum and file size.
> ---
>  libavformat/mov.c| 18 --
>  tests/ref/fate/rgb24-mkv |  4 ++--
>  2 files changed, 18 insertions(+), 4 deletions(-)

breaks
fate-mov-zombie
i think it needs an update too

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

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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

[FFmpeg-devel] [PATCH] opus_celt: rename structures to better names and reorganize them

This is meant to be applied on top of my previous patch which
split PVQ into celt_pvq.c and made opus_celt.h

Essentially nothing has been changed other than renaming CeltFrame
to CeltBlock (CeltFrame had absolutely nothing at all to do with
a frame) and CeltContext to CeltFrame.
3 variables have been put in CeltFrame as they make more sense
there rather than being passed around as arguments.
The coefficients have been moved to the CeltBlock structure
(why the hell were they in CeltContext and not in CeltFrame??).

Now the encoder would be able to use the exact context the decoder
uses (plus a couple of extra fields in there).

FATE passes, no slowdowns, etc.

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/opus.h  |  14 +-
 libavcodec/opus_celt.c | 719 +
 libavcodec/opus_celt.h |  82 +++---
 libavcodec/opus_pvq.c  |  50 ++--
 libavcodec/opus_pvq.h  |   8 +-
 libavcodec/opus_rc.c   |  12 +-
 libavcodec/opus_rc.h   |   6 +-
 libavcodec/opusdec.c   |   1 +
 8 files changed, 449 insertions(+), 443 deletions(-)

diff --git a/libavcodec/opus.h b/libavcodec/opus.h
index be04249..e8d13df 100644
--- a/libavcodec/opus.h
+++ b/libavcodec/opus.h
@@ -75,7 +75,7 @@ enum OpusBandwidth {
 
 typedef struct SilkContext SilkContext;
 
-typedef struct CeltContext CeltContext;
+typedef struct CeltFrame CeltFrame;
 
 typedef struct OpusPacket {
 int packet_size;/**< packet size */
@@ -100,7 +100,7 @@ typedef struct OpusStreamContext {
 OpusRangeCoder rc;
 OpusRangeCoder redundancy_rc;
 SilkContext *silk;
-CeltContext *celt;
+CeltFrame *celt;
 AVFloatDSPContext *fdsp;
 
 float silk_buf[2][960];
@@ -185,14 +185,4 @@ int ff_silk_decode_superframe(SilkContext *s, 
OpusRangeCoder *rc,
   enum OpusBandwidth bandwidth, int coded_channels,
   int duration_ms);
 
-int ff_celt_init(AVCodecContext *avctx, CeltContext **s, int output_channels);
-
-void ff_celt_free(CeltContext **s);
-
-void ff_celt_flush(CeltContext *s);
-
-int ff_celt_decode_frame(CeltContext *s, OpusRangeCoder *rc,
- float **output, int coded_channels, int frame_size,
- int startband,  int endband);
-
 #endif /* AVCODEC_OPUS_H */
diff --git a/libavcodec/opus_celt.c b/libavcodec/opus_celt.c
index 6cc5d2f..7e4a5e3 100644
--- a/libavcodec/opus_celt.c
+++ b/libavcodec/opus_celt.c
@@ -1,6 +1,7 @@
 /*
  * Copyright (c) 2012 Andrew D'Addesio
  * Copyright (c) 2013-2014 Mozilla Corporation
+ * Copyright (c) 2016 Rostislav Pehlivanov 
  *
  * This file is part of FFmpeg.
  *
@@ -28,7 +29,7 @@
 #include "opustab.h"
 #include "opus_pvq.h"
 
-static void celt_decode_coarse_energy(CeltContext *s, OpusRangeCoder *rc)
+static void celt_decode_coarse_energy(CeltFrame *f, OpusRangeCoder *rc)
 {
 int i, j;
 float prev[2] = {0};
@@ -38,29 +39,29 @@ static void celt_decode_coarse_energy(CeltContext *s, 
OpusRangeCoder *rc)
 /* use the 2D z-transform to apply prediction in both */
 /* the time domain (alpha) and the frequency domain (beta) */
 
-if (opus_rc_tell(rc)+3 <= s->framebits && ff_opus_rc_dec_log(rc, 3)) {
+if (opus_rc_tell(rc)+3 <= f->framebits && ff_opus_rc_dec_log(rc, 3)) {
 /* intra frame */
 alpha = 0;
 beta  = 1.0f - 4915.0f/32768.0f;
-model = ff_celt_coarse_energy_dist[s->duration][1];
+model = ff_celt_coarse_energy_dist[f->size][1];
 } else {
-alpha = ff_celt_alpha_coef[s->duration];
-beta  = 1.0f - ff_celt_beta_coef[s->duration];
-model = ff_celt_coarse_energy_dist[s->duration][0];
+alpha = ff_celt_alpha_coef[f->size];
+beta  = 1.0f - ff_celt_beta_coef[f->size];
+model = ff_celt_coarse_energy_dist[f->size][0];
 }
 
 for (i = 0; i < CELT_MAX_BANDS; i++) {
-for (j = 0; j < s->coded_channels; j++) {
-CeltFrame *frame = >frame[j];
+for (j = 0; j < f->channels; j++) {
+CeltBlock *block = >block[j];
 float value;
 int available;
 
-if (i < s->startband || i >= s->endband) {
-frame->energy[i] = 0.0;
+if (i < f->start_band || i >= f->end_band) {
+block->energy[i] = 0.0;
 continue;
 }
 
-available = s->framebits - opus_rc_tell(rc);
+available = f->framebits - opus_rc_tell(rc);
 if (available >= 15) {
 /* decode using a Laplace distribution */
 int k = FFMIN(i, 20) << 1;
@@ -72,82 +73,81 @@ static void celt_decode_coarse_energy(CeltContext *s, 
OpusRangeCoder *rc)
 value = -(float)ff_opus_rc_dec_log(rc, 1);
 } else value = -1;
 
-frame->energy[i] = FFMAX(-9.0f, frame->energy[i]) * alpha + 
prev[j] + value;
+block->energy[i] = FFMAX(-9.0f,

Re: [FFmpeg-devel] [PATCH] opus_celt: move quantization and band decoding to opus_pvq.c

2016-11-10 Thread James Almer

On 11/10/2016 2:01 AM, Rostislav Pehlivanov wrote:
> On 10 November 2016 at 03:13, Rostislav Pehlivanov 
>  wrote:
> 
>> A huge amount can be reused by the encoder, as the only thing
>> which needs to be done would be to add a 10 line celt_icwrsi,
>> a wrapper around it (celt_alg_quant) and templating the
>> ff_celt_decode_band to replace entropy decoding functions
>> with entropy encoding.
>>
>> There is no performance loss but in fact a performance gain of
>> nearly 6% which is caused by the compiler being able to optimize
>> the decoding more efficiently.
>>
>> This commit also removes a redundant declaration (ff_celt_window2
>> was already defined in opus.h but was not removed with the commit
>> which split the tables away to opustab.h).
>>
>> Signed-off-by: Rostislav Pehlivanov 
>> ---
>>  libavcodec/Makefile|   2 +-
>>  libavcodec/opus.h  |  12 -
>>  libavcodec/opus_celt.c | 828 +-
>> ---
>>  libavcodec/opus_celt.h | 103 ++
>>  libavcodec/opus_pvq.c  | 729 +++
>>  libavcodec/opus_pvq.h  |  65 
>>  libavcodec/opusdec.c   |   1 +
>>  7 files changed, 910 insertions(+), 830 deletions(-)
>>  create mode 100644 libavcodec/opus_celt.h
>>  create mode 100644 libavcodec/opus_pvq.c
>>  create mode 100644 libavcodec/opus_pvq.h
> 
> 
> Actually, I don't like how the CELT decoder now has an exposed state. I
> think the names the
> CELT decoder uses for/in its contexts are confusing. So I'll remove
> opus_celt.h and instead
> give ff_celt_decode_band a pointer to the remaining bits, the TF change and
> the IS flag
> manually rather than as a context. That way it would be less painful to
> template
> the function for the encoder.
> 
> Changed that locally.

That kinda change requires a new patch. Anyone reviewing this may not
get the correct idea of what you locally changed and intend to push
otherwise.

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

Re: [FFmpeg-devel] [PATCH] hls: call avformat_find_stream_info for mpegts subdemuxer

2016-11-10 Thread Hendrik Leppkes

On Thu, Nov 10, 2016 at 12:38 PM, wm4  wrote:
> On Thu, 3 Nov 2016 01:12:03 +0100
> Andreas Cadhalpun  wrote:
>
>> This fixes probing dts/eac3/mp2 in hls.
>>
>> The problem was introduced in commit 
>> 04964ac311abe670fb3b60290a330f2067544b13.
>>
>> Also update the fate reference for the fate-segment-mp4-to-ts test.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>
>> I've no idea why the fate reference changes, but this also happens when
>> partially/fully reverting commit 04964ac311abe670fb3b60290a330f2067544b13.
>> And it's a very recent fate test...
>>
>> ---
>
> Will this make segment switch latencies even worse? The HLS demuxer is
> already terrible for realtime playback because it closes and reopens
> the TCP connection on each segment.
>

An alternative patch was applied that doesn't use double-probing
(hence the slowdown issue was brought up in this thread), but even in
this approach it would only probe at startup once, and not every
segment.

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

[FFmpeg-devel] [PATCH] doc/encoders: add documentation for the Hap encoder

2016-11-10 Thread Tom Butterworth

Documents options and behaviour, noting when 'chunks' option will
not be honoured.

Signed-off-by: Tom Butterworth 
---
 doc/encoders.texi | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index ba60e0a..c0597d8 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2501,6 +2501,45 @@ Reduces detail but attempts to preserve color at 
extremely low bitrates.
 
 @end table
 
+@section Hap
+
+Vidvox Hap video encoder.
+
+@subsection Options
+
+@table @option
+@item format @var{integer}
+Specifies the Hap format to encode.
+
+@table @option
+@item hap
+@item hap_alpha
+@item hap_q
+@end table
+
+Default value is @option{hap}.
+
+@item chunks @var{integer}
+Specifies the number of chunks to split frames into, between 1 and 64. This
+permits multithreaded decoding of large frames, potentially at the cost of
+data-rate. The encoder may modify this value to divide frames evenly.
+
+Default value is @var{1}.
+
+@item compressor @var{integer}
+Specifies the second-stage compressor to use. If set to @option{none},
+@option{chunks} will be limited to 1, as chunked uncompressed frames offer no
+benefit.
+
+@table @option
+@item none
+@item snappy
+@end table
+
+Default value is @option{snappy}.
+
+@end table
+
 @c man end VIDEO ENCODERS
 
 @chapter Subtitles Encoders
-- 
2.9.3 (Apple Git-75)

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Fallback to finding non-keyframe in fix_index, if keyframe search fails.

2016-11-10 Thread Derek Buitenhuis

On 11/9/2016 6:51 PM, Sasi Inguva wrote:
> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/mov.c   |  41 
>  tests/fate/mov.mak  |   6 +-
>  tests/ref/fate/mp4-init-nonkeyframe | 120 
> 
>  3 files changed, 155 insertions(+), 12 deletions(-)
>  create mode 100644 tests/ref/fate/mp4-init-nonkeyframe

Seems OK.

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

Re: [FFmpeg-devel] [PATCH] proresdec_lgpl: explicitly check coff[3] against slice_data_size

On Wed, Nov 09, 2016 at 11:56:36PM +0100, Andreas Cadhalpun wrote:
> The implicit checks via v_data_size and a_data_size don't work in the case
> '(hdr_size > 7) && !ctx->alpha_info'.
> 
> This fixes segmentation faults due to invalid reads.
> 
> This problem was introduced in commit
> 547c2f002a87f4412a83c23b0d60364be5e7ce58.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/proresdec_lgpl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

LGTM

thx

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

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


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

Re: [FFmpeg-devel] [PATCH] lavc/utils.c: Make sure skip_samples never goes negative.

2016-11-10 Thread Derek Buitenhuis

On 11/4/2016 10:31 PM, Sasi Inguva wrote:
> -avctx->internal->skip_samples -= frame->nb_samples;
> +avctx->internal->skip_samples = FFMAX(0, 
> avctx->internal->skip_samples - frame->nb_samples);

LGTM.

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

Re: [FFmpeg-devel] [PATCH] hls: call avformat_find_stream_info for mpegts subdemuxer

On Thu, 3 Nov 2016 01:12:03 +0100
Andreas Cadhalpun  wrote:

> This fixes probing dts/eac3/mp2 in hls.
> 
> The problem was introduced in commit 04964ac311abe670fb3b60290a330f2067544b13.
> 
> Also update the fate reference for the fate-segment-mp4-to-ts test.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
> 
> I've no idea why the fate reference changes, but this also happens when
> partially/fully reverting commit 04964ac311abe670fb3b60290a330f2067544b13.
> And it's a very recent fate test...
> 
> ---

Will this make segment switch latencies even worse? The HLS demuxer is
already terrible for realtime playback because it closes and reopens
the TCP connection on each segment.

(Didn't check whether this is already applied.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/alsdec: allow for predictor orders higher than block length which is valid in ALS.

On Thu, Nov 10, 2016 at 12:39:24PM +0100, Michael Niedermayer wrote:
> On Wed, Nov 09, 2016 at 08:02:41PM +0100, Thilo Borgmann wrote:
> > Hi,
> > 
> > fixes ticket #5297 reverting an old commit.
> > 
> > -Thilo
> 
> >  alsdec.c |6 +-
> >  1 file changed, 1 insertion(+), 5 deletions(-)
> > 82dc6f263e8a3f35e5321f355a61b2f3304f531d  
> > 0001-lavc-alsdec-allow-for-predictor-orders-higher-than-b.patch
> > From 50f62f88696d1401d93c552d52fe1b9c396f8a00 Mon Sep 17 00:00:00 2001
> > From: Thilo Borgmann 
> > Date: Wed, 9 Nov 2016 20:00:02 +0100
> > Subject: [PATCH] lavc/alsdec: allow for predictor orders higher than block
> >  length which is valid in ALS.
> > 
> > Reverts: 18f94df8af04f2c02a25a7dec512289feff6517f
> > Fixes ticket #5297
> > ---
> >  libavcodec/alsdec.c | 6 +-
> >  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> this causes segfautlts:
> 
> valgrind ./ffmpeg_g -i 
> abd3c041acbcb816be113455d138166b-asan_heap-oob_b11634_3707_cov_1707137151_als_05_2ch48k16b.mp4
>  -f null -
> ==15702== Memcheck, a memory error detector
> ==15702== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
> ==15702== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
> ==15702== Command: ./ffmpeg_g -i 
> abd3c041acbcb816be113455d138166b-asan_heap-oob_b11634_3707_cov_1707137151_als_05_2ch48k16b.mp4
>  -f null -
> ==15702==
> [...]
> 
> ==15702== Invalid read of size 4
> ==15702==at 0x792EC8: decode_var_block_data (alsdec.c:931)
> ==15702==by 0x7932EE: decode_block (alsdec.c:1029)
> ==15702==by 0x7933AC: read_decode_block (alsdec.c:1053)
> ==15702==by 0x79356D: decode_blocks_ind (alsdec.c:1100)
> ==15702==by 0x795611: read_frame_data (alsdec.c:1640)
> ==15702==by 0x795EF6: decode_frame (alsdec.c:1782)
> ==15702==by 0xB213E1: avcodec_decode_audio4 (utils.c:2362)
> ==15702==by 0xB22E01: do_decode (utils.c:2793)
> ==15702==by 0xB231AB: avcodec_send_packet (utils.c:2877)
> ==15702==by 0x430FD5: decode (ffmpeg.c:2049)
> ==15702==by 0x431135: decode_audio (ffmpeg.c:2079)
> ==15702==by 0x432F4D: process_input_packet (ffmpeg.c:2493)
> ==15702==  Address 0x1067ed10 is 0 bytes after a block of size 6,224 alloc'd
> ==15702==at 0x4C2A6C5: memalign (vg_replace_malloc.c:727)
> ==15702==by 0x4C2A760: posix_memalign (vg_replace_malloc.c:876)
> ==15702==by 0x1063B9F: av_malloc (mem.c:97)
> ==15702==by 0x1063E47: av_mallocz (mem.c:254)
> ==15702==by 0x790931: av_mallocz_array (mem.h:230)
> ==15702==by 0x796EE0: decode_init (alsdec.c:2061)
> ==15702==by 0xB1EE96: avcodec_open2 (utils.c:1603)
> ==15702==by 0x433E04: init_input_stream (ffmpeg.c:2755)
> ==15702==by 0x436A38: transcode_init (ffmpeg.c:3509)
> ==15702==by 0x43A3A2: transcode (ffmpeg.c:4395)
> ==15702==by 0x43AC2F: main (ffmpeg.c:4629)

=
==31617==ERROR: AddressSanitizer: heap-buffer-overflow on address 
0x6230dd50 at pc 0x00c1c462 bp 0x7ffd3a768600 sp 0x7ffd3a7685f8
READ of size 4 at 0x6230dd50 thread T0
#0 0xc1c461 in decode_var_block_data libavcodec/alsdec.c:931:28
#1 0xc17c80 in decode_block libavcodec/alsdec.c:1029:15
#2 0xc197d0 in read_decode_block libavcodec/alsdec.c:1053:12
#3 0xc14f9a in decode_blocks_ind libavcodec/alsdec.c:1100:20
#4 0xc1318d in read_frame_data libavcodec/alsdec.c:1640:23
#5 0xc0fdd7 in decode_frame libavcodec/alsdec.c:1782:26
#6 0x13f3cc8 in avcodec_decode_audio4 libavcodec/utils.c:2362:19
#7 0x13f7d06 in do_decode libavcodec/utils.c:2793:15
#8 0x13f79c9 in avcodec_send_packet libavcodec/utils.c:2877:12
#9 0x532efb in decode ffmpeg.c:2049:15
#10 0x52db05 in decode_audio ffmpeg.c:2079:11
#11 0x5186ad in process_input_packet ffmpeg.c:2493:19
#12 0x52483d in process_input ffmpeg.c:4282:5
#13 0x516639 in transcode_step ffmpeg.c:4370:11
#14 0x50fd99 in transcode ffmpeg.c:4424:15
#15 0x50ecfe in main ffmpeg.c:4629:9
#16 0x7f844cc367ec in __libc_start_main 
/build/eglibc-oqps9y/eglibc-2.15/csu/libc-start.c:226
#17 0x424258 in _start (ffmpeg_g+0x424258)

0x6230dd50 is located 0 bytes to the right of 6224-byte region 
[0x6230c500,0x6230dd50)
allocated by thread T0 here:
#0 0x4b4dc5 in __interceptor_posix_memalign (ffmpeg_g+0x4b4dc5)
#1 0x1f419a8 in av_malloc libavutil/mem.c:97:9
#2 0x1f41f2e in av_mallocz libavutil/mem.c:254:17
#3 0xc0ee66 in decode_init libavcodec/alsdec.c:2061:29
#4 0x13eda4f in avcodec_open2 libavcodec/utils.c:1603:15
#5 0x51b0e3 in init_input_stream ffmpeg.c:2755:20
#6 0x51362e in transcode_init ffmpeg.c:3509:20
#7 0x50fcec in transcode ffmpeg.c:4395:11
#8 0x50ecfe in main ffmpeg.c:4629:9
#9 0x7f844cc367ec in __libc_start_main 
/build/eglibc-oqps9y/eglibc-2.15/csu/libc-start.c:226

SUMMARY: AddressSanitizer: heap-buffer-overflow libavcodec/alsdec.c:931:28 in 
decode_var_block_data
Shadow

Re: [FFmpeg-devel] [PATCH] avformat: Allow forcing use of AVParsers

On Sun,  6 Nov 2016 21:16:43 +0100
Michael Niedermayer  wrote:

> TODO: version bump, docs
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/avformat.h  | 8 
>  libavformat/options_table.h | 7 +++
>  libavformat/utils.c | 3 +++
>  3 files changed, 18 insertions(+)
> 
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index f9f4d72..96e6b94 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -1899,6 +1899,14 @@ typedef struct AVFormatContext {
>   * - decoding: set by user through AVOptions (NO direct access)
>   */
>  char *protocol_blacklist;
> +
> +/**
> + * Force parsing.
> + * - encoding: unused
> + * - decoding: set by user through AVOptions (NO direct access)
> + */
> +int force_parsing;
> +
>  } AVFormatContext;
>  
>  int av_format_get_probe_score(const AVFormatContext *s);
> diff --git a/libavformat/options_table.h b/libavformat/options_table.h
> index 9d61d5a..50ea3c1 100644
> --- a/libavformat/options_table.h
> +++ b/libavformat/options_table.h
> @@ -105,6 +105,13 @@ static const AVOption avformat_options[] = {
>  {"format_whitelist", "List of demuxers that are allowed to be used", 
> OFFSET(format_whitelist), AV_OPT_TYPE_STRING, { .str = NULL },  CHAR_MIN, 
> CHAR_MAX, D },
>  {"protocol_whitelist", "List of protocols that are allowed to be used", 
> OFFSET(protocol_whitelist), AV_OPT_TYPE_STRING, { .str = NULL },  CHAR_MIN, 
> CHAR_MAX, D },
>  {"protocol_blacklist", "List of protocols that are not allowed to be used", 
> OFFSET(protocol_blacklist), AV_OPT_TYPE_STRING, { .str = NULL },  CHAR_MIN, 
> CHAR_MAX, D },
> +{"forceparsing", "force use of AVParsers", OFFSET(force_parsing), 
> AV_OPT_TYPE_INT, { .i64 = -1 },  -1, AVSTREAM_PARSE_FULL_ONCE, D, 
> "forceparsing"},
> +{"none",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AVSTREAM_PARSE_NONE 
>   }, INT_MIN, INT_MAX, D, "forceparsing" },
> +{"full",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AVSTREAM_PARSE_FULL 
>   }, INT_MIN, INT_MAX, D, "forceparsing" },
> +{"headers", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AVSTREAM_PARSE_HEADERS  
>   }, INT_MIN, INT_MAX, D, "forceparsing" },
> +{"timestamps",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
> AVSTREAM_PARSE_TIMESTAMPS }, INT_MIN, INT_MAX, D, "forceparsing" },
> +{"once",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
> AVSTREAM_PARSE_FULL_ONCE  }, INT_MIN, INT_MAX, D, "forceparsing" },
> +{"raw", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AVSTREAM_PARSE_FULL_RAW 
>   }, INT_MIN, INT_MAX, D, "forceparsing" },
>  {NULL},
>  };
>  
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 5664646..23e063f 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -4264,6 +4264,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
>   * timestamps have their first few packets buffered and the
>   * timestamps corrected before they are returned to the user */
>  st->cur_dts = RELATIVE_TS_BASE;
> +
> +if (s->force_parsing >= 0)
> +st->need_parsing = s->force_parsing;
>  } else {
>  st->cur_dts = AV_NOPTS_VALUE;
>  }

Use case?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] [PATCH 0/2] Two alternative ways to fix auto bsfs and merged side data

On Fri,  4 Nov 2016 13:43:43 +0100
Michael Niedermayer  wrote:

> Here are 2 ways to fix merged side data and auto BSFs
> the testcase i have requires a non public rtmp stream

Third way: remove merged side data. It's a terrible and evil hack and
should have never existed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/alsdec: allow for predictor orders higher than block length which is valid in ALS.

On Wed, Nov 09, 2016 at 08:02:41PM +0100, Thilo Borgmann wrote:
> Hi,
> 
> fixes ticket #5297 reverting an old commit.
> 
> -Thilo

>  alsdec.c |6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 82dc6f263e8a3f35e5321f355a61b2f3304f531d  
> 0001-lavc-alsdec-allow-for-predictor-orders-higher-than-b.patch
> From 50f62f88696d1401d93c552d52fe1b9c396f8a00 Mon Sep 17 00:00:00 2001
> From: Thilo Borgmann 
> Date: Wed, 9 Nov 2016 20:00:02 +0100
> Subject: [PATCH] lavc/alsdec: allow for predictor orders higher than block
>  length which is valid in ALS.
> 
> Reverts: 18f94df8af04f2c02a25a7dec512289feff6517f
> Fixes ticket #5297
> ---
>  libavcodec/alsdec.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)

this causes segfautlts:

valgrind ./ffmpeg_g -i 
abd3c041acbcb816be113455d138166b-asan_heap-oob_b11634_3707_cov_1707137151_als_05_2ch48k16b.mp4
 -f null -
==15702== Memcheck, a memory error detector
==15702== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==15702== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==15702== Command: ./ffmpeg_g -i 
abd3c041acbcb816be113455d138166b-asan_heap-oob_b11634_3707_cov_1707137151_als_05_2ch48k16b.mp4
 -f null -
==15702==
[...]

==15702== Invalid read of size 4
==15702==at 0x792EC8: decode_var_block_data (alsdec.c:931)
==15702==by 0x7932EE: decode_block (alsdec.c:1029)
==15702==by 0x7933AC: read_decode_block (alsdec.c:1053)
==15702==by 0x79356D: decode_blocks_ind (alsdec.c:1100)
==15702==by 0x795611: read_frame_data (alsdec.c:1640)
==15702==by 0x795EF6: decode_frame (alsdec.c:1782)
==15702==by 0xB213E1: avcodec_decode_audio4 (utils.c:2362)
==15702==by 0xB22E01: do_decode (utils.c:2793)
==15702==by 0xB231AB: avcodec_send_packet (utils.c:2877)
==15702==by 0x430FD5: decode (ffmpeg.c:2049)
==15702==by 0x431135: decode_audio (ffmpeg.c:2079)
==15702==by 0x432F4D: process_input_packet (ffmpeg.c:2493)
==15702==  Address 0x1067ed10 is 0 bytes after a block of size 6,224 alloc'd
==15702==at 0x4C2A6C5: memalign (vg_replace_malloc.c:727)
==15702==by 0x4C2A760: posix_memalign (vg_replace_malloc.c:876)
==15702==by 0x1063B9F: av_malloc (mem.c:97)
==15702==by 0x1063E47: av_mallocz (mem.c:254)
==15702==by 0x790931: av_mallocz_array (mem.h:230)
==15702==by 0x796EE0: decode_init (alsdec.c:2061)
==15702==by 0xB1EE96: avcodec_open2 (utils.c:1603)
==15702==by 0x433E04: init_input_stream (ffmpeg.c:2755)
==15702==by 0x436A38: transcode_init (ffmpeg.c:3509)
==15702==by 0x43A3A2: transcode (ffmpeg.c:4395)
==15702==by 0x43AC2F: main (ffmpeg.c:4629)

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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

Re: [FFmpeg-devel] [PATCH] ffmpeg: Fix bsf corrupting merged side data