date:20150616

Re: [FFmpeg-devel] [PATCH] libvpxenc: add color-space option for vp9

2015-06-16 Thread James Almer

On 16/06/15 2:43 AM, James Zern wrote:
> the vp9 bitstream supports 8 values:
> unknown (default), bt601, bt709, smpte170, smpte240, bt2020, reserved
> and sRGB.
> ---
>  doc/encoders.texi  | 12 
>  libavcodec/libvpxenc.c | 22 ++
>  2 files changed, 34 insertions(+)
> 
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 8b0ecb7..09c90c2 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -1550,6 +1550,18 @@ Enable frame parallel decodability features.
>  @item aq-mode
>  Set adaptive quantization mode (0: off (default), 1: variance 2: complexity, 
> 3:
>  cyclic refresh).
> +@item color-space
> +Set input color space.
> +@table @samp
> +@item unknown
> +@item bt601
> +@item bt709
> +@item smpte170
> +@item smpte240
> +@item bt2020
> +@item reserved
> +@item sRGB
> +@end table
>  @end table
>  
>  @end table
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 28a0e14..10f16e7 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -100,8 +100,12 @@ typedef struct VP8EncoderContext {
>  int tile_rows;
>  int frame_parallel;
>  int aq_mode;
> +int colorspace;
>  } VP8Context;
>  
> +// VP9E_SET_COLOR_SPACE was added just prior to v1.4.0.
> +#define HAVE_VP9_COLORSPACE_CONTROL (VPX_ENCODER_ABI_VERSION > 8)

Why this custom define? the end result is not shorter and there are other uses 
of VPX version
defines on this same file, like VPX_IMAGE_ABI_VERSION.

> +
>  /** String mappings for enum vp8e_enc_control_id */
>  static const char *const ctlidstr[] = {
>  [VP8E_UPD_ENTROPY]   = "VP8E_UPD_ENTROPY",
> @@ -128,6 +132,9 @@ static const char *const ctlidstr[] = {
>  [VP9E_SET_TILE_ROWS]   = "VP9E_SET_TILE_ROWS",
>  [VP9E_SET_FRAME_PARALLEL_DECODING] = "VP9E_SET_FRAME_PARALLEL_DECODING",
>  [VP9E_SET_AQ_MODE] = "VP9E_SET_AQ_MODE",
> +#if HAVE_VP9_COLORSPACE_CONTROL
> +[VP9E_SET_COLOR_SPACE] = "VP9E_SET_COLOR_SPACE",
> +#endif
>  #endif
>  };
>  
> @@ -593,6 +600,10 @@ static av_cold int vpx_init(AVCodecContext *avctx,
>  codecctl_int(avctx, VP9E_SET_FRAME_PARALLEL_DECODING, 
> ctx->frame_parallel);
>  if (ctx->aq_mode >= 0)
>  codecctl_int(avctx, VP9E_SET_AQ_MODE, ctx->aq_mode);
> +#if HAVE_VP9_COLORSPACE_CONTROL
> +if (ctx->colorspace >= 0)
> +codecctl_int(avctx, VP9E_SET_COLOR_SPACE, ctx->colorspace);
> +#endif
>  }
>  #endif
>  
> @@ -968,6 +979,17 @@ static const AVOption vp9_options[] = {
>  { "variance","Variance based Aq",   0, AV_OPT_TYPE_CONST, {.i64 
> = 1}, 0, 0, VE, "aq_mode" },
>  { "complexity",  "Complexity based Aq", 0, AV_OPT_TYPE_CONST, {.i64 
> = 2}, 0, 0, VE, "aq_mode" },
>  { "cyclic",  "Cyclic Refresh Aq",   0, AV_OPT_TYPE_CONST, {.i64 
> = 3}, 0, 0, VE, "aq_mode" },
> +#if HAVE_VP9_COLORSPACE_CONTROL
> +{ "color-space", "Input color space",   
> OFFSET(colorspace),  AV_OPT_TYPE_INT, {.i64 = -1}, -1, 7, VE, 
> "colorspace"},
> +{ "unknown", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
> VPX_CS_UNKNOWN},   0, 0, VE, "colorspace" },
> +{ "bt601",   NULL, 0, AV_OPT_TYPE_CONST, {.i64 = VPX_CS_BT_601}, 
>0, 0, VE, "colorspace" },
> +{ "bt709",   NULL, 0, AV_OPT_TYPE_CONST, {.i64 = VPX_CS_BT_709}, 
>0, 0, VE, "colorspace" },
> +{ "smpte170",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
> VPX_CS_SMPTE_170}, 0, 0, VE, "colorspace" },
> +{ "smpte240",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
> VPX_CS_SMPTE_240}, 0, 0, VE, "colorspace" },
> +{ "bt2020",  NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
> VPX_CS_BT_2020},   0, 0, VE, "colorspace" },
> +{ "reserved",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
> VPX_CS_RESERVED},  0, 0, VE, "colorspace" },
> +{ "sRGB",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = VPX_CS_SRGB},   
>0, 0, VE, "colorspace" },
> +#endif
>  LEGACY_OPTIONS
>  { NULL }
>  };
> 

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

Re: [FFmpeg-devel] [PATCH] avio: fix potential crashes when combining ffio_ensure_seekback + crc

2015-06-16 Thread Michael Niedermayer

On Wed, Jun 17, 2015 at 12:21:02AM +0200, wm4 wrote:
> Calling ffio_ensure_seekback() if ffio_init_checksum() has been called
> on the same context can lead to out of bounds memory accesses and
> crashes. The reason is that ffio_ensure_seekback() does not update
> checksum_ptr after reallocating the buffer, resulting in a dangling
> pointer.
> 
> This effectively fixes potential crashes when opening mp3 files.
> ---
> checksum_ptr is an abomination. Should probably be replaced by an
> offset or so, except it's part of the ABI now.
> ---
>  libavformat/aviobuf.c | 4 
>  1 file changed, 4 insertions(+)

applied

thanks

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

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


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

[FFmpeg-devel] [PATCH 6/6] lavf/brstm: expose the loop point when present

2015-06-16 Thread Rodger Combs

---
 libavformat/brstm.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/libavformat/brstm.c b/libavformat/brstm.c
index 8adffb8..53d8da9 100644
--- a/libavformat/brstm.c
+++ b/libavformat/brstm.c
@@ -72,6 +72,7 @@ static int read_header(AVFormatContext *s)
 uint32_t size, start, asize;
 AVStream *st;
 int ret = AVERROR_EOF;
+int loop = 0;
 
 b->bfstm = !strcmp("bfstm", s->iformat->name);
 
@@ -173,7 +174,7 @@ static int read_header(AVFormatContext *s)
 return AVERROR_PATCHWELCOME;
 }
 
-avio_skip(s->pb, 1); // loop flag
+loop = avio_r8(s->pb); // loop flag
 st->codec->codec_id = codec;
 st->codec->channels = avio_r8(s->pb);
 if (!st->codec->channels)
@@ -189,7 +190,12 @@ static int read_header(AVFormatContext *s)
 
 if (!b->bfstm)
 avio_skip(s->pb, 2); // padding
-avio_skip(s->pb, 4); // loop start sample
+
+if (loop)
+s->loop_start = av_rescale(avio_rb32(s->pb), AV_TIME_BASE, 
st->codec->sample_rate);
+else
+avio_skip(s->pb, 4);
+
 st->start_time = 0;
 st->duration = avio_rb32(s->pb);
 avpriv_set_pts_info(st, 64, 1, st->codec->sample_rate);
-- 
2.4.1

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

[FFmpeg-devel] [PATCH 5/6] ffprobe: display loop points when applicable

2015-06-16 Thread Rodger Combs

---
 ffprobe.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/ffprobe.c b/ffprobe.c
index 3e5324e..d54eb87 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -2436,6 +2436,10 @@ static int show_format(WriterContext *w, AVFormatContext 
*fmt_ctx)
 }
 print_time("start_time",  fmt_ctx->start_time, &AV_TIME_BASE_Q);
 print_time("duration",fmt_ctx->duration,   &AV_TIME_BASE_Q);
+if (fmt_ctx->loop_start != AV_NOPTS_VALUE)
+print_time("loop_start",  fmt_ctx->loop_start, &AV_TIME_BASE_Q);
+if (fmt_ctx->loop_end != AV_NOPTS_VALUE)
+print_time("loop_end",  fmt_ctx->loop_end, &AV_TIME_BASE_Q);
 if (size >= 0) print_val("size", size, unit_byte_str);
 else   print_str_opt("size", "N/A");
 if (fmt_ctx->bit_rate > 0) print_val("bit_rate", fmt_ctx->bit_rate, 
unit_bit_per_second_str);
-- 
2.4.1

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

[FFmpeg-devel] [PATCH 4/6] lavf: add support for loop points

2015-06-16 Thread Rodger Combs

---
 libavformat/avformat.h  | 12 
 libavformat/options_table.h |  2 ++
 libavformat/utils.c |  2 +-
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 719c23b..8158874 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1799,6 +1799,18 @@ typedef struct AVFormatContext {
  * Demuxing: Set by user.
  */
 int (*open_cb)(struct AVFormatContext *s, AVIOContext **p, const char 
*url, int flags, const AVIOInterruptCB *int_cb, AVDictionary **options);
+
+/**
+ * Suggested timestamps to start and end a loop at, in
+ * AV_TIME_BASE fractional seconds. AV_NOPTS_VALUE for loop_start indicates
+ * no looping. AV_NOPTS_VALUE for loop_end indicates the end of the file.
+ * loop_end before loop_start indicates ping-pong looping.
+ *
+ * - muxing: Set by user
+ * - demuxing: Set by avformat
+ */
+int64_t loop_start;
+int64_t loop_end;
 } AVFormatContext;
 
 int av_format_get_probe_score(const AVFormatContext *s);
diff --git a/libavformat/options_table.h b/libavformat/options_table.h
index 58670b0..8dec7e5 100644
--- a/libavformat/options_table.h
+++ b/libavformat/options_table.h
@@ -100,6 +100,8 @@ static const AVOption avformat_options[] = {
 {"dump_separator", "set information dump field separator", 
OFFSET(dump_separator), AV_OPT_TYPE_STRING, {.str = ", "}, CHAR_MIN, CHAR_MAX, 
D|E},
 {"codec_whitelist", "List of decoders that are allowed to be used", 
OFFSET(codec_whitelist), AV_OPT_TYPE_STRING, { .str = NULL },  CHAR_MIN, 
CHAR_MAX, D },
 {"format_whitelist", "List of demuxers that are allowed to be used", 
OFFSET(format_whitelist), AV_OPT_TYPE_STRING, { .str = NULL },  CHAR_MIN, 
CHAR_MAX, D },
+{"loop_start", "start time of a loop", OFFSET(loop_start), AV_OPT_TYPE_INT64, 
{.i64 = AV_NOPTS_VALUE}, INT64_MIN, INT64_MAX, E},
+{"loop_end", "start time of a loop", OFFSET(loop_end), AV_OPT_TYPE_INT64, 
{.i64 = AV_NOPTS_VALUE}, INT64_MIN, INT64_MAX, E},
 {NULL},
 };
 
diff --git a/libavformat/utils.c b/libavformat/utils.c
index caa15ab..36961f0 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -445,7 +445,7 @@ int avformat_open_input(AVFormatContext **ps, const char 
*filename,
 }
 }
 
-s->duration = s->start_time = AV_NOPTS_VALUE;
+s->duration = s->start_time = s->loop_start = s->loop_end = AV_NOPTS_VALUE;
 av_strlcpy(s->filename, filename ? filename : "", sizeof(s->filename));
 
 /* Allocate private data. */
-- 
2.4.1

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

[FFmpeg-devel] [PATCH 2/6] lavc/adpcm: THP: handle trailing padding

2015-06-16 Thread Rodger Combs

---
 libavcodec/adpcm.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index 22b5468..07ebce8 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -637,7 +637,7 @@ static int get_nb_samples(AVCodecContext *avctx, 
GetByteContext *gb,
 }
 case AV_CODEC_ID_ADPCM_THP:
 if (avctx->extradata) {
-nb_samples = buf_size / (8 * ch) * 14;
+nb_samples = buf_size * 14 / (8 * ch);
 break;
 }
 has_coded_samples = 1;
@@ -1472,6 +1472,9 @@ static int adpcm_decode_frame(AVCodecContext *avctx, void 
*data,
 }
 }
 }
