Re: [FFmpeg-devel] [PATCH] rtmpdh: Initialize gcrypt before using it

2016-01-11 Thread Michael Niedermayer 
On Sun, Jan 10, 2016 at 10:04:34PM +, Ricardo Constantino wrote:
> On 10 January 2016 at 19:54, Michael Niedermayer 
> wrote:
> 
> >
> > please explain in the commit message why secmem is disabled
> >
> >

>  rtmpdh.c |   11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> a340654ed5741348282a81f4d1065f85b26896be  
> 0001-rtmpdh-Initialize-gcrypt-before-using-it.patch
> From 0225f408ef437e02d1dd5fc8e925e61120d56031 Mon Sep 17 00:00:00 2001
> From: Ricardo Constantino 
> Date: Tue, 29 Dec 2015 21:40:14 +
> Subject: [PATCH] rtmpdh: Initialize gcrypt before using it
> 
> Either disabling or init'ing secure memory is required after the use
> of gcry_check_version. From a look at the functions rtmpdh uses, I
> noticed none require the use of secure memory, so we disable it [1][2].
> 
> This resolves some errors returned by rtmpdh code with uninitialized
> gcrypt, especifically:
> Fatal: failed to create the RNG lock: Invalid argument
> FATAL: failed to acquire the FSM lock in libgrypt: Invalid argument
> 
> Version "1.5.4" was arbitrarily chosen. An older version probably works
> as well, but I couldn't compile older versions to test on my machine.
> 
> [1]
> https://gnupg.org/documentation/manuals/gcrypt/Initializing-the-library.html
> [2]
> https://www.gnupg.org/documentation/manuals/gcrypt/Controlling-the-library.html
> 
> Signed-off-by: Ricardo Constantino 
> ---
>  libavformat/rtmpdh.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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

Re: [FFmpeg-devel] [PATCHv2] lavc/cbrt_tablegen: speed up tablegen

2016-01-11 Thread Ganesh Ajjanagadde 
On Fri, Jan 8, 2016 at 6:52 AM, Michael Niedermayer
 wrote:
> On Thu, Jan 07, 2016 at 05:20:55PM -0800, Ganesh Ajjanagadde wrote:
>> On Thu, Jan 7, 2016 at 4:48 PM, Michael Niedermayer
>>  wrote:
>> > On Mon, Jan 04, 2016 at 06:33:59PM -0800, Ganesh Ajjanagadde wrote:
>> >> This exploits an approach based on the sieve of Eratosthenes, a popular
>> >> method for generating prime numbers.
>> >>
>> >> Tables are identical to previous ones.
>> >>
>> >> Tested with FATE with/without --enable-hardcoded-tables.
>> >>
>> >> Sample benchmark (Haswell, GNU/Linux+gcc):
>> >> prev:
>> >> 7860100 decicycles in cbrt_tableinit,   1 runs,  0 skips
>> >> 490 decicycles in cbrt_tableinit,   2 runs,  0 skips
>> >> [...]
>> >> 7582339 decicycles in cbrt_tableinit, 256 runs,  0 skips
>> >> 7563556 decicycles in cbrt_tableinit, 512 runs,  0 skips
>> >>
>> >> new:
>> >> 2099480 decicycles in cbrt_tableinit,   1 runs,  0 skips
>> >> 2044470 decicycles in cbrt_tableinit,   2 runs,  0 skips
>> >> [...]
>> >> 1796544 decicycles in cbrt_tableinit, 256 runs,  0 skips
>> >> 1791631 decicycles in cbrt_tableinit, 512 runs,  0 skips
>> >>
>> >> Both small and large run count given as this is called once so small run
>> >> count may give a better picture, small numbers are fairly consistent,
>> >> and there is a consistent downward trend from small to large runs,
>> >> at which point it stabilizes to a new value.
>> >>
>> >> Signed-off-by: Ganesh Ajjanagadde 
>> >> ---
>> >>  libavcodec/aacdec_fixed.c   |  4 +--
>> >>  libavcodec/aacdec_template.c|  2 +-
>> >>  libavcodec/cbrt_tablegen.h  | 53 
>> >> ++---
>> >>  libavcodec/cbrt_tablegen_template.c | 12 -
>> >>  4 files changed, 51 insertions(+), 20 deletions(-)
>> >>
>> >> diff --git a/libavcodec/aacdec_fixed.c b/libavcodec/aacdec_fixed.c
>> >> index 396a874..f7b882b 100644
>> >> --- a/libavcodec/aacdec_fixed.c
>> >> +++ b/libavcodec/aacdec_fixed.c
>> >> @@ -155,9 +155,9 @@ static void vector_pow43(int *coefs, int len)
>> >>  for (i=0; i> >>  coef = coefs[i];
>> >>  if (coef < 0)
>> >> -coef = -(int)cbrt_tab[-coef];
>> >> +coef = -(int)cbrt_tab[-coef].i;
>> >>  else
>> >> -coef = (int)cbrt_tab[coef];
>> >> +coef = (int)cbrt_tab[coef].i;
>> >>  coefs[i] = coef;
>> >>  }
>> >>  }
>> >> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
>> >> index d819958..1380510 100644
>> >> --- a/libavcodec/aacdec_template.c
>> >> +++ b/libavcodec/aacdec_template.c
>> >> @@ -1791,7 +1791,7 @@ static int decode_spectrum_and_dequant(AACContext 
>> >> *ac, INTFLOAT coef[1024],
>> >>  v = -v;
>> >>  *icf++ = v;
>> >>  #else
>> >> -*icf++ = cbrt_tab[n] | (bits & 
>> >> 1U<<31);
>> >> +*icf++ = cbrt_tab[n].i | (bits & 
>> >> 1U<<31);
>> >>  #endif /* USE_FIXED */
>> >>  bits <<= 1;
>> >>  } else {
>> >> diff --git a/libavcodec/cbrt_tablegen.h b/libavcodec/cbrt_tablegen.h
>> >> index 59b5a1d..e3d6634 100644
>> >> --- a/libavcodec/cbrt_tablegen.h
>> >> +++ b/libavcodec/cbrt_tablegen.h
>> >> @@ -26,14 +26,13 @@
>> >>  #include 
>> >>  #include 
>> >>  #include "libavutil/attributes.h"
>> >> +#include "libavutil/intfloat.h"
>> >>  #include "libavcodec/aac_defines.h"
>> >>
>> >> -#if USE_FIXED
>> >> -#define CBRT(x) lrint((x).f * 8192)
>> >> -#else
>> >> -#define CBRT(x) x.i
>> >> -#endif
>> >> -
>> >
>> >> +union ff_int32float64 {
>> >> +uint32_t i;
>> >> +double   f;
>> >> +};
>> >>  #if CONFIG_HARDCODED_TABLES
>> >>  #if USE_FIXED
>> >>  #define cbrt_tableinit_fixed()
>> >> @@ -43,20 +42,42 @@
>> >>  #include "libavcodec/cbrt_tables.h"
>> >>  #endif
>> >>  #else
>> >> -static uint32_t cbrt_tab[1 << 13];
>> >> +static union ff_int32float64 cbrt_tab[1 << 13];
>> >
>> > this doubles the size of the cpu cache needed at runtime to store
>> > the same number of elements
>>
>> Yes, it does, and it was a tradeoff I made that I forgot to list. One
>> can of course use floats; but this loses accuracy at significant
>> levels.
>>
>> So one could malloc and free a double precision array (for temporary
>> storage) at costs of some code complexity, possible heap
>> fragmentation, and the problem of possible failure (may be ok since
>> anyway aac_decode_init is not guaranteed to succeed; it allocates
>> memory for the dsp context). Malloc/free is AFAIK ~ 100's of cycles,
>> dwarfed by the table generation cost.
>>
>> The problem is that it is impossible to give an answer as to precisely
>> what impact that will have on decoding/encoding performance, and
>> results of course vary based

Re: [FFmpeg-devel] [PATCH 3/3] ffmdec: change type of len to ptrdiff_t

2016-01-11 Thread Andreas Cadhalpun 
On 07.01.2016 04:12, Michael Niedermayer wrote:
> On Sat, Jan 02, 2016 at 04:52:25PM +0100, Andreas Cadhalpun wrote:
>> It is used to store the difference between pointers, so ptrdiff_t is the
>> correct type.
>>
>> This prevents potential overflows.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavformat/ffmdec.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> I think if these pointers can differ by more than te int range then
> theres someting else wrong and changing one variable to ptrdiff_t
> might be insufficient to support that

That's right.

> that said, it should do no harm if you feel that changing these 2
> would make the code more robust

OK, pushed it now.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] diracdec: fix idwt_stride calculation in bytes

