Re: [FFmpeg-devel] [PATCH] delete the old segment file from hls list

2014-08-30 Thread Anshul
On August 30, 2014 8:57:12 AM IST, Steven Liu lingjiujia...@gmail.com wrote:

On Aug 28, 2014, at 4:52 AM, Anshul anshul.ffm...@gmail.com wrote:

 On August 22, 2014 8:01:20 AM IST, Steven Liu
lingjiujia...@gmail.com wrote:
 repost new patch:
 
 when update the hls m3u8 list, the old file is not unlinked
 this patch can do this operation
 delete the old ts segment which not show in m3u8,
 use hls_sync_list.
 
 Signed-off-by: Steven Liu qi@chinacache.com
 ---
 libavformat/hlsenc.c |   15 ++-
 1 files changed, 14 insertions(+), 1 deletions(-)
 
 diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
 index 11f1e5b..fc1063e 100644
 --- a/libavformat/hlsenc.c
 +++ b/libavformat/hlsenc.c
 @@ -30,6 +30,10 @@
 
 #include avformat.h
 #include internal.h
 +#if HAVE_UNISTD_H
 +#include unistd.h
 +#endif
 +
 
 typedef struct HLSSegment {
char filename[1024];
 @@ -50,6 +54,7 @@ typedef struct HLSContext {
float time;// Set by a private option.
int max_nb_segments;   // Set by a private option.
int  wrap; // Set by a private option.
 +int  sync_list;
 
int64_t recording_time;
int has_video;
 @@ -96,6 +101,7 @@ static int hls_mux_init(AVFormatContext *s)
 static int hls_append_segment(HLSContext *hls, double duration)
 {
HLSSegment *en = av_malloc(sizeof(*en));
 +int ret = 0;
 
if (!en)
return AVERROR(ENOMEM);
 @@ -115,7 +121,13 @@ static int hls_append_segment(HLSContext *hls,
 double
 duration)
 if (hls-max_nb_segments  hls-nb_entries = hls-max_nb_segments)
{
en = hls-segments;
hls-segments = en-next;
 -av_free(en);
 +if (hls-sync_list) {
 +ret = unlink(en-filename);
 +if (ret  0) {
 +av_log(hls-avf, AV_LOG_WARNING, remove %s
failed\n,
 en-filename);
 +}
 +}
 +av_free(en);
} else
hls-nb_entries++;
 
 @@ -340,6 +352,7 @@ static const AVOption options[] = {
{hls_list_size, set maximum number of playlist entries,
 OFFSET(max_nb_segments),AV_OPT_TYPE_INT,{.i64 = 5}, 0,
 INT_MAX,
 E},
{hls_wrap,  set number after which the index wraps,
 OFFSET(wrap),AV_OPT_TYPE_INT,{.i64 = 0}, 0, INT_MAX, E},
{hls_base_url,  url to prepend to each playlist entry,
 OFFSET(baseurl), AV_OPT_TYPE_STRING, {.str = NULL},  0, 0,   E},
 +{hls_sync_list, remove old ts segment for sync the file with
 the
 m3u8 list,  OFFSET(sync_list),AV_OPT_TYPE_INT,{.i64 = 0},  
 
 0,
 INT_MAX, E},
{ NULL },
 };
 
 --
 1.7.1
 
 
 
 2014-08-21 16:51 GMT+08:00 Steven Liu lingjiujia...@gmail.com:
 
 Hi Stefano,
 if unistd is not available under Linux,
 it will output error message when compile the source code.
 
  [root@testrtmp ffmpeg]# make
 CC  libavformat/hlsenc.o
 libavformat/hlsenc.c: In function ‘hls_append_segment’:
 libavformat/hlsenc.c:125: error: implicit declaration of function
 ‘unlink’
 make: *** [libavformat/hlsenc.o] Error 1
 [root@testrtmp ffmpeg]#
 
 
 
 the follow is the new patch:
 
 diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
 index 11f1e5b..fc1063e 100644
 
 --- a/libavformat/hlsenc.c
 +++ b/libavformat/hlsenc.c
 @@ -30,6 +30,10 @@
 
 #include avformat.h
 #include internal.h
 +#if HAVE_UNISTD_H
 +#include unistd.h
 +#endif
 +
 
 typedef struct HLSSegment {
 char filename[1024];
 @@ -50,6 +54,7 @@ typedef struct HLSContext {
 float time;// Set by a private option.
 int max_nb_segments;   // Set by a private option.
 int  wrap; // Set by a private option.
 +int  sync_list;// Set by a private option.
 
 int64_t recording_time;
 int has_video;
 @@ -96,6 +101,7 @@ static int hls_mux_init(AVFormatContext *s)
 
 static int hls_append_segment(HLSContext *hls, double duration)
 {
 HLSSegment *en = av_malloc(sizeof(*en));
 +   int ret = 0;
 
 if (!en)
 return AVERROR(ENOMEM);
 @@ -115,7 +121,13 @@ static int hls_append_segment(HLSContext *hls,
 double
 duration)
 
 if (hls-max_nb_segments  hls-nb_entries =
 hls-max_nb_segments) {
 en = hls-segments;
 hls-segments = en-next;
 -av_free(en);
 +if (hls-sync_list) {
 +ret = unlink(en-filename);
 +if (ret  0) {
 +av_log(hls-avf, AV_LOG_WARNING, remove %s
 failed\n,
 en-filename);
 +}
 +}
 +   av_free(en);
 } else
 hls-nb_entries++;
 
 @@ -340,6 +352,7 @@ static const AVOption options[] = {
 {hls_list_size, set maximum number of playlist entries,
 OFFSET(max_nb_segments),AV_OPT_TYPE_INT,{.i64 = 5}, 0,
 INT_MAX,
 E},
 {hls_wrap,  set number after which the index wraps,
 OFFSET(wrap),AV_OPT_TYPE_INT,{.i64 = 0}, 0, INT_MAX,
E},
 {hls_base_url,  url to prepend to each playlist entry,
 OFFSET(baseurl), AV_OPT_TYPE_STRING, {.str = NULL},  0, 0,  
E},
 +{hls_sync_list, remove old ts segment for sync 

[FFmpeg-devel] [PATCH] avformat/rtpdec_qt: add cast to silence discards const qualifier from pointer target type warning

2014-08-30 Thread Michael Niedermayer
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
 libavformat/rtpdec_qt.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/rtpdec_qt.c b/libavformat/rtpdec_qt.c
index ee8a48a..58253b6 100644
--- a/libavformat/rtpdec_qt.c
+++ b/libavformat/rtpdec_qt.c
@@ -71,7 +71,7 @@ static int qt_rtp_parse_packet(AVFormatContext *s, 
PayloadContext *qt,
  * http://developer.apple.com/quicktime/icefloe/dispatch026.html
  */
 init_get_bits(gb, buf, len  3);
-ffio_init_context(pb, buf, len, 0, NULL, NULL, NULL, NULL);
+ffio_init_context(pb, (uint8_t*)buf, len, 0, NULL, NULL, NULL, NULL);
 
 if (len  4)
 return AVERROR_INVALIDDATA;
-- 
1.7.9.5

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


Re: [FFmpeg-devel] [RFC] [PATCH] proresenc_kostya: warn/reject on incorrect profile

2014-08-30 Thread Christophe Gisquet
Hi,

2014-08-24 18:56 GMT+02:00 Michael Niedermayer michae...@gmx.at:
 aggree, a PRORES_PROFILE_AUTO seems like a good idea
 with it mismatching profile and pixel format can be errors while
 by default the profile can be selected based on the pixel format

The attached patch makes it selects either  or HQ profile
depending on whether there's an alpha channel. If a profile is
selected that does not have alpha but the input data has alpha, it
warns that it will not encode it.

Best regards,
-- 
Christophe
From 0b134da9eba4f6f08422d22a1a0428f564fe8f11 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet christophe.gisq...@gmail.com
Date: Mon, 18 Aug 2014 11:27:50 +0200
Subject: [PATCH] proresenc_ks: allow auto-selecting profile

The user may not know how to select the profile, nor what he needs, in
particular to encode alpha.

Therefore, use an automatic selection as default, and warn when the
manually selected profile may cause issues.
---
 libavcodec/proresenc_kostya.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index c30c9c0..cdeb917 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -40,6 +40,7 @@
 #define MAX_PLANES 4
 
 enum {
+PRORES_PROFILE_AUTO  = -1,
 PRORES_PROFILE_PROXY = 0,
 PRORES_PROFILE_LT,
 PRORES_PROFILE_STANDARD,
@@ -1146,7 +1147,21 @@ static av_cold int encode_init(AVCodecContext *avctx)
there should be an integer power of two MBs per slice\n);
 return AVERROR(EINVAL);
 }
+if (ctx-profile == PRORES_PROFILE_AUTO) {
+ctx-profile = av_pix_fmt_desc_get(avctx-pix_fmt)-flags  AV_PIX_FMT_FLAG_ALPHA
+ ? PRORES_PROFILE_ : PRORES_PROFILE_HQ;
+av_log(avctx, AV_LOG_INFO, Autoselected %s. It can be overriden 
+   through -profile option.\n, ctx-profile == PRORES_PROFILE_
+   ? 4:4:4:4 profile because of the alpha channel
+   : HQ profile to keep best quality);
+}
 if (av_pix_fmt_desc_get(avctx-pix_fmt)-flags  AV_PIX_FMT_FLAG_ALPHA) {
+if (ctx-profile != PRORES_PROFILE_) {
+// force alpha and warn
+av_log(avctx, AV_LOG_WARNING, Profile selected will not 
+   encode alpha. Override with -profile if needed.\n);
+ctx-alpha_bits = 0;
+}
 if (ctx-alpha_bits  7) {
 av_log(avctx, AV_LOG_ERROR, alpha bits should be 0, 8 or 16\n);
 return AVERROR(EINVAL);
@@ -1280,8 +1295,10 @@ static const AVOption options[] = {
 { mbs_per_slice, macroblocks per slice, OFFSET(mbs_per_slice),
 AV_OPT_TYPE_INT, { .i64 = 8 }, 1, MAX_MBS_PER_SLICE, VE },
 { profile,   NULL, OFFSET(profile), AV_OPT_TYPE_INT,
-{ .i64 = PRORES_PROFILE_STANDARD },
-PRORES_PROFILE_PROXY, PRORES_PROFILE_, VE, profile },
+{ .i64 = PRORES_PROFILE_AUTO },
+PRORES_PROFILE_AUTO, PRORES_PROFILE_, VE, profile },
+{ auto, NULL, 0, AV_OPT_TYPE_CONST, { .i64 = PRORES_PROFILE_AUTO },
+0, 0, VE, profile },
 { proxy, NULL, 0, AV_OPT_TYPE_CONST, { .i64 = PRORES_PROFILE_PROXY },
 0, 0, VE, profile },
 { lt,NULL, 0, AV_OPT_TYPE_CONST, { .i64 = PRORES_PROFILE_LT },
-- 
1.9.2.msysgit.0

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


Re: [FFmpeg-devel] [PATCH] avcodec/vp3data: use more compact data types

2014-08-30 Thread Paul B Mahol
On 8/30/14, Michael Niedermayer michae...@gmx.at wrote:
 Signed-off-by: Michael Niedermayer michae...@gmx.at
 ---
  libavcodec/vp3data.h |   20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

 diff --git a/libavcodec/vp3data.h b/libavcodec/vp3data.h
 index 427827b..da31f6d 100644
 --- a/libavcodec/vp3data.h
 +++ b/libavcodec/vp3data.h
 @@ -26,7 +26,7 @@

  /* these coefficients dequantize intraframe Y plane coefficients
   * (note: same as JPEG) */
 -static const int16_t vp31_intra_y_dequant[64] = {
 +static const int8_t vp31_intra_y_dequant[64] = {
  16, 11, 10, 16,  24,  40,  51,  61,
  12, 12, 14, 19,  26,  58,  60,  55,
  14, 13, 16, 24,  40,  57,  69,  56,
 @@ -39,7 +39,7 @@ static const int16_t vp31_intra_y_dequant[64] = {

  /* these coefficients dequantize intraframe C plane coefficients
   * (note: same as JPEG) */
 -static const int16_t vp31_intra_c_dequant[64] = {
 +static const int8_t vp31_intra_c_dequant[64] = {
  17, 18, 24, 47, 99, 99, 99, 99,
  18, 21, 26, 66, 99, 99, 99, 99,
  24, 26, 56, 99, 99, 99, 99, 99,
 @@ -51,7 +51,7 @@ static const int16_t vp31_intra_c_dequant[64] = {
  };

  /* these coefficients dequantize interframe coefficients (all planes) */
 -static const int16_t vp31_inter_dequant[64] = {
 +static const int8_t vp31_inter_dequant[64] = {
  16, 16, 16, 20, 24, 28,  32,  40,
  16, 16, 20, 24, 28, 32,  40,  48,
  16, 20, 24, 28, 32, 40,  48,  64,
 @@ -62,7 +62,7 @@ static const int16_t vp31_inter_dequant[64] = {
  40, 48, 64, 64, 64, 96, 128, 128
  };

 -static const int16_t vp31_dc_scale_factor[64] = {
 +static const uint8_t vp31_dc_scale_factor[64] = {
  220, 200, 190, 180, 170, 170, 160, 160,
  150, 150, 140, 140, 130, 130, 120, 120,
  110, 110, 100, 100,  90,  90,  90,  80,
 @@ -176,7 +176,7 @@ static const uint8_t motion_vector_vlc_table[63][2] = {
  { 0xFC, 8 }, { 0xFD, 8 }, { 0xFE, 8 }, { 0xFF, 8 }
  };

 -static const int motion_vector_table[63] = {
 +static const int8_t motion_vector_table[63] = {
   0,   1, -1,
   2,  -2,
   3,  -3,
 @@ -198,21 +198,21 @@ static const int8_t fixed_motion_vector_table[64] = {
  };

  /* only tokens 0..6 indicate eob runs */
 -static const int eob_run_base[7] = {
 +static const uint8_t eob_run_base[7] = {
  1, 2, 3, 4, 8, 16, 0
  };
 -static const int eob_run_get_bits[7] = {
 +static const uint8_t eob_run_get_bits[7] = {
  0, 0, 0, 2, 3, 4, 12
  };

 -static const int zero_run_base[32] = {
 +static const uint8_t zero_run_base[32] = {
  0,  0, 0, 0, 0, 0, 0,   /* 0..6 are never used */
  0,  0,  /* 7..8 */
  0,  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 9..22 */
  1,  2, 3, 4, 5, /* 23..27 */
  6, 10, 1, 2 /* 28..31 */
  };
 -static const int zero_run_get_bits[32] = {
 +static const uint8_t zero_run_get_bits[32] = {
  0, 0, 0, 0, 0, 0, 0,/* 0..6 are never used */
  3, 6,   /* 7..8 */
  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 9..22 */
 @@ -220,7 +220,7 @@ static const int zero_run_get_bits[32] = {
  2, 3, 0, 1  /* 28..31 */
  };

 -static const int coeff_get_bits[32] = {
 +static const uint8_t coeff_get_bits[32] = {
  0, 0, 0, 0, 0, 0, 0,/* 0..6 are never used */
  0, 0, 0, 0, 0, 0,   /* 7..12 use constant coeffs */
  1, 1, 1, 1, /* 13..16 are constants but still need sign bit
 */
 --
 1.7.9.5

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

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


Re: [FFmpeg-devel] [PATCH] avcodec/vp3data: use more compact data types

2014-08-30 Thread Michael Niedermayer
On Sat, Aug 30, 2014 at 01:31:04PM +0200, Paul B Mahol wrote:
 On 8/30/14, Michael Niedermayer michae...@gmx.at wrote:
  Signed-off-by: Michael Niedermayer michae...@gmx.at
  ---
   libavcodec/vp3data.h |   20 ++--
   1 file changed, 10 insertions(+), 10 deletions(-)
 
  diff --git a/libavcodec/vp3data.h b/libavcodec/vp3data.h
  index 427827b..da31f6d 100644
  --- a/libavcodec/vp3data.h
  +++ b/libavcodec/vp3data.h
  @@ -26,7 +26,7 @@
 
   /* these coefficients dequantize intraframe Y plane coefficients
* (note: same as JPEG) */
  -static const int16_t vp31_intra_y_dequant[64] = {
  +static const int8_t vp31_intra_y_dequant[64] = {
   16, 11, 10, 16,  24,  40,  51,  61,
   12, 12, 14, 19,  26,  58,  60,  55,
   14, 13, 16, 24,  40,  57,  69,  56,
  @@ -39,7 +39,7 @@ static const int16_t vp31_intra_y_dequant[64] = {
 
   /* these coefficients dequantize intraframe C plane coefficients
* (note: same as JPEG) */
  -static const int16_t vp31_intra_c_dequant[64] = {
  +static const int8_t vp31_intra_c_dequant[64] = {
   17, 18, 24, 47, 99, 99, 99, 99,
   18, 21, 26, 66, 99, 99, 99, 99,
   24, 26, 56, 99, 99, 99, 99, 99,
  @@ -51,7 +51,7 @@ static const int16_t vp31_intra_c_dequant[64] = {
   };
 
   /* these coefficients dequantize interframe coefficients (all planes) */
  -static const int16_t vp31_inter_dequant[64] = {
  +static const int8_t vp31_inter_dequant[64] = {
   16, 16, 16, 20, 24, 28,  32,  40,
   16, 16, 20, 24, 28, 32,  40,  48,
   16, 20, 24, 28, 32, 40,  48,  64,
  @@ -62,7 +62,7 @@ static const int16_t vp31_inter_dequant[64] = {
   40, 48, 64, 64, 64, 96, 128, 128
   };
 
  -static const int16_t vp31_dc_scale_factor[64] = {
  +static const uint8_t vp31_dc_scale_factor[64] = {
   220, 200, 190, 180, 170, 170, 160, 160,
   150, 150, 140, 140, 130, 130, 120, 120,
   110, 110, 100, 100,  90,  90,  90,  80,
  @@ -176,7 +176,7 @@ static const uint8_t motion_vector_vlc_table[63][2] = {
   { 0xFC, 8 }, { 0xFD, 8 }, { 0xFE, 8 }, { 0xFF, 8 }
   };
 
  -static const int motion_vector_table[63] = {
  +static const int8_t motion_vector_table[63] = {
0,   1, -1,
2,  -2,
3,  -3,
  @@ -198,21 +198,21 @@ static const int8_t fixed_motion_vector_table[64] = {
   };
 
   /* only tokens 0..6 indicate eob runs */
  -static const int eob_run_base[7] = {
  +static const uint8_t eob_run_base[7] = {
   1, 2, 3, 4, 8, 16, 0
   };
  -static const int eob_run_get_bits[7] = {
  +static const uint8_t eob_run_get_bits[7] = {
   0, 0, 0, 2, 3, 4, 12
   };
 
  -static const int zero_run_base[32] = {
  +static const uint8_t zero_run_base[32] = {
   0,  0, 0, 0, 0, 0, 0,   /* 0..6 are never used */
   0,  0,  /* 7..8 */
   0,  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 9..22 */
   1,  2, 3, 4, 5, /* 23..27 */
   6, 10, 1, 2 /* 28..31 */
   };
  -static const int zero_run_get_bits[32] = {
  +static const uint8_t zero_run_get_bits[32] = {
   0, 0, 0, 0, 0, 0, 0,/* 0..6 are never used */
   3, 6,   /* 7..8 */
   0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 9..22 */
  @@ -220,7 +220,7 @@ static const int zero_run_get_bits[32] = {
   2, 3, 0, 1  /* 28..31 */
   };
 
  -static const int coeff_get_bits[32] = {
  +static const uint8_t coeff_get_bits[32] = {
   0, 0, 0, 0, 0, 0, 0,/* 0..6 are never used */
   0, 0, 0, 0, 0, 0,   /* 7..12 use constant coeffs */
   1, 1, 1, 1, /* 13..16 are constants but still need sign bit
  */
  --
  1.7.9.5
 
  ___
  ffmpeg-devel mailing list
  ffmpeg-devel@ffmpeg.org
  http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 
 lgtm

applied

thanks

[...]
-- 
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] [RFC] [PATCH] proresenc_kostya: warn/reject on incorrect profile

2014-08-30 Thread Michael Niedermayer
On Sat, Aug 30, 2014 at 01:13:56PM +0200, Christophe Gisquet wrote:
 Hi,
 
 2014-08-24 18:56 GMT+02:00 Michael Niedermayer michae...@gmx.at:
  aggree, a PRORES_PROFILE_AUTO seems like a good idea
  with it mismatching profile and pixel format can be errors while
  by default the profile can be selected based on the pixel format
 
 The attached patch makes it selects either  or HQ profile
 depending on whether there's an alpha channel. If a profile is
 selected that does not have alpha but the input data has alpha, it
 warns that it will not encode it.
 
 Best regards,
 -- 
 Christophe

  proresenc_kostya.c |   21 +++--
  1 file changed, 19 insertions(+), 2 deletions(-)
 cf627c08cf26aa889a17ded6b3e9684115eec296  
 0001-proresenc_ks-allow-auto-selecting-profile.patch
 From 0b134da9eba4f6f08422d22a1a0428f564fe8f11 Mon Sep 17 00:00:00 2001
 From: Christophe Gisquet christophe.gisq...@gmail.com
 Date: Mon, 18 Aug 2014 11:27:50 +0200
 Subject: [PATCH] proresenc_ks: allow auto-selecting profile
 
 The user may not know how to select the profile, nor what he needs, in
 particular to encode alpha.
 
 Therefore, use an automatic selection as default, and warn when the
 manually selected profile may cause issues.

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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


Re: [FFmpeg-devel] [PATCH] lavu/avstring: check for overlong encodings

2014-08-30 Thread Stefano Sabatini
On date Friday 2014-08-29 15:57:32 +0200, wm4 encoded:
 On Thu, 28 Aug 2014 17:39:27 +0200
 Stefano Sabatini stefa...@gmail.com wrote:
 
  Fix reopened trac ticket #1163.
  ---
   libavutil/avstring.c | 13 -
   1 file changed, 12 insertions(+), 1 deletion(-)
  
  diff --git a/libavutil/avstring.c b/libavutil/avstring.c
  index a63fb84..df27d5e 100644
  --- a/libavutil/avstring.c
  +++ b/libavutil/avstring.c
  @@ -331,7 +331,10 @@ int av_utf8_decode(int32_t *codep, const uint8_t 
  **bufp, const uint8_t *buf_end,
   const uint8_t *p = *bufp;
   uint32_t top;
   uint64_t code;
  -int ret = 0;
  +int ret = 0, tail_len;
  +uint32_t overlong_encoding_mins[6] = {
  +0x, 0x0080, 0x0800, 0x0001, 0x0020, 
  0x0400,
  +};
   
   if (p = buf_end)
   return 0;
  @@ -346,8 +349,10 @@ int av_utf8_decode(int32_t *codep, const uint8_t 
  **bufp, const uint8_t *buf_end,
   }
   top = (code  128)  1;
   
  +tail_len = 0;
   while (code  top) {
   int tmp;
  +tail_len++;
   if (p = buf_end) {
   (*bufp) ++;
   return AVERROR(EILSEQ); /* incomplete sequence */
  @@ -364,6 +369,12 @@ int av_utf8_decode(int32_t *codep, const uint8_t 
  **bufp, const uint8_t *buf_end,
   }
   code = (top  1) - 1;
   
  +/* check for overlong encodings */
  +if (code  overlong_encoding_mins[tail_len]) {
  +ret = AVERROR(EILSEQ);
  +goto end;
  +}
  +
   if (code = 131) {
   ret = AVERROR(EILSEQ);  /* out-of-range value */
   goto end;
 

 Looks ok and simple to me. Is there a guarantee tail_len never
 becomes larger than 5?

It is mathematically impossible that the length will be larger than 5.
Added an assert for that though, alternatively I could add a check.

 
 Also note that libavcodec/utils.c contains the same check (but less
 readable) in utf8_check().
-- 
FFmpeg = Faithful Fundamentalist Most Power Enhancing Goblin
From 75db7cc2ea2b7b12e611b7b3fd103aee4f707dde Mon Sep 17 00:00:00 2001
From: Stefano Sabatini stefa...@gmail.com
Date: Thu, 28 Aug 2014 17:37:27 +0200
Subject: [PATCH] lavu/avstring: check for overlong encodings

Fix reopened trac ticket #1163.
---
 libavutil/avstring.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/libavutil/avstring.c b/libavutil/avstring.c
index a63fb84..fd010e4 100644
--- a/libavutil/avstring.c
+++ b/libavutil/avstring.c
@@ -27,6 +27,7 @@
 #include config.h
 #include common.h
 #include mem.h
+#include avassert.h
 #include avstring.h
 #include bprint.h
 
@@ -331,7 +332,10 @@ int av_utf8_decode(int32_t *codep, const uint8_t **bufp, const uint8_t *buf_end,
 const uint8_t *p = *bufp;
 uint32_t top;
 uint64_t code;
-int ret = 0;
+int ret = 0, tail_len;
+uint32_t overlong_encoding_mins[6] = {
+0x, 0x0080, 0x0800, 0x0001, 0x0020, 0x0400,
+};
 
 if (p = buf_end)
 return 0;
@@ -346,8 +350,10 @@ int av_utf8_decode(int32_t *codep, const uint8_t **bufp, const uint8_t *buf_end,
 }
 top = (code  128)  1;
 
+tail_len = 0;
 while (code  top) {
 int tmp;
+tail_len++;
 if (p = buf_end) {
 (*bufp) ++;
 return AVERROR(EILSEQ); /* incomplete sequence */
@@ -364,6 +370,13 @@ int av_utf8_decode(int32_t *codep, const uint8_t **bufp, const uint8_t *buf_end,
 }
 code = (top  1) - 1;
 
+/* check for overlong encodings */
+av_assert0(tail_len = 5);
+if (code  overlong_encoding_mins[tail_len]) {
+ret = AVERROR(EILSEQ);
+goto end;
+}
+
 if (code = 131) {
 ret = AVERROR(EILSEQ);  /* out-of-range value */
 goto end;
-- 
1.8.3.2

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


Re: [FFmpeg-devel] [PATCH] lavu/avstring: check for overlong encodings

2014-08-30 Thread Nicolas George
Le tridi 13 fructidor, an CCXXII, Stefano Sabatini a écrit :
 It is mathematically impossible that the length will be larger than 5.
 Added an assert for that though, alternatively I could add a check.

In ffprobe, the function is used with values coming directly from the file's
metadata: an assert is not acceptable in this case.

Furthermore, the function is capable of decoding the full UTF-8 range, up to
(131)-1, and that takes 6 octets.

Also, I suspect checking for overlong encodings could have a flag just like
the other extraneous checks below.

Regards,

-- 
  Nicolas George


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


Re: [FFmpeg-devel] [PATCH] lavu/avstring: check for overlong encodings

2014-08-30 Thread Stefano Sabatini
On date Saturday 2014-08-30 15:06:14 +0200, Nicolas George encoded:
 Le tridi 13 fructidor, an CCXXII, Stefano Sabatini a écrit :
  It is mathematically impossible that the length will be larger than 5.
  Added an assert for that though, alternatively I could add a check.
 

 In ffprobe, the function is used with values coming directly from the file's
 metadata: an assert is not acceptable in this case.

Unless there is an error in the code, a tail length of 6 bytes should
never be reached.

 Furthermore, the function is capable of decoding the full UTF-8 range, up to
 (131)-1, and that takes 6 octets.

There is a separate check in the function:
if (code  0x10 
!(flags  AV_UTF8_FLAG_ACCEPT_INVALID_BIG_CODES))
ret = AVERROR(EILSEQ);
 
 Also, I suspect checking for overlong encodings could have a flag just like
 the other extraneous checks below.

I believe overlong encodings are illegal, and thus should be never
accepted.
-- 
FFmpeg = Formidable and Free Mastering Political Evil Gorilla
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] lavu/hash.c: Add missing static const.

2014-08-30 Thread Reimar Döffinger
On Fri, Aug 29, 2014 at 09:29:46PM +0200, Clément Bœsch wrote:
 On Fri, Aug 29, 2014 at 06:34:52PM +0200, Reimar Döffinger wrote:
  Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
  ---
   libavutil/hash.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
  diff --git a/libavutil/hash.c b/libavutil/hash.c
  index 773f29e..979fdd9 100644
  --- a/libavutil/hash.c
  +++ b/libavutil/hash.c
  @@ -63,7 +63,7 @@ typedef struct AVHashContext {
   struct {
   const char *name;
   int size;
  -} hashdesc[] = {
  +} static const hashdesc[] = {
   [MD5] = {MD5, 16},
   [MURMUR3] = {murmur3, 16},
   [RIPEMD128] = {RIPEMD128, 16},
 
 shouldn't that be static const struct { } hashdesc[] = { ... }
 
 as in static const type foo[] = { ... };

Reason I prefer this one is that if the struct becomes
large it because very non-obvious that the array actually is
static const.
It also is much harder to check/filter with grep.
So for practical reasons I think it is better to place it here,
or alternatively to name the struct and split them...
But mostly I care about having it in .rodata, everything else
I'm willing to adapt to what others prefer.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 5/6] xv.c: Add missing const to lookup table.

2014-08-30 Thread Reimar Döffinger
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
 libavdevice/xv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavdevice/xv.c b/libavdevice/xv.c
index aeb3e41..c19c15c 100644
--- a/libavdevice/xv.c
+++ b/libavdevice/xv.c
@@ -67,7 +67,7 @@ typedef struct XVTagFormatMap
 enum AVPixelFormat format;
 } XVTagFormatMap;
 
-static XVTagFormatMap tag_codec_map[] = {
+static const XVTagFormatMap tag_codec_map[] = {
 { MKTAG('I','4','2','0'), AV_PIX_FMT_YUV420P },
 { MKTAG('U','Y','V','Y'), AV_PIX_FMT_UYVY422 },
 { MKTAG('Y','U','Y','2'), AV_PIX_FMT_YUYV422 },
@@ -76,7 +76,7 @@ static XVTagFormatMap tag_codec_map[] = {
 
 static int xv_get_tag_from_format(enum AVPixelFormat format)
 {
-XVTagFormatMap *m = tag_codec_map;
+const XVTagFormatMap *m = tag_codec_map;
 int i;
 for (i = 0; m-tag; m = tag_codec_map[++i]) {
 if (m-format == format)
-- 
2.1.0

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


[FFmpeg-devel] [PATCH 4/6] lavf: add const/static const to pix_fmts arrays.

2014-08-30 Thread Reimar Döffinger
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
 libavfilter/vf_blackdetect.c| 2 +-
 libavfilter/vf_lenscorrection.c | 2 +-
 libavfilter/vf_signalstats.c| 2 +-
 libavfilter/vf_tinterlace.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vf_blackdetect.c b/libavfilter/vf_blackdetect.c
index 94af613..87a7a23 100644
--- a/libavfilter/vf_blackdetect.c
+++ b/libavfilter/vf_blackdetect.c
@@ -64,7 +64,7 @@ AVFILTER_DEFINE_CLASS(blackdetect);
 #define YUVJ_FORMATS \
 AV_PIX_FMT_YUVJ411P, AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, 
AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ440P
 
-static enum AVPixelFormat yuvj_formats[] = {
+static const enum AVPixelFormat yuvj_formats[] = {
 YUVJ_FORMATS, AV_PIX_FMT_NONE
 };
 
diff --git a/libavfilter/vf_lenscorrection.c b/libavfilter/vf_lenscorrection.c
index 58184b0..9fb1424 100644
--- a/libavfilter/vf_lenscorrection.c
+++ b/libavfilter/vf_lenscorrection.c
@@ -98,7 +98,7 @@ static int filter_slice(AVFilterContext *ctx, void *arg, int 
job, int nb_jobs)
 
 static int query_formats(AVFilterContext *ctx)
 {
-static enum AVPixelFormat pix_fmts[] = {
+static const enum AVPixelFormat pix_fmts[] = {
 AV_PIX_FMT_YUV410P,
 AV_PIX_FMT_YUV444P,  AV_PIX_FMT_YUVJ444P,
 AV_PIX_FMT_YUV420P,  AV_PIX_FMT_YUVJ420P,
diff --git a/libavfilter/vf_signalstats.c b/libavfilter/vf_signalstats.c
index 263de23..53f7401 100644
--- a/libavfilter/vf_signalstats.c
+++ b/libavfilter/vf_signalstats.c
@@ -94,7 +94,7 @@ static av_cold void uninit(AVFilterContext *ctx)
 static int query_formats(AVFilterContext *ctx)
 {
 // TODO: add more
-enum AVPixelFormat pix_fmts[] = {
+static const enum AVPixelFormat pix_fmts[] = {
 AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV420P, 
AV_PIX_FMT_YUV411P,
 AV_PIX_FMT_NONE
 };
diff --git a/libavfilter/vf_tinterlace.c b/libavfilter/vf_tinterlace.c
index 3ebb971..6bc55b5 100644
--- a/libavfilter/vf_tinterlace.c
+++ b/libavfilter/vf_tinterlace.c
@@ -80,7 +80,7 @@ AVFILTER_DEFINE_CLASS(tinterlace);
 #define FULL_SCALE_YUVJ_FORMATS \
 AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P, 
AV_PIX_FMT_YUVJ440P
 
-static enum AVPixelFormat full_scale_yuvj_pix_fmts[] = {
+static const enum AVPixelFormat full_scale_yuvj_pix_fmts[] = {
 FULL_SCALE_YUVJ_FORMATS, AV_PIX_FMT_NONE
 };
 
-- 
2.1.0

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


[FFmpeg-devel] [PATCH 3/6] sipr16kdata.h: add forgotten const.

2014-08-30 Thread Reimar Döffinger
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
 libavcodec/sipr16kdata.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/sipr16kdata.h b/libavcodec/sipr16kdata.h
index 96bf0e9..16a653d 100644
--- a/libavcodec/sipr16kdata.h
+++ b/libavcodec/sipr16kdata.h
@@ -525,7 +525,7 @@ static const float lsf_cb5_16k[128][4] = {
 { 0.124405,  0.009943, -0.148477, -0.205184}
 };
 
-static const float *lsf_codebooks_16k[] = {
+static const float * const lsf_codebooks_16k[] = {
 lsf_cb1_16k[0], lsf_cb2_16k[0], lsf_cb3_16k[0], lsf_cb4_16k[0],
 lsf_cb5_16k[0]
 };
-- 
2.1.0

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


[FFmpeg-devel] [PATCH 1/6] fft: add ff_ prefix to some global arrays.

2014-08-30 Thread Reimar Döffinger
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
 libavcodec/fft_init_table.c |  4 ++--
 libavcodec/fft_table.h  |  4 ++--
 libavcodec/fft_template.c   | 12 ++--
 libavcodec/mips/fft_mips.c  |  8 
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/libavcodec/fft_init_table.c b/libavcodec/fft_init_table.c
index 4e8b082..4d74f8a 100644
--- a/libavcodec/fft_init_table.c
+++ b/libavcodec/fft_init_table.c
@@ -53,7 +53,7 @@
  */
 #include libavcodec/fft_table.h
 
-const int32_t w_tab_sr[MAX_FFT_SIZE/(4*16)] = {
+const int32_t ff_w_tab_sr[MAX_FFT_SIZE/(4*16)] = {
 2147483647, 2147481121, 2147473542, 2147460908, 2147443222, 2147420483, 
2147392690, 2147359845,
 2147321946, 2147278995, 2147230991, 2147177934, 2147119825, 2147056664, 
2146988450, 2146915184,
 2146836866, 2146753497, 2146665076, 2146571603, 2146473080, 2146369505, 
2146260881, 2146147205,
@@ -184,7 +184,7 @@ const int32_t w_tab_sr[MAX_FFT_SIZE/(4*16)] = {
   26352928,   23058947,   19764913,   16470832,   13176712,9882561,
6588387,3294197
 };
 
-uint16_t fft_offsets_lut[0x2aab];
+uint16_t ff_fft_offsets_lut[0x2aab];
 
 void ff_fft_lut_init(uint16_t *table, int off, int size, int *index)
 {
diff --git a/libavcodec/fft_table.h b/libavcodec/fft_table.h
index 4cd3a45..e5e54b6 100644
--- a/libavcodec/fft_table.h
+++ b/libavcodec/fft_table.h
@@ -59,8 +59,8 @@
 #define MAX_LOG2_NFFT 16 //! Specifies maximum allowed fft size
 #define MAX_FFT_SIZE (1  MAX_LOG2_NFFT)
 
-extern const int32_t w_tab_sr[];
-extern uint16_t fft_offsets_lut[];
+extern const int32_t ff_w_tab_sr[];
+extern uint16_t ff_fft_offsets_lut[];
 void ff_fft_lut_init(uint16_t *table, int off, int size, int *index);
 
 #endif /* AVCODEC_FFT_TABLE_H */
diff --git a/libavcodec/fft_template.c b/libavcodec/fft_template.c
index 697d1fc..3abf948 100644
--- a/libavcodec/fft_template.c
+++ b/libavcodec/fft_template.c
@@ -166,7 +166,7 @@ av_cold int ff_fft_init(FFTContext *s, int nbits, int 
inverse)
 #if FFT_FIXED_32
 {
 int n=0;
-ff_fft_lut_init(fft_offsets_lut, 0, 1  16, n);
+ff_fft_lut_init(ff_fft_offsets_lut, 0, 1  16, n);
 }
 #else /* FFT_FIXED_32 */
 #if FFT_FLOAT
@@ -236,7 +236,7 @@ static void fft_calc_c(FFTContext *s, FFTComplex *z) {
 num_transforms = (0x2aab  (16 - s-nbits)) | 1;
 
 for (n=0; nnum_transforms; n++){
-offset = fft_offsets_lut[n]  2;
+offset = ff_fft_offsets_lut[n]  2;
 tmpz = z + offset;
 
 tmp1 = tmpz[0].re + tmpz[1].re;
@@ -264,7 +264,7 @@ static void fft_calc_c(FFTContext *s, FFTComplex *z) {
 num_transforms = (num_transforms  1) | 1;
 
 for (n=0; nnum_transforms; n++){
-offset = fft_offsets_lut[n]  3;
+offset = ff_fft_offsets_lut[n]  3;
 tmpz = z + offset;
 
 tmp1 = tmpz[4].re + tmpz[5].re;
@@ -322,7 +322,7 @@ static void fft_calc_c(FFTContext *s, FFTComplex *z) {
 num_transforms = (num_transforms  1) | 1;
 
 for (n=0; nnum_transforms; n++){
-offset = fft_offsets_lut[n]  nbits;
+offset = ff_fft_offsets_lut[n]  nbits;
 tmpz = z + offset;
 
 tmp5 = tmpz[ n2].re + tmpz[n34].re;
@@ -339,8 +339,8 @@ static void fft_calc_c(FFTContext *s, FFTComplex *z) {
 tmpz[n34].im = tmpz[n4].im + tmp1;
 tmpz[ n4].im = tmpz[n4].im - tmp1;
 
-w_re_ptr = w_tab_sr + step;
-w_im_ptr = w_tab_sr + MAX_FFT_SIZE/(4*16) - step;
+w_re_ptr = ff_w_tab_sr + step;
+w_im_ptr = ff_w_tab_sr + MAX_FFT_SIZE/(4*16) - step;
 
 for (i=1; in4; i++){
 w_re = w_re_ptr[0];
diff --git a/libavcodec/mips/fft_mips.c b/libavcodec/mips/fft_mips.c
index d240f1f..691f2db 100644
--- a/libavcodec/mips/fft_mips.c
+++ b/libavcodec/mips/fft_mips.c
@@ -87,7 +87,7 @@ static void ff_fft_calc_mips(FFTContext *s, FFTComplex *z)
 
 
 for (n=0; nnum_transforms; n++) {
-offset = fft_offsets_lut[n]  2;
+offset = ff_fft_offsets_lut[n]  2;
 tmpz = z + offset;
 
 tmp1 = tmpz[0].re + tmpz[1].re;
@@ -116,7 +116,7 @@ static void ff_fft_calc_mips(FFTContext *s, FFTComplex *z)
 num_transforms = (num_transforms  1) | 1;
 
 for (n=0; nnum_transforms; n++) {
-offset = fft_offsets_lut[n]  3;
+offset = ff_fft_offsets_lut[n]  3;
 tmpz = z + offset;
 
 __asm__ volatile (
@@ -227,7 +227,7 @@ static void ff_fft_calc_mips(FFTContext *s, FFTComplex *z)
 n34 = 3 * n4;
 
 for (n=0; nnum_transforms; n++) {
-offset = fft_offsets_lut[n]  nbits;
+offset = ff_fft_offsets_lut[n]  nbits;
 tmpz = z + offset;
 
 tmpz_n2  = tmpz +  n2;
@@ -521,7 +521,7 @@ av_cold void ff_fft_init_mips(FFTContext *s)
 {
 int n=0;
 
-ff_fft_lut_init(fft_offsets_lut, 0, 1  16, n);
+ff_fft_lut_init(ff_fft_offsets_lut, 0, 1  16, n);
 ff_init_ff_cos_tabs(16);
 
 #if HAVE_INLINE_ASM
-- 
2.1.0


Re: [FFmpeg-devel] [PATCH] oggdec: fix invalid free on error

2014-08-30 Thread Michael Niedermayer
On Sat, Aug 30, 2014 at 03:39:15PM +0200, wm4 wrote:
 The read_packet callback passes a pointer to a stack-allocated AVPacket.
 Attempting to free it with av_free() makes no sense.
 ---
 Found by looking at the code; there's no sample file.
 ---
  libavformat/oggdec.c | 1 -
  1 file changed, 1 deletion(-)

applied

thanks

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


[FFmpeg-devel] [PATCH] aacsbr: support hardcoding tables.

2014-08-30 Thread Reimar Döffinger
For sbr_qmf_window_us there is even a question if it maybe
should be fully hardcoded all the time.
Since half of it is coded, it ends up in .data and not .bss.

Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
 libavcodec/Makefile  |   4 +-
 libavcodec/aacsbr.c  |  10 +---
 libavcodec/aacsbr_tablegen.c |  39 +
 libavcodec/aacsbr_tablegen.h | 132 +++
 libavcodec/aacsbrdata.h  |  86 
 libavcodec/tableprint.h  |  10 
 6 files changed, 186 insertions(+), 95 deletions(-)
 create mode 100644 libavcodec/aacsbr_tablegen.c
 create mode 100644 libavcodec/aacsbr_tablegen.h

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 8173449..0ed5478 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -871,6 +871,7 @@ TOOLS = fourcc2pixfmt
 
 HOSTPROGS = aac_tablegen\
 aacps_tablegen  \
+aacsbr_tablegen \
 cbrt_tablegen   \
 cos_tablegen\
 dsd_tablegen\
@@ -898,7 +899,7 @@ else
 $(SUBDIR)%_tablegen$(HOSTEXESUF): HOSTCFLAGS += -DCONFIG_SMALL=0
 endif
 
-GEN_HEADERS = cbrt_tables.h aacps_tables.h aac_tables.h dsd_tables.h 
dv_tables.h \
+GEN_HEADERS = cbrt_tables.h aacps_tables.h aacsbr_tables.h aac_tables.h 
dsd_tables.h dv_tables.h \
   sinewin_tables.h mpegaudio_tables.h motionpixels_tables.h \
   pcm_tables.h qdm2_tables.h
 GEN_HEADERS := $(addprefix $(SUBDIR), $(GEN_HEADERS))
@@ -909,6 +910,7 @@ $(GEN_HEADERS): $(SUBDIR)%_tables.h: 
$(SUBDIR)%_tablegen$(HOSTEXESUF)
 ifdef CONFIG_HARDCODED_TABLES
 $(SUBDIR)aacdec.o: $(SUBDIR)cbrt_tables.h
 $(SUBDIR)aacps.o: $(SUBDIR)aacps_tables.h
+$(SUBDIR)aacsbr.o: $(SUBDIR)aacsbr_tables.h
 $(SUBDIR)aactab.o: $(SUBDIR)aac_tables.h
 $(SUBDIR)dsddec.o: $(SUBDIR)dsd_tables.h
 $(SUBDIR)dvenc.o: $(SUBDIR)dv_tables.h
diff --git a/libavcodec/aacsbr.c b/libavcodec/aacsbr.c
index 290fb81..f550ead 100644
--- a/libavcodec/aacsbr.c
+++ b/libavcodec/aacsbr.c
@@ -30,6 +30,7 @@
 #include sbr.h
 #include aacsbr.h
 #include aacsbrdata.h
+#include aacsbr_tablegen.h
 #include fft.h
 #include aacps.h
 #include sbrdsp.h
@@ -95,7 +96,6 @@ static void aacsbr_func_ptr_init(AACSBRContext *c);
 
 av_cold void ff_aac_sbr_init(void)
 {
-int n;
 static const struct {
 const void *sbr_codes, *sbr_bits;
 const unsigned int table_size, elem_size;
@@ -124,13 +124,7 @@ av_cold void ff_aac_sbr_init(void)
 SBR_INIT_VLC_STATIC(8, 592);
 SBR_INIT_VLC_STATIC(9, 512);
 
-for (n = 1; n  320; n++)
-sbr_qmf_window_us[320 + n] = sbr_qmf_window_us[320 - n];
-sbr_qmf_window_us[384] = -sbr_qmf_window_us[384];
-sbr_qmf_window_us[512] = -sbr_qmf_window_us[512];
-
-for (n = 0; n  320; n++)
-sbr_qmf_window_ds[n] = sbr_qmf_window_us[2*n];
+aacsbr_tableinit();
 
 ff_ps_init();
 }
diff --git a/libavcodec/aacsbr_tablegen.c b/libavcodec/aacsbr_tablegen.c
new file mode 100644
index 000..c3c0f0c
--- /dev/null
+++ b/libavcodec/aacsbr_tablegen.c
@@ -0,0 +1,39 @@
+/*
+ * Header file for hardcoded AAC SBR windows
+ *
+ * Copyright (c) 2014 Reimar Döffinger reimar.doeffin...@gmx.de
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include stdlib.h
+#define CONFIG_HARDCODED_TABLES 0
+#include libavutil/common.h
+#include aacsbr_tablegen.h
+#include tableprint.h
+
+int main(void)
+{
+aacsbr_tableinit();
+
+write_fileheader();
+
+WRITE_ARRAY_ALIGNED(static const, 32, float, sbr_qmf_window_ds);
+WRITE_ARRAY_ALIGNED(static const, 32, float, sbr_qmf_window_us);
+
+return 0;
+}
diff --git a/libavcodec/aacsbr_tablegen.h b/libavcodec/aacsbr_tablegen.h
new file mode 100644
index 000..104daae
--- /dev/null
+++ b/libavcodec/aacsbr_tablegen.h
@@ -0,0 +1,132 @@
+/*
+ * Header file for hardcoded AAC SBR windows
+ *
+ * Copyright (c) 2014 Reimar Döffinger reimar.doeffin...@gmx.de
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; 

Re: [FFmpeg-devel] [PATCH 4/6] lavf: add const/static const to pix_fmts arrays.

2014-08-30 Thread Reimar Döffinger
On Sat, Aug 30, 2014 at 08:07:29AM -0700, Timothy Gu wrote:
 On Aug 30, 2014 7:44 AM, Reimar Döffinger reimar.doeffin...@gmx.de
 wrote:
 
 It's lavfi, not lavf.

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


Re: [FFmpeg-devel] [PATCH 5/6] xv.c: Add missing const to lookup table.

2014-08-30 Thread Paul B Mahol
On 8/30/14, Reimar Doeffinger reimar.doeffin...@gmx.de wrote:
 Signed-off-by: Reimar Doeffinger reimar.doeffin...@gmx.de
 ---
  libavdevice/xv.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/libavdevice/xv.c b/libavdevice/xv.c
 index aeb3e41..c19c15c 100644
 --- a/libavdevice/xv.c
 +++ b/libavdevice/xv.c
 @@ -67,7 +67,7 @@ typedef struct XVTagFormatMap
  enum AVPixelFormat format;
  } XVTagFormatMap;

 -static XVTagFormatMap tag_codec_map[] = {
 +static const XVTagFormatMap tag_codec_map[] = {
  { MKTAG('I','4','2','0'), AV_PIX_FMT_YUV420P },
  { MKTAG('U','Y','V','Y'), AV_PIX_FMT_UYVY422 },
  { MKTAG('Y','U','Y','2'), AV_PIX_FMT_YUYV422 },
 @@ -76,7 +76,7 @@ static XVTagFormatMap tag_codec_map[] = {

  static int xv_get_tag_from_format(enum AVPixelFormat format)
  {
 -XVTagFormatMap *m = tag_codec_map;
 +const XVTagFormatMap *m = tag_codec_map;
  int i;
  for (i = 0; m-tag; m = tag_codec_map[++i]) {
  if (m-format == format)
 --
 2.1.0

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


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


[FFmpeg-devel] [PATCH] WMA: add const to avoid warnings with hardcoded tables.

2014-08-30 Thread Reimar Döffinger
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
 libavcodec/wma.h   | 2 +-
 libavcodec/wmaprodec.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/wma.h b/libavcodec/wma.h
index c4056ec..01244a0 100644
--- a/libavcodec/wma.h
+++ b/libavcodec/wma.h
@@ -115,7 +115,7 @@ typedef struct WMACodecContext {
 DECLARE_ALIGNED(32, float, coefs)[MAX_CHANNELS][BLOCK_MAX_SIZE];
 DECLARE_ALIGNED(32, FFTSample, output)[BLOCK_MAX_SIZE * 2];
 FFTContext mdct_ctx[BLOCK_NB_SIZES];
-float *windows[BLOCK_NB_SIZES];
+const float *windows[BLOCK_NB_SIZES];
 /* output buffer for one frame and the last for IMDCT windowing */
 DECLARE_ALIGNED(32, float, frame_out)[MAX_CHANNELS][BLOCK_MAX_SIZE * 2];
 /* last frame info */
diff --git a/libavcodec/wmaprodec.c b/libavcodec/wmaprodec.c
index 2f6c485..f45e1fc 100644
--- a/libavcodec/wmaprodec.c
+++ b/libavcodec/wmaprodec.c
@@ -177,7 +177,7 @@ typedef struct WMAProDecodeCtx {
 PutBitContextpb;/// context for filling 
the frame_data buffer
 FFTContext   mdct_ctx[WMAPRO_BLOCK_SIZES];  /// MDCT context per 
block size
 DECLARE_ALIGNED(32, float, tmp)[WMAPRO_BLOCK_MAX_SIZE]; /// IMDCT output 
buffer
-float*   windows[WMAPRO_BLOCK_SIZES];   /// windows for the 
different block sizes
+const float* windows[WMAPRO_BLOCK_SIZES];   /// windows for the 
different block sizes
 
 /* frame size dependent frame information (set during initialization) */
 uint32_t decode_flags;  /// used compression 
features
@@ -1055,7 +1055,7 @@ static void wmapro_window(WMAProDecodeCtx *s)
 int i;
 for (i = 0; i  s-channels_for_cur_subframe; i++) {
 int c = s-channel_indexes_for_cur_subframe[i];
-float* window;
+const float* window;
 int winlen = s-channel[c].prev_block_len;
 float* start = s-channel[c].coeffs - (winlen  1);
 
-- 
2.1.0

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


[FFmpeg-devel] [PATCH] Add av_cold to table generation functions.

2014-08-30 Thread Reimar Döffinger
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
 libavcodec/aac_tablegen.h  | 2 +-
 libavcodec/aacps_tablegen.h| 4 ++--
 libavcodec/aacsbr_tablegen.h   | 2 +-
 libavcodec/cbrt_tablegen.h | 3 ++-
 libavcodec/dv_tablegen.h   | 3 ++-
 libavcodec/motionpixels_tablegen.h | 7 ---
 libavcodec/mpegaudio_tablegen.h| 3 ++-
 7 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/libavcodec/aac_tablegen.h b/libavcodec/aac_tablegen.h
index 1c19a15..bf71e59 100644
--- a/libavcodec/aac_tablegen.h
+++ b/libavcodec/aac_tablegen.h
@@ -31,7 +31,7 @@
 #include libavutil/mathematics.h
 float ff_aac_pow2sf_tab[428];
 
-void ff_aac_tableinit(void)
+av_cold void ff_aac_tableinit(void)
 {
 int i;
 for (i = 0; i  428; i++)
diff --git a/libavcodec/aacps_tablegen.h b/libavcodec/aacps_tablegen.h
index 9df38ff..ca1112d 100644
--- a/libavcodec/aacps_tablegen.h
+++ b/libavcodec/aacps_tablegen.h
@@ -70,7 +70,7 @@ static const float g2_Q4[] = {
  0.16486303567403f,  0.23279856662996f, 0.25f
 };
 
-static void make_filters_from_proto(float (*filter)[8][2], const float *proto, 
int bands)
+static av_cold void make_filters_from_proto(float (*filter)[8][2], const float 
*proto, int bands)
 {
 int q, n;
 for (q = 0; q  bands; q++) {
@@ -82,7 +82,7 @@ static void make_filters_from_proto(float (*filter)[8][2], 
const float *proto, i
 }
 }
 
-static void ps_tableinit(void)
+static av_cold void ps_tableinit(void)
 {
 static const float ipdopd_sin[] = { 0, M_SQRT1_2, 1,  M_SQRT1_2,  0, 
-M_SQRT1_2, -1, -M_SQRT1_2 };
 static const float ipdopd_cos[] = { 1, M_SQRT1_2, 0, -M_SQRT1_2, -1, 
-M_SQRT1_2,  0,  M_SQRT1_2 };
diff --git a/libavcodec/aacsbr_tablegen.h b/libavcodec/aacsbr_tablegen.h
index 7b70c26..56fdccc 100644
--- a/libavcodec/aacsbr_tablegen.h
+++ b/libavcodec/aacsbr_tablegen.h
@@ -113,7 +113,7 @@ static DECLARE_ALIGNED(32, float, sbr_qmf_window_us)[640] = 
{
  0.8537385600,
 };
 
-static void aacsbr_tableinit(void)
+static av_cold void aacsbr_tableinit(void)
 {
 int n;
 for (n = 1; n  320; n++)
diff --git a/libavcodec/cbrt_tablegen.h b/libavcodec/cbrt_tablegen.h
index 0db64fc..d8c77c2 100644
--- a/libavcodec/cbrt_tablegen.h
+++ b/libavcodec/cbrt_tablegen.h
@@ -25,6 +25,7 @@
 
 #include stdint.h
 #include math.h
+#include libavutil/attributes.h
 
 #if CONFIG_HARDCODED_TABLES
 #define cbrt_tableinit()
@@ -32,7 +33,7 @@
 #else
 static uint32_t cbrt_tab[1  13];
 
-static void cbrt_tableinit(void)
+static av_cold void cbrt_tableinit(void)
 {
 if (!cbrt_tab[(113) - 1]) {
 int i;
diff --git a/libavcodec/dv_tablegen.h b/libavcodec/dv_tablegen.h
index c04b802..cc6605b 100644
--- a/libavcodec/dv_tablegen.h
+++ b/libavcodec/dv_tablegen.h
@@ -24,6 +24,7 @@
 #define AVCODEC_DV_TABLEGEN_H
 
 #include stdint.h
+#include libavutil/attributes.h
 
 #include dvdata.h
 
@@ -47,7 +48,7 @@ typedef struct dv_vlc_pair {
 #else
 static struct dv_vlc_pair dv_vlc_map[DV_VLC_MAP_RUN_SIZE][DV_VLC_MAP_LEV_SIZE];
 
-static void dv_vlc_map_tableinit(void)
+static av_cold void dv_vlc_map_tableinit(void)
 {
 int i, j;
 for (i = 0; i  NB_DV_VLC - 1; i++) {
diff --git a/libavcodec/motionpixels_tablegen.h 
b/libavcodec/motionpixels_tablegen.h
index 8fb840f..4ffe74c 100644
--- a/libavcodec/motionpixels_tablegen.h
+++ b/libavcodec/motionpixels_tablegen.h
@@ -24,6 +24,7 @@
 #define AVCODEC_MOTIONPIXELS_TABLEGEN_H
 
 #include stdint.h
+#include libavutil/attributes.h
 
 typedef struct YuvPixel {
 int8_t y, v, u;
@@ -49,7 +50,7 @@ static int mp_yuv_to_rgb(int y, int v, int u, int clip_rgb) {
 #else
 static YuvPixel mp_rgb_yuv_table[1  15];
 
-static void mp_set_zero_yuv(YuvPixel *p)
+static av_cold void mp_set_zero_yuv(YuvPixel *p)
 {
 int i, j;
 
@@ -63,7 +64,7 @@ static void mp_set_zero_yuv(YuvPixel *p)
 }
 }
 
-static void mp_build_rgb_yuv_table(YuvPixel *p)
+static av_cold void mp_build_rgb_yuv_table(YuvPixel *p)
 {
 int y, v, u, i;
 
@@ -81,7 +82,7 @@ static void mp_build_rgb_yuv_table(YuvPixel *p)
 mp_set_zero_yuv(p + i * 32);
 }
 
-static void motionpixels_tableinit(void)
+static av_cold void motionpixels_tableinit(void)
 {
 if (!mp_rgb_yuv_table[0].u)
 mp_build_rgb_yuv_table(mp_rgb_yuv_table);
diff --git a/libavcodec/mpegaudio_tablegen.h b/libavcodec/mpegaudio_tablegen.h
index f9557c9..86b2cd3 100644
--- a/libavcodec/mpegaudio_tablegen.h
+++ b/libavcodec/mpegaudio_tablegen.h
@@ -25,6 +25,7 @@
 
 #include stdint.h
 #include math.h
+#include libavutil/attributes.h
 
 #define TABLE_4_3_SIZE (8191 + 16)*4
 #if CONFIG_HARDCODED_TABLES
@@ -41,7 +42,7 @@ static float expval_table_float[512][16];
 #define FRAC_BITS 23
 #define IMDCT_SCALAR 1.759
 
-static void mpegaudio_tableinit(void)
+static av_cold void mpegaudio_tableinit(void)
 {
 int i, value, exponent;
 for (i = 1; i  TABLE_4_3_SIZE; i++) {
-- 
2.1.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH 5/6] xv.c: Add missing const to lookup table.

2014-08-30 Thread Reimar Döffinger
On Sat, Aug 30, 2014 at 05:55:39PM +0200, Paul B Mahol wrote:
 On 8/30/14, Reimar Doeffinger reimar.doeffin...@gmx.de wrote:
  Signed-off-by: Reimar Doeffinger reimar.doeffin...@gmx.de
  ---
   libavdevice/xv.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)
 
 lgtm

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


Re: [FFmpeg-devel] [PATCH] WMA: add const to avoid warnings with hardcoded tables.

2014-08-30 Thread Michael Niedermayer
On Sat, Aug 30, 2014 at 06:00:20PM +0200, Reimar Döffinger wrote:
 Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
 ---
  libavcodec/wma.h   | 2 +-
  libavcodec/wmaprodec.c | 4 ++--
  2 files changed, 3 insertions(+), 3 deletions(-)

LGTM

thanks

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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


Re: [FFmpeg-devel] [PATCH] Add av_cold to table generation functions.

2014-08-30 Thread Michael Niedermayer
On Sat, Aug 30, 2014 at 06:00:43PM +0200, Reimar Döffinger wrote:
 Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
 ---
  libavcodec/aac_tablegen.h  | 2 +-
  libavcodec/aacps_tablegen.h| 4 ++--
  libavcodec/aacsbr_tablegen.h   | 2 +-
  libavcodec/cbrt_tablegen.h | 3 ++-
  libavcodec/dv_tablegen.h   | 3 ++-
  libavcodec/motionpixels_tablegen.h | 7 ---
  libavcodec/mpegaudio_tablegen.h| 3 ++-
  7 files changed, 14 insertions(+), 10 deletions(-)

probably ok

[...]
-- 
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] cabac: initialize all of ff_h264_cabac_tables programmatically.

2014-08-30 Thread wm4
On Sat, 30 Aug 2014 18:41:52 +0200
Reimar Döffinger reimar.doeffin...@gmx.de wrote:

 On 30.08.2014, at 18:29, Reimar Döffinger reimar.doeffin...@gmx.de wrote:
  On Sat, Aug 30, 2014 at 06:20:56PM +0200, wm4 wrote:
  On Sat, 30 Aug 2014 18:18:41 +0200
  Reimar Döffinger reimar.doeffin...@gmx.de wrote:
  
  Moves it from .data to .bss, slightly reducing binary size.
  
  Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
  ---
  libavcodec/cabac.c | 26 --
  1 file changed, 4 insertions(+), 22 deletions(-)
  
  diff --git a/libavcodec/cabac.c b/libavcodec/cabac.c
  index 65579d8..803c81c 100644
  --- a/libavcodec/cabac.c
  +++ b/libavcodec/cabac.c
  @@ -32,28 +32,7 @@
  #include cabac.h
  #include cabac_functions.h
  
  -uint8_t ff_h264_cabac_tables[512 + 4*2*64 + 4*64 + 63] = {
  - 9,8,7,7,6,6,6,6,5,5,5,5,5,5,5,5,
  - 4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,
  - 3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
  - 3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
  - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
  - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
  - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
  - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
  - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
  - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
  - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
  - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
  - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
  -};
  +uint8_t ff_h264_cabac_tables[512 + 4*2*64 + 4*64 + 63];
  
  static const uint8_t lps_range[64][4]= {
  {128,176,208,240}, {128,167,197,227}, {128,158,187,216}, 
  {123,150,178,205},
  @@ -143,6 +122,9 @@ void ff_init_cabac_states(void)
  if (initialized)
  return;
  
  +for (i = 0; i  512; i++)
  +ff_h264_norm_shift[i] = i ? 8 - av_log2(i) : 9;
  +
  for(i=0; i64; i++){
  for(j=0; j4; j++){ //FIXME check if this is worth the 1 shift we 
  save
  ff_h264_lps_range[j*2*64+2*i+0]=
  
  Doesn't this make library safety issues worse, instead of improving it?
  
  Why would it make anything even a slightest bit worse than it is now?
  Also, it makes it easier to make this hardcoded, which I think solves
  your concern?
 
 Just to be clear since it's not obvious: the lines just below what I added 
 initialise the second half of the array.
 I just added that the first half is initialised in the same place.

I have no strong feelings about it, but adding even more global mutable
state feels wrong. Yes, I know there are many places like this etc.,
so your patch is pretty innocent, but still I wonder why you'd optimize
for binary size, in exchange for higher RAM usage. What is your
motivation for doing this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] libavdevice/v4l2: fix of crash caused by assert

2014-08-30 Thread Michael Niedermayer
On Sat, Aug 30, 2014 at 08:19:37PM +0400, Dmitry Volyntsev wrote:
 To understand the problem one needs to see the original code around
 and to think what would happen if from time to time while capturing
 condition (s-frame_size  0  buf.bytesused != s-frame_size)
 happens to be true (this is not critical error so capturing would
 continue). It is obvious that eventually buffers_queued would become 
 1.

why is this condition true, what are these mismatching buffers ?


 
 static int mmap_read_frame(AVFormatContext *ctx, AVPacket *pkt)
 {
   ...
 if (buf.index = s-buffers) {
 av_log(ctx, AV_LOG_ERROR, Invalid buffer index received.\n);
 
 return AVERROR(EINVAL);
 }
 
 avpriv_atomic_int_add_and_fetch(s-buffers_queued, -1);
 // always keep at least one buffer queued
 av_assert0(avpriv_atomic_int_get(s-buffers_queued) = 1);
 
 if (s-frame_size  0  buf.bytesused != s-frame_size) {
av_log(ctx, AV_LOG_ERROR,
The v4l2 frame is %d bytes, but %d bytes are expected\n,
buf.bytesused, s-frame_size);
 return AVERROR_INVALIDDATA;
 
 }
 
 So my solution:  we should make all checks here before decrementing
 buffers_queued
 
 On Wed, Aug 27, 2014 at 1:20 AM, Michael Niedermayer michae...@gmx.at wrote:
  On Wed, Aug 13, 2014 at 07:04:01PM +0400, Dmitry Volyntsev wrote:
  From: Dmitry Volyntsev xeioexcept...@gmail.com
 
  s-buffers_queued constantly decremented and not incremented
  in case of (s-frame_size  0  buf.bytesused != s-frame_size)
  condition (caught on long run capture of Logitech C310)
 
  can you explain why this happens ? where do this misatching
  bufs come from ?
  why is droping them correct ?
 
 
  [...]
  --
  Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
 
  Dictatorship naturally arises out of democracy, and the most aggravated
  form of tyranny and slavery out of the most extreme liberty. -- Plato
 
 
 
 -- 
 Be happy,
 Best regards,
 Dmitry Volyntsev
 ___
 ffmpeg-devel mailing list
 ffmpeg-devel@ffmpeg.org
 http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 

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


Re: [FFmpeg-devel] [PATCH] cabac: initialize all of ff_h264_cabac_tables programmatically.

2014-08-30 Thread Reimar Döffinger
On 30.08.2014, at 19:46, Reimar Döffinger reimar.doeffin...@gmx.de wrote:
 On 30.08.2014, at 19:01, wm4 nfx...@googlemail.com wrote:
 
 but still I wonder why you'd optimize
 for binary size, in exchange for higher RAM usage. What is your
 motivation for doing this?
 
 The only higher RAM usage would be when you actually use H.264, and it would 
 be from the two additional lines of code.
 When you are not using H.264 the RAM usage (with some caveats on what the 
 linker does) will be several 100 bytes lower.

Small amendment: I missed that Linux seems to use copy-on-write for the data 
section.
This means that the first 512 bytes of the table could in theory end up being 
shared. You'd have to be lucky enough that they just end up on a different page 
than the rest of the array. At the same time, the extra RAM usage when H.264 is 
not used would be once per system, not per process.
I still wouldn't count it as using more RAM, especially considering not all 
OSes handle this as nicely as Linux, but it makes it a bit more borderline.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] cabac: initialize all of ff_h264_cabac_tables programmatically.

2014-08-30 Thread wm4
On Sat, 30 Aug 2014 19:58:11 +0200
Reimar Döffinger reimar.doeffin...@gmx.de wrote:

 On 30.08.2014, at 19:46, Reimar Döffinger reimar.doeffin...@gmx.de wrote:
  On 30.08.2014, at 19:01, wm4 nfx...@googlemail.com wrote:
  
  but still I wonder why you'd optimize
  for binary size, in exchange for higher RAM usage. What is your
  motivation for doing this?
  
  The only higher RAM usage would be when you actually use H.264, and it 
  would be from the two additional lines of code.
  When you are not using H.264 the RAM usage (with some caveats on what the 
  linker does) will be several 100 bytes lower.
 
 Small amendment: I missed that Linux seems to use copy-on-write for the data 
 section.
 This means that the first 512 bytes of the table could in theory end up being 
 shared. You'd have to be lucky enough that they just end up on a different 
 page than the rest of the array. At the same time, the extra RAM usage when 
 H.264 is not used would be once per system, not per process.
 I still wouldn't count it as using more RAM, especially considering not all 
 OSes handle this as nicely as Linux, but it makes it a bit more borderline.

OK... never mind then.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] lavu/hash.c: Add missing static const.

2014-08-30 Thread Clément Bœsch
On Sat, Aug 30, 2014 at 04:36:57PM +0200, Reimar Döffinger wrote:
 On Fri, Aug 29, 2014 at 09:29:46PM +0200, Clément Bœsch wrote:
  On Fri, Aug 29, 2014 at 06:34:52PM +0200, Reimar Döffinger wrote:
   Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
   ---
libavutil/hash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
   
   diff --git a/libavutil/hash.c b/libavutil/hash.c
   index 773f29e..979fdd9 100644
   --- a/libavutil/hash.c
   +++ b/libavutil/hash.c
   @@ -63,7 +63,7 @@ typedef struct AVHashContext {
struct {
const char *name;
int size;
   -} hashdesc[] = {
   +} static const hashdesc[] = {
[MD5] = {MD5, 16},
[MURMUR3] = {murmur3, 16},
[RIPEMD128] = {RIPEMD128, 16},
  
  shouldn't that be static const struct { } hashdesc[] = { ... }
  
  as in static const type foo[] = { ... };
 
 Reason I prefer this one is that if the struct becomes
 large it because very non-obvious that the array actually is
 static const.
 It also is much harder to check/filter with grep.
 So for practical reasons I think it is better to place it here,
 or alternatively to name the struct and split them...
 But mostly I care about having it in .rodata, everything else
 I'm willing to adapt to what others prefer.

I'm mostly concerned about consistency. Except the one you added in
drawtext, this form is never used:

[~/src/ffmpeg]☭ git grep 'static const struct {'
libavcodec/aacps.c:static const struct {
libavcodec/aacsbr.c:static const struct {
libavcodec/dirac.c:static const struct {
libavcodec/dirac.c:static const struct {
libavcodec/indeo4.c:static const struct {
libavcodec/jacosubdec.c:static const struct {
libavcodec/libschroedinger.h:static const struct {
libavcodec/mace.c:static const struct {
libavcodec/svq3.c:static const struct {
libavcodec/twinvq_data.h:static const struct {
libavcodec/vorbis_enc_data.h:static const struct {
libavcodec/vorbis_enc_data.h:static const struct {
libavcodec/vp9.c:static const struct {
libavcodec/webvttdec.c:static const struct {
libavdevice/v4l.c:static const struct {
libavfilter/avf_showspectrum.c:static const struct {
libavfilter/vf_curves.c:static const struct {
libavfilter/vf_mp.c:static const struct {
libavfilter/vf_signalstats.c:static const struct {
libavformat/gxfenc.c:static const struct {
libavformat/mov_chan.c:static const struct {
libavformat/movenc.c:static const struct {
libavformat/mxf.c:static const struct {
libavformat/mxfenc.c:static const struct {
libavformat/rtp.c:static const struct {
libavformat/utils.c:static const struct {
libavutil/channel_layout.c:static const struct {
libavutil/cpu.c:static const struct {
libavutil/eval.c:static const struct {
[~/src/ffmpeg]☭ git grep '} static const'
libavfilter/vf_drawtext.c:} static const ft_errors[] =
[~/src/ffmpeg]☭  

-- 
Clément B.


pgpWl839lazpB.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] lavu/hash.c: Add missing static const.

2014-08-30 Thread Timothy Gu
On Aug 30, 2014 7:37 AM, Reimar Döffinger reimar.doeffin...@gmx.de
wrote:

 But mostly I care about having it in .rodata, everything else
 I'm willing to adapt to what others prefer.

What are the gains for using .rodata instead of .data?

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


Re: [FFmpeg-devel] [PATCH] lavu/hash.c: Add missing static const.

2014-08-30 Thread Reimar Döffinger
On Sat, Aug 30, 2014 at 12:58:35PM -0700, Timothy Gu wrote:
 On Aug 30, 2014 7:37 AM, Reimar Döffinger reimar.doeffin...@gmx.de
 wrote:
 
  But mostly I care about having it in .rodata, everything else
  I'm willing to adapt to what others prefer.
 
 What are the gains for using .rodata instead of .data?

It is read-only.
Which means at least
1) It is shared between all processes using the library
2) It cannot be overwritten, accidentally or as part of an exploit

Maybe other things I can't think of right now.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 4/6] lavf: add const/static const to pix_fmts arrays.

2014-08-30 Thread Michael Niedermayer
On Sat, Aug 30, 2014 at 04:43:42PM +0200, Reimar Döffinger wrote:
 Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
 ---
  libavfilter/vf_blackdetect.c| 2 +-
  libavfilter/vf_lenscorrection.c | 2 +-
  libavfilter/vf_signalstats.c| 2 +-
  libavfilter/vf_tinterlace.c | 2 +-
  4 files changed, 4 insertions(+), 4 deletions(-)

LGTM

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

The real ebay dictionary, page 3
Rare item - Common item with rare defect or maybe just a lie
Professional - 'Toy' made in china, not functional except as doorstop
Experts will know - The seller hopes you are not an expert


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


Re: [FFmpeg-devel] [PATCH 3/6] sipr16kdata.h: add forgotten const.

2014-08-30 Thread Michael Niedermayer
On Sat, Aug 30, 2014 at 04:43:41PM +0200, Reimar Döffinger wrote:
 Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
 ---
  libavcodec/sipr16kdata.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

LGTM

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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


Re: [FFmpeg-devel] [PATCH 6/6] ac3dec_fixed: add missing static const.

2014-08-30 Thread Michael Niedermayer
On Sat, Aug 30, 2014 at 04:43:44PM +0200, Reimar Döffinger wrote:
 Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
 ---
  libavcodec/ac3dec_fixed.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

LGTM

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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


Re: [FFmpeg-devel] [PATCH] Add SUP/PGS subtitle demuxer

2014-08-30 Thread wm4
On Sat, 30 Aug 2014 18:16:27 -0400
Marcus Johnson bumblebritche...@gmail.com wrote:

 Here's a PGS subtitle sample from Eac3to:
 https://dl.dropboxusercontent.com/u/52358991/English.zip
 

Thanks!

The DTS fields in this one are all 0 too.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Add SUP/PGS subtitle demuxer

2014-08-30 Thread Timothy Gu
On Sat, Aug 30, 2014 at 9:41 PM, Marcus Johnson
bumblebritche...@gmail.com wrote:
 If you don't mind me asking, what is DTS? because when I hear it I think of
 the DTS audio codec, but I know it's obviously not that, and googling DTS
 in the codec context won't get me anywhere.

DTS = decoding time stamp
PTS = presentation time stamp

See 
http://stackoverflow.com/questions/6044330/ffmpeg-c-what-are-pts-and-dts-what-does-this-code-block-do-in-ffmpeg-c

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