+
+// Consume trailing padding
+bytestream2_skip(&gb, bytestream2_get_bytes_left(&gb));
 break;
 }
 case AV_CODEC_ID_ADPCM_DTK:
-- 
2.4.1

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

[FFmpeg-devel] [PATCH 3/6] lavf/brstm: add support for seeking

2015-06-16 Thread Rodger Combs

---
 libavformat/brstm.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/libavformat/brstm.c b/libavformat/brstm.c
index 1eba943..8adffb8 100644
--- a/libavformat/brstm.c
+++ b/libavformat/brstm.c
@@ -30,6 +30,7 @@ typedef struct BRSTMDemuxContext {
 uint32_tcurrent_block;
 uint32_tsamples_per_block;
 uint32_tlast_block_used_bytes;
+uint32_tdata_start;
 uint8_t *table;
 uint8_t *adpc;
 int bfstm;
@@ -298,6 +299,8 @@ static int read_header(AVFormatContext *s)
 }
 avio_skip(s->pb, start - avio_tell(s->pb));
 
+b->data_start = avio_tell(s->pb);
+
 if ((major != 1 || minor) && !b->bfstm)
 avpriv_request_sample(s, "Version %d.%d", major, minor);
 
@@ -363,6 +366,18 @@ static int read_packet(AVFormatContext *s, AVPacket *pkt)
 return ret;
 }
 
+static int read_seek(AVFormatContext *s, int stream_index,
+ int64_t timestamp, int flags)
+{
+AVStream *st = s->streams[stream_index];
+BRSTMDemuxContext *b = s->priv_data;
+timestamp /= b->samples_per_block;
+avio_seek(s->pb, b->data_start + timestamp * b->block_size, SEEK_SET);
+b->current_block = timestamp;
+ff_update_cur_dts(s, st, timestamp * b->samples_per_block);
+return 0;
+}
+
 AVInputFormat ff_brstm_demuxer = {
 .name   = "brstm",
 .long_name  = NULL_IF_CONFIG_SMALL("BRSTM (Binary Revolution Stream)"),
@@ -371,6 +386,7 @@ AVInputFormat ff_brstm_demuxer = {
 .read_header= read_header,
 .read_packet= read_packet,
 .read_close = read_close,
+.read_seek  = read_seek,
 .extensions = "brstm",
 };
 
@@ -382,5 +398,6 @@ AVInputFormat ff_bfstm_demuxer = {
 .read_header= read_header,
 .read_packet= read_packet,
 .read_close = read_close,
+.read_seek  = read_seek,
 .extensions = "bfstm",
 };
-- 
2.4.1

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

[FFmpeg-devel] [PATCH 1/6] lavf/brstm: add support for BFSTM files

2015-06-16 Thread Rodger Combs

---
 libavcodec/utils.c   |   4 ++
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/brstm.c  | 129 +++
 4 files changed, 115 insertions(+), 20 deletions(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 558afeb..a444a5e 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -3430,6 +3430,10 @@ int av_get_audio_frame_duration(AVCodecContext *avctx, 
int frame_bytes)
 return (frame_bytes - 4) * 2 / ch;
 case AV_CODEC_ID_ADPCM_IMA_AMV:
 return (frame_bytes - 8) * 2 / ch;
+case AV_CODEC_ID_ADPCM_THP:
+if (avctx->extradata)
+return frame_bytes * 14 / (8 * ch);
+break;
 case AV_CODEC_ID_ADPCM_XA:
 return (frame_bytes / 128) * 224 / ch;
 case AV_CODEC_ID_INTERPLAY_DPCM:
diff --git a/libavformat/Makefile b/libavformat/Makefile
index b9169d9..3c2cf9f 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -106,6 +106,7 @@ OBJS-$(CONFIG_BIT_MUXER) += bit.o
 OBJS-$(CONFIG_BMV_DEMUXER)   += bmv.o
 OBJS-$(CONFIG_BOA_DEMUXER)   += boadec.o
 OBJS-$(CONFIG_BRSTM_DEMUXER) += brstm.o
+OBJS-$(CONFIG_BFSTM_DEMUXER) += brstm.o
 OBJS-$(CONFIG_C93_DEMUXER)   += c93.o vocdec.o voc.o
 OBJS-$(CONFIG_CAF_DEMUXER)   += cafdec.o caf.o mov.o mov_chan.o \
 isom.o replaygain.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 3a49650..cc77d1c 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -93,6 +93,7 @@ void av_register_all(void)
 REGISTER_MUXDEMUX(BIT,  bit);
 REGISTER_DEMUXER (BMV,  bmv);
 REGISTER_DEMUXER (BRSTM,brstm);
+REGISTER_DEMUXER (BFSTM,bfstm);
 REGISTER_DEMUXER (BOA,  boa);
 REGISTER_DEMUXER (C93,  c93);
 REGISTER_MUXDEMUX(CAF,  caf);
diff --git a/libavformat/brstm.c b/libavformat/brstm.c
index 19a4a2a..1eba943 100644
--- a/libavformat/brstm.c
+++ b/libavformat/brstm.c
@@ -32,6 +32,7 @@ typedef struct BRSTMDemuxContext {
 uint32_tlast_block_used_bytes;
 uint8_t *table;
 uint8_t *adpc;
+int bfstm;
 } BRSTMDemuxContext;
 
 static int probe(AVProbeData *p)
@@ -43,6 +44,15 @@ static int probe(AVProbeData *p)
 return 0;
 }
 
+static int probe_bfstm(AVProbeData *p)
+{
+if (AV_RL32(p->buf) == MKTAG('F','S','T','M') &&
+(AV_RL16(p->buf + 4) == 0xFFFE ||
+ AV_RL16(p->buf + 4) == 0xFEFF))
+return AVPROBE_SCORE_MAX / 3 * 2;
+return 0;
+}
+
 static int read_close(AVFormatContext *s)
 {
 BRSTMDemuxContext *b = s->priv_data;
@@ -57,11 +67,13 @@ static int read_header(AVFormatContext *s)
 {
 BRSTMDemuxContext *b = s->priv_data;
 int bom, major, minor, codec, chunk;
-int64_t pos, h1offset, toffset;
+int64_t h1offset, pos, toffset, data_offset = 0;
 uint32_t size, start, asize;
 AVStream *st;
 int ret = AVERROR_EOF;
 
+b->bfstm = !strcmp("bfstm", s->iformat->name);
+
 st = avformat_new_stream(s, NULL);
 if (!st)
 return AVERROR(ENOMEM);
@@ -79,19 +91,65 @@ static int read_header(AVFormatContext *s)
 return AVERROR_PATCHWELCOME;
 }
 
-major = avio_r8(s->pb);
-minor = avio_r8(s->pb);
-avio_skip(s->pb, 4); // size of file
-size = avio_rb16(s->pb);
-if (size < 14)
-return AVERROR_INVALIDDATA;
+if (!b->bfstm) {
+major = avio_r8(s->pb);
+minor = avio_r8(s->pb);
+avio_skip(s->pb, 4); // size of file
+size = avio_rb16(s->pb);
+if (size < 14)
+return AVERROR_INVALIDDATA;
+
+avio_skip(s->pb, size - 14);
+pos = avio_tell(s->pb);
+if (avio_rl32(s->pb) != MKTAG('H','E','A','D'))
+return AVERROR_INVALIDDATA;
+} else {
+uint32_t info_offset = 0, info_size;
+uint16_t section_count, header_size, i;
+
+header_size = avio_rb16(s->pb); // 6
+
+avio_skip(s->pb, 4); // Unknown constant 0x0003
+avio_skip(s->pb, 4); // size of file
+section_count = avio_rb16(s->pb);
+avio_skip(s->pb, 2); // padding
+for (i = 0; avio_tell(s->pb) < header_size
+&& !(data_offset && info_offset)
+&& i < section_count; i++) {
+uint32_t flag = avio_rb32(s->pb);
+switch (flag) {
+case 0x4000:
+info_offset = avio_rb32(s->pb);
+info_size   = avio_rb32(s->pb);
+break;
+case 0x4001:
+avio_skip(s->pb, 4); // seek offset
+avio_skip(s->pb, 4); // seek size
+break;
+case 0x4002:
+data_offset = avio_rb32(s->pb);
+

[FFmpeg-devel] [PATCH] avio: fix potential crashes when combining ffio_ensure_seekback + crc

2015-06-16 Thread wm4

Calling ffio_ensure_seekback() if ffio_init_checksum() has been called
on the same context can lead to out of bounds memory accesses and
crashes. The reason is that ffio_ensure_seekback() does not update
checksum_ptr after reallocating the buffer, resulting in a dangling
pointer.

This effectively fixes potential crashes when opening mp3 files.
---
checksum_ptr is an abomination. Should probably be replaced by an
offset or so, except it's part of the ABI now.
---
 libavformat/aviobuf.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index dfefe62..194bc22 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -820,6 +820,8 @@ int ffio_ensure_seekback(AVIOContext *s, int64_t buf_size)
 return 0;
 av_assert0(!s->write_flag);
 
+ptrdiff_t checksum_ptr_offset = s->checksum_ptr ? s->checksum_ptr - 
s->buffer : -1;
+
 buffer = av_malloc(buf_size);
 if (!buffer)
 return AVERROR(ENOMEM);
@@ -830,6 +832,8 @@ int ffio_ensure_seekback(AVIOContext *s, int64_t buf_size)
 s->buf_end = buffer + (s->buf_end - s->buffer);
 s->buffer = buffer;
 s->buffer_size = buf_size;
+if (checksum_ptr_offset >= 0)
+s->checksum_ptr = s->buffer + checksum_ptr_offset;
 return 0;
 }
 
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH] avcodec/codec_desc: rename smv video codec name to smvjpeg to match decoder name

2015-06-16 Thread Andreas Cadhalpun

On 16.06.2015 22:29, Paul B Mahol wrote:
> On 6/16/15, Andreas Cadhalpun  wrote:
>> On 16.06.2015 21:31, Hendrik Leppkes wrote:
>>> I see no reason these strings should be considered API. They are
>>> descriptive names, not option tokens or anything.
>>> If you want a reliable static way to identify a codec, use the id.
>>
>> At least currently using the codec id is the only way to reliably
>> identify codecs, because there are decoders with the same name,
>> but different codec ids.
>> (name: "iff", id: AV_CODEC_ID_IFF_ILBM or AV_CODEC_ID_IFF_BYTERUN1)
>>
>> However, I think that is broken, but I'm not sure how that can be fixed.
> 
> That used to be two different decoders but now are both same decoder,
> my plan is to rename one to AV_CODEC_ID_IFF and deprecate other.

Ah, I see. Doing that would be good, but definitely requires a soversion bump.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] avcodec/codec_desc: rename smv video codec name to smvjpeg to match decoder name

2015-06-16 Thread Paul B Mahol

On 6/16/15, Andreas Cadhalpun  wrote:
> On 16.06.2015 21:31, Hendrik Leppkes wrote:
>> I see no reason these strings should be considered API. They are
>> descriptive names, not option tokens or anything.
>> If you want a reliable static way to identify a codec, use the id.
>
> At least currently using the codec id is the only way to reliably
> identify codecs, because there are decoders with the same name,
> but different codec ids.
> (name: "iff", id: AV_CODEC_ID_IFF_ILBM or AV_CODEC_ID_IFF_BYTERUN1)
>
> However, I think that is broken, but I'm not sure how that can be fixed.

That used to be two different decoders but now are both same decoder,
my plan is to rename one to AV_CODEC_ID_IFF and deprecate other.

>
> Best regards,
> Andreas
> ___
> 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] avcodec/codec_desc: rename smv video codec name to smvjpeg to match decoder name

2015-06-16 Thread Andreas Cadhalpun

On 16.06.2015 21:31, Hendrik Leppkes wrote:
> I see no reason these strings should be considered API. They are
> descriptive names, not option tokens or anything.
> If you want a reliable static way to identify a codec, use the id.

At least currently using the codec id is the only way to reliably
identify codecs, because there are decoders with the same name,
but different codec ids.
(name: "iff", id: AV_CODEC_ID_IFF_ILBM or AV_CODEC_ID_IFF_BYTERUN1)

However, I think that is broken, but I'm not sure how that can be fixed.

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

Re: [FFmpeg-devel] [PATCH] avcodec/codec_desc: rename smv video codec name to smvjpeg to match decoder name

2015-06-16 Thread wm4

On Tue, 16 Jun 2015 21:55:13 +0200
Hendrik Leppkes  wrote:

> On Tue, Jun 16, 2015 at 9:45 PM, wm4  wrote:
> > On Tue, 16 Jun 2015 21:31:26 +0200
> > Hendrik Leppkes  wrote:
> >
> >> On Tue, Jun 16, 2015 at 9:23 PM, wm4  wrote:
> >> > On Tue, 16 Jun 2015 21:18:13 +0200
> >> > Hendrik Leppkes  wrote:
> >> >
> >> >> On Tue, Jun 16, 2015 at 8:33 PM, wm4  wrote:
> >> >> > On Tue, 16 Jun 2015 13:29:55 +
> >> >> > Paul B Mahol  wrote:
> >> >> >
> >> >> >> Also fixes clash with smv audio codec.
> >> >> >>
> >> >> >> Signed-off-by: Paul B Mahol 
> >> >> >> ---
> >> >> >>  libavcodec/codec_desc.c | 2 +-
> >> >> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >> >>
> >> >> >> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> >> >> >> index c1694f3..f32843a 100644
> >> >> >> --- a/libavcodec/codec_desc.c
> >> >> >> +++ b/libavcodec/codec_desc.c
> >> >> >> @@ -1178,7 +1178,7 @@ static const AVCodecDescriptor 
> >> >> >> codec_descriptors[] = {
> >> >> >>  {
> >> >> >>  .id= AV_CODEC_ID_SMVJPEG,
> >> >> >>  .type  = AVMEDIA_TYPE_VIDEO,
> >> >> >> -.name  = "smv",
> >> >> >> +.name  = "smvjpeg",
> >> >> >>  .long_name = NULL_IF_CONFIG_SMALL("Sigmatel Motion Video"),
> >> >> >>  },
> >> >> >>
> >> >> >
> >> >> > An incompatible API change should come with a major bump.
> >> >> >
> >> >>
> >> >> Strings in the codec descriptor are API now?
> >> >
> >> > Of course. Just like AVOptions, filter names, etc.
> >> >
> >> > (The patch was pushed anyway. Who needs reviews. Or stable APIs.)
> >>
> >> If you want to go down that route, you could argue that any return
> >> value from any function is part of the API, and if it changes, it
> >> needs a major bump.
> >> .. and that would mean you cannot change anything ever at all.
> >>
> >> I see no reason these strings should be considered API. They are
> >> descriptive names, not option tokens or anything.
> >> If you want a reliable static way to identify a codec, use the id.
> >
> > Using strings for codec IDs is pretty flexible and convenient, and I
> > don't want to give up on it. But more importantly, these are being used
> > by many scripts and user interfaces which make use of libavcodec. Can
> > you imagine the chaos if you renamed the "h264" codec to "avc"? Do you
> > suppose applications should have their own lookup tables for
> > AV_CODEC_IDs? They'd have to update it all the time. And it wouldn't
> > work for scripts using ffmpeg.c (which makes ffmpeg.c an API user
> > relying on codec strings not changing randomly).
> >
> 
> But this is not the name of the decoder that was changed, which I
> would agree would be bad, since you can use it to select the decoder
> you want, but the codec descriptor.

Well, "libx264" (and "libx264rgb") is the name of the encoder, while
"h264" is the name of the codec (dictated by the codec descriptor). I
claim you can't rename either without breaking users.

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

Re: [FFmpeg-devel] [PATCH] doc: avoid incorrect phrase 'allows to'

2015-06-16 Thread Andreas Cadhalpun

On 16.06.2015 07:51, Lou Logan wrote:
> On Mon, Jun 15, 2015, at 08:24 AM, Andreas Cadhalpun wrote:
>>
>> OK, I reworded the changes in avformat.h. New patch attached.
> 
> Patch looks good to me. Thanks.

Pushed.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [libav-devel] [PATCH 2/2] matroskadec: validate audio channels and bitdepth

2015-06-16 Thread Andreas Cadhalpun

On 16.06.2015 03:22, Michael Niedermayer wrote:
> On Tue, Jun 16, 2015 at 12:09:37AM +0200, Andreas Cadhalpun wrote:
>>  matroskadec.c |   12 
>>  1 file changed, 12 insertions(+)
>> c84b48d9c49779669de96671e178dd1f6da215d9  
>> 0002-matroskadec-validate-audio-channels-and-bitdepth.patch
>> From 903de886ae73469831f3416d5fc57c2a6ab97708 Mon Sep 17 00:00:00 2001
>> From: Andreas Cadhalpun 
>> Date: Mon, 15 Jun 2015 21:06:51 +0200
>> Subject: [PATCH 2/2] matroskadec: validate audio channels and bitdepth
>>
>> In the TTA extradata re-construction the values are written with
>> avio_wl16 and if they don't fit into uint16_t, this triggers an
>> av_assert2 in avio_w8.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavformat/matroskadec.c | 12 
>>  1 file changed, 12 insertions(+)
> 
> LGTM

Pushed.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] configure: make makeinfo_html check more robust

2015-06-16 Thread Andreas Cadhalpun

On 16.06.2015 02:50, Timothy Gu wrote:
> On Sun, Jun 14, 2015 at 2:32 AM Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
> 
>> The current check is too strict for newer makeinfo versions.
>> Existing version strings are:
>> makeinfo (GNU texinfo) 4.13
>> makeinfo (GNU texinfo) 5.2
>> texi2any (GNU texinfo) 5.9.93
>>
>> Probably version 6 will come in the not too far future.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  configure | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
> Looks much better than my old one. Thanks!

Pushed.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH 1/2] matroskadec: check audio sample rate