2016-01-11 Thread Andreas Cadhalpun 
On 12.01.2016 00:01, Kieran Kunhya wrote:
> Ok

Pushed.

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

Re: [FFmpeg-devel] [PATCH] diracdec: fix idwt_stride calculation in bytes

2016-01-11 Thread Kieran Kunhya 
Ok

On Mon, 11 Jan 2016 at 22:27 Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:

> The transformation to bytes must happen after alignment to get the same
> resulting pointers as before.
>
> This fixes segmentation faults in the assembler code.
>
> The regression was introduced in commit 9553689.
>
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/diracdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c
> index 486c1b3..9d985351 100644
> --- a/libavcodec/diracdec.c
> +++ b/libavcodec/diracdec.c
> @@ -941,7 +941,7 @@ static void init_planes(DiracContext *s)
>  p->height  = s->seq.height >> (i ? s->chroma_y_shift : 0);
>  p->idwt_width  = w = CALC_PADDING(p->width , s->wavelet_depth);
>  p->idwt_height = h = CALC_PADDING(p->height, s->wavelet_depth);
> -p->idwt_stride = FFALIGN(p->idwt_width << (1 + s->pshift), 8);
> +p->idwt_stride = FFALIGN(p->idwt_width, 8) << (1 + s->pshift);
>
>  for (level = s->wavelet_depth-1; level >= 0; level--) {
>  w = w>>1;
> --
> 2.6.4
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] qtpalette: make the color_* variables unsigned again

2016-01-11 Thread Andreas Cadhalpun 
On 10.01.2016 13:03, Mats Peterson wrote:
> On 01/10/2016 11:56 AM, Andreas Cadhalpun wrote:
>> This fixes segmentation faults due to out of bounds writes, when
>> color_start is interpreted as negative number.
>>
> Yes Andreas, until my normalization patch for matroskadec.c is applied, of 
> course
> it's very easy for these variables to be negative when using an int, because 
> of
> the invalid private data. I stand corrected.

It can probably also happen with matroska files, but I saw it crash with
a mov file.

In any case, I pushed the patch now.

Best regards,
Andreas

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

[FFmpeg-devel] [PATCH] avcodec/aacenc_is: replace pow(x, 0.75) by x/sqrtf(sqrtf(x))

2016-01-11 Thread Ganesh Ajjanagadde 
This is quite an accurate approximation; testing shows ~ 2ulp error in
the floating point result. Tested with FATE.

Alternatively, if one wants "full accuracy", one can use powf, or sqrt
instead of sqrtf. With powf, one gets 1 ulp error (theoretically should be 0, as
0.75 is exactly representable) on GNU libm, with sqrt, 0 ulp error.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/aacenc_is.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/aacenc_is.c b/libavcodec/aacenc_is.c
index 4f7ec19..846b8ec 100644
--- a/libavcodec/aacenc_is.c
+++ b/libavcodec/aacenc_is.c
@@ -54,7 +54,7 @@ struct AACISError ff_aac_is_encoding_err(AACEncContext *s, 
ChannelElement *cpe,
 FFPsyBand *band0 = >psy.ch[s->cur_channel+0].psy_bands[(w+w2)*16+g];
 FFPsyBand *band1 = >psy.ch[s->cur_channel+1].psy_bands[(w+w2)*16+g];
 int is_band_type, is_sf_idx = FFMAX(1, sce0->sf_idx[(w+w2)*16+g]-4);
-float e01_34 = phase*pow(ener1/ener0, 3.0/4.0);
+float e01_34 = phase*(ener1/ener0)/sqrtf(sqrtf(ener1/ener0));
 float maxval, dist_spec_err = 0.0f;
 float minthr = FFMIN(band0->threshold, band1->threshold);
 for (i = 0; i < sce0->ics.swb_sizes[g]; i++)
-- 
2.7.0

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

[FFmpeg-devel] [PATCH] diracdec: Add slice threading to HQ profile

2016-01-11 Thread Kieran Kunhya 



0001-diracdec-Add-slice-threading-to-HQ-profile.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] ffmpeg_opt: check fclose return value

2016-01-11 Thread Ganesh Ajjanagadde 
This one may be slightly more theoretical, since the preset file is opened in a
read-only mode. Nevertheless, it is a good idea to check its return value.

Signed-off-by: Ganesh Ajjanagadde 
---
 ffmpeg_opt.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 9b341cf..13786da 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -2724,7 +2724,10 @@ static int opt_preset(void *optctx, const char *opt, 
const char *arg)
 }
 }
 
-fclose(f);
+if (fclose(f))
+av_log(NULL, AV_LOG_ERROR,
+   "Error closing preset file: %s\n",
+   av_err2str(AVERROR(errno)));
 
 return 0;
 }
-- 
2.7.0

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

[FFmpeg-devel] [PATCH] lavf/avi: pull stream durations from index, when available

2016-01-11 Thread Rodger Combs 
This fixes files that have an incorrect nb_frames but a valid index
---
 libavformat/avidec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index 3859810..0b14860 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -1602,6 +1602,7 @@ static int avi_read_idx1(AVFormatContext *s, int size)
 ast->cum_len += get_duration(ast, len);
 last_pos  = pos;
 anykey   |= flags_INDEX;