2015-06-16 Thread Andreas Cadhalpun

On 16.06.2015 02:16, Michael Niedermayer wrote:
> On Mon, Jun 15, 2015 at 09:17:36PM +0200, Andreas Cadhalpun wrote:
>> And default to 8000 if it is invalid.
>>
>> An invalid sample rate can trigger av_assert2 in av_rescale_rnd.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavformat/matroskadec.c | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
>> index 3512f0f..81dd53f 100644
>> --- a/libavformat/matroskadec.c
>> +++ b/libavformat/matroskadec.c
>> @@ -1680,6 +1680,14 @@ static int matroska_parse_tracks(AVFormatContext *s)
>>  if (!track->codec_id)
>>  continue;
>>  
>> +if (track->audio.samplerate < 0 || track->audio.samplerate > 
>> INT_MAX ||
>> +isnan(track->audio.samplerate)) {
>> +av_log(matroska->ctx, AV_LOG_WARNING,
>> +   "Invalid sample rate %f, defaulting to 8000 instead.\n",
>> +   track->audio.samplerate);
>> +track->audio.samplerate = 8000;
>> +}
>> +
> 
> LGTM, alternatively the sample rate could be set to 0

I'd think using the MATROSKA_ID_AUDIOSAMPLINGFREQ default of 8000 is better,
but if there are good reasons to use 0 instead, that can be changed.

I pushed my patch with 8000 for now.

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

Re: [FFmpeg-devel] [libav-devel] [PATCH 2/2] matroskadec: validate audio channels and bitdepth

2015-06-16 Thread Andreas Cadhalpun

On 16.06.2015 00:37, Luca Barbato wrote:
> On 16/06/15 00:14, Andreas Cadhalpun wrote:
>>> I wonder if the sanity check in the decoder would be enough to not have
>>> other problems down the line.
>>
>> No, because the problem is in the two lines below the check.
> 
> Not here =)

The avio_wl16 calls are also present in Libav and writing something larger
than 16bit with them is a bug. The av_assert2 in FFmpeg is only a means
to detect such a bug.

>>> I'd provide an explode mode and as best effort mode I'd just mark the
>>> data as corrupted.
>>
>> What do you mean with marking the data as corrupted?
> 
> There is a packet flag, AV_PKT_FLAG_CORRUPT, to mark the data that
> shouldn't be trusted.

This flag is used rather rarely. I'm not convinced that it would be
particularly useful for this corner case.

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

Re: [FFmpeg-devel] [PATCH] avcodec/codec_desc: rename smv video codec name to smvjpeg to match decoder name

2015-06-16 Thread Hendrik Leppkes

On Tue, Jun 16, 2015 at 9:45 PM, wm4  wrote:
> On Tue, 16 Jun 2015 21:31:26 +0200
> Hendrik Leppkes  wrote:
>
>> On Tue, Jun 16, 2015 at 9:23 PM, wm4  wrote:
>> > On Tue, 16 Jun 2015 21:18:13 +0200
>> > Hendrik Leppkes  wrote:
>> >
>> >> On Tue, Jun 16, 2015 at 8:33 PM, wm4  wrote:
>> >> > On Tue, 16 Jun 2015 13:29:55 +
>> >> > Paul B Mahol  wrote:
>> >> >
>> >> >> Also fixes clash with smv audio codec.
>> >> >>
>> >> >> Signed-off-by: Paul B Mahol 
>> >> >> ---
>> >> >>  libavcodec/codec_desc.c | 2 +-
>> >> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >> >>
>> >> >> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
>> >> >> index c1694f3..f32843a 100644
>> >> >> --- a/libavcodec/codec_desc.c
>> >> >> +++ b/libavcodec/codec_desc.c
>> >> >> @@ -1178,7 +1178,7 @@ static const AVCodecDescriptor 
>> >> >> codec_descriptors[] = {
>> >> >>  {
>> >> >>  .id= AV_CODEC_ID_SMVJPEG,
>> >> >>  .type  = AVMEDIA_TYPE_VIDEO,
>> >> >> -.name  = "smv",
>> >> >> +.name  = "smvjpeg",
>> >> >>  .long_name = NULL_IF_CONFIG_SMALL("Sigmatel Motion Video"),
>> >> >>  },
>> >> >>
>> >> >
>> >> > An incompatible API change should come with a major bump.
>> >> >
>> >>
>> >> Strings in the codec descriptor are API now?
>> >
>> > Of course. Just like AVOptions, filter names, etc.
>> >
>> > (The patch was pushed anyway. Who needs reviews. Or stable APIs.)
>>
>> If you want to go down that route, you could argue that any return
>> value from any function is part of the API, and if it changes, it
>> needs a major bump.
>> .. and that would mean you cannot change anything ever at all.
>>
>> I see no reason these strings should be considered API. They are
>> descriptive names, not option tokens or anything.
>> If you want a reliable static way to identify a codec, use the id.
>
> Using strings for codec IDs is pretty flexible and convenient, and I
> don't want to give up on it. But more importantly, these are being used
> by many scripts and user interfaces which make use of libavcodec. Can
> you imagine the chaos if you renamed the "h264" codec to "avc"? Do you
> suppose applications should have their own lookup tables for
> AV_CODEC_IDs? They'd have to update it all the time. And it wouldn't
> work for scripts using ffmpeg.c (which makes ffmpeg.c an API user
> relying on codec strings not changing randomly).
>

But this is not the name of the decoder that was changed, which I
would agree would be bad, since you can use it to select the decoder
you want, but the codec descriptor.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/codec_desc: rename smv video codec name to smvjpeg to match decoder name

2015-06-16 Thread wm4

On Tue, 16 Jun 2015 21:31:26 +0200
Hendrik Leppkes  wrote:

> On Tue, Jun 16, 2015 at 9:23 PM, wm4  wrote:
> > On Tue, 16 Jun 2015 21:18:13 +0200
> > Hendrik Leppkes  wrote:
> >
> >> On Tue, Jun 16, 2015 at 8:33 PM, wm4  wrote:
> >> > On Tue, 16 Jun 2015 13:29:55 +
> >> > Paul B Mahol  wrote:
> >> >
> >> >> Also fixes clash with smv audio codec.
> >> >>
> >> >> Signed-off-by: Paul B Mahol 
> >> >> ---
> >> >>  libavcodec/codec_desc.c | 2 +-
> >> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> >> >> index c1694f3..f32843a 100644
> >> >> --- a/libavcodec/codec_desc.c
> >> >> +++ b/libavcodec/codec_desc.c
> >> >> @@ -1178,7 +1178,7 @@ static const AVCodecDescriptor 
> >> >> codec_descriptors[] = {
> >> >>  {
> >> >>  .id= AV_CODEC_ID_SMVJPEG,
> >> >>  .type  = AVMEDIA_TYPE_VIDEO,
> >> >> -.name  = "smv",
> >> >> +.name  = "smvjpeg",
> >> >>  .long_name = NULL_IF_CONFIG_SMALL("Sigmatel Motion Video"),
> >> >>  },
> >> >>
> >> >
> >> > An incompatible API change should come with a major bump.
> >> >
> >>
> >> Strings in the codec descriptor are API now?
> >
> > Of course. Just like AVOptions, filter names, etc.
> >
> > (The patch was pushed anyway. Who needs reviews. Or stable APIs.)
> 
> If you want to go down that route, you could argue that any return
> value from any function is part of the API, and if it changes, it
> needs a major bump.
> .. and that would mean you cannot change anything ever at all.
> 
> I see no reason these strings should be considered API. They are
> descriptive names, not option tokens or anything.
> If you want a reliable static way to identify a codec, use the id.

Using strings for codec IDs is pretty flexible and convenient, and I
don't want to give up on it. But more importantly, these are being used
by many scripts and user interfaces which make use of libavcodec. Can
you imagine the chaos if you renamed the "h264" codec to "avc"? Do you
suppose applications should have their own lookup tables for
AV_CODEC_IDs? They'd have to update it all the time. And it wouldn't
work for scripts using ffmpeg.c (which makes ffmpeg.c an API user
relying on codec strings not changing randomly).

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

Re: [FFmpeg-devel] [PATCH] avcodec/codec_desc: rename smv video codec name to smvjpeg to match decoder name

2015-06-16 Thread Hendrik Leppkes

On Tue, Jun 16, 2015 at 9:23 PM, wm4  wrote:
> On Tue, 16 Jun 2015 21:18:13 +0200
> Hendrik Leppkes  wrote:
>
>> On Tue, Jun 16, 2015 at 8:33 PM, wm4  wrote:
>> > On Tue, 16 Jun 2015 13:29:55 +
>> > Paul B Mahol  wrote:
>> >
>> >> Also fixes clash with smv audio codec.
>> >>
>> >> Signed-off-by: Paul B Mahol 
>> >> ---
>> >>  libavcodec/codec_desc.c | 2 +-
>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
>> >> index c1694f3..f32843a 100644
>> >> --- a/libavcodec/codec_desc.c
>> >> +++ b/libavcodec/codec_desc.c
>> >> @@ -1178,7 +1178,7 @@ static const AVCodecDescriptor codec_descriptors[] 
>> >> = {
>> >>  {
>> >>  .id= AV_CODEC_ID_SMVJPEG,
>> >>  .type  = AVMEDIA_TYPE_VIDEO,
>> >> -.name  = "smv",
>> >> +.name  = "smvjpeg",
>> >>  .long_name = NULL_IF_CONFIG_SMALL("Sigmatel Motion Video"),
>> >>  },
>> >>
>> >
>> > An incompatible API change should come with a major bump.
>> >
>>
>> Strings in the codec descriptor are API now?
>
> Of course. Just like AVOptions, filter names, etc.
>
> (The patch was pushed anyway. Who needs reviews. Or stable APIs.)

If you want to go down that route, you could argue that any return
value from any function is part of the API, and if it changes, it
needs a major bump.
.. and that would mean you cannot change anything ever at all.

I see no reason these strings should be considered API. They are
descriptive names, not option tokens or anything.
If you want a reliable static way to identify a codec, use the id.

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

Re: [FFmpeg-devel] [PATCH] avcodec/codec_desc: rename smv video codec name to smvjpeg to match decoder name

2015-06-16 Thread wm4

On Tue, 16 Jun 2015 21:18:13 +0200
Hendrik Leppkes  wrote:

> On Tue, Jun 16, 2015 at 8:33 PM, wm4  wrote:
> > On Tue, 16 Jun 2015 13:29:55 +
> > Paul B Mahol  wrote:
> >
> >> Also fixes clash with smv audio codec.
> >>
> >> Signed-off-by: Paul B Mahol 
> >> ---
> >>  libavcodec/codec_desc.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> >> index c1694f3..f32843a 100644
> >> --- a/libavcodec/codec_desc.c
> >> +++ b/libavcodec/codec_desc.c
> >> @@ -1178,7 +1178,7 @@ static const AVCodecDescriptor codec_descriptors[] = 
> >> {
> >>  {
> >>  .id= AV_CODEC_ID_SMVJPEG,
> >>  .type  = AVMEDIA_TYPE_VIDEO,
> >> -.name  = "smv",
> >> +.name  = "smvjpeg",
> >>  .long_name = NULL_IF_CONFIG_SMALL("Sigmatel Motion Video"),
> >>  },
> >>
> >
> > An incompatible API change should come with a major bump.
> >
> 
> Strings in the codec descriptor are API now?

Of course. Just like AVOptions, filter names, etc.

(The patch was pushed anyway. Who needs reviews. Or stable APIs.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/codec_desc: rename smv video codec name to smvjpeg to match decoder name

2015-06-16 Thread Hendrik Leppkes

On Tue, Jun 16, 2015 at 8:33 PM, wm4  wrote:
> On Tue, 16 Jun 2015 13:29:55 +
> Paul B Mahol  wrote:
>
>> Also fixes clash with smv audio codec.
>>
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/codec_desc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
>> index c1694f3..f32843a 100644
>> --- a/libavcodec/codec_desc.c
>> +++ b/libavcodec/codec_desc.c
>> @@ -1178,7 +1178,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
>>  {
>>  .id= AV_CODEC_ID_SMVJPEG,
>>  .type  = AVMEDIA_TYPE_VIDEO,
>> -.name  = "smv",
>> +.name  = "smvjpeg",
>>  .long_name = NULL_IF_CONFIG_SMALL("Sigmatel Motion Video"),
>>  },
>>
>
> An incompatible API change should come with a major bump.
>

Strings in the codec descriptor are API now?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/codec_desc: rename smv video codec name to smvjpeg to match decoder name

2015-06-16 Thread wm4

On Tue, 16 Jun 2015 13:29:55 +
Paul B Mahol  wrote:

> Also fixes clash with smv audio codec.
> 
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/codec_desc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index c1694f3..f32843a 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -1178,7 +1178,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
>  {
>  .id= AV_CODEC_ID_SMVJPEG,
>  .type  = AVMEDIA_TYPE_VIDEO,
> -.name  = "smv",
> +.name  = "smvjpeg",
>  .long_name = NULL_IF_CONFIG_SMALL("Sigmatel Motion Video"),
>  },
>  

An incompatible API change should come with a major bump.

(I guess my absolutely terrible mail client ate the previous mail I
sent.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Code review tools

2015-06-16 Thread Philip Langdale

Hi all,

I've been thinking about whether we'd benefit from using a code review
tool like reviewboard (www.reviewboard.org). I use reviewboard at work
and it offers a lot of features that make email based reviews seem very
crude by comparison.

For me, the stand out features are a very good diff viewer, handling of
inline comments and interdiffs between different versions of a change.
It also has explicit support for renames and can track chunks that are
moving around within a file.

There are obviously other tools out there, particularly gerrit, but
I've always felt reviewboard had the best review features (in contrast,
gerrit has very strong workflow capabilities - it will automatically
test and commit changes submited and reviewd through it - but it's
pretty bare in terms of the actual code review).

If there's enough interested, I'd be happy to get an instance of
reviewboard running on ffmpeg.org for us.

Thanks,

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

Re: [FFmpeg-devel] [PATCH] avcodec/codec_desc: rename smv video codec name to smvjpeg to match decoder name

2015-06-16 Thread Michael Niedermayer

On Tue, Jun 16, 2015 at 01:29:55PM +, Paul B Mahol wrote:
> Also fixes clash with smv audio codec.
> 
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/codec_desc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

LGTM

thanks

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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

Re: [FFmpeg-devel] [PATCH 2/2] MAINTAINERS: add myself as hls encryption maintainer

2015-06-16 Thread Michael Niedermayer

On Tue, Jun 16, 2015 at 09:15:57AM -0500, Christian Suloway wrote:
> Signed-off-by: Christian Suloway 
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)

applied

thanks

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

DNS cache poisoning attacks, popular search engine, Google internet authority
dont be evil, please


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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: removed empty/unused print_encryption_tag function

2015-06-16 Thread Michael Niedermayer

On Tue, Jun 16, 2015 at 09:15:56AM -0500, Christian Suloway wrote:
> Signed-off-by: Christian Suloway 
> ---
>  libavformat/hlsenc.c | 4 
>  1 file changed, 4 deletions(-)

applied

thanks

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

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.

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

[FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: removed empty/unused print_encryption_tag function

2015-06-16 Thread Christian Suloway

Signed-off-by: Christian Suloway 
---
 libavformat/hlsenc.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 68c6479..cf29f4f 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -310,10 +310,6 @@ static void hls_free_segments(HLSSegment *p)
 }
 }
 
-static void print_encryption_tag(HLSContext *hls, HLSSegment *en)
-{
-}
-
 static int hls_window(AVFormatContext *s, int last)
 {
 HLSContext *hls = s->priv_data;
-- 
2.4.2

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

[FFmpeg-devel] [PATCH 2/2] MAINTAINERS: add myself as hls encryption maintainer

2015-06-16 Thread Christian Suloway

Signed-off-by: Christian Suloway 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7b239a1..fa9e966 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -416,6 +416,7 @@ Muxers/Demuxers:
   gxf.c Reimar Doeffinger
   gxfenc.c  Baptiste Coudurier
   hls.c Anssi Hannula
+  hls encryption (hlsenc.c) Christian Suloway
   idcin.c   Mike Melanson
   idroqdec.cMike Melanson
   iff.c Jaikrishnan Menon
-- 
2.4.2

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

[FFmpeg-devel] [PATCH] avcodec/codec_desc: rename smv video codec name to smvjpeg to match decoder name

2015-06-16 Thread Paul B Mahol

Also fixes clash with smv audio codec.

Signed-off-by: Paul B Mahol 
---
 libavcodec/codec_desc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index c1694f3..f32843a 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1178,7 +1178,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
 {
 .id= AV_CODEC_ID_SMVJPEG,
 .type  = AVMEDIA_TYPE_VIDEO,
-.name  = "smv",
+.name  = "smvjpeg",
 .long_name = NULL_IF_CONFIG_SMALL("Sigmatel Motion Video"),
 },
 
-- 
1.7.11.2

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

Re: [FFmpeg-devel] [RFC] DXVA2 decoding and FFmpeg

2015-06-16 Thread Hendrik Leppkes

On Tue, Jun 16, 2015 at 2:30 PM, Stefano Sabatini  wrote:
> On date Tuesday 2015-06-16 14:16:11 +0200, Gwenole Beauchesne encoded:
>> Hi,
>>
>> 2015-06-16 14:03 GMT+02:00 Michael Niedermayer :
> [...]
>> >> +#if HAVE_SSE2
>> >> +/* Copy 16/64 bytes from srcp to dstp loading data with the SSE>=2 
>> >> instruction
>> >> + * load and storing data with the SSE>=2 instruction store.
>> >> + */
>> >> +#define COPY16(dstp, srcp, load, store) \
>> >> +__asm__ volatile (  \
>> >> +load "  0(%[src]), %%xmm1\n"\
>> >> +store " %%xmm1,0(%[dst])\n" \
>> >> +: : [dst]"r"(dstp), [src]"r"(srcp) : "memory", "xmm1")
>> >> +
>> >> +#define COPY64(dstp, srcp, load, store) \
>> >> +__asm__ volatile (  \
>> >> +load "  0(%[src]), %%xmm1\n"\
>> >> +load " 16(%[src]), %%xmm2\n"\
>> >> +load " 32(%[src]), %%xmm3\n"\
>> >> +load " 48(%[src]), %%xmm4\n"\
>> >> +store " %%xmm1,0(%[dst])\n" \
>> >> +store " %%xmm2,   16(%[dst])\n" \
>> >> +store " %%xmm3,   32(%[dst])\n" \
>> >> +store " %%xmm4,   48(%[dst])\n" \
>> >> +: : [dst]"r"(dstp), [src]"r"(srcp) : "memory", "xmm1", "xmm2", 
>> >> "xmm3", "xmm4")
>> >> +#endif
>> >> +
>> >> +#define COPY_LINE(dstp, srcp, size, load)   \
>> >> +const unsigned unaligned = (-(uintptr_t)srcp) & 0x0f;   \
>> >> +unsigned x = unaligned; \
>> >> +\
>> >> +av_assert0(((intptr_t)dstp & 0x0f) == 0);   \
>> >> +\
>> >> +__asm__ volatile ("mfence");\
>> >> +if (!unaligned) {   \
>> >> +for (; x+63 < size; x += 64)\
>> >> +COPY64(&dstp[x], &srcp[x], load, "movdqa"); \
>> >> +} else {\
>> >> +COPY16(dst, src, "movdqu", "movdqa");   \
>> >> +for (; x+63 < size; x += 64)\
>> >> +COPY64(&dstp[x], &srcp[x], load, "movdqu"); \
>> >
>> > to use SSE registers in inline asm operands or clobber list you need
>> > to build with -msse (which probably is default on on x86-64)
>> >
>> > files build with -msse will result in undefined behavior if anything
>> > in them is executed on a pre SSE cpu, as these allow gcc to put
>> > SSE instructions directly in the code where it likes
>> >
>> > The way out of this "design" is not to tell gcc that it passes
>> > a string with SSE code to the assembler
>> > that is not to use SSE registers in operands and not to put them
>> > on the clobber list unless gcc actually is in SSE mode and can use and
>> > need them there.
>> > see XMM_CLOBBERS*
>>
>> Well, from past experience, lying to gcc is generally not a good thing
>> either. There are multiple interesting ways it could fail from time to
>> time. :)
>>
>> Other approaches:
>> - With GCC >= 4.4, you can use __attribute__((target(T))) where T =
>> "ssse3", "sse4.1", etc. This is the easiest way ;
>> - Split into several separate files per target. Though, one would then
>> argue that while we are at it why not just start moving to yasm.
>>
>
>> The former approach looks more appealing to me, considering there may
>> be an effort to migrate to yasm afterwards.
>
> I plan to port this patch to yasm. I'll ask for help on IRC since
> probably it will take too much time otherwise without any guidance.
> --

If you accept a few restrictions (like requiring aligned and padded
input/output) and maybe give it a more specific name so that people
won't try to replace generic memcpy with it, yasm'ing it would be
pretty simple.
If you want it to be generic like the C version, supporting unaligned
and whatnot, the asm is going to get a bit more verbose..

I could probably whip up a basic implementation of the restricted
version, and the yasm experts can make suggestions on improvements
then.

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

Re: [FFmpeg-devel] [RFC] DXVA2 decoding and FFmpeg

2015-06-16 Thread wm4

On Tue, 16 Jun 2015 14:16:11 +0200
Gwenole Beauchesne  wrote:

> Hi,
> 
> 2015-06-16 14:03 GMT+02:00 Michael Niedermayer :
> > On Tue, Jun 16, 2015 at 10:35:52AM +0200, Stefano Sabatini wrote:
> >> On date Tuesday 2015-06-16 10:20:31 +0200, wm4 encoded:
> >> > On Mon, 15 Jun 2015 17:55:35 +0200
> >> > Stefano Sabatini  wrote:
> >> >
> >> > > On date Monday 2015-06-15 11:56:13 +0200, Stefano Sabatini encoded:
> >> > > [...]
> >> > > > From 3a75ef1e86360cd6f30b8e550307404d0d1c1dba Mon Sep 17 00:00:00 
> >> > > > 2001
> >> > > > From: Stefano Sabatini 
> >> > > > Date: Mon, 15 Jun 2015 11:02:50 +0200
> >> > > > Subject: [PATCH] lavu/mem: add av_memcpynt() function with x86 
> >> > > > optimizations
> >> > > >
> >> > > > Assembly based on code from vlc dxva2.c, commit 62107e56 by Laurent 
> >> > > > Aimar
> >> > > > .
> >> > > >
> >> > > > TODO: bump minor, update APIchanges
> >> > > > ---
> >> > > >  libavutil/mem.c  |  9 +
> >> > > >  libavutil/mem.h  | 14 
> >> > > >  libavutil/mem_internal.h | 26 +++
> >> > > >  libavutil/x86/Makefile   |  1 +
> >> > > >  libavutil/x86/mem.c  | 85 
> >> > > > 
> >> > > >  5 files changed, 135 insertions(+)
> >> > > >  create mode 100644 libavutil/mem_internal.h
> >> > > >  create mode 100644 libavutil/x86/mem.c
> >> > > >
> >> > > > diff --git a/libavutil/mem.c b/libavutil/mem.c
> >> > > > index da291fb..0e1eb01 100644
> >> > > > --- a/libavutil/mem.c
> >> > > > +++ b/libavutil/mem.c
> >> > > > @@ -42,6 +42,7 @@
> >> > > >  #include "dynarray.h"
> >> > > >  #include "intreadwrite.h"
> >> > > >  #include "mem.h"
> >> > > > +#include "mem_internal.h"
> >> > > >
> >> > > >  #ifdef MALLOC_PREFIX
> >> > > >
> >> > > > @@ -515,3 +516,11 @@ void av_fast_malloc(void *ptr, unsigned int 
> >> > > > *size, size_t min_size)
> >> > > >  ff_fast_malloc(ptr, size, min_size, 0);
> >> > > >  }
> >> > > >
> >> > > > +void av_memcpynt(void *dst, const void *src, size_t size, int 
> >> > > > cpu_flags)
> >> > > > +{
> >> > > > +#if ARCH_X86
> >> > > > +ff_memcpynt_x86(dst, src, size, cpu_flags);
> >> > > > +#else
> >> > > > +memcpy(dst, src, size, cpu_flags);
> >> > > > +#endif
> >> > > > +}
> >> > >
> >> > > Alternatively, what about something like:
> >> > >
> >> > > av_memcpynt_fn av_memcpynt_get_fn(void);
> >> > >
> >> > > modeled after av_pixelutils_get_sad_fn()? This would skip the need for
> >> > > a wrapper calling the right function.
> >> >
> >>
> >> > I don't see much value in this, unless determining the right function
> >> > causes too much overhead.
> >>
> >> I see two advantages, 1. no branch and function call when the function
> >> is called, 2. the cpu_flags must not be passed around, so it's somehow
> >> safer.
> >>
> >> I have no strong preference though, updated (untested patch) in
> >> attachment.
> >> --
> >> FFmpeg = Fierce and Forgiving Merciless Powered Extroverse Gargoyle
> >
> >>  mem.c  |9 +
> >>  mem.h  |   13 +++
> >>  mem_internal.h |   26 +++
> >>  x86/Makefile   |1
> >>  x86/mem.c  |   98 
> >> +
> >>  5 files changed, 147 insertions(+)
> >> f536b25834e0927b8cab5c996042aae697b8d773  
> >> 0003-lavu-mem-add-av_memcpynt_get_fn.patch
> >> From c005ff5405dd48e6b0fed24ed94947f69bfe2783 Mon Sep 17 00:00:00 2001
> >> From: Stefano Sabatini 
> >> Date: Mon, 15 Jun 2015 11:02:50 +0200
> >> Subject: [PATCH] lavu/mem: add av_memcpynt_get_fn()
> >>
> >> Assembly based on code from vlc dxva2.c, commit 62107e56 by Laurent Aimar
> >> .
> >>
> >> TODO: remove use of inline assembly, bump minor, update APIchanges
> >> ---
> >>  libavutil/mem.c  |  9 +
> >>  libavutil/mem.h  | 13 +++
> >>  libavutil/mem_internal.h | 26 +
> >>  libavutil/x86/Makefile   |  1 +
> >>  libavutil/x86/mem.c  | 98 
> >> 
> >>  5 files changed, 147 insertions(+)
> >>  create mode 100644 libavutil/mem_internal.h
> >>  create mode 100644 libavutil/x86/mem.c
> >>
> >> diff --git a/libavutil/mem.c b/libavutil/mem.c
> >> index da291fb..325bfc9 100644
> >> --- a/libavutil/mem.c
> >> +++ b/libavutil/mem.c
> >> @@ -42,6 +42,7 @@
> >>  #include "dynarray.h"
> >>  #include "intreadwrite.h"
> >>  #include "mem.h"
> >> +#include "mem_internal.h"
> >>
> >>  #ifdef MALLOC_PREFIX
> >>
> >> @@ -515,3 +516,11 @@ void av_fast_malloc(void *ptr, unsigned int *size, 
> >> size_t min_size)
> >>  ff_fast_malloc(ptr, size, min_size, 0);
> >>  }
> >>
> >> +av_memcpynt_fn av_memcpynt_get_fn(void)
> >> +{
> >> +#if ARCH_X86
> >> +return ff_memcpynt_get_fn_x86();
> >> +#else
> >> +return memcpy;
> >> +#endif
> >> +}
> >> diff --git a/libavutil/mem.h b/libavutil/mem.h
> >> index 2a1e36d..d9f1b7a 100644
> >> --- a/libavutil/mem.h
> >> +++ b/libavutil/mem.h
> >> @@ -382,6 +382,19 @@ void *av_fast_realloc(void *ptr, unsigned int *size

Re: [FFmpeg-devel] [RFC] DXVA2 decoding and FFmpeg

2015-06-16 Thread Stefano Sabatini

On date Tuesday 2015-06-16 14:16:11 +0200, Gwenole Beauchesne encoded:
> Hi,
> 
> 2015-06-16 14:03 GMT+02:00 Michael Niedermayer :
[...]
> >> +#if HAVE_SSE2
> >> +/* Copy 16/64 bytes from srcp to dstp loading data with the SSE>=2 
> >> instruction
> >> + * load and storing data with the SSE>=2 instruction store.
> >> + */
> >> +#define COPY16(dstp, srcp, load, store) \
> >> +__asm__ volatile (  \
> >> +load "  0(%[src]), %%xmm1\n"\
> >> +store " %%xmm1,0(%[dst])\n" \
> >> +: : [dst]"r"(dstp), [src]"r"(srcp) : "memory", "xmm1")
> >> +
> >> +#define COPY64(dstp, srcp, load, store) \
> >> +__asm__ volatile (  \
> >> +load "  0(%[src]), %%xmm1\n"\
> >> +load " 16(%[src]), %%xmm2\n"\
> >> +load " 32(%[src]), %%xmm3\n"\
> >> +load " 48(%[src]), %%xmm4\n"\
> >> +store " %%xmm1,0(%[dst])\n" \
> >> +store " %%xmm2,   16(%[dst])\n" \
> >> +store " %%xmm3,   32(%[dst])\n" \
> >> +store " %%xmm4,   48(%[dst])\n" \
> >> +: : [dst]"r"(dstp), [src]"r"(srcp) : "memory", "xmm1", "xmm2", 
> >> "xmm3", "xmm4")
> >> +#endif
> >> +
> >> +#define COPY_LINE(dstp, srcp, size, load)   \
> >> +const unsigned unaligned = (-(uintptr_t)srcp) & 0x0f;   \
> >> +unsigned x = unaligned; \
> >> +\
> >> +av_assert0(((intptr_t)dstp & 0x0f) == 0);   \
> >> +\
> >> +__asm__ volatile ("mfence");\
> >> +if (!unaligned) {   \
> >> +for (; x+63 < size; x += 64)\
> >> +COPY64(&dstp[x], &srcp[x], load, "movdqa"); \
> >> +} else {\
> >> +COPY16(dst, src, "movdqu", "movdqa");   \
> >> +for (; x+63 < size; x += 64)\
> >> +COPY64(&dstp[x], &srcp[x], load, "movdqu"); \
> >
> > to use SSE registers in inline asm operands or clobber list you need
> > to build with -msse (which probably is default on on x86-64)
> >
> > files build with -msse will result in undefined behavior if anything
> > in them is executed on a pre SSE cpu, as these allow gcc to put
> > SSE instructions directly in the code where it likes
> >
> > The way out of this "design" is not to tell gcc that it passes
> > a string with SSE code to the assembler
> > that is not to use SSE registers in operands and not to put them
> > on the clobber list unless gcc actually is in SSE mode and can use and
> > need them there.
> > see XMM_CLOBBERS*
> 
> Well, from past experience, lying to gcc is generally not a good thing
> either. There are multiple interesting ways it could fail from time to
> time. :)
> 
> Other approaches:
> - With GCC >= 4.4, you can use __attribute__((target(T))) where T =
> "ssse3", "sse4.1", etc. This is the easiest way ;
> - Split into several separate files per target. Though, one would then
> argue that while we are at it why not just start moving to yasm.
> 

> The former approach looks more appealing to me, considering there may
> be an effort to migrate to yasm afterwards.

I plan to port this patch to yasm. I'll ask for help on IRC since
probably it will take too much time otherwise without any guidance.
-- 
FFmpeg = Friendly and Fancy Mind-dumbing Pacific Easy Generator
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] DXVA2 decoding and FFmpeg

2015-06-16 Thread Gwenole Beauchesne

Hi,

2015-06-16 14:03 GMT+02:00 Michael Niedermayer :
> On Tue, Jun 16, 2015 at 10:35:52AM +0200, Stefano Sabatini wrote:
>> On date Tuesday 2015-06-16 10:20:31 +0200, wm4 encoded:
>> > On Mon, 15 Jun 2015 17:55:35 +0200
>> > Stefano Sabatini  wrote:
>> >
>> > > On date Monday 2015-06-15 11:56:13 +0200, Stefano Sabatini encoded:
>> > > [...]
>> > > > From 3a75ef1e86360cd6f30b8e550307404d0d1c1dba Mon Sep 17 00:00:00 2001
>> > > > From: Stefano Sabatini 
>> > > > Date: Mon, 15 Jun 2015 11:02:50 +0200
>> > > > Subject: [PATCH] lavu/mem: add av_memcpynt() function with x86 
>> > > > optimizations
>> > > >
>> > > > Assembly based on code from vlc dxva2.c, commit 62107e56 by Laurent 
>> > > > Aimar
>> > > > .
>> > > >
>> > > > TODO: bump minor, update APIchanges
>> > > > ---
>> > > >  libavutil/mem.c  |  9 +
>> > > >  libavutil/mem.h  | 14 
>> > > >  libavutil/mem_internal.h | 26 +++
>> > > >  libavutil/x86/Makefile   |  1 +
>> > > >  libavutil/x86/mem.c  | 85 
>> > > > 
>> > > >  5 files changed, 135 insertions(+)
>> > > >  create mode 100644 libavutil/mem_internal.h
>> > > >  create mode 100644 libavutil/x86/mem.c
>> > > >
>> > > > diff --git a/libavutil/mem.c b/libavutil/mem.c
>> > > > index da291fb..0e1eb01 100644
>> > > > --- a/libavutil/mem.c
>> > > > +++ b/libavutil/mem.c
>> > > > @@ -42,6 +42,7 @@
>> > > >  #include "dynarray.h"
>> > > >  #include "intreadwrite.h"
>> > > >  #include "mem.h"
>> > > > +#include "mem_internal.h"
>> > > >
>> > > >  #ifdef MALLOC_PREFIX
>> > > >
>> > > > @@ -515,3 +516,11 @@ void av_fast_malloc(void *ptr, unsigned int 
>> > > > *size, size_t min_size)
>> > > >  ff_fast_malloc(ptr, size, min_size, 0);
>> > > >  }
>> > > >
>> > > > +void av_memcpynt(void *dst, const void *src, size_t size, int 
>> > > > cpu_flags)
>> > > > +{
>> > > > +#if ARCH_X86
>> > > > +ff_memcpynt_x86(dst, src, size, cpu_flags);
>> > > > +#else
>> > > > +memcpy(dst, src, size, cpu_flags);
>> > > > +#endif
>> > > > +}
>> > >
>> > > Alternatively, what about something like:
>> > >
>> > > av_memcpynt_fn av_memcpynt_get_fn(void);
>> > >
>> > > modeled after av_pixelutils_get_sad_fn()? This would skip the need for
>> > > a wrapper calling the right function.
>> >
>>
>> > I don't see much value in this, unless determining the right function
>> > causes too much overhead.
>>
>> I see two advantages, 1. no branch and function call when the function
>> is called, 2. the cpu_flags must not be passed around, so it's somehow
>> safer.
>>
>> I have no strong preference though, updated (untested patch) in
>> attachment.
>> --
>> FFmpeg = Fierce and Forgiving Merciless Powered Extroverse Gargoyle
>
>>  mem.c  |9 +
>>  mem.h  |   13 +++
>>  mem_internal.h |   26 +++
>>  x86/Makefile   |1
>>  x86/mem.c  |   98 
>> +
>>  5 files changed, 147 insertions(+)
>> f536b25834e0927b8cab5c996042aae697b8d773  
>> 0003-lavu-mem-add-av_memcpynt_get_fn.patch
>> From c005ff5405dd48e6b0fed24ed94947f69bfe2783 Mon Sep 17 00:00:00 2001
>> From: Stefano Sabatini 
>> Date: Mon, 15 Jun 2015 11:02:50 +0200
>> Subject: [PATCH] lavu/mem: add av_memcpynt_get_fn()
>>
>> Assembly based on code from vlc dxva2.c, commit 62107e56 by Laurent Aimar
>> .
>>
>> TODO: remove use of inline assembly, bump minor, update APIchanges
>> ---
>>  libavutil/mem.c  |  9 +
>>  libavutil/mem.h  | 13 +++
>>  libavutil/mem_internal.h | 26 +
>>  libavutil/x86/Makefile   |  1 +
>>  libavutil/x86/mem.c  | 98 
>> 
>>  5 files changed, 147 insertions(+)
>>  create mode 100644 libavutil/mem_internal.h
>>  create mode 100644 libavutil/x86/mem.c
>>
>> diff --git a/libavutil/mem.c b/libavutil/mem.c
>> index da291fb..325bfc9 100644
>> --- a/libavutil/mem.c
>> +++ b/libavutil/mem.c
>> @@ -42,6 +42,7 @@
>>  #include "dynarray.h"
>>  #include "intreadwrite.h"
>>  #include "mem.h"
>> +#include "mem_internal.h"
>>
>>  #ifdef MALLOC_PREFIX
>>
>> @@ -515,3 +516,11 @@ void av_fast_malloc(void *ptr, unsigned int *size, 
>> size_t min_size)
>>  ff_fast_malloc(ptr, size, min_size, 0);
>>  }
>>
>> +av_memcpynt_fn av_memcpynt_get_fn(void)
>> +{
>> +#if ARCH_X86
>> +return ff_memcpynt_get_fn_x86();
>> +#else
>> +return memcpy;
>> +#endif
>> +}
>> diff --git a/libavutil/mem.h b/libavutil/mem.h
>> index 2a1e36d..d9f1b7a 100644
>> --- a/libavutil/mem.h
>> +++ b/libavutil/mem.h
>> @@ -382,6 +382,19 @@ void *av_fast_realloc(void *ptr, unsigned int *size, 
>> size_t min_size);
>>   */
>>  void av_fast_malloc(void *ptr, unsigned int *size, size_t min_size);
>>
>> +typedef void* (*av_memcpynt_fn)(void *dst, const void *src, size_t size);
>> +
>> +/**
>> + * Return possibly optimized function to copy size bytes from from src
>> + * to dst, using non-temporal copy.
>> + *
>> + * The returned function w

Re: [FFmpeg-devel] [RFC] DXVA2 decoding and FFmpeg

2015-06-16 Thread Gwenole Beauchesne

Hi,

2015-06-16 10:35 GMT+02:00 Stefano Sabatini :
> On date Tuesday 2015-06-16 10:20:31 +0200, wm4 encoded:
>> On Mon, 15 Jun 2015 17:55:35 +0200
>> Stefano Sabatini  wrote:
>>
>> > On date Monday 2015-06-15 11:56:13 +0200, Stefano Sabatini encoded:
>> > [...]
>> > > From 3a75ef1e86360cd6f30b8e550307404d0d1c1dba Mon Sep 17 00:00:00 2001
>> > > From: Stefano Sabatini 
>> > > Date: Mon, 15 Jun 2015 11:02:50 +0200
>> > > Subject: [PATCH] lavu/mem: add av_memcpynt() function with x86 
>> > > optimizations
>> > >
>> > > Assembly based on code from vlc dxva2.c, commit 62107e56 by Laurent Aimar
>> > > .
>> > >
>> > > TODO: bump minor, update APIchanges
>> > > ---
>> > >  libavutil/mem.c  |  9 +
>> > >  libavutil/mem.h  | 14 
>> > >  libavutil/mem_internal.h | 26 +++
>> > >  libavutil/x86/Makefile   |  1 +
>> > >  libavutil/x86/mem.c  | 85 
>> > > 
>> > >  5 files changed, 135 insertions(+)
>> > >  create mode 100644 libavutil/mem_internal.h
>> > >  create mode 100644 libavutil/x86/mem.c
>> > >
>> > > diff --git a/libavutil/mem.c b/libavutil/mem.c
>> > > index da291fb..0e1eb01 100644
>> > > --- a/libavutil/mem.c
>> > > +++ b/libavutil/mem.c
>> > > @@ -42,6 +42,7 @@
>> > >  #include "dynarray.h"
>> > >  #include "intreadwrite.h"
>> > >  #include "mem.h"
>> > > +#include "mem_internal.h"
>> > >
>> > >  #ifdef MALLOC_PREFIX
>> > >
>> > > @@ -515,3 +516,11 @@ void av_fast_malloc(void *ptr, unsigned int *size, 
>> > > size_t min_size)
>> > >  ff_fast_malloc(ptr, size, min_size, 0);
>> > >  }
>> > >
>> > > +void av_memcpynt(void *dst, const void *src, size_t size, int cpu_flags)
>> > > +{
>> > > +#if ARCH_X86
>> > > +ff_memcpynt_x86(dst, src, size, cpu_flags);
>> > > +#else
>> > > +memcpy(dst, src, size, cpu_flags);
>> > > +#endif
>> > > +}
>> >
>> > Alternatively, what about something like:
>> >
>> > av_memcpynt_fn av_memcpynt_get_fn(void);
>> >
>> > modeled after av_pixelutils_get_sad_fn()? This would skip the need for
>> > a wrapper calling the right function.
>>
>
>> I don't see much value in this, unless determining the right function
>> causes too much overhead.
>
> I see two advantages, 1. no branch and function call when the function
> is called, 2. the cpu_flags must not be passed around, so it's somehow
> safer.

Interesting approach. You probably could also use something similar to
sws context you build up based on surface size, and other
characteristics (flags)?

Regards,
-- 
Gwenole Beauchesne
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
Registration Number (RCS): Nanterre B 302 456 199
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] DXVA2 decoding and FFmpeg

2015-06-16 Thread Michael Niedermayer

On Tue, Jun 16, 2015 at 10:35:52AM +0200, Stefano Sabatini wrote:
> On date Tuesday 2015-06-16 10:20:31 +0200, wm4 encoded:
> > On Mon, 15 Jun 2015 17:55:35 +0200
> > Stefano Sabatini  wrote:
> > 
> > > On date Monday 2015-06-15 11:56:13 +0200, Stefano Sabatini encoded:
> > > [...]
> > > > From 3a75ef1e86360cd6f30b8e550307404d0d1c1dba Mon Sep 17 00:00:00 2001
> > > > From: Stefano Sabatini 
> > > > Date: Mon, 15 Jun 2015 11:02:50 +0200
> > > > Subject: [PATCH] lavu/mem: add av_memcpynt() function with x86 
> > > > optimizations
> > > > 
> > > > Assembly based on code from vlc dxva2.c, commit 62107e56 by Laurent 
> > > > Aimar
> > > > .
> > > > 
> > > > TODO: bump minor, update APIchanges
> > > > ---
> > > >  libavutil/mem.c  |  9 +
> > > >  libavutil/mem.h  | 14 
> > > >  libavutil/mem_internal.h | 26 +++
> > > >  libavutil/x86/Makefile   |  1 +
> > > >  libavutil/x86/mem.c  | 85 
> > > > 
> > > >  5 files changed, 135 insertions(+)
> > > >  create mode 100644 libavutil/mem_internal.h
> > > >  create mode 100644 libavutil/x86/mem.c
> > > > 
> > > > diff --git a/libavutil/mem.c b/libavutil/mem.c
> > > > index da291fb..0e1eb01 100644
> > > > --- a/libavutil/mem.c
> > > > +++ b/libavutil/mem.c
> > > > @@ -42,6 +42,7 @@
> > > >  #include "dynarray.h"
> > > >  #include "intreadwrite.h"
> > > >  #include "mem.h"
> > > > +#include "mem_internal.h"
> > > >  
> > > >  #ifdef MALLOC_PREFIX
> > > >  
> > > > @@ -515,3 +516,11 @@ void av_fast_malloc(void *ptr, unsigned int *size, 
> > > > size_t min_size)
> > > >  ff_fast_malloc(ptr, size, min_size, 0);
> > > >  }
> > > >  
> > > > +void av_memcpynt(void *dst, const void *src, size_t size, int 
> > > > cpu_flags)
> > > > +{
> > > > +#if ARCH_X86
> > > > +ff_memcpynt_x86(dst, src, size, cpu_flags);
> > > > +#else
> > > > +memcpy(dst, src, size, cpu_flags);
> > > > +#endif
> > > > +}
> > > 
> > > Alternatively, what about something like:
> > > 
> > > av_memcpynt_fn av_memcpynt_get_fn(void);
> > > 
> > > modeled after av_pixelutils_get_sad_fn()? This would skip the need for
> > > a wrapper calling the right function.
> > 
> 
> > I don't see much value in this, unless determining the right function
> > causes too much overhead.
> 
> I see two advantages, 1. no branch and function call when the function
> is called, 2. the cpu_flags must not be passed around, so it's somehow
> safer.
> 
> I have no strong preference though, updated (untested patch) in
> attachment.
> -- 
> FFmpeg = Fierce and Forgiving Merciless Powered Extroverse Gargoyle

>  mem.c  |9 +
>  mem.h  |   13 +++
>  mem_internal.h |   26 +++
>  x86/Makefile   |1 
>  x86/mem.c  |   98 
> +
>  5 files changed, 147 insertions(+)
> f536b25834e0927b8cab5c996042aae697b8d773  
> 0003-lavu-mem-add-av_memcpynt_get_fn.patch
> From c005ff5405dd48e6b0fed24ed94947f69bfe2783 Mon Sep 17 00:00:00 2001
> From: Stefano Sabatini 
> Date: Mon, 15 Jun 2015 11:02:50 +0200
> Subject: [PATCH] lavu/mem: add av_memcpynt_get_fn()
> 
> Assembly based on code from vlc dxva2.c, commit 62107e56 by Laurent Aimar
> .
> 
> TODO: remove use of inline assembly, bump minor, update APIchanges
> ---
>  libavutil/mem.c  |  9 +
>  libavutil/mem.h  | 13 +++
>  libavutil/mem_internal.h | 26 +
>  libavutil/x86/Makefile   |  1 +
>  libavutil/x86/mem.c  | 98 
> 
>  5 files changed, 147 insertions(+)
>  create mode 100644 libavutil/mem_internal.h
>  create mode 100644 libavutil/x86/mem.c
> 
> diff --git a/libavutil/mem.c b/libavutil/mem.c
> index da291fb..325bfc9 100644
> --- a/libavutil/mem.c
> +++ b/libavutil/mem.c
> @@ -42,6 +42,7 @@
>  #include "dynarray.h"
>  #include "intreadwrite.h"
>  #include "mem.h"
> +#include "mem_internal.h"
>  
>  #ifdef MALLOC_PREFIX
>  
> @@ -515,3 +516,11 @@ void av_fast_malloc(void *ptr, unsigned int *size, 
> size_t min_size)
>  ff_fast_malloc(ptr, size, min_size, 0);
>  }
>  
> +av_memcpynt_fn av_memcpynt_get_fn(void)
> +{
> +#if ARCH_X86
> +return ff_memcpynt_get_fn_x86();
> +#else
> +return memcpy;
> +#endif
> +}
> diff --git a/libavutil/mem.h b/libavutil/mem.h
> index 2a1e36d..d9f1b7a 100644
> --- a/libavutil/mem.h
> +++ b/libavutil/mem.h
> @@ -382,6 +382,19 @@ void *av_fast_realloc(void *ptr, unsigned int *size, 
> size_t min_size);
>   */
>  void av_fast_malloc(void *ptr, unsigned int *size, size_t min_size);
>  
> +typedef void* (*av_memcpynt_fn)(void *dst, const void *src, size_t size);
> +
> +/**
> + * Return possibly optimized function to copy size bytes from from src
> + * to dst, using non-temporal copy.
> + *
> + * The returned function works as memcpy, but adopts non-temporal
> + * instructios when available. This can lead to better performances
> + * when transferring data from source to destination is e

Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: Change version byte for JPEG2000 to match mxf.c and RP224v12

2015-06-16 Thread Michael Niedermayer

On Tue, Jun 16, 2015 at 07:26:18AM +0100, tim nicholson wrote:
> On 15/06/15 13:13, Michael Niedermayer wrote:
> > This should make no difference as the byte is ignored
> > 
> > Found-by: tim nicholson 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/mxfdec.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index 7389555..b3c25b7 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -1156,7 +1156,7 @@ static const MXFCodecUL 
> > mxf_data_essence_container_uls[] = {
> >  };
> >  
> >  static const MXFCodecUL mxf_codec_uls[] = {
> > -{ { 
> > 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x09,0x04,0x01,0x02,0x02,0x03,0x01,0x01,0x00
> >  }, 14,   AV_CODEC_ID_JPEG2000 },
> > +{ { 
> > 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x07,0x04,0x01,0x02,0x02,0x03,0x01,0x01,0x00
> >  }, 14,   AV_CODEC_ID_JPEG2000 },
> >  { { 
> > 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> >  },  0,  AV_CODEC_ID_NONE },
> >  };
> >  
> > 
> LGTM ;)

applied

thanks

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- 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] avcodec/flacenc: Invalid Rice order

2015-06-16 Thread George Boyle

On 16/06/15 12:02, Michael Niedermayer wrote:
> 
> please post a patch that contains the remaining 2 hunks in >24h
> 
> also for future fate tests, small samples are preferred to keep the
> fate testsuite manageable size wise

Ok, will do. Thanks
George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/flacenc: Invalid Rice order

2015-06-16 Thread Michael Niedermayer

On Tue, Jun 16, 2015 at 08:25:01AM +0100, George Boyle wrote:
> Fixes ticket #4628.
> 
> The problem arose, in the sample file at least, in the last block where the
> minimum and maximum Rice partition orders were both 0. In that case, and any
> other where pmax == pmin, the original UINT32_MAX placeholder value for
> bits[opt_porder] was getting overwritten before the comparison to check if the
> current partition order is a new optimal, so the correct partition order and
> RiceContext params were not being set.
> 
> Regression test sample to be added to `$(SAMPLES)/audio-reference/`:
> http://thebuds.net/chorusnoise_2ch_44kHz_s16.wav
> 
> Signed-off-by: George Boyle 
> ---
>  libavcodec/flacenc.c | 2 +-
>  tests/fate/flac.mak  | 4 
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/flacenc.c b/libavcodec/flacenc.c
> index cdfeaf8..29bd999 100644
> --- a/libavcodec/flacenc.c
> +++ b/libavcodec/flacenc.c
> @@ -705,7 +705,7 @@ static uint64_t calc_rice_params(RiceContext *rc,
>  bits[pmin] = UINT32_MAX;
>  for (i = pmax; ; ) {
>  bits[i] = calc_optimal_rice_params(&tmp_rc, i, sums, n, pred_order, 
> kmax, exact);
> -if (bits[i] < bits[opt_porder]) {
> +if (bits[i] < bits[opt_porder] || pmax == pmin) {
>  opt_porder = i;
>  *rc = tmp_rc;
>  }

bugfix applied

fate sample uploaded

fate test not applied as some of the clients need 24h to sync the
samples
please post a patch that contains the remaining 2 hunks in >24h

also for future fate tests, small samples are preferred to keep the
fate testsuite manageable size wise

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] [PATCH] doc/muxers.texi: properly insert {}s in example

2015-06-16 Thread Michael Niedermayer

On Mon, Jun 15, 2015 at 11:04:45PM -0700, James Zern wrote:
> use '@{' / '@}', fixes compile errors:
> *** '{' without macro. Before: 1:-'.'}
> *** '}' without opening '{' before:
> 
> since:
> 907ac20 avformat/hlsenc: added HLS encryption
> 
> Signed-off-by: James Zern 
> ---
>  doc/muxers.texi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

thanks

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


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

Re: [FFmpeg-devel] [PATCH] libvpxenc: add color-space option for vp9

2015-06-16 Thread Michael Niedermayer

On Mon, Jun 15, 2015 at 10:43:17PM -0700, James Zern wrote:
> the vp9 bitstream supports 8 values:
> unknown (default), bt601, bt709, smpte170, smpte240, bt2020, reserved
> and sRGB.
> ---
>  doc/encoders.texi  | 12 
>  libavcodec/libvpxenc.c | 22 ++
>  2 files changed, 34 insertions(+)
> 
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 8b0ecb7..09c90c2 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -1550,6 +1550,18 @@ Enable frame parallel decodability features.
>  @item aq-mode
>  Set adaptive quantization mode (0: off (default), 1: variance 2: complexity, 
> 3:
>  cyclic refresh).
> +@item color-space
> +Set input color space.
> +@table @samp
> +@item unknown
> +@item bt601
> +@item bt709
> +@item smpte170
> +@item smpte240
> +@item bt2020
> +@item reserved
> +@item sRGB
> +@end table
>  @end table
>  
>  @end table
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 28a0e14..10f16e7 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -100,8 +100,12 @@ typedef struct VP8EncoderContext {
>  int tile_rows;
>  int frame_parallel;
>  int aq_mode;
> +int colorspace;
>  } VP8Context;
>  
> +// VP9E_SET_COLOR_SPACE was added just prior to v1.4.0.
> +#define HAVE_VP9_COLORSPACE_CONTROL (VPX_ENCODER_ABI_VERSION > 8)
> +
>  /** String mappings for enum vp8e_enc_control_id */
>  static const char *const ctlidstr[] = {
>  [VP8E_UPD_ENTROPY]   = "VP8E_UPD_ENTROPY",
> @@ -128,6 +132,9 @@ static const char *const ctlidstr[] = {
>  [VP9E_SET_TILE_ROWS]   = "VP9E_SET_TILE_ROWS",
>  [VP9E_SET_FRAME_PARALLEL_DECODING] = "VP9E_SET_FRAME_PARALLEL_DECODING",
>  [VP9E_SET_AQ_MODE] = "VP9E_SET_AQ_MODE",
> +#if HAVE_VP9_COLORSPACE_CONTROL
> +[VP9E_SET_COLOR_SPACE] = "VP9E_SET_COLOR_SPACE",
> +#endif
>  #endif
>  };
>  
> @@ -593,6 +600,10 @@ static av_cold int vpx_init(AVCodecContext *avctx,
>  codecctl_int(avctx, VP9E_SET_FRAME_PARALLEL_DECODING, 
> ctx->frame_parallel);
>  if (ctx->aq_mode >= 0)
>  codecctl_int(avctx, VP9E_SET_AQ_MODE, ctx->aq_mode);
> +#if HAVE_VP9_COLORSPACE_CONTROL
> +if (ctx->colorspace >= 0)
> +codecctl_int(avctx, VP9E_SET_COLOR_SPACE, ctx->colorspace);
> +#endif
>  }
>  #endif
>  
> @@ -968,6 +979,17 @@ static const AVOption vp9_options[] = {
>  { "variance","Variance based Aq",   0, AV_OPT_TYPE_CONST, {.i64 
> = 1}, 0, 0, VE, "aq_mode" },
>  { "complexity",  "Complexity based Aq", 0, AV_OPT_TYPE_CONST, {.i64 
> = 2}, 0, 0, VE, "aq_mode" },
>  { "cyclic",  "Cyclic Refresh Aq",   0, AV_OPT_TYPE_CONST, {.i64 
> = 3}, 0, 0, VE, "aq_mode" },
> +#if HAVE_VP9_COLORSPACE_CONTROL
> +{ "color-space", "Input color space",   
> OFFSET(colorspace),  AV_OPT_TYPE_INT, {.i64 = -1}, -1, 7, VE, 
> "colorspace"},
> +{ "unknown", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
> VPX_CS_UNKNOWN},   0, 0, VE, "colorspace" },
> +{ "bt601",   NULL, 0, AV_OPT_TYPE_CONST, {.i64 = VPX_CS_BT_601}, 
>0, 0, VE, "colorspace" },
> +{ "bt709",   NULL, 0, AV_OPT_TYPE_CONST, {.i64 = VPX_CS_BT_709}, 
>0, 0, VE, "colorspace" },
> +{ "smpte170",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
> VPX_CS_SMPTE_170}, 0, 0, VE, "colorspace" },
> +{ "smpte240",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
> VPX_CS_SMPTE_240}, 0, 0, VE, "colorspace" },
> +{ "bt2020",  NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
> VPX_CS_BT_2020},   0, 0, VE, "colorspace" },
> +{ "reserved",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
> VPX_CS_RESERVED},  0, 0, VE, "colorspace" },
> +{ "sRGB",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = VPX_CS_SRGB},   
>0, 0, VE, "colorspace" },
> +#endif