+st->duration  = ast->cum_len;
 }
 if (!anykey) {
 for (index = 0; index < s->nb_streams; index++) {
-- 
2.6.4

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

[FFmpeg-devel] [PATCH] diracdec: fix idwt_stride calculation in bytes

2016-01-11 Thread Andreas Cadhalpun 
The transformation to bytes must happen after alignment to get the same
resulting pointers as before.

This fixes segmentation faults in the assembler code.

The regression was introduced in commit 9553689.

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

diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c
index 486c1b3..9d985351 100644
--- a/libavcodec/diracdec.c
+++ b/libavcodec/diracdec.c
@@ -941,7 +941,7 @@ static void init_planes(DiracContext *s)
 p->height  = s->seq.height >> (i ? s->chroma_y_shift : 0);
 p->idwt_width  = w = CALC_PADDING(p->width , s->wavelet_depth);
 p->idwt_height = h = CALC_PADDING(p->height, s->wavelet_depth);
-p->idwt_stride = FFALIGN(p->idwt_width << (1 + s->pshift), 8);
+p->idwt_stride = FFALIGN(p->idwt_width, 8) << (1 + s->pshift);
 
 for (level = s->wavelet_depth-1; level >= 0; level--) {
 w = w>>1;
-- 
2.6.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libvpx: Support setting color range for vp9.

2016-01-11 Thread Sasi Inguva 
Thanks

On Sat, Jan 9, 2016 at 7:53 AM, James Almer  wrote:

> On 1/9/2016 11:43 AM, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Fri, Jan 8, 2016 at 10:12 PM, Sasi Inguva  wrote:
> >
> >> Pass through color range to vp9 encoder. Parse color range in
> libvpxdec.c.
> >>
> >> Signed-off-by: Sasi Inguva 
> >> ---
> >>  libavcodec/libvpxdec.c |  6 ++
> >>  libavcodec/libvpxenc.c | 26 ++
> >>  2 files changed, 32 insertions(+)
> >>
> >> diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
> >> index 698c546..de72be9 100644
> >> --- a/libavcodec/libvpxdec.c
> >> +++ b/libavcodec/libvpxdec.c
> >> @@ -69,6 +69,12 @@ static int set_pix_fmt(AVCodecContext *avctx, struct
> >> vpx_image *img)
> >>  AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED,
> >> AVCOL_SPC_RGB,
> >>  };
> >>  avctx->colorspace = colorspaces[img->cs];
> >> +#if VPX_IMAGE_ABI_VERSION >= 4
> >> +static const enum AVColorRange color_ranges[] = {
> >> +AVCOL_RANGE_MPEG, AVCOL_RANGE_JPEG
> >> +};
> >> +avctx->color_range = color_ranges[img->range];
> >> +#endif
> >>  #endif
> >>  if (avctx->codec_id == AV_CODEC_ID_VP8 && img->fmt !=
> >> VPX_IMG_FMT_I420)
> >>  return AVERROR_INVALIDDATA;
> >> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> >> index 9cf32bf..ef531d5 100644
> >> --- a/libavcodec/libvpxenc.c
> >> +++ b/libavcodec/libvpxenc.c
> >> @@ -125,6 +125,9 @@ static const char *const ctlidstr[] = {
> >>  #if VPX_ENCODER_ABI_VERSION > 8
> >>  [VP9E_SET_COLOR_SPACE] = "VP9E_SET_COLOR_SPACE",
> >>  #endif
> >> +#if VPX_ENCODER_ABI_VERSION >= 11
> >> +[VP9E_SET_COLOR_RANGE] = "VP9E_SET_COLOR_RANGE",
> >> +#endif
> >>  #endif
> >>  };
> >>
> >> @@ -368,6 +371,26 @@ static void set_colorspace(AVCodecContext *avctx)
> >>  codecctl_int(avctx, VP9E_SET_COLOR_SPACE, vpx_cs);
> >>  }
> >>  #endif
> >> +
> >> +#if VPX_ENCODER_ABI_VERSION >= 11
> >> +static void set_color_range(AVCodecContext *avctx)
> >> +{
> >> +enum vpx_color_range vpx_cr;
> >> +switch (avctx->color_range) {
> >> +case AVCOL_RANGE_UNSPECIFIED:
> >> +case AVCOL_RANGE_MPEG:
> >> +vpx_cr = VPX_CR_STUDIO_RANGE; break;
> >> +case AVCOL_RANGE_JPEG:
> >> +vpx_cr = VPX_CR_FULL_RANGE; break;
> >>
> >
> > Patch itself is good, but can you please put the break on a newline? I
> > don't think we ever put break on the same line as the statement unless
> it's
> > on the same line as the "case" also.
> >
> > (Whoever commits this patch can also do it for you.)
>
> Pushed. You could have done it yourself, though :p
>
> >
> > Thanks,
> > Ronald
> > ___
> > 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
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavc/x264: Improve level setting

2016-01-11 Thread Carl Eugen Hoyos 
Hi!

I guess that attached patch fixes the additional issue in ticket #3307.

Please comment, Carl Eugen
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 88406a3..c1e52a1 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -559,6 +559,8 @@ static av_cold int X264_init(AVCodecContext *avctx)
 
 if (!strcmp(x4->level, "1b")) {
 level_id = 9;
+} else if (atoi(x4->level) > 9) {
+level_id = atoi(x4->level);
 } else if (strlen(x4->level) <= 3){
 level_id = av_strtod(x4->level, ) * 10 + 0.5;
 if (*tail)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] lavc/srtdec: fix rounding errors in end times

2016-01-11 Thread Rodger Combs 
---
 libavcodec/srtdec.c  |  4 +++
 tests/ref/fate/sub-textenc   | 66 ++--
 tests/ref/fate/sub-webvttenc | 66 ++--
 3 files changed, 70 insertions(+), 66 deletions(-)

diff --git a/libavcodec/srtdec.c b/libavcodec/srtdec.c
index 542dd35..285ca7b 100644
--- a/libavcodec/srtdec.c
+++ b/libavcodec/srtdec.c
@@ -81,6 +81,10 @@ static int srt_decode_frame(AVCodecContext *avctx,
 avctx->time_base,
 (AVRational){1,100});
 
+sub->end_display_time = av_rescale_q(avpkt->duration,
+ avctx->pkt_timebase,
+ (AVRational){1,1000});
+
 srt_to_ass(avctx, , avpkt->data, x1, y1, x2, y2);
 ret = ff_ass_add_rect_bprint(sub, , ts_start, ts_end-ts_start);
 av_bprint_finalize(, NULL);
diff --git a/tests/ref/fate/sub-textenc b/tests/ref/fate/sub-textenc
index cb0db7f..f7d82ce 100644
--- a/tests/ref/fate/sub-textenc
+++ b/tests/ref/fate/sub-textenc
@@ -16,13 +16,13 @@ If you see this with the normal font, the player don't 
(fully) support font face
 Hidden
 
 4
-00:00:04,501 --> 00:00:07,501
+00:00:04,501 --> 00:00:07,500
 This text should be small
 This text should be normal
 This text should be big
 
 5
-00:00:07,501 --> 00:00:11,501
+00:00:07,501 --> 00:00:11,500
 This should be an E with an accent: È
 日本語
 This text should be bold, italics and underline
@@ -31,7 +31,7 @@ This text should be small and red
 This text should be big and brown
 
 6
-00:00:11,501 --> 00:00:14,501
+00:00:11,501 --> 00:00:14,500
 This line should be bold
 This line should be italics
 This line should be underline
@@ -40,7 +40,7 @@ Both lines
 should be underline
 
 7
-00:00:14,501 --> 00:00:17,501
+00:00:14,501 --> 00:00:17,500
 >
 It would be a good thing to
 hide invalid html tags that are closed and show the text in them
@@ -49,7 +49,7 @@ Show not opened tags
 <
 
 8
-00:00:17,501 --> 00:00:20,501
+00:00:17,501 --> 00:00:20,500
 and also
 hide invalid html tags with parameters that are closed and show the text in 
them
 but show un-closed invalid html tags
@@ -57,66 +57,66 @@ This text should be showed underlined without problems 
also: 2<3,5>1,4<6
 This shouldn't be underlined
 
 9
-00:00:20,501 --> 00:00:21,501
+00:00:20,501 --> 00:00:21,500
 This text should be in the normal position...
 
 10
-00:00:21,501 --> 00:00:22,501
+00:00:21,501 --> 00:00:22,500
 This text should NOT be in the normal position
 
 11
-00:00:22,501 --> 00:00:24,501
+00:00:22,501 --> 00:00:24,500
 Implementation is the same of the ASS tag
 This text should be at the
 top and horizontally centered
 
 12
-00:00:22,501 --> 00:00:24,501
+00:00:22,501 --> 00:00:24,500
 This text should be at the
 middle and horizontally centered
 
 13
-00:00:22,501 --> 00:00:24,501
+00:00:22,501 --> 00:00:24,500
 This text should be at the
 bottom and horizontally centered
 
 14
-00:00:24,501 --> 00:00:26,501
+00:00:24,501 --> 00:00:26,500
 This text should be at the
 top and horizontally at the left
 
 15
-00:00:24,501 --> 00:00:26,501
+00:00:24,501 --> 00:00:26,500
 This text should be at the
 middle and horizontally at the left
 (The second position must be ignored)
 
 16
-00:00:24,501 --> 00:00:26,501
+00:00:24,501 --> 00:00:26,500
 This text should be at the
 bottom and horizontally at the left
 
 17
-00:00:26,501 --> 00:00:28,501
+00:00:26,501 --> 00:00:28,500
 This text should be at the
 top and horizontally at the right
 
 18
-00:00:26,501 --> 00:00:28,501
+00:00:26,501 --> 00:00:28,500
 This text should be at the
 middle and horizontally at the right
 
 19
-00:00:26,501 --> 00:00:28,501
+00:00:26,501 --> 00:00:28,500
 This text should be at the
 bottom and horizontally at the right
 
 20
-00:00:28,501 --> 00:00:31,501
+00:00:28,501 --> 00:00:31,500
 This could be the most difficult thing to implement
 
 21
-00:00:31,501 --> 00:00:50,501
+00:00:31,501 --> 00:00:50,500
 First text
 
 22
@@ -124,38 +124,38 @@ First text
 Second, it shouldn't overlap first
 
 23
-00:00:35,501 --> 00:00:37,501
+00:00:35,501 --> 00:00:37,500
 Third, it should replace second
 
 24
-00:00:36,501 --> 00:00:50,501
+00:00:36,501 --> 00:00:50,500
 Fourth, it shouldn't overlap first and third
 
 25
-00:00:40,501 --> 00:00:45,501
+00:00:40,501 --> 00:00:45,500
 Fifth, it should replace third
 
 26
-00:00:45,501 --> 00:00:50,501
+00:00:45,501 --> 00:00:50,500
 Sixth, it shouldn't be
 showed overlapped
 
 27
-00:00:50,501 --> 00:00:52,501
+00:00:50,501 --> 00:00:52,500
 TEXT 1 (bottom)
 
 28
-00:00:50,501 --> 00:00:52,501
+00:00:50,501 --> 00:00:52,500
 text 2
 
 29
-00:00:52,501 --> 00:00:54,501
+00:00:52,501 --> 00:00:54,500
 Hide these tags:
 also hide these tags:
 but show this: {normal text}
 
 30
-00:00:54,501 --> 00:01:00,501
+00:00:54,501 --> 00:01:00,500
 
 \ N is a forced line break
 \ h is a hard space
@@ -163,21 +163,21 @@ Normal spaces at the start and at the end of the

[FFmpeg-devel] [PATCH 1/2] lavc/ass: don't reset end_display_time if it's already set

2016-01-11 Thread Rodger Combs 
---
 libavcodec/ass.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/ass.c b/libavcodec/ass.c
index 336c308..797b1c1 100644
--- a/libavcodec/ass.c
+++ b/libavcodec/ass.c
@@ -159,7 +159,8 @@ int ff_ass_add_rect(AVSubtitle *sub, const char *dialog,
 if (!rects)
 goto errnomem;
 sub->rects = rects;
-sub->end_display_time = FFMAX(sub->end_display_time, 10 * duration);
+if (!sub->end_display_time)
+sub->end_display_time = 10 * duration;
 rects[sub->num_rects]   = av_mallocz(sizeof(*rects[0]));
 if (!rects[sub->num_rects])
 goto errnomem;
-- 
2.6.4

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

Re: [FFmpeg-devel] [PATCH] qtpalette: make the color_* variables unsigned again

2016-01-11 Thread Mats Peterson 

On 01/12/2016 03:32 AM, Mats Peterson wrote:

Valid question. Of course there's no problem using uint32_t, but in the
original code the variables are unsigned int... ask Andreas ;)


Well, I'm to blame as well, since I have been using uint32_t for the a, 
r, g and b variables rather than unsigned int, since I thought they 
matched the uint32_t palette[] array better. Is that sensible enough?


Mats

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

Re: [FFmpeg-devel] [PATCH] qtpalette: make the color_* variables unsigned again

2016-01-11 Thread Ganesh Ajjanagadde 
On Mon, Jan 11, 2016 at 9:35 PM, Mats Peterson
 wrote:
> On 01/12/2016 03:32 AM, Mats Peterson wrote:
>>
>> On 01/12/2016 03:26 AM, Ronald S. Bultje wrote:
>>>
>>> Why are we using stdint types for non-vector data here? Our custom has
>>> always been to used sized (stdint-style) data only for vector data
>>> (arrays
>>> etc.), and use native-sized types (e.g. unsigned, int, whatever) for
>>> scalar
>>> values. Why are we making exceptions here?

That is not true; for instance while parsing headers, see avio_rl64.
In fact, really avio_rb32 and the like should return a uint32_t
instead of an unsigned int IMHO. There are of course a variety of
opinions on the subject of stdint types vs native-sized types; and I
doubt there is universal consensus on how liberally to use the stdint
sized types among FFmpeg developers.

>>>
>>> Ronald
>>
>>
>> Valid question. Of course there's no problem using uint32_t, but in the
>> original code the variables are unsigned int... ask Andreas ;)
>>
>> Mats
[...]
> You're free to make another patch, or if perhaps I should do it.

If something is inherently 32 bits (e.g obtained by reading 4 bytes),
then please don't make such a patch.
Seems to be the case here, and so I would nack such a patch:
color_start is obtained by an avio_rb32, keeping as uint32_t is
cleaner.

>
> Mats
>
> --
> Mats Peterson
> http://matsp888.no-ip.org/~mats/
>
> ___
> 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] qtpalette: make the color_* variables unsigned again

2016-01-11 Thread Mats Peterson 

On 01/12/2016 06:28 AM, Mats Peterson wrote:

Exactly, I actually thought of that myself. And I like the stdint
variables because they eliminate guesswork. That has always been a
problem with the "standard" types in C.


The stdint TYPES, of course.

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

[FFmpeg-devel] [PATCH 03/13] lavfi/vf_lut3d: check fclose return value

2016-01-11 Thread Ganesh Ajjanagadde 
Maybe theoretical; since the file is opened in read-only mode.
Nevertheless, it is a good idea to check the return value.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/vf_lut3d.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_lut3d.c b/libavfilter/vf_lut3d.c
index 2b8e027..45477d4 100644
--- a/libavfilter/vf_lut3d.c
+++ b/libavfilter/vf_lut3d.c
@@ -602,7 +602,8 @@ static av_cold int lut3d_init(AVFilterContext *ctx)
 }
 
 end:
-fclose(f);
+if(fclose(f))
+av_log(ctx, AV_LOG_WARNING, "%s: %s\n", lut3d->file, 
av_err2str(AVERROR(errno)));
 return ret;
 }
 
-- 
2.7.0

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

[FFmpeg-devel] [PATCH 00/13] check all fclose usage

2016-01-11 Thread Ganesh Ajjanagadde 
Some preliminary work has already been done on fclose checking. This completes
the work, modulo a few exceptions:
1. Things under an ifdef DEBUG or similar: these are not important.
2. Tests/tools code: also not important.
3. Likely not important, and beyond my knowledge: see lavu/arm/cpu.c. fclose is
done on read-only files, see get_cpuinfo, get_hwcap. Thus,
the importance of checking the return value is relatively little. Furthermore, 
/proc/cpuinfo is a method
that only works on Linux, on BSD's sysctl or other method must be used:
https://lists.freebsd.org/pipermail/freebsd-questions/2006-March/117134.html.
Thus, a proper, portable solution may bypass fclose altogether.

Note that the choice of error level, e.g WARNING vs ERROR is subjective. 
Generally,
for the read only case, WARNING is used. In no case is the error propagated out
of the function; cursory glances reveal that it is usually not a critical error.
I may be entirely wrong in some cases.

In the case of ffserver, some nearby improvements were done. Most serious was 
the
build failure on non Linux machines.

Ganesh Ajjanagadde (13):
  lavc/dvdsubdec: check fclose return value
  lavfi/vf_deshake: check fclose return value
  lavfi/vf_lut3d: check fclose return value
  lavfi/vf_paletteuse: check fclose return value
  lavfi/vf_psnr: check fclose return value
  lavfi/vf_ssim: check fclose return value
  lavfi/vf_vidstabdetect: check fclose return value
  lavfi/vf_vidstabtransform: check fclose return value
  ffserver: check fclose return value
  ffserver: fix build failure on non linux machines
  ffserver: log diagnostics for popen return failure
  ffserver: correct indentation
  ffserver_config: check fclose return value

 ffserver.c| 48 +++
 ffserver_config.c | 10 ++--
 libavcodec/dvdsubdec.c|  3 ++-
 libavfilter/vf_deshake.c  |  5 +++-
 libavfilter/vf_lut3d.c|  3 ++-
 libavfilter/vf_paletteuse.c   |  8 ++-
 libavfilter/vf_psnr.c |  5 +++-
 libavfilter/vf_ssim.c |  5 +++-
 libavfilter/vf_vidstabdetect.c|  5 +++-
 libavfilter/vf_vidstabtransform.c |  4 +++-
 10 files changed, 72 insertions(+), 24 deletions(-)

-- 
2.7.0

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

Re: [FFmpeg-devel] [PATCH] qtpalette: make the color_* variables unsigned again

2016-01-11 Thread Mats Peterson 

On 01/12/2016 05:48 AM, Ganesh Ajjanagadde wrote:

You're free to make another patch, or if perhaps I should do it.


If something is inherently 32 bits (e.g obtained by reading 4 bytes),
then please don't make such a patch.
Seems to be the case here, and so I would nack such a patch:
color_start is obtained by an avio_rb32, keeping as uint32_t is
cleaner.

No we'll skip it in my book. I don't see reason enough to change it. 
Thanks for your input, Ganesh.


Mats

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

[FFmpeg-devel] [PATCH] libvpxdec: fix 'ISO C90 forbids mixed declarations and code' warning

2016-01-11 Thread James Zern 
since:
cbcc88c libvpx: Support setting color range for vp9.

Signed-off-by: James Zern 
---
 libavcodec/libvpxdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