why does this not use AVCodecContext.colorspace or other colorspace
related fields ?


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

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


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

Re: [FFmpeg-devel] [PATCH] swresample: make swr_get_out_samples() work with all resamplers

2015-06-16 Thread wm4

On Tue, 16 Jun 2015 01:43:59 +0200
Michael Niedermayer  wrote:

> On Thu, Jun 04, 2015 at 07:19:25PM +0200, wm4 wrote:
> > Making it fail if e.g. soxr is used makes the function completely
> > useless.
> > ---
> >  libswresample/swresample.c | 10 +++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> this together with the other commit results in an insufficent number
> of samples being returned for some inputs
> 
> an example of this is
> ./ffmpeg -f s32le -acodec pcm_s32le -ar 44100 -ac 1 -i lena.pnm -af 
> aresample=osr=96000:resampler=soxr:cutoff=.993 -f null -
> 
> iam also CCing, Rob Sykes, who is also working on this
> 

That's bad, because AFAIK I used calculations that were suggested in
the public API.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] DXVA2 decoding and FFmpeg

2015-06-16 Thread Stefano Sabatini

On date Tuesday 2015-06-16 10:20:31 +0200, wm4 encoded:
> On Mon, 15 Jun 2015 17:55:35 +0200
> Stefano Sabatini  wrote:
> 
> > On date Monday 2015-06-15 11:56:13 +0200, Stefano Sabatini encoded:
> > [...]
> > > From 3a75ef1e86360cd6f30b8e550307404d0d1c1dba Mon Sep 17 00:00:00 2001
> > > From: Stefano Sabatini 
> > > Date: Mon, 15 Jun 2015 11:02:50 +0200
> > > Subject: [PATCH] lavu/mem: add av_memcpynt() function with x86 
> > > optimizations
> > > 
> > > Assembly based on code from vlc dxva2.c, commit 62107e56 by Laurent Aimar
> > > .
> > > 
> > > TODO: bump minor, update APIchanges
> > > ---
> > >  libavutil/mem.c  |  9 +
> > >  libavutil/mem.h  | 14 
> > >  libavutil/mem_internal.h | 26 +++
> > >  libavutil/x86/Makefile   |  1 +
> > >  libavutil/x86/mem.c  | 85 
> > > 
> > >  5 files changed, 135 insertions(+)
> > >  create mode 100644 libavutil/mem_internal.h
> > >  create mode 100644 libavutil/x86/mem.c
> > > 
> > > diff --git a/libavutil/mem.c b/libavutil/mem.c
> > > index da291fb..0e1eb01 100644
> > > --- a/libavutil/mem.c
> > > +++ b/libavutil/mem.c
> > > @@ -42,6 +42,7 @@
> > >  #include "dynarray.h"
> > >  #include "intreadwrite.h"
> > >  #include "mem.h"
> > > +#include "mem_internal.h"
> > >  
> > >  #ifdef MALLOC_PREFIX
> > >  
> > > @@ -515,3 +516,11 @@ void av_fast_malloc(void *ptr, unsigned int *size, 
> > > size_t min_size)
> > >  ff_fast_malloc(ptr, size, min_size, 0);
> > >  }
> > >  
> > > +void av_memcpynt(void *dst, const void *src, size_t size, int cpu_flags)
> > > +{
> > > +#if ARCH_X86
> > > +ff_memcpynt_x86(dst, src, size, cpu_flags);
> > > +#else
> > > +memcpy(dst, src, size, cpu_flags);
> > > +#endif
> > > +}
> > 
> > Alternatively, what about something like:
> > 
> > av_memcpynt_fn av_memcpynt_get_fn(void);
> > 
> > modeled after av_pixelutils_get_sad_fn()? This would skip the need for
> > a wrapper calling the right function.
> 

> I don't see much value in this, unless determining the right function
> causes too much overhead.

I see two advantages, 1. no branch and function call when the function
is called, 2. the cpu_flags must not be passed around, so it's somehow
safer.

I have no strong preference though, updated (untested patch) in
attachment.
-- 
FFmpeg = Fierce and Forgiving Merciless Powered Extroverse Gargoyle
>From c005ff5405dd48e6b0fed24ed94947f69bfe2783 Mon Sep 17 00:00:00 2001
From: Stefano Sabatini 
Date: Mon, 15 Jun 2015 11:02:50 +0200
Subject: [PATCH] lavu/mem: add av_memcpynt_get_fn()

Assembly based on code from vlc dxva2.c, commit 62107e56 by Laurent Aimar
.

TODO: remove use of inline assembly, bump minor, update APIchanges
---
 libavutil/mem.c  |  9 +
 libavutil/mem.h  | 13 +++
 libavutil/mem_internal.h | 26 +
 libavutil/x86/Makefile   |  1 +
 libavutil/x86/mem.c  | 98 
 5 files changed, 147 insertions(+)
 create mode 100644 libavutil/mem_internal.h
 create mode 100644 libavutil/x86/mem.c

diff --git a/libavutil/mem.c b/libavutil/mem.c
index da291fb..325bfc9 100644
--- a/libavutil/mem.c
+++ b/libavutil/mem.c
@@ -42,6 +42,7 @@
 #include "dynarray.h"
 #include "intreadwrite.h"
 #include "mem.h"