index de72be9..b51bfa2 100644
--- a/libavcodec/libvpxdec.c
+++ b/libavcodec/libvpxdec.c
@@ -68,13 +68,13 @@ static int set_pix_fmt(AVCodecContext *avctx, struct 
vpx_image *img)
 AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG, AVCOL_SPC_BT709, 
AVCOL_SPC_SMPTE170M,
 AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED, 
AVCOL_SPC_RGB,
 };
-avctx->colorspace = colorspaces[img->cs];
 #if VPX_IMAGE_ABI_VERSION >= 4
 static const enum AVColorRange color_ranges[] = {
 AVCOL_RANGE_MPEG, AVCOL_RANGE_JPEG
 };
 avctx->color_range = color_ranges[img->range];
 #endif
+avctx->colorspace = colorspaces[img->cs];
 #endif
 if (avctx->codec_id == AV_CODEC_ID_VP8 && img->fmt != VPX_IMG_FMT_I420)
 return AVERROR_INVALIDDATA;
-- 
2.6.0.rc2.230.g3dd15c0

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

Re: [FFmpeg-devel] [PATCH 00/13] check all fclose usage

2016-01-11 Thread Ganesh Ajjanagadde 
On Mon, Jan 11, 2016 at 11:25 PM, Ganesh Ajjanagadde
 wrote:
[...]
>
> In the case of ffserver, some nearby improvements were done. Most serious was 
> the
> build failure on non Linux machines.

This was a completely bogus one; an error made while
rebasing/squashing stuff. Sorry for the noise. Amended locally (squash
the first 2 ffserver patches together, i.e 9 and 10).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] qtpalette: make the color_* variables unsigned again

2016-01-11 Thread Mats Peterson 

On 01/12/2016 03:26 AM, Ronald S. Bultje wrote:

Why are we using stdint types for non-vector data here? Our custom has
always been to used sized (stdint-style) data only for vector data (arrays
etc.), and use native-sized types (e.g. unsigned, int, whatever) for scalar
values. Why are we making exceptions here?

Ronald


Valid question. Of course there's no problem using uint32_t, but in the 
original code the variables are unsigned int... ask Andreas ;)


Mats

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

[FFmpeg-devel] [PATCH 12/13] ffserver: correct indentation

2016-01-11 Thread Ganesh Ajjanagadde 
Signed-off-by: Ganesh Ajjanagadde 
---
 ffserver.c | 44 ++--
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/ffserver.c b/ffserver.c
index 4cd5834..c68894f 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -2072,31 +2072,31 @@ static void compute_status(HTTPContext *c)
  "ps -o \"%%cpu,cputime\" --no-headers %"PRId64"",
  (int64_t) stream->pid);
 
- /* reset errno before trying popen */
- errno = 0;
- pid_stat = popen(ps_cmd, "r");
- if (pid_stat) {
- char cpuperc[10];
- char cpuused[64];
-
- if (fscanf(pid_stat, "%9s %63s", cpuperc, cpuused) == 2) {
- avio_printf(pb, "Currently using %s%% of the cpu. "
- "Total time used %s.\n",
- cpuperc, cpuused);
- }
- if (fclose(pid_stat))
+/* reset errno before trying popen */
+errno = 0;
+pid_stat = popen(ps_cmd, "r");
+if (pid_stat) {
+char cpuperc[10];
+char cpuused[64];
+
+if (fscanf(pid_stat, "%9s %63s", cpuperc, cpuused) == 2) {
+avio_printf(pb, "Currently using %s%% of the cpu. "
+"Total time used %s.\n",
+cpuperc, cpuused);
+}
+if (fclose(pid_stat))
 av_log(NULL, AV_LOG_WARNING,
"Unable to close pid stat '%s': %s\n",
ps_cmd, av_err2str(AVERROR(errno)));
- }
- else if (errno)
- av_log(NULL, AV_LOG_WARNING,
-"Unable to open pid stat '%s': %s\n",
-ps_cmd, av_err2str(AVERROR(errno)));
- else
- av_log(NULL, AV_LOG_WARNING,
-"Unable to open pid stat '%s': %s\n",
-ps_cmd, av_err2str(AVERROR(ENOMEM)));
+}
+else if (errno)
+av_log(NULL, AV_LOG_WARNING,
+   "Unable to open pid stat '%s': %s\n",
+   ps_cmd, av_err2str(AVERROR(errno)));
+else
+av_log(NULL, AV_LOG_WARNING,
+   "Unable to open pid stat '%s': %s\n",
+   ps_cmd, av_err2str(AVERROR(ENOMEM)));
 
 }
 #endif
-- 
2.7.0

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

Re: [FFmpeg-devel] [PATCH] qtpalette: make the color_* variables unsigned again

2016-01-11 Thread Ganesh Ajjanagadde 
On Mon, Jan 11, 2016 at 9:48 PM, Mats Peterson
 wrote:
> On 01/12/2016 03:32 AM, Mats Peterson wrote:
>>
>> Valid question. Of course there's no problem using uint32_t, but in the
>> original code the variables are unsigned int... ask Andreas ;)
>
>
> Well, I'm to blame as well, since I have been using uint32_t for the a, r, g
> and b variables rather than unsigned int, since I thought they matched the
> uint32_t palette[] array better. Is that sensible enough?

Don't blame yourself; it is in fact a regression IMHO to change to
unsigned int, albeit a theoretical one. C only guarantees 16 bits for
int/unsigned int, you shift by 24 making it undefined behavior on 16
bit platforms. This is theoretical since POSIX guarantees 32 bits
here; FFmpeg does not support such 16 bit (likely embedded) platforms
anyway. But why change to something worse for no gain ;)?

>
>
> Mats
>
> ___
> 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] rtmpdh: Initialize gcrypt before using it

2016-01-11 Thread Timothy Gu 
On Sun, Jan 10, 2016 at 10:04:34PM +, Ricardo Constantino wrote:

> Either disabling or init'ing secure memory is required after the use
> of gcry_check_version. From a look at the functions rtmpdh uses, I
> noticed none require the use of secure memory, so we disable it [1][2].
> 
> This resolves some errors returned by rtmpdh code with uninitialized
> gcrypt, especifically:
> Fatal: failed to create the RNG lock: Invalid argument
> FATAL: failed to acquire the FSM lock in libgrypt: Invalid argument
> 
> Version "1.5.4" was arbitrarily chosen. An older version probably works
> as well, but I couldn't compile older versions to test on my machine.
> 
> [1]
> https://gnupg.org/documentation/manuals/gcrypt/Initializing-the-library.html
> [2]
> https://www.gnupg.org/documentation/manuals/gcrypt/Controlling-the-library.html

Sorry for being late to the party, but [1] above says:

> It is important that these initialization steps are not done by a
> library but by the actual application. A library using Libgcrypt might
> want to check for finished initialization

Are you sure you want to initialize libgcrypt unconditionally as you are
doing here?

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

Re: [FFmpeg-devel] [PATCH] qtpalette: make the color_* variables unsigned again

2016-01-11 Thread Mats Peterson 

On 01/12/2016 05:51 AM, Ganesh Ajjanagadde wrote:

On Mon, Jan 11, 2016 at 9:48 PM, Mats Peterson
 wrote:

On 01/12/2016 03:32 AM, Mats Peterson wrote:

Don't blame yourself; it is in fact a regression IMHO to change to
unsigned int, albeit a theoretical one. C only guarantees 16 bits for
int/unsigned int, you shift by 24 making it undefined behavior on 16
bit platforms. This is theoretical since POSIX guarantees 32 bits
here; FFmpeg does not support such 16 bit (likely embedded) platforms
anyway. But why change to something worse for no gain ;)?




Exactly, I actually thought of that myself. And I like the stdint 
variables because they eliminate guesswork. That has always been a 
problem with the "standard" types in C.


Mats

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

Re: [FFmpeg-devel] [PATCH] qtpalette: make the color_* variables unsigned again

2016-01-11 Thread Mats Peterson 

On 01/12/2016 03:32 AM, Mats Peterson wrote:

On 01/12/2016 03:26 AM, Ronald S. Bultje wrote:

Why are we using stdint types for non-vector data here? Our custom has
always been to used sized (stdint-style) data only for vector data
(arrays
etc.), and use native-sized types (e.g. unsigned, int, whatever) for
scalar
values. Why are we making exceptions here?

Ronald


Valid question. Of course there's no problem using uint32_t, but in the
original code the variables are unsigned int... ask Andreas ;)

Mats

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


You're free to make another patch, or if perhaps I should do it.

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 11/13] ffserver: log diagnostics for popen return failure

2016-01-11 Thread Ganesh Ajjanagadde 
Some errno hackery needed since errno is not set for when popen fails
due to out of memory; man popen.

Signed-off-by: Ganesh Ajjanagadde 
---
 ffserver.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/ffserver.c b/ffserver.c
index 51928f3..4cd5834 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -2072,6 +2072,8 @@ static void compute_status(HTTPContext *c)
  "ps -o \"%%cpu,cputime\" --no-headers %"PRId64"",
  (int64_t) stream->pid);
 
+ /* reset errno before trying popen */
+ errno = 0;
  pid_stat = popen(ps_cmd, "r");
  if (pid_stat) {
  char cpuperc[10];
@@ -2087,6 +2089,15 @@ static void compute_status(HTTPContext *c)
"Unable to close pid stat '%s': %s\n",
ps_cmd, av_err2str(AVERROR(errno)));
  }
+ else if (errno)
+ av_log(NULL, AV_LOG_WARNING,
+"Unable to open pid stat '%s': %s\n",
+ps_cmd, av_err2str(AVERROR(errno)));
+ else
+ av_log(NULL, AV_LOG_WARNING,
+"Unable to open pid stat '%s': %s\n",
+ps_cmd, av_err2str(AVERROR(ENOMEM)));
+
 }
 #endif
 
-- 
2.7.0

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

[FFmpeg-devel] [PATCH 13/13] ffserver_config: check fclose return value

2016-01-11 Thread Ganesh Ajjanagadde 
Maybe theoretical; since all files here are opened in read only mode.
Nevertheless, it is a good idea to check the return value.

Signed-off-by: Ganesh Ajjanagadde 
---
 ffserver_config.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/ffserver_config.c b/ffserver_config.c
index 411db53..b68f97c 100644
--- a/ffserver_config.c
+++ b/ffserver_config.c
@@ -403,7 +403,10 @@ static int ffserver_opt_preset(const char *arg, int type, 
FFServerConfig *config
 break;
 }
 
-fclose(f);
+if (fclose(f))
+av_log(NULL, AV_LOG_WARNING,
+   "Unable to close preset file '%s': %s\n",
+   filename, av_err2str(AVERROR(errno)));
 
 return ret;
 }
@@ -1281,7 +1284,10 @@ int ffserver_parse_ffconfig(const char *filename, 
FFServerConfig *config)
 ERROR("Missing closing  tag\n",
   stream ? "Stream" : (feed ? "Feed" : "Redirect"));
 
-fclose(f);
+if (fclose(f))
+av_log(NULL, AV_LOG_WARNING,
+   "Unable to close config file '%s': %s\n",
+   filename, av_err2str(AVERROR(errno)));
 if (ret < 0)
 return ret;
 if (config->errors)
-- 
2.7.0

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

[FFmpeg-devel] [PATCH 09/13] ffserver: check fclose return value

2016-01-11 Thread Ganesh Ajjanagadde 
Maybe theoretical; since all files here are opened in read only mode.
Nevertheless, it is a good idea to check the return value.

Signed-off-by: Ganesh Ajjanagadde 
---
 ffserver.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/ffserver.c b/ffserver.c
index bc7dbee..720d164 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -1310,7 +1310,10 @@ static FFServerIPAddressACL* 
parse_dynamic_acl(FFServerStream *stream,
 
 acl = av_mallocz(sizeof(FFServerIPAddressACL));
 if (!acl) {
-fclose(f);
+if (fclose(f))
+av_log(NULL, AV_LOG_WARNING,
+   "Unable to close acl file '%s': %s\n",
+   stream->dynamic_acl, av_err2str(AVERROR(errno)));
 return NULL;
 }
 
@@ -1328,7 +1331,10 @@ static FFServerIPAddressACL* 
parse_dynamic_acl(FFServerStream *stream,
 ffserver_parse_acl_row(NULL, NULL, acl, p, stream->dynamic_acl,
line_num);
 }
-fclose(f);
+if (fclose(f))
+av_log(NULL, AV_LOG_WARNING,
+   "Unable to close acl file '%s': %s\n",
+   stream->dynamic_acl, av_err2str(AVERROR(errno)));
 return acl;
 }
 
@@ -2076,8 +2082,10 @@ static void compute_status(HTTPContext *c)
  "Total time used %s.\n",
  cpuperc, cpuused);
  }
- fclose(pid_stat);
- }
+ if (fclose(pid_stat))
+av_log(NULL, AV_LOG_WARNING,
+   "Unable to close pid stat '%s': %s\n",
+   ps_cmd, av_err2str(AVERROR(errno)));
 }
 #endif
 
-- 
2.7.0

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

[FFmpeg-devel] [PATCH 01/13] lavc/dvdsubdec: check fclose return value

2016-01-11 Thread Ganesh Ajjanagadde 
Maybe theoretical; since the file is opened in read-only mode.
Nevertheless, it is a good idea to check the return value.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/dvdsubdec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/dvdsubdec.c b/libavcodec/dvdsubdec.c
index 19f25f0..a5665c8 100644
--- a/libavcodec/dvdsubdec.c
+++ b/libavcodec/dvdsubdec.c
@@ -686,7 +686,8 @@ static int parse_ifo_palette(DVDSubContext *ctx, char *p)
 ret = AVERROR_INVALIDDATA;
 }
 end:
-fclose(ifo);
+if (fclose(ifo))
+av_log(ctx, AV_LOG_WARNING, "Unable to close IFO file \"%s\": %s\n", 
p, av_err2str(AVERROR(errno)));
 return ret;
 }
 
-- 
2.7.0

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

[FFmpeg-devel] [PATCH 05/13] lavfi/vf_psnr: check fclose return value

2016-01-11 Thread Ganesh Ajjanagadde 
Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/vf_psnr.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_psnr.c b/libavfilter/vf_psnr.c
index bce5c51..b6e7f06 100644
--- a/libavfilter/vf_psnr.c
+++ b/libavfilter/vf_psnr.c
@@ -339,7 +339,10 @@ static av_cold void uninit(AVFilterContext *ctx)
 ff_dualinput_uninit(>dinput);
 
 if (s->stats_file && s->stats_file != stdout)
-fclose(s->stats_file);
+if (fclose(s->stats_file))
+av_log(NULL, AV_LOG_ERROR,
+   "Unable to close file '%s', loss of information possible: 
%s\n",
+   s->stats_file_str, av_err2str(AVERROR(errno)));
 }
 
 static const AVFilterPad psnr_inputs[] = {
-- 
2.7.0

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

[FFmpeg-devel] [PATCH 02/13] lavfi/vf_deshake: check fclose return value

2016-01-11 Thread Ganesh Ajjanagadde 
Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/vf_deshake.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_deshake.c b/libavfilter/vf_deshake.c
index e7ece44..a89506b 100644
--- a/libavfilter/vf_deshake.c
+++ b/libavfilter/vf_deshake.c
@@ -423,7 +423,10 @@ static av_cold void uninit(AVFilterContext *ctx)
 av_freep(>angles);
 deshake->angles_size = 0;
 if (deshake->fp)
-fclose(deshake->fp);
+if (fclose(deshake->fp))
+av_log(ctx, AV_LOG_WARNING,
+   "Unable to close motion search log \"%s\": %s\n",
+   deshake->filename, av_err2str(AVERROR(errno)));
 }
 
 static int filter_frame(AVFilterLink *link, AVFrame *in)
-- 
2.7.0

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

[FFmpeg-devel] [PATCH 06/13] lavfi/vf_ssim: check fclose return value

2016-01-11 Thread Ganesh Ajjanagadde 
Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/vf_ssim.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c
index 7c43e98..1050b68 100644
--- a/libavfilter/vf_ssim.c
+++ b/libavfilter/vf_ssim.c
@@ -360,7 +360,10 @@ static av_cold void uninit(AVFilterContext *ctx)
 ff_dualinput_uninit(>dinput);
 
 if (s->stats_file && s->stats_file != stdout)