+#include "mem_internal.h"
 
 #ifdef MALLOC_PREFIX
 
@@ -515,3 +516,11 @@ void av_fast_malloc(void *ptr, unsigned int *size, size_t min_size)
 ff_fast_malloc(ptr, size, min_size, 0);
 }
 
+av_memcpynt_fn av_memcpynt_get_fn(void)
+{
+#if ARCH_X86
+return ff_memcpynt_get_fn_x86();
+#else
+return memcpy;
+#endif
+}
diff --git a/libavutil/mem.h b/libavutil/mem.h
index 2a1e36d..d9f1b7a 100644
--- a/libavutil/mem.h
+++ b/libavutil/mem.h
@@ -382,6 +382,19 @@ void *av_fast_realloc(void *ptr, unsigned int *size, size_t min_size);
  */
 void av_fast_malloc(void *ptr, unsigned int *size, size_t min_size);
 
+typedef void* (*av_memcpynt_fn)(void *dst, const void *src, size_t size);
+
+/**
+ * Return possibly optimized function to copy size bytes from from src
+ * to dst, using non-temporal copy.
+ *
+ * The returned function works as memcpy, but adopts non-temporal
+ * instructios when available. This can lead to better performances
+ * when transferring data from source to destination is expensive, for
+ * example when reading from GPU memory.
+ */
+av_memcpynt_fn av_memcpynt_get_fn(void);
+
 /**
  * @}
  */