-fclose(s->stats_file);
+if (fclose(s->stats_file))
+av_log(NULL, AV_LOG_ERROR,
+   "Unable to close file '%s', loss of information possible: 
%s\n",
+   s->stats_file_str, av_err2str(AVERROR(errno)));
 
 av_freep(>temp);
 }
-- 
2.7.0

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

[FFmpeg-devel] [PATCH 07/13] lavfi/vf_vidstabdetect: check fclose return value

2016-01-11 Thread Ganesh Ajjanagadde 
Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/vf_vidstabdetect.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_vidstabdetect.c b/libavfilter/vf_vidstabdetect.c
index 4742949..a91968a 100644
--- a/libavfilter/vf_vidstabdetect.c
+++ b/libavfilter/vf_vidstabdetect.c
@@ -75,7 +75,10 @@ static av_cold void uninit(AVFilterContext *ctx)
 VSMotionDetect *md = &(s->md);
 
 if (s->f) {
-fclose(s->f);
+if (fclose(s->f))
+av_log(ctx, AV_LOG_ERROR,
+   "Unable to close transform file, loss of information 
possible: %s\n",
+   av_err2str(AVERROR(errno)));
 s->f = NULL;
 }
 
-- 
2.7.0

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

[FFmpeg-devel] [PATCH 04/13] lavfi/vf_paletteuse: check fclose return value

2016-01-11 Thread Ganesh Ajjanagadde 
Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/vf_paletteuse.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_paletteuse.c b/libavfilter/vf_paletteuse.c
index 1225a66..a5449df 100644
--- a/libavfilter/vf_paletteuse.c
+++ b/libavfilter/vf_paletteuse.c
@@ -525,7 +525,13 @@ static int disp_tree(const struct color_node *node, const 
char *fname)
 av_bprintf(, "}\n");
 
 fwrite(buf.str, 1, buf.len, f);
-fclose(f);
+if (fclose(f)) {
+int ret = AVERROR(errno);
+av_log(NULL, AV_LOG_ERROR,
+   "Unable to close file '%s', loss of information possible: %s\n",
+   fname, av_err2str(AVERROR(errno)));
+return ret;
+}
 av_bprint_finalize(, NULL);
 return 0;
 }
-- 
2.7.0

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

[FFmpeg-devel] [PATCH 10/13] ffserver: fix build failure on non linux machines

2016-01-11 Thread Ganesh Ajjanagadde 
Simple test: just change to !defined(linux). No idea why this was never fixed...

Signed-off-by: Ganesh Ajjanagadde 
---
 ffserver.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ffserver.c b/ffserver.c
index 720d164..51928f3 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -2086,6 +2086,7 @@ static void compute_status(HTTPContext *c)
 av_log(NULL, AV_LOG_WARNING,
"Unable to close pid stat '%s': %s\n",
ps_cmd, av_err2str(AVERROR(errno)));
+ }
 }
 #endif
 
-- 
2.7.0

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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/ccaption_dec: implement real_time option