diff --git a/libavutil/mem_internal.h b/libavutil/mem_internal.h
new file mode 100644
index 000..de61cba
--- /dev/null
+++ b/libavutil/mem_internal.h
@@ -0,0 +1,26 @@
+/*
+ * 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

Re: [FFmpeg-devel] [RFC] DXVA2 decoding and FFmpeg

2015-06-16 Thread wm4

On Mon, 15 Jun 2015 17:55:35 +0200
Stefano Sabatini  wrote:

> On date Monday 2015-06-15 11:56:13 +0200, Stefano Sabatini encoded:
> [...]
> > From 3a75ef1e86360cd6f30b8e550307404d0d1c1dba Mon Sep 17 00:00:00 2001
> > From: Stefano Sabatini 
> > Date: Mon, 15 Jun 2015 11:02:50 +0200
> > Subject: [PATCH] lavu/mem: add av_memcpynt() function with x86 optimizations
> > 
> > Assembly based on code from vlc dxva2.c, commit 62107e56 by Laurent Aimar
> > .
> > 
> > TODO: bump minor, update APIchanges
> > ---
> >  libavutil/mem.c  |  9 +
> >  libavutil/mem.h  | 14 
> >  libavutil/mem_internal.h | 26 +++
> >  libavutil/x86/Makefile   |  1 +
> >  libavutil/x86/mem.c  | 85 
> > 
> >  5 files changed, 135 insertions(+)
> >  create mode 100644 libavutil/mem_internal.h
> >  create mode 100644 libavutil/x86/mem.c
> > 
> > diff --git a/libavutil/mem.c b/libavutil/mem.c
> > index da291fb..0e1eb01 100644
> > --- a/libavutil/mem.c
> > +++ b/libavutil/mem.c
> > @@ -42,6 +42,7 @@
> >  #include "dynarray.h"
> >  #include "intreadwrite.h"
> >  #include "mem.h"
> > +#include "mem_internal.h"
> >  
> >  #ifdef MALLOC_PREFIX
> >  
> > @@ -515,3 +516,11 @@ void av_fast_malloc(void *ptr, unsigned int *size, 
> > size_t min_size)
> >  ff_fast_malloc(ptr, size, min_size, 0);
> >  }
> >  
> > +void av_memcpynt(void *dst, const void *src, size_t size, int cpu_flags)
> > +{
> > +#if ARCH_X86
> > +ff_memcpynt_x86(dst, src, size, cpu_flags);
> > +#else
> > +memcpy(dst, src, size, cpu_flags);
> > +#endif
> > +}
> 
> Alternatively, what about something like:
> 
> av_memcpynt_fn av_memcpynt_get_fn(void);
> 
> modeled after av_pixelutils_get_sad_fn()? This would skip the need for
> a wrapper calling the right function.

I don't see much value in this, unless determining the right function
causes too much overhead.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/flacenc: Invalid Rice order

2015-06-16 Thread George Boyle

Fixes ticket #4628.

The problem arose, in the sample file at least, in the last block where the
minimum and maximum Rice partition orders were both 0. In that case, and any
other where pmax == pmin, the original UINT32_MAX placeholder value for
bits[opt_porder] was getting overwritten before the comparison to check if the
current partition order is a new optimal, so the correct partition order and
RiceContext params were not being set.

Regression test sample to be added to `$(SAMPLES)/audio-reference/`:
http://thebuds.net/chorusnoise_2ch_44kHz_s16.wav

Signed-off-by: George Boyle 
---
 libavcodec/flacenc.c | 2 +-
 tests/fate/flac.mak  | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavcodec/flacenc.c b/libavcodec/flacenc.c
index cdfeaf8..29bd999 100644
--- a/libavcodec/flacenc.c
+++ b/libavcodec/flacenc.c
@@ -705,7 +705,7 @@ static uint64_t calc_rice_params(RiceContext *rc,
 bits[pmin] = UINT32_MAX;
 for (i = pmax; ; ) {
 bits[i] = calc_optimal_rice_params(&tmp_rc, i, sums, n, pred_order, 
kmax, exact);
-if (bits[i] < bits[opt_porder]) {
+if (bits[i] < bits[opt_porder] || pmax == pmin) {
 opt_porder = i;
 *rc = tmp_rc;
 }
diff --git a/tests/fate/flac.mak b/tests/fate/flac.mak
index 4a13404..115cc96 100644
--- a/tests/fate/flac.mak
+++ b/tests/fate/flac.mak
@@ -6,6 +6,7 @@ FATE_FLAC += fate-flac-16-chmode-indep  
\
  fate-flac-16-lpc-cholesky  \
  fate-flac-16-lpc-levinson  \
  fate-flac-24-comp-8\
+ fate-flac-rice-params  \
 
 fate-flac-16-chmode-%: OPTS = -ch_mode $(@:fate-flac-16-chmode-%=%)
 fate-flac-16-fixed:OPTS = -lpc_type fixed
@@ -19,6 +20,9 @@ fate-flac-24-comp-%: OPTS = -compression_level 
$(@:fate-flac-24-comp-%=%)
 fate-flac-24-%: REF = $(SAMPLES)/audio-reference/divertimenti_2ch_96kHz_s24.wav
 fate-flac-24-%: CMD = enc_dec_pcm flac wav s24le $(subst 
$(SAMPLES),$(TARGET_SAMPLES),$(REF)) -c flac $(OPTS)
 
+fate-flac-rice-params: REF = 
$(SAMPLES)/audio-reference/chorusnoise_2ch_44kHz_s16.wav
+fate-flac-rice-params: CMD = enc_dec_pcm flac wav s16le $(subst 
$(SAMPLES),$(TARGET_SAMPLES),$(REF)) -c flac
+
 fate-flac-%: CMP = oneoff
 fate-flac-%: FUZZ = 0
 
-- 
2.4.3

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

46 matches

Mail list logo