2016-01-11 Thread anshul . ffmpeg 
On Saturday, January 09, 2016 02:55:01 PM Aman Gupta wrote:
> From: Aman Gupta 
> 
> This new mode is useful for realtime decoding of closed captions so they
> can be display along with mpeg2 frames.
> 
> Closed caption streams contain two major types of captions:
> 
> - POPON captions, which are buffered off-screen and displayed
>   only after EOC (end of caption, aka display buffer)
> 
> - PAINTON/ROLLUP captions, which are written to the display as soon as
>   they arrive.
> 
> In a typical real-time eia608 decoder, commands like EOC (end of
> caption; display buffer), EDM (erase display memory) and EBM (erase
> buffered memory) perform their expected functions as soon as the
> commands are processed. This is implemented in the real_time branches
> added in this commit.
> 
> Before this commit, and in the !real_time branches after this commit,
> the decoder cleverly implements its own version of the decoder which is
> specifically geared towards buffered decoding. It does so by actively
> ignoring commands like EBM (erase buffered memory), and then re-using
> the non-display buffer to hold the previous caption while the new one is
> received. This is the opposite of the real-time decoder, which uses the
> non-display buffer to hold the new caption while the display buffer is
> still showing the current caption.
> 
> In addition to ignoring EBM, the buffered decoder also has custom
> implementations for EDM and EOC. An EDM (erase display memory) command
> flushes the existing contents before clearing the screen, and EOC
> similarly always flushes the active buffer (the previous subtitle)
> before flipping buffers.
> ---
>  libavcodec/ccaption_dec.c  | 85
> +- tests/fate/subtitles.mak   |
>  3 ++
>  tests/ref/fate/sub-cc-realtime | 42 +
>  3 files changed, 121 insertions(+), 9 deletions(-)
>  create mode 100644 tests/ref/fate/sub-cc-realtime
> 
> diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
> index 8bef771..8c26fcc 100644
> --- a/libavcodec/ccaption_dec.c
> +++ b/libavcodec/ccaption_dec.c
> @@ -116,6 +116,7 @@ struct Screen {
> 
>  typedef struct CCaptionSubContext {
>  AVClass *class;
> +int real_time;
>  struct Screen screen[2];
>  int active_screen;
>  uint8_t cursor_row;
> @@ -130,6 +131,8 @@ typedef struct CCaptionSubContext {
>  /* visible screen time */
>  int64_t startv_time;
>  int64_t end_time;
> +int screen_touched;
> +int64_t last_real_time;
>  char prev_cmd[2];
>  /* buffer to store pkt data */
>  AVBufferRef *pktbuf;
> @@ -180,7 +183,10 @@ static void flush_decoder(AVCodecContext *avctx)
>  ctx->cursor_color = 0;
>  ctx->active_screen = 0;
>  av_bprint_clear(>buffer);
> -ctx->buffer_changed = 0;
> +ctx->last_real_time = 0;
> +ctx->screen_touched = 0;
> +/* emit empty subtitle on seek in realtime mode */
> +ctx->buffer_changed = ctx->real_time ? 1 : 0;
>  }
> 
>  /**
> @@ -418,15 +424,33 @@ static void handle_edm(CCaptionSubContext *ctx,
> int64_t pts) {
>  struct Screen *screen = ctx->screen + ctx->active_screen;
> 
> -reap_screen(ctx, pts);
> +// In buffered mode, keep writing to screen until it is wiped.
> +// Before wiping the display, capture contents to emit subtitle.
> +if (!ctx->real_time)
> +reap_screen(ctx, pts);
> +
>  screen->row_used = 0;
> +
> +// In realtime mode, emit an empty caption so the last one doesn't
> +// stay on the screen.
> +if (ctx->real_time)
> +reap_screen(ctx, pts);
>  }
> 
>  static void handle_eoc(CCaptionSubContext *ctx, int64_t pts)
>  {
> -handle_edm(ctx,pts);
> +// In buffered mode, we wait til the *next* EOC and
> +// reap what was already on the screen since the last EOC.
> +if (!ctx->real_time)
> +handle_edm(ctx,pts);
> +
>  ctx->active_screen = !ctx->active_screen;
>  ctx->cursor_column = 0;
> +
> +// In realtime mode, we display the buffered contents (after
> +// flipping the buffer to active above) as soon as EOC arrives.
> +if (ctx->real_time)
> +reap_screen(ctx, pts);
>  }
> 
>  static void handle_delete_end_of_row(CCaptionSubContext *ctx, char hi, char
> lo) @@ -448,6 +472,9 @@ static void handle_char(CCaptionSubContext *ctx,
> char hi, char lo, int64_t pts) }
>  write_char(ctx, screen, 0);
> 
> +if (ctx->mode != CCMODE_POPON)
> +ctx->screen_touched = 1;
> +
>  /* reset prev command since character can repeat */
>  ctx->prev_cmd[0] = 0;
>  ctx->prev_cmd[1] = 0;
> @@ -497,10 +524,20 @@ static void process_cc608(CCaptionSubContext *ctx,
> int64_t pts, uint8_t hi, uint case 0x2d:
>  /* carriage return */
>  ff_dlog(ctx, "carriage return\n");
> -reap_screen(ctx, pts);
> +if (!ctx->real_time)
> +reap_screen(ctx, pts);
>  roll_up(ctx);
>

[FFmpeg-devel] [PATCH] ffmpeg: extend -benchmark_all option to show elapsed time

2016-01-11 Thread Stefano Sabatini 
The value is useful to get a raw estimate of the expected
encoding/decoding time.

Also extend option documentation.
---
 doc/ffmpeg.texi | 6 ++
 ffmpeg.c| 9 +++--
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index a38a32e..9ea48bb 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -999,6 +999,12 @@ it will usually display as 0 if not supported.
 @item -benchmark_all (@emph{global})
 Show benchmarking information during the encode.
 Shows CPU time used in various steps (audio/video encode/decode).
+
+This option shows the following information for each processing step,
+in this order: the user process time (in microseconds), the elapsed
+relative time (in microseconds), the processing step type, and the
+relative stream.
+
 @item -timelimit @var{duration} (@emph{global})
 Exit after ffmpeg has been running for @var{duration} seconds.
 @item -dump (@emph{global})
diff --git a/ffmpeg.c b/ffmpeg.c
index 86a0960..24536d1 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -129,7 +129,9 @@ static int nb_frames_dup = 0;
 static int nb_frames_drop = 0;
 static int64_t decode_error_stat[2];
 
-static int current_time;
+static int64_t current_time;
+static int64_t current_time_rel;
+
 AVIOContext *progress_avio = NULL;
 
 static uint8_t *subtitle_out;
@@ -608,6 +610,7 @@ static void update_benchmark(const char *fmt, ...)
 {
 if (do_benchmark_all) {
 int64_t t = getutime();
+int64_t t_rel = av_gettime_relative();
 va_list va;
 char buf[1024];
 
@@ -615,8 +618,10 @@ static void update_benchmark(const char *fmt, ...)
 va_start(va, fmt);
 vsnprintf(buf, sizeof(buf), fmt, va);
 va_end(va);
-av_log(NULL, AV_LOG_INFO, "bench: %8"PRIu64" %s \n", t - 
current_time, buf);
+av_log(NULL, AV_LOG_INFO, "bench: %8"PRIu64" %8"PRIu64" %s \n",
+   t - current_time, t_rel - current_time_rel, buf);
 }
+current_time_rel = t_rel;
 current_time = t;
 }
 }
-- 
1.9.1

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

Re: [FFmpeg-devel] [libav-devel] [PATCH 1/2] avcodec: Add Cineform HD Decoder

2016-01-11 Thread Vittorio Giovara 
On Sun, Jan 10, 2016 at 1:28 AM, Kieran Kunhya  wrote:
> ---
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/avcodec.h|   1 +
>  libavcodec/cfhd.c   | 565 
> 
>  libavcodec/cfhd.h   |  99 +
>  libavcodec/cfhddata.c   | 470 
>  libavcodec/codec_desc.c |   6 +
>  7 files changed, 1143 insertions(+)
>  create mode 100644 libavcodec/cfhd.c
>  create mode 100644 libavcodec/cfhd.h
>  create mode 100644 libavcodec/cfhddata.c

> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> new file mode 100644
> index 000..dc36889
> --- /dev/null
> +++ b/libavcodec/cfhd.c
> +for (i = 0; i < len; i++) {
> +if( i == 0 )
> +{
> +tmp = (11*low[0*low_stride] - 4*low[1*low_stride] + 
> low[2*low_stride] + 4) >> 3;
> +output[(2*i+0)*out_stride] = (tmp + high[0*high_stride]) >> 1;
> +tmp = ( 5*low[0*low_stride] + 4*low[1*low_stride] - 
> low[2*low_stride] + 4) >> 3;
> +output[(2*i+1)*out_stride] = (tmp - high[0*high_stride]) >> 1;
> +}
> +else if( i == len-1 )
> +{
> +tmp = ( 5*low[i*low_stride] + 4*low[(i-1)*low_stride] - 
> low[(i-2)*low_stride] + 4) >> 3;
> +output[(2*i+0)*out_stride] = (tmp + high[i*high_stride]) >> 1;
> +tmp = (11*low[i*low_stride] - 4*low[(i-1)*low_stride] + 
> low[(i-2)*low_stride] + 4) >> 3;
> +output[(2*i+1)*out_stride] = (tmp - high[i*high_stride]) >> 1;
> +}
> +else
> +{
> +tmp = (low[(i-1)*low_stride] - low[(i+1)*low_stride] + 4) >> 3;
> +output[(2*i+0)*out_stride] = (tmp + low[i*low_stride] + 
> high[i*high_stride]) >> 1;
> +tmp = (low[(i+1)*low_stride] - low[(i-1)*low_stride] + 4) >> 3;
> +output[(2*i+1)*out_stride] = (tmp + low[i*low_stride] - 
> high[i*high_stride]) >> 1;
> +}
> +}
> +}

this formatting will make Diego cry blood

> +static void horiz_filter(int16_t *output, int16_t *low, int16_t *high, int 
> width)
> +{
> +filter(output, 1, low, 1, high, 1, width);
> +}
> +
> +static void vert_filter(int16_t *output, int out_stride, int16_t *low, int 
> low_stride,
> +int16_t *high, int high_stride, int len)
> +{
> +filter(output, out_stride, low, low_stride, high, high_stride, len);
> +}

these might be very good av_always_inline candidates

> +static int cfhd_decode(AVCodecContext *avctx, void *data, int *got_frame,
> +   AVPacket *avpkt)
> +{
> +CFHDContext *s = avctx->priv_data;
> +GetByteContext gb;
> +AVFrame *pic = data;
> +int ret = 0, i, j;
> +int16_t *plane[3] = {NULL};
> +int16_t *tmp[3] = {NULL};
> +int16_t *subband[3][10] = {{0}};
> +int16_t *l_h[3][8];
> +int16_t *coeff_data;
> +
> +avcodec_get_chroma_sub_sample(avctx->pix_fmt, >chroma_x_shift, 
> >chroma_y_shift);

this is a deprecated function, looks like you have to use
av_pix_fmt_get_chroma_sub_sample and check its return value

> +for (i = 0; i < 3; i++) {
> +int width = i ? avctx->width >> s->chroma_x_shift : avctx->width;
> +int height = i ? avctx->height >> s->chroma_y_shift : avctx->height;
> +int stride = FFALIGN(width / 8, 8) * 8;
> +int w8, h8, w4, h4, w2, h2;
> +height = FFALIGN(height / 8, 2) * 8;
> +s->plane[i].width = width;
> +s->plane[i].height = height;
> +s->plane[i].stride = stride;
> +
> +w8 = FFALIGN(s->plane[i].width / 8, 8);
> +h8 = FFALIGN(s->plane[i].height / 8, 2);
> +w4 = w8 * 2;
> +h4 = h8 * 2;
> +w2 = w4 * 2;
> +h2 = h4 * 2;
> +
> +plane[i] = av_malloc(height * stride * sizeof(*plane[i]));
> +tmp[i]   = av_malloc(height * stride * sizeof(*tmp[i]));
> +if (!plane[i] || !tmp[i]) {
> +ret = AVERROR(ENOMEM);
> +goto end;
> +}
> +
> +subband[i][0] = plane[i];
> +subband[i][1] = plane[i] + 2 * w8 * h8;
> +subband[i][2] = plane[i] + 1 * w8 * h8;
> +subband[i][3] = plane[i] + 3 * w8 * h8;
> +subband[i][4] = plane[i] + 2 * w4 * h4;
> +subband[i][5] = plane[i] + 1 * w4 * h4;
> +subband[i][6] = plane[i] + 3 * w4 * h4;
> +subband[i][7] = plane[i] + 2 * w2 * h2;
> +subband[i][8] = plane[i] + 1 * w2 * h2;
> +subband[i][9] = plane[i] + 3 * w2 * h2;
> +
> +l_h[i][0] = tmp[i];
> +l_h[i][1] = tmp[i] + 2 * w8 * h8;
> +//l_h[i][2] = ll2;
> +l_h[i][3] = tmp[i];
> +l_h[i][4] = tmp[i] + 2 * w4 * h4;
> +//l_h[i][5] = ll1;
> +l_h[i][6] = tmp[i];
> +l_h[i][7] = tmp[i] + 2 * w2 * h2;
> +}
> +
> +init_frame_defaults(s);
> +
> +if ((ret = ff_get_buffer(avctx, pic, 0)) < 0)
> +return ret;

you are leaking plane and tmp in case