Re: [FFmpeg-devel] [PATCH] avcodec/wavpackenc: remove unneeded L suffixes

2015-02-02 Thread Paul B Mahol 
On 2/1/15, Michael Niedermayer  wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/wavpackenc.c |8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/wavpackenc.c b/libavcodec/wavpackenc.c
> index 63971c6..c174950 100644
> --- a/libavcodec/wavpackenc.c
> +++ b/libavcodec/wavpackenc.c
> @@ -640,9 +640,9 @@ static uint32_t log2sample(uint32_t v, int limit,
> uint32_t *result)
>  dbits = nbits_table[v];
>  *result += (dbits << 8) + wp_log2_table[(v << (9 - dbits)) &
> 0xff];
>  } else {
> -if (v < (1L << 16))
> +if (v < (1 << 16))
>  dbits = nbits_table[v >> 8] + 8;
> -else if (v < (1L << 24))
> +else if (v < (1 << 24))
>  dbits = nbits_table[v >> 16] + 16;
>  else
>  dbits = nbits_table[v >> 24] + 24;
> @@ -1967,8 +1967,8 @@ static int wv_stereo(WavPackEncodeContext *s,
>  #define count_bits(av) ( \
>   (av) < (1 << 8) ? nbits_table[av] : \
>( \
> -   (av) < (1L << 16) ? nbits_table[(av) >> 8] + 8 : \
> -   ((av) < (1L << 24) ? nbits_table[(av) >> 16] + 16 : nbits_table[(av) >>
> 24] + 24) \
> +   (av) < (1 << 16) ? nbits_table[(av) >> 8] + 8 : \
> +   ((av) < (1 << 24) ? nbits_table[(av) >> 16] + 16 : nbits_table[(av) >>
> 24] + 24) \
>) \
>  )
>
> --
> 1.7.9.5
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

[FFmpeg-devel] [PATCH] libavformat/mpegtsenc: allow to set service_type in sdt

2015-02-02 Thread dhead666 
This adds an option to set the service type in mpegts as defined in ETSI 300 
468.

I added what I believe are the most useful service types as pre defined values,
the others can be sent by using their hexdecimal form directly (e.g. 
-mpegts_service_type digital_radio, -mpegts_service_type 0x07).

I've been using this patch in order to pipe internet radio stream (originally 
as HLS/m3u8) from ffmpeg to tvheadend,
when the service type set right tvheadend recognize the mpegts stream as a 
radio channel.

The patch in its original form was written by linuxstb from freenode's hts 
channel which allowed me pushing it upstream.

This close issue 4118.
---

Hi Michael,
I added a commit message as requested, thanks.

 doc/muxers.texi | 24 
 libavformat/mpegtsenc.c | 37 -
 2 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 7ca6409..9fed9f2 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -690,6 +690,9 @@ Set the transport_stream_id (default 0x0001). This 
identifies a
 transponder in DVB.
 @item -mpegts_service_id @var{number}
 Set the service_id (default 0x0001) also known as program in DVB.
+@item -mpegts_service_type @var{number}
+Set the program service_type (default @var{digital_tv}), see below
+a list of pre defined values.
 @item -mpegts_pmt_start_pid @var{number}
 Set the first PID for PMT (default 0x1000, max 0x1f00).
 @item -mpegts_start_pid @var{number}
@@ -724,6 +727,27 @@ ffmpeg -i source2.ts -codec copy -f mpegts -tables_version 
1 udp://1.1.1.1:
 @end example
 @end table
 
+Option mpegts_service_type accepts the following values:
+
+@table @option
+@item hex_value
+Any hexdecimal value between 0x01 to 0xff as defined in ETSI 300 468.
+@item digital_tv
+Digital TV service.
+@item digital_radio
+Digital Radio service.
+@item teletext
+Teletext service.
+@item advanced_codec_digital_radio
+Advanced Codec Digital Radio service.
+@item mpeg2_digital_hdtv
+MPEG2 Digital HDTV service.
+@item advanced_codec_digital_sdtv
+Advanced Codec Digital SDTV service.
+@item advanced_codec_digital_hdtv
+Advanced Codec Digital HDTV service.
+@end table
+
 Option mpegts_flags may take a set of such flags:
 
 @table @option
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 8d0da0b..46ff522 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -76,6 +76,17 @@ typedef struct MpegTSWrite {
 int transport_stream_id;
 int original_network_id;
 int service_id;
+int service_type;
+// service_type values as defined in ETSI 300 468
+   enum {
+ MPEGTS_SERVICE_TYPE_DIGITAL_TV   = 0x01,
+ MPEGTS_SERVICE_TYPE_DIGITAL_RADIO= 0x02,
+ MPEGTS_SERVICE_TYPE_TELETEXT = 0x03,
+ MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_RADIO = 0x0A,
+ MPEGTS_SERVICE_TYPE_MPEG2_DIGITAL_HDTV   = 0x11,
+ MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_SDTV  = 0x16,
+ MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_HDTV  = 0x19
+   };
 
 int pmt_start_pid;
 int start_pid;
@@ -521,7 +532,7 @@ static void mpegts_write_sdt(AVFormatContext *s)
 *q++ = 0x48;
 desc_len_ptr = q;
 q++;
-*q++ = 0x01; /* digital television service */
+*q++ = ts->service_type;
 putstr8(&q, service->provider_name);
 putstr8(&q, service->name);
 desc_len_ptr[0] = q - desc_len_ptr - 1;
@@ -1434,6 +1445,30 @@ static const AVOption options[] = {
 { "mpegts_service_id", "Set service_id field.",
   offsetof(MpegTSWrite, service_id), AV_OPT_TYPE_INT,
   { .i64 = 0x0001 }, 0x0001, 0x, AV_OPT_FLAG_ENCODING_PARAM },
+{ "mpegts_service_type", "Set service_type field.",
+  offsetof(MpegTSWrite, service_type), AV_OPT_TYPE_INT,
+  { .i64 = 0x01 }, 0x01, 0xff, AV_OPT_FLAG_ENCODING_PARAM, 
"mpegts_service_type" },
+{ "digital_tv", "Digital Television.",
+  0, AV_OPT_TYPE_CONST, { .i64 = MPEGTS_SERVICE_TYPE_DIGITAL_TV }, 0x01, 
0xff,
+  AV_OPT_FLAG_ENCODING_PARAM, "mpegts_service_type" },
+{ "digital_radio", "Digital Radio.",
+  0, AV_OPT_TYPE_CONST, { .i64 = MPEGTS_SERVICE_TYPE_DIGITAL_RADIO }, 
0x01, 0xff,
+  AV_OPT_FLAG_ENCODING_PARAM, "mpegts_service_type" },
+{ "teletext", "Teletext.",
+  0, AV_OPT_TYPE_CONST, { .i64 = MPEGTS_SERVICE_TYPE_TELETEXT }, 0x01, 
0xff,
+  AV_OPT_FLAG_ENCODING_PARAM, "mpegts_service_type" },
+{ "advanced_codec_digital_radio", "Advanced Codec Digital Radio.",
+  0, AV_OPT_TYPE_CONST, { .i64 = 
MPEGTS_SERVICE_TYPE_ADVANCED_CODEC_DIGITAL_RADIO }, 0x01, 0xff,
+  AV_OPT_FLAG_ENCODING_PARAM, "mpegts_service_type" },
+{ "mpeg2_digital_hdtv", "MPEG2 Digital HDTV.",
+  0, AV_OPT_TYPE_CONST, { .i64 = MPEGTS_SERVICE_TYPE_MPEG2_DIGITAL_HDTV }, 
0x01, 0xff,
+  AV_OPT_FLAG_ENCODING_PARAM, "mpegts_service_type" },
+{ "advanced_codec_digital_sdtv", "Ad

Re: [FFmpeg-devel] [PATCH 2/3] lavc/libopenjpegenc: add layerrates parameter to allow different compression rates per layer

2015-02-02 Thread Jean First 
>From fe0afff9c7b8c6f78dcad0720965c6f6a50e7813 Mon Sep 17 00:00:00 2001
From: Jean First 
Date: Mon, 2 Feb 2015 12:57:03 +0100
Subject: [PATCH] lavc/libopenjpegenc: move opj_create_compress, opj_cio_open
 and opj_set_event_mgr to libopenjpeg_encode_frame

 libopenjpegenc crashes with "pointer being freed was not allocated" when 
threading
 is enabled with:
 ffmpeg -i tests/vsynth1/01.pgm -vcodec libopenjpeg file.j2k

Signed-off-by: Jean First 
---
 libavcodec/libopenjpegenc.c | 42 --
 1 file changed, 20 insertions(+), 22 deletions(-)

diff --git a/libavcodec/libopenjpegenc.c b/libavcodec/libopenjpegenc.c
index 4039663..53d0fe9 100644
--- a/libavcodec/libopenjpegenc.c
+++ b/libavcodec/libopenjpegenc.c
@@ -43,9 +43,7 @@
 typedef struct {
 AVClass *avclass;
 opj_image_t *image;
-opj_cio_t *stream;
 opj_cparameters_t enc_params;
-opj_cinfo_t *compress;
 opj_event_mgr_t event_mgr;
 int format;
 int profile;
@@ -221,12 +219,6 @@ static av_cold int libopenjpeg_encode_init(AVCodecContext 
*avctx)
 ctx->enc_params.tp_on = 1;
 }
 
-ctx->compress = opj_create_compress(ctx->format);
-if (!ctx->compress) {
-av_log(avctx, AV_LOG_ERROR, "Error creating the compressor\n");
-return AVERROR(ENOMEM);
-}
-
 ctx->image = mj2_create_image(avctx, &ctx->enc_params);
 if (!ctx->image) {
 av_log(avctx, AV_LOG_ERROR, "Error creating the mj2 image\n");
@@ -240,17 +232,9 @@ static av_cold int libopenjpeg_encode_init(AVCodecContext 
*avctx)
 goto fail;
 }
 
-memset(&ctx->event_mgr, 0, sizeof(opj_event_mgr_t));
-ctx->event_mgr.info_handler= info_callback;
-ctx->event_mgr.error_handler = error_callback;
-ctx->event_mgr.warning_handler = warning_callback;
-opj_set_event_mgr((opj_common_ptr) ctx->compress, &ctx->event_mgr, avctx);
-
 return 0;
 
 fail:
-opj_destroy_compress(ctx->compress);
-ctx->compress = NULL;
 opj_image_destroy(ctx->image);
 ctx->image = NULL;
 av_freep(&avctx->coded_frame);
@@ -464,9 +448,9 @@ static int libopenjpeg_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt,
 const AVFrame *frame, int *got_packet)
 {
 LibOpenJPEGContext *ctx = avctx->priv_data;
-opj_cinfo_t *compress   = ctx->compress;
 opj_image_t *image  = ctx->image;
-opj_cio_t *stream   = ctx->stream;
+opj_cinfo_t *compress   = NULL;
+opj_cio_t *stream   = NULL;
 int cpyresult = 0;
 int ret, len;
 AVFrame *gbrframe;
@@ -559,6 +543,12 @@ static int libopenjpeg_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt,
 return -1;
 }
 
+compress = opj_create_compress(ctx->format);
+if (!compress) {
+av_log(avctx, AV_LOG_ERROR, "Error creating the compressor\n");
+return AVERROR(ENOMEM);
+}
+
 opj_setup_encoder(compress, &ctx->enc_params, image);
 
 stream = opj_cio_open((opj_common_ptr) compress, NULL, 0);
@@ -567,6 +557,12 @@ static int libopenjpeg_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt,
 return AVERROR(ENOMEM);
 }
 
+memset(&ctx->event_mgr, 0, sizeof(opj_event_mgr_t));
+ctx->event_mgr.info_handler= info_callback;
+ctx->event_mgr.error_handler   = error_callback;
+ctx->event_mgr.warning_handler = warning_callback;
+opj_set_event_mgr((opj_common_ptr) compress, &ctx->event_mgr, avctx);
+
 if (!opj_encode(compress, stream, image, NULL)) {
 av_log(avctx, AV_LOG_ERROR, "Error during the opj encode\n");
 return -1;
@@ -580,6 +576,12 @@ static int libopenjpeg_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt,
 memcpy(pkt->data, stream->buffer, len);
 pkt->flags |= AV_PKT_FLAG_KEY;
 *got_packet = 1;
+
+opj_cio_close(stream);
+stream = NULL;
+opj_destroy_compress(compress);
+compress = NULL;
+
 return 0;
 }
 
@@ -587,10 +589,6 @@ static av_cold int libopenjpeg_encode_close(AVCodecContext 
*avctx)
 {
 LibOpenJPEGContext *ctx = avctx->priv_data;
 
-opj_cio_close(ctx->stream);
-ctx->stream = NULL;
-opj_destroy_compress(ctx->compress);
-ctx->compress = NULL;
 opj_image_destroy(ctx->image);
 ctx->image = NULL;
 av_freep(&avctx->coded_frame);
-- 
2.2.2

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

Re: [FFmpeg-devel] [PATCH] avcodec/hevc: reduce memory used by the SAO

2015-02-02 Thread Michael Niedermayer 
On Mon, Feb 02, 2015 at 07:41:54AM +0100, Christophe Gisquet wrote:
> Hi,
> 
> the attached patch is somewhat of a hack job, as the commit I used may
> already have been edited from its original version, and I have added
> some stuff on top of it (eg the commit message).

hmm, is there a reason not to take the original commit unchanged ?
I was hoping to reduce the difference to openhevc so that we also
are able to merge future changes from openhevc with few confilcts
but maybe iam missing something

also it seems this does not apply cleanly

Applying: avcodec/hevc: reduce memory used by the SAO
fatal: sha1 information is lacking or useless (libavcodec/hevc.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 avcodec/hevc: reduce memory used by the SAO
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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/hevc: reduce memory used by the SAO

2015-02-02 Thread Christophe Gisquet 
Hi,

2015-02-02 13:32 GMT+01:00 Michael Niedermayer :
> On Mon, Feb 02, 2015 at 07:41:54AM +0100, Christophe Gisquet wrote:
> hmm, is there a reason not to take the original commit unchanged ?
> I was hoping to reduce the difference to openhevc so that we also
> are able to merge future changes from openhevc with few confilcts
> but maybe iam missing something

Because there are alignment requirements in our dsp, and technically,
adding another buffer (which isn't aligned) while there are already
perfectly good ones is not the best solution (memory-wise and
bookkeeping-wise).

I'd go as far as suggest openhevc to align to this version. But maybe
they have diverged too much.

Also, I don't really like merge for the sake of merging in that case,
because those are matters difficult to follow, and I prefer something
that is more logical and makes sense.

> also it seems this does not apply cleanly

OK, I took a shortcut thinking my branch wouldn't cause such an issue.
Please try the attached patch.

-- 
Christophe
From c691861e730f941412749b764a15d66c26d9a216 Mon Sep 17 00:00:00 2001
From: Fabrice Bellard 
Date: Mon, 12 Jan 2015 23:35:25 +0100
Subject: [PATCH] avcodec/hevc: reduce memory used by the SAO

SAO edge filter uses pre-SAO pixel data on the left and top of the ctb, so
this data must be kept available. This was done previously by having 2
copies of the frame, one before and one after SAO.

This patch reduces the storage to just that, instead of the previous whole
frame. A slight adaptation from Fabrice's version is to match our alignment
requirements, and abuse the edge emu buffers instead of adding a new
buffer.

Decicycles: 26772->26220 (BO32),  83803->80942 (BO64)

Signed-off-by: Christophe Gisquet 
---
 libavcodec/hevc.c|  43 +--
 libavcodec/hevc.h|   5 +-
 libavcodec/hevc_filter.c | 192 ++-
 3 files changed, 177 insertions(+), 63 deletions(-)

diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index f24cd8f..7699297 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -280,24 +280,6 @@ static int decode_lt_rps(HEVCContext *s, LongTermRPS *rps, GetBitContext *gb)
 return 0;
 }
 
-static int get_buffer_sao(HEVCContext *s, AVFrame *frame, const HEVCSPS *sps)
-{
-int ret, i;
-
-frame->width  = FFALIGN(s->avctx->coded_width + 2, FF_INPUT_BUFFER_PADDING_SIZE);
-frame->height = s->avctx->coded_height + 3;
-if ((ret = ff_get_buffer(s->avctx, frame, AV_GET_BUFFER_FLAG_REF)) < 0)
-return ret;
-for (i = 0; frame->data[i]; i++) {
-int offset = frame->linesize[i] + FF_INPUT_BUFFER_PADDING_SIZE;
-frame->data[i] += offset;
-}
-frame->width  = s->avctx->coded_width;
-frame->height = s->avctx->coded_height;
-
-return 0;
-}
-
 static int set_sps(HEVCContext *s, const HEVCSPS *sps)
 {
 #define HWACCEL_MAX (CONFIG_HEVC_DXVA2_HWACCEL)
@@ -353,9 +335,19 @@ static int set_sps(HEVCContext *s, const HEVCSPS *sps)
 ff_videodsp_init (&s->vdsp,sps->bit_depth);
 
 if (sps->sao_enabled && !s->avctx->hwaccel) {
-av_frame_unref(s->tmp_frame);
-ret = get_buffer_sao(s, s->tmp_frame, sps);
-s->sao_frame = s->tmp_frame;
+int c_count = (sps->chroma_format_idc != 0) ? 3 : 1;
+int c_idx;
+
+for(c_idx = 0; c_idx < c_count; c_idx++) {
+int w = sps->width >> sps->hshift[c_idx];
+int h = sps->height >> sps->vshift[c_idx];
+s->sao_pixel_buffer_h[c_idx] =
+av_malloc((w * 2 * sps->ctb_height) <<
+  sps->pixel_shift);
+s->sao_pixel_buffer_v[c_idx] =
+av_malloc((h * 2 * sps->ctb_width) <<
+  sps->pixel_shift);
+}
 }
 
 s->sps = sps;
@@ -3175,7 +3167,10 @@ static av_cold int hevc_decode_free(AVCodecContext *avctx)
 
 av_freep(&s->cabac_state);
 
-av_frame_free(&s->tmp_frame);
+for (i = 0; i < 3; i++) {
+av_freep(&s->sao_pixel_buffer_h[i]);
+av_freep(&s->sao_pixel_buffer_v[i]);
+}
 av_frame_free(&s->output_frame);
 
 for (i = 0; i < FF_ARRAY_ELEMS(s->DPB); i++) {
@@ -3235,10 +3230,6 @@ static av_cold int hevc_init_context(AVCodecContext *avctx)
 if (!s->cabac_state)
 goto fail;
 
-s->tmp_frame = av_frame_alloc();
-if (!s->tmp_frame)
-goto fail;
-
 s->output_frame = av_frame_alloc();
 if (!s->output_frame)
 goto fail;
diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
index 1727b60..ae9a32a 100644
--- a/libavcodec/hevc.h
+++ b/libavcodec/hevc.h
@@ -769,6 +769,7 @@ typedef struct HEVCLocalContext {
 int end_of_tiles_y;
 /* +7 is for subpixel interpolation, *2 for high bit depths */
 DECLARE_ALIGNED(32, uint8_t, edge_emu_buffer)[(MAX_PB_SIZE + 7) * EDGE_EMU_BUFFER_STRIDE * 2];
+/* The extended size between the new edge emu buffer is abused by SAO */
 DECLARE_ALIGNED(32, uint8_t, edge_emu_buffer2)[(MAX_PB

[FFmpeg-devel] [PATCH] x86: hevc_mc: remove non necessary moves

2015-02-02 Thread Christophe Gisquet 
This is not a clean equivalent of the openhevc patch, as we don't have
the same history on hevc_mc.

-- 
Christophe
From 0eedfb7d5902cc388d018111c670cc31ad22db60 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micka=C3=ABl=20Raulet?= 
Date: Thu, 31 Jul 2014 19:26:57 +0200
Subject: [PATCH] x86: hevc_mc: remove non necessary moves

Signed-off-by: Christophe Gisquet 
---
 libavcodec/x86/hevc_mc.asm | 48 +-
 1 file changed, 18 insertions(+), 30 deletions(-)

diff --git a/libavcodec/x86/hevc_mc.asm b/libavcodec/x86/hevc_mc.asm
index 42fe65a..99f8c0a 100644
--- a/libavcodec/x86/hevc_mc.asm
+++ b/libavcodec/x86/hevc_mc.asm
@@ -81,20 +81,6 @@ QPEL_TABLE 12, 4, w, sse4
 
 %if ARCH_X86_64
 
-%macro SIMPLE_BILOAD 4   ;width, tab, r1, r2
-%if %1 <= 4
-movq  %3, [%2]  ; load data from source2
-%elif %1 <= 8
-movdqa%3, [%2]  ; load data from source2
-%elif %1 <= 12
-movdqa%3, [%2]  ; load data from source2
-movq  %4, [%2+16]   ; load data from source2
-%else
-movdqa%3, [%2]  ; load data from source2
-movdqa%4, [%2+16]   ; load data from source2
-%endif
-%endmacro
-
 %macro SIMPLE_LOAD 4;width, bitd, tab, r1
 %if %1 == 2 || (%2 == 8 && %1 <= 4)
 movd  %4, [%3]   ; load data from source
@@ -505,11 +491,20 @@ QPEL_TABLE 12, 4, w, sse4
 %endif
 %endmacro
 
-%macro BI_COMPUTE 7 ; width, bitd, src1l, src1h, scr2l, scr2h, pw
+%macro SIMPLE_BILOAD 5   ;width, tab, r1, r2
+%if %1 <= 4
+movq  %5, [%2]  ; load data from source2
 paddsw%3, %5
+%else
+paddsw%3, [%2]
 %if %1 > 8
-paddsw%4, %6
+paddsw%4, [%2+16]   ; load data from source2
+%endif
 %endif
+%endmacro
+
+%macro BI_COMPUTE 7 ; width, bitd, src1l, src1h, scr2l, scr2h, pw
+SIMPLE_BILOAD %1, %6, %3, %4, %5
 UNI_COMPUTE   %1, %2, %3, %4, %7
 %endmacro
 
@@ -562,9 +557,8 @@ cglobal hevc_put_hevc_bi_pel_pixels%1_%2, 6, 6, 6, dst, dststride, src, srcstrid
 movdqam5, [pw_bi_%2]
 .loop
 SIMPLE_LOAD   %1, %2, srcq, m0
-SIMPLE_BILOAD %1, src2q, m3, m4
 MC_PIXEL_COMPUTE  %1, %2
-BI_COMPUTE%1, %2, m0, m1, m3, m4, m5
+BI_COMPUTE%1, %2, m0, m1, m3, src2q, m5
 PEL_%2STORE%1   dstq, m0, m1
 add dstq, dststrideq ; dst += dststride
 add srcq, srcstrideq ; src += srcstride
@@ -616,8 +610,7 @@ cglobal hevc_put_hevc_bi_epel_h%1_%2, 7, 8, 11, dst, dststride, src, srcstride,
 .loop
 EPEL_LOAD %2, srcq-%%stride, %%stride, %1
 EPEL_COMPUTE  %2, %1, m4, m5
-SIMPLE_BILOAD %1, src2q, m2, m3
-BI_COMPUTE%1, %2, m0, m1, m2, m3, m6
+BI_COMPUTE%1, %2, m0, m1, m2, src2q, m6
 PEL_%2STORE%1   dstq, m0, m1
 add dstq, dststrideq ; dst += dststride
 add srcq, srcstrideq ; src += srcstride
@@ -669,8 +662,7 @@ cglobal hevc_put_hevc_bi_epel_v%1_%2, 8, 9, 11, dst, dststride, src, srcstride,
 .loop
 EPEL_LOAD %2, srcq, srcstride, %1
 EPEL_COMPUTE  %2, %1, m4, m5
-SIMPLE_BILOAD %1, src2q, m2, m3
-BI_COMPUTE%1, %2, m0, m1, m2, m3, m6
+BI_COMPUTE%1, %2, m0, m1, m2, src2q, m6
 PEL_%2STORE%1   dstq, m0, m1
 add dstq, dststrideq ; dst += dststride
 add srcq, srcstrideq ; src += srcstride
@@ -788,8 +780,7 @@ cglobal hevc_put_hevc_bi_epel_hv%1_%2, 8, 10, 16, dst, dststride, src, srcstride
 punpckhwd m3, m6, m7
 %endif
 EPEL_COMPUTE  14, %1, m12, m13
-SIMPLE_BILOAD %1, src2q, m8, m9
-BI_COMPUTE%1, %2, m0, m1, m8, m9, [pw_bi_%2]
+BI_COMPUTE%1, %2, m0, m1, m8, src2q, [pw_bi_%2]
 PEL_%2STORE%1   dstq, m0, m1
 movdqam4, m5
 movdqam5, m6
@@ -847,8 +838,7 @@ cglobal hevc_put_hevc_bi_qpel_h%1_%2, 7, 8, 16 , dst, dststride, src, srcstride,
 %if %2 > 8
 packssdw  m0, m1
 %endif
-SIMPLE_BILOAD %1, src2q, m10, m11
-BI_COMPUTE%1, %2, m0, m1, m10, m11, m9
+BI_COMPUTE%1, %2, m0, m1, m10, src2q, m9
 PEL_%2STORE%1   dstq, m0, m1
 add dstq, dststrideq ; dst += dststride
 add srcq, srcstrideq ; src += srcstride
@@ -900,13 +890,12 @@ cglobal hevc_put_hevc_bi_qpel_v%1_%2, 8, 10, 16, dst, dststride, src, srcstride,
 lea   r3srcq, [srcstrideq*3]
 QPEL_FILTER   %2, my
 .loo

Re: [FFmpeg-devel] [PATCH] avcodec/wavpackenc: remove unneeded L suffixes

2015-02-02 Thread Michael Niedermayer 
On Mon, Feb 02, 2015 at 08:57:04AM +, Paul B Mahol wrote:
> On 2/1/15, Michael Niedermayer  wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/wavpackenc.c |8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/wavpackenc.c b/libavcodec/wavpackenc.c
> > index 63971c6..c174950 100644
> > --- a/libavcodec/wavpackenc.c
> > +++ b/libavcodec/wavpackenc.c
> > @@ -640,9 +640,9 @@ static uint32_t log2sample(uint32_t v, int limit,
> > uint32_t *result)
> >  dbits = nbits_table[v];
> >  *result += (dbits << 8) + wp_log2_table[(v << (9 - dbits)) &
> > 0xff];
> >  } else {
> > -if (v < (1L << 16))
> > +if (v < (1 << 16))
> >  dbits = nbits_table[v >> 8] + 8;
> > -else if (v < (1L << 24))
> > +else if (v < (1 << 24))
> >  dbits = nbits_table[v >> 16] + 16;
> >  else
> >  dbits = nbits_table[v >> 24] + 24;
> > @@ -1967,8 +1967,8 @@ static int wv_stereo(WavPackEncodeContext *s,
> >  #define count_bits(av) ( \
> >   (av) < (1 << 8) ? nbits_table[av] : \
> >( \
> > -   (av) < (1L << 16) ? nbits_table[(av) >> 8] + 8 : \
> > -   ((av) < (1L << 24) ? nbits_table[(av) >> 16] + 16 : nbits_table[(av) >>
> > 24] + 24) \
> > +   (av) < (1 << 16) ? nbits_table[(av) >> 8] + 8 : \
> > +   ((av) < (1 << 24) ? nbits_table[(av) >> 16] + 16 : nbits_table[(av) >>
> > 24] + 24) \
> >) \
> >  )
> >
> > --
> > 1.7.9.5
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> 
> ok

applied

thx

[...]
-- 
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] avcodec/hevc: reduce memory used by the SAO

2015-02-02 Thread Michael Niedermayer 
On Mon, Feb 02, 2015 at 02:22:36PM +0100, Christophe Gisquet wrote:
> Hi,
> 
> 2015-02-02 13:32 GMT+01:00 Michael Niedermayer :
> > On Mon, Feb 02, 2015 at 07:41:54AM +0100, Christophe Gisquet wrote:
> > hmm, is there a reason not to take the original commit unchanged ?
> > I was hoping to reduce the difference to openhevc so that we also
> > are able to merge future changes from openhevc with few confilcts
> > but maybe iam missing something
> 
> Because there are alignment requirements in our dsp, and technically,
> adding another buffer (which isn't aligned) while there are already
> perfectly good ones is not the best solution (memory-wise and
> bookkeeping-wise).
> 

> I'd go as far as suggest openhevc to align to this version. But maybe
> they have diverged too much.

iam happy with either openhevc picking this version or us picking
the one from openhevc with minimal changes needed to make it work for
us..
Though in the first case we should pick the openhevc version and
comit our changes in a seperate commit on top so openhevc can
more easily pick the changes we made if they want to.

either way i hope very much that openhevcs and our implementation
could stay similar as divergence would mean duplicated maintaince
effort and both projects would have to do extra work in picking
changes from the other


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] PATCH dshow show devices options

2015-02-02 Thread Roger Pack 
On 1/31/15, Roger Pack  wrote:
> On 1/30/15, Michael Niedermayer  wrote:
>> On Fri, Jan 30, 2015 at 08:55:45AM -0700, Roger Pack wrote:
>>> On 1/30/15, Don Moir  wrote:
>>> >
>>> > - Original Message -
>>> > From: "Roger Pack" 
>>> > To: "FFmpeg development discussions and patches"
>>> > 
>>> > Sent: Friday, January 30, 2015 7:09 AM
>>> > Subject: [FFmpeg-devel] PATCH dshow show devices options
>>> >
>>> >
>>> >> See attached.  Hope I didn't get it reversed or something weird.
>>> >> -roger-
>>> >>
>>> > -#define DSHOWDEBUG 0
>>> > +/* Set to 1 to enable lots of verbose DSHOW debug info the logger */
>>> > +#define DSHOWDEBUG 1
>>> >
>>> > Seems to turn on a lot of over head even if not displayed.
>>>
>>> Oops good eye.  Thought I had just added the comment but no.
>>> Revision attached.
>>>
>>> If you'd like to review the other recent dshow commits feedback
>>> welcome there also.
>>> Cheers!
>>> -roger-
>>
>>>  dshow.c |   12 +++-
>>>  dshow_capture.h |1 +
>>>  2 files changed, 8 insertions(+), 5 deletions(-)
>>> 8cc6a2d1787151cc1a72be27dd5d5178784eb15a
>>> 0001-dshow-show-incremental-values-allowed.patch
>>> From e8e08ee49c6f80b02334891207d9f0d1b165b4b9 Mon Sep 17 00:00:00 2001
>>> From: rogerdpack 
>>> Date: Fri, 30 Jan 2015 08:53:16 -0700
>>> Subject: [PATCH] dshow: show incremental values allowed
>>>
>>> Signed-off-by: rogerdpack 
>>> ---
>>>  libavdevice/dshow.c | 12 +++-
>>>  libavdevice/dshow_capture.h |  1 +
>>>  2 files changed, 8 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
>>> index d03670e..f823793 100644
>>> --- a/libavdevice/dshow.c
>>> +++ b/libavdevice/dshow.c
>>> @@ -365,18 +365,18 @@ dshow_cycle_formats(AVFormatContext *avctx, enum
>>> dshowDeviceType devtype,
>>>  enum AVCodecID codec_id = av_codec_get_id(tags,
>>> bih->biCompression);
>>>  AVCodec *codec = avcodec_find_decoder(codec_id);
>>>  if (codec_id == AV_CODEC_ID_NONE || !codec) {
>>> -av_log(avctx, AV_LOG_INFO, "  unknown
>>> compression
>>> type 0x%X", (int) bih->biCompression);
>>> +av_log(avctx, AV_LOG_INFO, "  unknown
>>> compression
>>> type [please report] 0x%X", (int) bih->biCompression);
>>
>> this maybe should say where to report to like email address or url
>> of ffmpeg-devel
>>
>> the other changes look fine though if one wanted to nitpick could
>> be in seperate patches

OK see the attached.
Thanks!


0001-dshow-note-where-to-report-missing-codecs-add-commen.patch
Description: Binary data


0002-dshow-show-incremental-values-allowed.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/hevc: reduce memory used by the SAO

2015-02-02 Thread Michael Niedermayer 
On Mon, Feb 02, 2015 at 03:31:54PM +0100, Michael Niedermayer wrote:
> On Mon, Feb 02, 2015 at 02:22:36PM +0100, Christophe Gisquet wrote:
> > Hi,
> > 
> > 2015-02-02 13:32 GMT+01:00 Michael Niedermayer :
> > > On Mon, Feb 02, 2015 at 07:41:54AM +0100, Christophe Gisquet wrote:
> > > hmm, is there a reason not to take the original commit unchanged ?
> > > I was hoping to reduce the difference to openhevc so that we also
> > > are able to merge future changes from openhevc with few confilcts
> > > but maybe iam missing something
> > 
> > Because there are alignment requirements in our dsp, and technically,
> > adding another buffer (which isn't aligned) while there are already
> > perfectly good ones is not the best solution (memory-wise and
> > bookkeeping-wise).
> > 
> 
> > I'd go as far as suggest openhevc to align to this version. But maybe
> > they have diverged too much.
> 
> iam happy with either openhevc picking this version or us picking
> the one from openhevc with minimal changes needed to make it work for
> us..

> Though in the first case we should pick the openhevc version and
> comit our changes in a seperate commit on top so openhevc can
> more easily pick the changes we made if they want to.

For reference attached the difference between the 2 implementations
that is diff between this version and the one cherry picked from
openhevc (actually cherry picked yesterday and rebased to HEAD)

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
From d6c12c28f8a03edebab03f18631fa30ade01d0da Mon Sep 17 00:00:00 2001
From: Christophe Gisquet 
Date: Mon, 2 Feb 2015 15:51:45 +0100
Subject: [PATCH 2/2] Changes on top of openhevc

Signed-off-by: Michael Niedermayer 
---
 libavcodec/hevc.c|   65 +++---
 libavcodec/hevc.h|   11 +---
 libavcodec/hevc_filter.c |   56 ++-
 3 files changed, 18 insertions(+), 114 deletions(-)

diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index 1b526a0..7699297 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -104,8 +104,7 @@ static int pic_arrays_init(HEVCContext *s, const HEVCSPS *sps)
 
 s->cbf_luma = av_malloc_array(sps->min_tb_width, sps->min_tb_height);
 s->tab_ipm  = av_mallocz(min_pu_size);
-s->is_pcm   = av_mallocz_array(sps->min_pu_width + 1, sps->min_pu_height + 1);
-
+s->is_pcm   = av_malloc_array(sps->min_pu_width + 1, sps->min_pu_height + 1);
 if (!s->tab_ipm || !s->cbf_luma || !s->is_pcm)
 goto fail;
 
@@ -281,24 +280,6 @@ static int decode_lt_rps(HEVCContext *s, LongTermRPS *rps, GetBitContext *gb)
 return 0;
 }
 
-static int get_buffer_sao(HEVCContext *s, AVFrame *frame, const HEVCSPS *sps)
-{
-int ret, i;
-
-frame->width  = FFALIGN(s->avctx->coded_width + 2, FF_INPUT_BUFFER_PADDING_SIZE);
-frame->height = s->avctx->coded_height + 3;
-if ((ret = ff_get_buffer(s->avctx, frame, AV_GET_BUFFER_FLAG_REF)) < 0)
-return ret;
-for (i = 0; frame->data[i]; i++) {
-int offset = frame->linesize[i] + FF_INPUT_BUFFER_PADDING_SIZE;
-frame->data[i] += offset;
-}
-frame->width  = s->avctx->coded_width;
-frame->height = s->avctx->coded_height;
-
-return 0;
-}
-
 static int set_sps(HEVCContext *s, const HEVCSPS *sps)
 {
 #define HWACCEL_MAX (CONFIG_HEVC_DXVA2_HWACCEL)
@@ -354,34 +335,19 @@ static int set_sps(HEVCContext *s, const HEVCSPS *sps)
 ff_videodsp_init (&s->vdsp,sps->bit_depth);
 
 if (sps->sao_enabled && !s->avctx->hwaccel) {
-#ifdef USE_SAO_SMALL_BUFFER
-{
-int ctb_size = 1 << sps->log2_ctb_size;
-int c_count = (sps->chroma_format_idc != 0) ? 3 : 1;
-int c_idx, i;
-
-for (i = 0; i < s->threads_number ; i++) {
-HEVCLocalContext*lc = s->HEVClcList[i];
-lc->sao_pixel_buffer =
-av_malloc(((ctb_size + 2) * (ctb_size + 2)) <<
-  sps->pixel_shift);
-}
-for(c_idx = 0; c_idx < c_count; c_idx++) {
-int w = sps->width >> sps->hshift[c_idx];
-int h = sps->height >> sps->vshift[c_idx];
-s->sao_pixel_buffer_h[c_idx] =
+int c_count = (sps->chroma_format_idc != 0) ? 3 : 1;
+int c_idx;
+
+for(c_idx = 0; c_idx < c_count; c_idx++) {
+int w = sps->width >> sps->hshift[c_idx];
+int h = sps->height >> sps->vshift[c_idx];
+s->sao_pixel_buffer_h[c_idx] =
 av_malloc((w * 2 * sps->ctb_height) <<
   sps->pixel_shift);
-s->sao_pixel_buffer_v[c_idx] =
+s->sao_pixel_buffer_v[c_idx] =
 av_malloc((h * 2 * sps->ctb_width) <<
   sps->pixel_shift);
-}
 }
-#else
-av_frame_unref(s->tmp_frame);
-

[FFmpeg-devel] support for monochrome sequences in hevc decoder

2015-02-02 Thread Mickaël Raulet 
Hi here is a commit that support monochrome sequences!

https://github.com/OpenHEVC/FFmpeg/commit/8e50557707d2ec11ccad657470b2e140f314348e

Commit hash: 8e50557707d2ec11ccad657470b2e140f314348e

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

Re: [FFmpeg-devel] support for monochrome sequences in hevc decoder

2015-02-02 Thread Michael Niedermayer 
On Mon, Feb 02, 2015 at 04:11:33PM +0100, Mickaël Raulet wrote:
> Hi here is a commit that support monochrome sequences!
> 
> https://github.com/OpenHEVC/FFmpeg/commit/8e50557707d2ec11ccad657470b2e140f314348e
> 
> Commit hash: 8e50557707d2ec11ccad657470b2e140f314348e

is this an independant implementation than the one from fabrices BPG?
or is it based on his ?
iam asking so i know if i should add a "Based-on: ..." to the commit
message

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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

Re: [FFmpeg-devel] support for monochrome sequences in hevc decoder

2015-02-02 Thread Mickaël Raulet 
I did it first :)

2015-02-02 16:47 GMT+01:00 Michael Niedermayer :

> On Mon, Feb 02, 2015 at 04:11:33PM +0100, Mickaël Raulet wrote:
> > Hi here is a commit that support monochrome sequences!
> >
> >
> https://github.com/OpenHEVC/FFmpeg/commit/8e50557707d2ec11ccad657470b2e140f314348e
> >
> > Commit hash: 8e50557707d2ec11ccad657470b2e140f314348e
>
> is this an independant implementation than the one from fabrices BPG?
> or is it based on his ?
> iam asking so i know if i should add a "Based-on: ..." to the commit
> message
>
> Thanks
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The misfortune of the wise is better than the prosperity of the fool.
> -- Epicurus
>
> ___
> 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] x86: hevc_mc: remove non necessary moves

2015-02-02 Thread Mickaël Raulet 
Hi christophe,

I was willing to send avx2 mc patch, but I need to test it on top of ffmpeg
head. Last time I tried I had to revert
940300945995c20f7583394ebe6907e72829b4a.

https://github.com/OpenHEVC/FFmpeg/commit/940300945995c20f7583394ebe6907e72829b4a
.

Here is the avx2 implementation if someone has time to revise it or to make
it work without reverting anything.

https://github.com/OpenHEVC/FFmpeg/commit/b11101025c837cae58a29eaa357e6165da6a3240#diff-8b13abd742ccbe04c65fcdc4ec1e3487

Mickaël

2015-02-02 14:37 GMT+01:00 Christophe Gisquet 
:

> This is not a clean equivalent of the openhevc patch, as we don't have
> the same history on hevc_mc.
>
> --
> Christophe
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavc/libopenjpegenc: add layerrates parameter to allow different compression rates per layer

2015-02-02 Thread Michael Niedermayer 
On Mon, Feb 02, 2015 at 01:18:35PM +0100, Jean First wrote:
>  libopenjpegenc.c |   42 --
>  1 file changed, 20 insertions(+), 22 deletions(-)
> 6bed682adf441fa060b9fef84df173cd758320ed  
> 0001-lavc-libopenjpegenc-move-opj_create_compress-opj_cio.patch
> From fe0afff9c7b8c6f78dcad0720965c6f6a50e7813 Mon Sep 17 00:00:00 2001
> From: Jean First 
> Date: Mon, 2 Feb 2015 12:57:03 +0100
> Subject: [PATCH] lavc/libopenjpegenc: move opj_create_compress, opj_cio_open
>  and opj_set_event_mgr to libopenjpeg_encode_frame
> 

>  libopenjpegenc crashes with "pointer being freed was not allocated" when 
> threading
>  is enabled with:
>  ffmpeg -i tests/vsynth1/01.pgm -vcodec libopenjpeg file.j2k

cannot reproduce
do i assume correctly that this is a bug in libopenjpeg and unlreated
to this patch ?


[...]

-- 
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 1/3] lavc/libopenjpegenc: factorize cinema parameters to it's own function

2015-02-02 Thread Michael Niedermayer 
On Wed, Jan 28, 2015 at 04:41:24PM +0100, Jean First wrote:
> Signed-off-by: Jean First 
> ---
> 
>  also reordered them slightly to match the code in image_to_j2k.c provided by 
> openjpeg
>  
>  libavcodec/libopenjpegenc.c | 62 
> ++---
>  1 file changed, 36 insertions(+), 26 deletions(-)

applied

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 2/3] lavc/libopenjpegenc: add layerrates parameter to allow different compression rates per layer

2015-02-02 Thread Jean First 
On Mon Feb 02 2015 17:20:44 GMT+0100 (CET), Michael Niedermayer wrote:
> On Mon, Feb 02, 2015 at 01:18:35PM +0100, Jean First wrote:
>>  libopenjpegenc.c |   42 --
>>  1 file changed, 20 insertions(+), 22 deletions(-)
>> 6bed682adf441fa060b9fef84df173cd758320ed  
>> 0001-lavc-libopenjpegenc-move-opj_create_compress-opj_cio.patch
>> From fe0afff9c7b8c6f78dcad0720965c6f6a50e7813 Mon Sep 17 00:00:00 2001
>> From: Jean First 
>> Date: Mon, 2 Feb 2015 12:57:03 +0100
>> Subject: [PATCH] lavc/libopenjpegenc: move opj_create_compress, opj_cio_open
>>  and opj_set_event_mgr to libopenjpeg_encode_frame
>>
>>  libopenjpegenc crashes with "pointer being freed was not allocated" when 
>> threading
>>  is enabled with:
>>  ffmpeg -i tests/vsynth1/01.pgm -vcodec libopenjpeg file.j2k
> cannot reproduce
> do i assume correctly that this is a bug in libopenjpeg and unlreated
> to this patch ?
>

Yes, that's my guess. Any other implementation I saw using libopenjpeg
did initialise and encode the date in the same thread.
Jean

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

Re: [FFmpeg-devel] [PATCH 1/3] lavc/libopenjpegenc: factorize cinema parameters to it's own function

2015-02-02 Thread Michael Niedermayer 
On Mon, Feb 02, 2015 at 05:21:06PM +0100, Michael Niedermayer wrote:
> On Wed, Jan 28, 2015 at 04:41:24PM +0100, Jean First wrote:
> > Signed-off-by: Jean First 
> > ---
> > 
> >  also reordered them slightly to match the code in image_to_j2k.c provided 
> > by openjpeg
> >  
> >  libavcodec/libopenjpegenc.c | 62 
> > ++---
> >  1 file changed, 36 insertions(+), 26 deletions(-)
> 
> applied

note, ive left tcp_mct = 1 in there, iam not sure why its removed
but that should not happen in a patch moving the code at least

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

Re: [FFmpeg-devel] libopenjpegenc improvements

2015-02-02 Thread Michael Niedermayer 
On Wed, Jan 28, 2015 at 04:41:23PM +0100, Jean First wrote:
> This patchset sould alow ffmpeg to create jpeg2000 files conforming to the 
> dci specification.
> 
> Most of the code originates form the image_to_j2k file provided by openjpeg.
> 
> Can someone shed some light, if the following parameter is also needed ?

purely from a compression/quality point of view MCT should be used
for correlated colorspaces like RGB/RGBA but not YUV/YUVA and cannot
be used when theres just 1 component, i dont know what the specs
say about when it must or must not be used

not sure this awnsers your question

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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/3] lavc/libopenjpegenc: add layerrates parameter to allow different compression rates per layer

2015-02-02 Thread Michael Niedermayer 
On Mon, Feb 02, 2015 at 05:31:07PM +0100, Jean First wrote:
> On Mon Feb 02 2015 17:20:44 GMT+0100 (CET), Michael Niedermayer wrote:
> > On Mon, Feb 02, 2015 at 01:18:35PM +0100, Jean First wrote:
> >>  libopenjpegenc.c |   42 --
> >>  1 file changed, 20 insertions(+), 22 deletions(-)
> >> 6bed682adf441fa060b9fef84df173cd758320ed  
> >> 0001-lavc-libopenjpegenc-move-opj_create_compress-opj_cio.patch
> >> From fe0afff9c7b8c6f78dcad0720965c6f6a50e7813 Mon Sep 17 00:00:00 2001
> >> From: Jean First 
> >> Date: Mon, 2 Feb 2015 12:57:03 +0100
> >> Subject: [PATCH] lavc/libopenjpegenc: move opj_create_compress, 
> >> opj_cio_open
> >>  and opj_set_event_mgr to libopenjpeg_encode_frame
> >>
> >>  libopenjpegenc crashes with "pointer being freed was not allocated" when 
> >> threading
> >>  is enabled with:
> >>  ffmpeg -i tests/vsynth1/01.pgm -vcodec libopenjpeg file.j2k
> > cannot reproduce
> > do i assume correctly that this is a bug in libopenjpeg and unlreated
> > to this patch ?
> >
> 
> Yes, that's my guess. Any other implementation I saw using libopenjpeg
> did initialise and encode the date in the same thread.

ok, patch applied with slightly updated commit message to clarify
this
also this should be reported to libopenjpeg if its intended to
work or we should disable multiple threads or both

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] x86: hevc_mc: remove non necessary moves

2015-02-02 Thread Christophe Gisquet 
Hi,

2015-02-02 17:16 GMT+01:00 Mickaël Raulet :
> https://github.com/OpenHEVC/FFmpeg/commit/940300945995c20f7583394ebe6907e72829b4a

No longer apply cleanly, as multiple fixes and improvements have been
committed since then.

The attached patch fixes that, and passes on a non-avx2 machine. I
can't test it, and I'm not looking forward to do debug through a ssh
shell.

And who is the actual author? It has been committed under your name,
but wouldn't that be P-E Lepere rather?

And I guess I'll drop the previous patch for now.

-- 
Christophe
From f326724af77a65acc42eaabf17db6c30e8b7f75c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micka=C3=ABl=20Raulet?= 
Date: Thu, 31 Jul 2014 01:15:20 +0200
Subject: [PATCH] x86/hevc: add MC AVX2 optimizations

before
33304 decicycles in luma_bi_1, 523066 runs, 1222 skips
38138 decicycles in luma_bi_2, 523427 runs, 861 skips
13490 decicycles in luma_uni, 516138 runs, 8150 skips
after
20185 decicycles in luma_bi_1, 519970 runs, 4318 skips
24620 decicycles in luma_bi_2, 521024 runs, 3264 skips
10397 decicycles in luma_uni, 515715 runs, 8573 skips

Conflicts:
	libavcodec/x86/hevc_mc.asm
	libavcodec/x86/hevcdsp_init.c
---
 libavcodec/x86/hevc_mc.asm| 584 +++---
 libavcodec/x86/hevcdsp.h  | 105 
 libavcodec/x86/hevcdsp_init.c | 371 ++-
 3 files changed, 910 insertions(+), 150 deletions(-)

diff --git a/libavcodec/x86/hevc_mc.asm b/libavcodec/x86/hevc_mc.asm
index 8f9f939..e8d1e3a 100644
--- a/libavcodec/x86/hevc_mc.asm
+++ b/libavcodec/x86/hevc_mc.asm
@@ -20,19 +20,20 @@
 ; */
 %include "libavutil/x86/x86util.asm"
 
-SECTION_RODATA
-pw_8:   times 8 dw (1 << 9)
-pw_10:  times 8 dw (1 << 11)
-pw_12:  times 8 dw (1 << 13)
-pw_bi_8:times 8 dw (1 << 8)
-pw_bi_10:   times 8 dw (1 << 10)
-pw_bi_12:   times 8 dw (1 << 12)
-max_pixels_10:  times 8  dw ((1 << 10)-1)
-max_pixels_12:  times 8  dw ((1 << 12)-1)
-zero:   times 4  dd 0
-one_per_32: times 4  dd 1
-
-SECTION .text
+SECTION_RODATA 32
+pw_8:   times 16 dw  (1 <<  9)
+pw_10:  times 16 dw  (1 << 11)
+pw_12:  times 16 dw  (1 << 13)
+pw_bi_8:times 16 dw  (1 <<  8)
+pw_bi_10:   times 16 dw  (1 << 10)
+pw_bi_12:   times 16 dw  (1 << 12)
+max_pixels_8:   times 16 dw ((1 <<  8)-1)
+max_pixels_10:  times 16 dw ((1 << 10)-1)
+max_pixels_12:  times 16 dw ((1 << 12)-1)
+zero:   times 8  dd 0
+one_per_32: times 8  dd 1
+
+SECTION_TEXT 32
 %macro EPEL_TABLE 4
 hevc_epel_filters_%4_%1 times %2 d%3 -2, 58
 times %2 d%3 10, -2
@@ -51,6 +52,8 @@ hevc_epel_filters_%4_%1 times %2 d%3 -2, 58
 %endmacro
 
 
+EPEL_TABLE  8,16, b, avx2
+EPEL_TABLE 10, 8, w, avx2
 
 EPEL_TABLE  8, 8, b, sse4
 EPEL_TABLE 10, 4, w, sse4
@@ -75,10 +78,15 @@ QPEL_TABLE  8, 8, b, sse4
 QPEL_TABLE 10, 4, w, sse4
 QPEL_TABLE 12, 4, w, sse4
 
+QPEL_TABLE  8,16, b, avx2
+QPEL_TABLE 10, 8, w, avx2
+
 %define MAX_PB_SIZE  64
 
 %define hevc_qpel_filters_sse4_14 hevc_qpel_filters_sse4_10
 
+%define hevc_qpel_filters_avx2_14 hevc_qpel_filters_avx2_10
+
 %if ARCH_X86_64
 
 %macro SIMPLE_BILOAD 4   ;width, tab, r1, r2
@@ -87,11 +95,22 @@ QPEL_TABLE 12, 4, w, sse4
 %elif %1 <= 8
 movdqa%3, [%2]  ; load data from source2
 %elif %1 <= 12
+%if avx_enabled
+mova  %3, [%2]
+%else
 movdqa%3, [%2]  ; load data from source2
 movq  %4, [%2+16]   ; load data from source2
+%endif ;avx
+%elif %1 <= 16
+%if avx_enabled
+movu  %3, [%2]
 %else
 movdqa%3, [%2]  ; load data from source2
 movdqa%4, [%2+16]   ; load data from source2
+%endif ; avx
+%else ; %1 = 32
+movu  %3, [%2]
+movu  %4, [%2+32]
 %endif
 %endmacro
 
@@ -100,71 +119,108 @@ QPEL_TABLE 12, 4, w, sse4
 movd  %4, [%3]   ; load data from source
 %elif %1 == 4 || (%2 == 8 && %1 <= 8)
 movq  %4, [%3]   ; load data from source
+%elif notcpuflag(avx)
+movu  %4, [%3]   ; load data from source
+%elif %1 <= 8 || (%2 == 8 && %1 <= 16)
+movdqu   %4, [%3]
 %else
-movdqu%4, [%3]   ; load data from source
+movu  %4, [%3]
 %endif
 %endmacro
 
-%macro SIMPLE_8LOAD 5;width, bitd, tab, r1, r2
-%if %1 == 2 || (%2 == 8 && %1 <= 4)
-movq  %4, [%3]

Re: [FFmpeg-devel] [PATCH] x86: hevc_mc: remove non necessary moves

2015-02-02 Thread Mickaël Raulet 
PL Lepere is the original author and I did some improvements on top of it.


Mickael

2015-02-02 18:11 GMT+01:00 Christophe Gisquet 
:

> Hi,
>
> 2015-02-02 17:16 GMT+01:00 Mickaël Raulet :
> >
> https://github.com/OpenHEVC/FFmpeg/commit/940300945995c20f7583394ebe6907e72829b4a
>
> No longer apply cleanly, as multiple fixes and improvements have been
> committed since then.
>
> The attached patch fixes that, and passes on a non-avx2 machine. I
> can't test it, and I'm not looking forward to do debug through a ssh
> shell.
>
> And who is the actual author? It has been committed under your name,
> but wouldn't that be P-E Lepere rather?
>
> And I guess I'll drop the previous patch for now.
>
> --
> Christophe
>
> ___
> 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] support for monochrome sequences in hevc decoder

2015-02-02 Thread Michael Niedermayer 
On Mon, Feb 02, 2015 at 05:04:04PM +0100, Mickaël Raulet wrote:
> I did it first :)

ahh, ok
applied

thanks alot

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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

Re: [FFmpeg-devel] [PATCH] x86: hevc_mc: remove non necessary moves

2015-02-02 Thread James Almer 
On 02/02/15 2:11 PM, Christophe Gisquet wrote:
> Hi,
> 
> 2015-02-02 17:16 GMT+01:00 Mickaël Raulet :
>> https://github.com/OpenHEVC/FFmpeg/commit/940300945995c20f7583394ebe6907e72829b4a
> 
> No longer apply cleanly, as multiple fixes and improvements have been
> committed since then.
> 
> The attached patch fixes that, and passes on a non-avx2 machine. I
> can't test it, and I'm not looking forward to do debug through a ssh
> shell.

Tested it. Doesn't pass with avx2.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/mpegtsenc: allow to set service_type in sdt

2015-02-02 Thread Michael Niedermayer 
On Mon, Feb 02, 2015 at 11:56:52AM +0200, dhead666 wrote:
> This adds an option to set the service type in mpegts as defined in ETSI 300 
> 468.
> 
> I added what I believe are the most useful service types as pre defined 
> values,
> the others can be sent by using their hexdecimal form directly (e.g. 
> -mpegts_service_type digital_radio, -mpegts_service_type 0x07).
> 
> I've been using this patch in order to pipe internet radio stream (originally 
> as HLS/m3u8) from ffmpeg to tvheadend,
> when the service type set right tvheadend recognize the mpegts stream as a 
> radio channel.
> 
> The patch in its original form was written by linuxstb from freenode's hts 
> channel which allowed me pushing it upstream.
> 
> This close issue 4118.
> ---
> 
> Hi Michael,
> I added a commit message as requested, thanks.

applied

thanks

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

[FFmpeg-devel] [PATCH 3/7] avfilter/avf_showspectrum: Change enums to int, which are accessed via AVOption as int

2015-02-02 Thread Michael Niedermayer 
Signed-off-by: Michael Niedermayer 
---
 libavfilter/avf_showspectrum.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavfilter/avf_showspectrum.c b/libavfilter/avf_showspectrum.c
index 24116da..49491b6 100644
--- a/libavfilter/avf_showspectrum.c
+++ b/libavfilter/avf_showspectrum.c
@@ -48,16 +48,16 @@ typedef struct {
 int nb_display_channels;
 int channel_height;
 int sliding;///< 1 if sliding mode, 0 otherwise
-enum DisplayMode mode;  ///< channel display mode
-enum ColorMode color_mode;  ///< display color scheme
-enum DisplayScale scale;
+int mode;   ///< channel display mode
+int color_mode; ///< display color scheme
+int scale;
 float saturation;   ///< color saturation multiplier
 int xpos;   ///< x position (current column)
 RDFTContext *rdft;  ///< Real Discrete Fourier Transform context
 int rdft_bits;  ///< number of bits (RDFT window size = 
1

[FFmpeg-devel] [PATCH 1/7] ffprobe: Change string_validation to int, its accessed via AVOption as int

2015-02-02 Thread Michael Niedermayer 
Signed-off-by: Michael Niedermayer 
---
 ffprobe.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ffprobe.c b/ffprobe.c
index d352bb6b..30f9cba 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -338,7 +338,7 @@ struct WriterContext {
 unsigned int nb_section_frame;  ///< number of the frame  section in case 
we are in "packets_and_frames" section
 unsigned int nb_section_packet_frame; ///< nb_section_packet or 
nb_section_frame according if is_packets_and_frames
 
-StringValidation string_validation;
+int string_validation;
 char *string_validation_replacement;
 unsigned int string_validation_utf8_flags;
 };
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH 2/7] avcodec/libfdk-aacdec: Change conceal_method to int, its accessed via AVOption as int

2015-02-02 Thread Michael Niedermayer 
Signed-off-by: Michael Niedermayer 
---
 libavcodec/libfdk-aacdec.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/libfdk-aacdec.c b/libavcodec/libfdk-aacdec.c
index a8ed104..f7fc811 100644
--- a/libavcodec/libfdk-aacdec.c
+++ b/libavcodec/libfdk-aacdec.c
@@ -44,7 +44,7 @@ typedef struct FDKAACDecContext {
 int initialized;
 uint8_t *decoder_buffer;
 uint8_t *anc_buffer;
-enum ConcealMethod conceal_method;
+int conceal_method;
 int drc_level;
 int drc_boost;
 int drc_heavy;
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH 5/7] avfilter/af_volume: Change enums to int, which are accessed via AVOption as int

2015-02-02 Thread Michael Niedermayer 
Signed-off-by: Michael Niedermayer 
---
 libavfilter/af_volume.h |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavfilter/af_volume.h b/libavfilter/af_volume.h
index 53a328e..aff7526 100644
--- a/libavfilter/af_volume.h
+++ b/libavfilter/af_volume.h
@@ -68,13 +68,13 @@ enum ReplayGainType {
 typedef struct VolumeContext {
 const AVClass *class;
 AVFloatDSPContext *fdsp;
-enum PrecisionType precision;
-enum EvalMode eval_mode;
+int precision;
+int eval_mode;
 const char *volume_expr;
 AVExpr *volume_pexpr;
 double var_values[VAR_VARS_NB];
 
-enum ReplayGainType replaygain;
+int replaygain;
 double replaygain_preamp;
 intreplaygain_noclip;
 double volume;
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH 7/7] avfilter/af_aphaser: Change type to int as its accessed as int via AVOptions

2015-02-02 Thread Michael Niedermayer 
Signed-off-by: Michael Niedermayer 
---
 libavfilter/af_aphaser.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/af_aphaser.c b/libavfilter/af_aphaser.c
index 9d8f696..708b568 100644
--- a/libavfilter/af_aphaser.c
+++ b/libavfilter/af_aphaser.c
@@ -37,7 +37,7 @@ typedef struct AudioPhaserContext {
 double decay;
 double speed;
 
-enum WaveType type;
+int type;
 
 int delay_buffer_length;
 double *delay_buffer;
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH 6/7] avfilter/af_biquads: Change width_type to int as its accessed as int via AVOptions

2015-02-02 Thread Michael Niedermayer 
Signed-off-by: Michael Niedermayer 
---
 libavfilter/af_biquads.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/af_biquads.c b/libavfilter/af_biquads.c
index 10de28d..91662c4 100644
--- a/libavfilter/af_biquads.c
+++ b/libavfilter/af_biquads.c
@@ -98,7 +98,7 @@ typedef struct {
 const AVClass *class;
 
 enum FilterType filter_type;
-enum WidthType width_type;
+int width_type;
 int poles;
 int csg;
 
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH 4/7] avfilter/avf_avectorscope: Change enums to int, which are accessed via AVOption as int

2015-02-02 Thread Michael Niedermayer 
Signed-off-by: Michael Niedermayer 
---
 libavfilter/avf_avectorscope.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/avf_avectorscope.c b/libavfilter/avf_avectorscope.c
index 1b5365a..3027de3 100644
--- a/libavfilter/avf_avectorscope.c
+++ b/libavfilter/avf_avectorscope.c
@@ -44,7 +44,7 @@ typedef struct AudioVectorScopeContext {
 AVFrame *outpicref;
 int w, h;
 int hw, hh;
-enum VectorScopeMode mode;
+int mode;
 int contrast[3];
 int fade[3];
 double zoom;
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCHv2] flac: ignore IDv3 tags if vorbis tags exist

2015-02-02 Thread Ben Boeckel 
FLAC doesn't really support IDv3 tags, so warn if they are found at all.
If vorbis tags are found, toss out the IDv3 tags. They are kept if
vorbis tags aren't found to at least have something there.

Fixes #3799.

Signed-off-by: Ben Boeckel 
---
 libavformat/flacdec.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/libavformat/flacdec.c b/libavformat/flacdec.c
index 1a8dc19..e33ab91 100644
--- a/libavformat/flacdec.c
+++ b/libavformat/flacdec.c
@@ -33,6 +33,7 @@ static int flac_read_header(AVFormatContext *s)
 int ret, metadata_last=0, metadata_type, metadata_size, found_streaminfo=0;
 uint8_t header[4];
 uint8_t *buffer=NULL;
+int has_idv3 = 0;
 AVStream *st = avformat_new_stream(s, NULL);
 if (!st)
 return AVERROR(ENOMEM);
@@ -47,6 +48,19 @@ static int flac_read_header(AVFormatContext *s)
 return 0;
 }
 
+if (av_dict_count(s->metadata)) {
+/* XXX: Is there a better way to parse this out? IDv3 parsing is done
+ * all the way out in avformat_open_input. */
+has_idv3 = 1;
+}
+
+if (has_idv3) {
+int level = AV_LOG_WARNING;
+if (s->err_recognition & AV_EF_COMPLIANT)
+level = AV_LOG_ERROR;
+av_log(s, level, "Spec-compliant FLAC do not support IDv3 tags.\n");
+}
+
 /* process metadata blocks */
 while (!avio_feof(s->pb) && !metadata_last) {
 avio_read(s->pb, header, 4);
@@ -141,6 +155,12 @@ static int flac_read_header(AVFormatContext *s)
 if (metadata_type == FLAC_METADATA_TYPE_VORBIS_COMMENT) {
 AVDictionaryEntry *chmask;
 
+if (has_idv3) {
+av_log(s, AV_LOG_VERBOSE, "FLAC found with IDv3 and vorbis 
tags; ignoring IDv3 tags.\n");
+
+av_dict_free(&s->metadata);
+}
+
 ret = ff_vorbis_comment(s, &s->metadata, buffer, 
metadata_size, 1);
 if (ret < 0) {
 av_log(s, AV_LOG_WARNING, "error parsing VorbisComment 
metadata\n");
-- 
2.2.2

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

Re: [FFmpeg-devel] [PATCHv2] flac: ignore IDv3 tags if vorbis tags exist

2015-02-02 Thread Reimar Döffinger 
On Mon, Feb 02, 2015 at 06:49:11PM -0500, Ben Boeckel wrote:
> FLAC doesn't really support IDv3 tags, so warn if they are found at all.
> If vorbis tags are found, toss out the IDv3 tags. They are kept if
> vorbis tags aren't found to at least have something there.

I'm not really convinced this makes sense.
There are thousands of programs that can edit IDv3 tags, but
comparatively few that can handle vorbis tags.
If both exist, why should the Vorbis tags be more likely to
be correct?
The warnings I sure agree with though.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2] flac: ignore IDv3 tags if vorbis tags exist

2015-02-02 Thread Michael Niedermayer 
On Mon, Feb 02, 2015 at 06:49:11PM -0500, Ben Boeckel wrote:
> FLAC doesn't really support IDv3 tags, so warn if they are found at all.
> If vorbis tags are found, toss out the IDv3 tags. They are kept if
> vorbis tags aren't found to at least have something there.
> 
> Fixes #3799.
> 
> Signed-off-by: Ben Boeckel 
> ---
>  libavformat/flacdec.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/libavformat/flacdec.c b/libavformat/flacdec.c
> index 1a8dc19..e33ab91 100644
> --- a/libavformat/flacdec.c
> +++ b/libavformat/flacdec.c
> @@ -33,6 +33,7 @@ static int flac_read_header(AVFormatContext *s)
>  int ret, metadata_last=0, metadata_type, metadata_size, 
> found_streaminfo=0;
>  uint8_t header[4];
>  uint8_t *buffer=NULL;
> +int has_idv3 = 0;
>  AVStream *st = avformat_new_stream(s, NULL);
>  if (!st)
>  return AVERROR(ENOMEM);
> @@ -47,6 +48,19 @@ static int flac_read_header(AVFormatContext *s)
>  return 0;
>  }
>  
> +if (av_dict_count(s->metadata)) {
> +/* XXX: Is there a better way to parse this out? IDv3 parsing is done
> + * all the way out in avformat_open_input. */
> +has_idv3 = 1;
> +}
> +
> +if (has_idv3) {
> +int level = AV_LOG_WARNING;
> +if (s->err_recognition & AV_EF_COMPLIANT)
> +level = AV_LOG_ERROR;

this doesnt build
libavformat/flacdec.c: In function ‘flac_read_header’:
libavformat/flacdec.c:59:14: error: ‘AVFormatContext’ has no member named 
‘err_recognition’
make: *** [libavformat/flacdec.o] Error 1

[...]
-- 
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] [PATCHv2] flac: ignore IDv3 tags if vorbis tags exist

2015-02-02 Thread Lou Logan 
On Mon, Feb 2, 2015, at 03:10 PM, Reimar Döffinger wrote:
> I'm not really convinced this makes sense.
> There are thousands of programs that can edit IDv3 tags, but
> comparatively few that can handle vorbis tags.
> If both exist, why should the Vorbis tags be more likely to
> be correct?
> The warnings I sure agree with though.

>From  http://xiph.org/flac/faq.html#general__tagging
What kinds of tags does FLAC support?

FLAC has it's own native tagging system which is identical to that of
Vorbis. They are called alternately "FLAC tags" and "Vorbis comments".
It is the only tagging system required and guaranteed to be supported by
FLAC implementations.

Out of convenience, the reference decoder knows how to skip ID3 tags so
that they don't interfere with decoding. But you should not expect any
tags beside FLAC tags to be supported in applications; some
implementations may not even be able to decode a FLAC file with ID3
tags.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2] flac: ignore IDv3 tags if vorbis tags exist

2015-02-02 Thread Reimar Döffinger 
On 03.02.2015, at 01:26, Lou Logan  wrote:
> On Mon, Feb 2, 2015, at 03:10 PM, Reimar Döffinger wrote:
>> I'm not really convinced this makes sense.
>> There are thousands of programs that can edit IDv3 tags, but
>> comparatively few that can handle vorbis tags.
>> If both exist, why should the Vorbis tags be more likely to
>> be correct?
>> The warnings I sure agree with though.
> 
> From  http://xiph.org/flac/faq.html#general__tagging
> What kinds of tags does FLAC support?
> 
> FLAC has it's own native tagging system which is identical to that of
> Vorbis. They are called alternately "FLAC tags" and "Vorbis comments".
> It is the only tagging system required and guaranteed to be supported by
> FLAC implementations.
> 
> Out of convenience, the reference decoder knows how to skip ID3 tags so
> that they don't interfere with decoding. But you should not expect any
> tags beside FLAC tags to be supported in applications; some
> implementations may not even be able to decode a FLAC file with ID3
> tags.

Yes, and?
Point one: ID3 won, it is generally supported. Insisting on something else IMHO 
is just being a pain on the user for little reason and nothing we should strive 
to emulate.
Point two: If despite that warning a ID3 tag exists, it seems sensible to 
assume it does so for a good reason and shouldn't be ignored. If it contains 
wrong information it should be removed, and that is relatively easy to do. I 
suspect removing FLAC tags isn't as easy in case things are broken the other 
way round.
I don't really care much, but ignoring an ID3 tag to me seems like the solution 
with much lower usability.
But if you feel strongly otherwise feel free to ignore my comments.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2] flac: ignore IDv3 tags if vorbis tags exist

2015-02-02 Thread Lou Logan 
On Mon, Feb 2, 2015, at 03:40 PM, Reimar Döffinger wrote:
> Yes, and?
> Point one: ID3 won, it is generally supported. Insisting on something
> else IMHO is just being a pain on the user for little reason and nothing
> we should strive to emulate.

I simply don't want to see ffmpeg output files that are broken when the
"specs" are fairly straigtforward, and I don't want to make things
harder for users. I never said I wanted the ID3 to be ignored.

I think that if non-Vorbis comments exist, and Vorbis comments are
missing, then converting them to Vorbis comment would be the best
solution. If both exist then ignore the non-Vorbis comments. I admit I
don't know how challenging that may or may not be.

Either way, I like the idea of a warning or info informing the user
whatever we do.

> Point two: If despite that warning a ID3 tag exists, it seems sensible to
> assume it does so for a good reason and shouldn't be ignored.

The "good reason" being a crappy tagger?

I wonder what the percentage is of flacs with only ID3 or whatever, only
Vorbis comment, or a mix. I have no idea.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/network: Check for av_malloc* failures in ff_tls_init()

2015-02-02 Thread Michael Niedermayer 
On Thu, Jan 22, 2015 at 04:48:57PM +0100, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/network.c |6 +-
>  libavformat/network.h |2 +-
>  libavformat/tls.c |3 ++-
>  libavformat/utils.c   |3 ++-
>  4 files changed, 10 insertions(+), 4 deletions(-)

applied


[...]
-- 
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] [PATCHv2] flac: ignore IDv3 tags if vorbis tags exist

2015-02-02 Thread Ben Boeckel 
On Tue, 03 Feb, 2015 at 00:23:55 GMT, Michael Niedermayer wrote:
> this doesnt build
> libavformat/flacdec.c: In function =E2=80=98flac_read_header=E2=80=99:
> libavformat/flacdec.c:59:14: error: =E2=80=98AVFormatContext=E2=80=99 has n=
> o member named =E2=80=98err_recognition=E2=80=99
> make: *** [libavformat/flacdec.o] Error 1

Oops, probably missed that when I was juggling branches. v3 incoming
once the build finishes to verify.

--Ben

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

Re: [FFmpeg-devel] [PATCHv2] flac: ignore IDv3 tags if vorbis tags exist

2015-02-02 Thread James Almer 
On 02/02/15 10:02 PM, Lou Logan wrote:
> On Mon, Feb 2, 2015, at 03:40 PM, Reimar Döffinger wrote:
>> Yes, and?
>> Point one: ID3 won, it is generally supported. Insisting on something
>> else IMHO is just being a pain on the user for little reason and nothing
>> we should strive to emulate.
> 
> I simply don't want to see ffmpeg output files that are broken when the
> "specs" are fairly straigtforward, and I don't want to make things
> harder for users. I never said I wanted the ID3 to be ignored.

This is about the demuxer, not muxer. We're not creating files that violate the 
spec if 
that's what you worry about.

> I think that if non-Vorbis comments exist, and Vorbis comments are
> missing, then converting them to Vorbis comment would be the best
> solution. If both exist then ignore the non-Vorbis comments. I admit I
> don't know how challenging that may or may not be.
> 
> Either way, I like the idea of a warning or info informing the user
> whatever we do.
> 
>> Point two: If despite that warning a ID3 tag exists, it seems sensible to
>> assume it does so for a good reason and shouldn't be ignored.
> 
> The "good reason" being a crappy tagger?
> 
> I wonder what the percentage is of flacs with only ID3 or whatever, only
> Vorbis comment, or a mix. I have no idea.

The whole discussion is, when demuxing, do we follow the spec and skip IDv3 
completely, 
do we skip them if spec-complaint Vorbis tags exist, or do we not skip them at 
all?
Reimar wants the latter, since if they exist it's because whatever application 
last 
wrote that file added them because it didn't care about the spec. They are 
likely to 
contain up-to-date metadata.

Personally I'd say lets not skip them if they exist unless AV_EF_COMPLIANT was 
requested, 
in which case we can either skip it or abort the entire demuxing process 
depending if 
AV_EF_EXPLODE was requested or not as well. Similar to what we do with crc 
checks.
At least one warning should be issued regardless of what the flags were set by 
the user, 
though.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCHv3] flac: ignore IDv3 tags if vorbis tags exist

2015-02-02 Thread Ben Boeckel 
FLAC doesn't really support IDv3 tags, so warn if they are found at all.
If vorbis tags are found, toss out the IDv3 tags. They are kept if
vorbis tags aren't found to at least have something there.

Fixes #3799.

Signed-off-by: Ben Boeckel 
---
 libavformat/flacdec.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/libavformat/flacdec.c b/libavformat/flacdec.c
index 1a8dc19..076332b 100644
--- a/libavformat/flacdec.c
+++ b/libavformat/flacdec.c
@@ -33,6 +33,7 @@ static int flac_read_header(AVFormatContext *s)
 int ret, metadata_last=0, metadata_type, metadata_size, found_streaminfo=0;
 uint8_t header[4];
 uint8_t *buffer=NULL;
+int has_idv3 = 0;
 AVStream *st = avformat_new_stream(s, NULL);
 if (!st)
 return AVERROR(ENOMEM);
@@ -47,6 +48,19 @@ static int flac_read_header(AVFormatContext *s)
 return 0;
 }
 
+if (av_dict_count(s->metadata)) {
+/* XXX: Is there a better way to parse this out? IDv3 parsing is done
+ * all the way out in avformat_open_input. */
+has_idv3 = 1;
+}
+
+if (has_idv3) {
+int level = AV_LOG_WARNING;
+if (s->error_recognition & AV_EF_COMPLIANT)
+level = AV_LOG_ERROR;
+av_log(s, level, "Spec-compliant FLAC do not support IDv3 tags.\n");
+}
+
 /* process metadata blocks */
 while (!avio_feof(s->pb) && !metadata_last) {
 avio_read(s->pb, header, 4);
@@ -141,6 +155,12 @@ static int flac_read_header(AVFormatContext *s)
 if (metadata_type == FLAC_METADATA_TYPE_VORBIS_COMMENT) {
 AVDictionaryEntry *chmask;
 
+if (has_idv3) {
+av_log(s, AV_LOG_VERBOSE, "FLAC found with IDv3 and vorbis 
tags; ignoring IDv3 tags.\n");
+
+av_dict_free(&s->metadata);
+}
+
 ret = ff_vorbis_comment(s, &s->metadata, buffer, 
metadata_size, 1);
 if (ret < 0) {
 av_log(s, AV_LOG_WARNING, "error parsing VorbisComment 
metadata\n");
-- 
2.2.2

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

Re: [FFmpeg-devel] [PATCHv2] flac: ignore IDv3 tags if vorbis tags exist

2015-02-02 Thread Ben Boeckel 
On Tue, 03 Feb, 2015 at 00:40:46 GMT, Reimar Döffinger wrote:
> Yes, and?
> Point one: ID3 won, it is generally supported. Insisting on something
> else IMHO is just being a pain on the user for little reason and
> nothing we should strive to emulate.
> Point two: If despite that warning a ID3 tag exists, it seems sensible
> to assume it does so for a good reason and shouldn't be ignored. If it
> contains wrong information it should be removed, and that is
> relatively easy to do. I suspect removing FLAC tags isn't as easy in
> case things are broken the other way round.
> I don't really care much, but ignoring an ID3 tag to me seems like the
> solution with much lower usability.

They're ignored only if vorbis tags exist. The problem is that they are
likely to be largely duplicated and you hit the code where the vorbis
parser will group values of tags with the save name together, so you end
up with:

Title: Foo;Foo

I could blacklist tags this doesn't make sense for (probably just
integer ones, and title), but that's hacky. Dedup is also a possibility,
but since IDv3 isn't really meant to be in flac files to begin with...
Anyways, at least one user has hit this:

https://trac.ffmpeg.org/ticket/3799

Looking at it, the encoder is claimed to be flac.exe and seems to be the
reference code (at least the options look valid), so I can only imagine
the tags were added by EAC (running the same thing here doesn't produce
IDv3 tags at least). Similar code might be needed for ogg decoding as
well.

--Ben

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

Re: [FFmpeg-devel] [PATCHv2] flac: ignore IDv3 tags if vorbis tags exist

2015-02-02 Thread Ben Boeckel 
On Tue, 03 Feb, 2015 at 01:37:05 GMT, James Almer wrote:
> On 02/02/15 10:02 PM, Lou Logan wrote:
>> I wonder what the percentage is of flacs with only ID3 or whatever, only
>> Vorbis comment, or a mix. I have no idea.

Seeing as EAC adds IDv3 to the files it creates, I'd not be surprised if
it isn't an unsubstantial amount :( . Personally, I scrub all FLAC files
of IDv3 tags without remorse with Picard, but I wonder if files from
BandCamp, Humble Bundle, OCRemix, and Game Music Bundle have both (at
least those are my typical sources for FLAC files other than
cdparanoia). Anyone have any unedited files from those sources handy?

> The whole discussion is, when demuxing, do we follow the spec and skip IDv3 
> completely, 
> do we skip them if spec-complaint Vorbis tags exist, or do we not skip them 
> at all?
> Reimar wants the latter, since if they exist it's because whatever 
> application last 
> wrote that file added them because it didn't care about the spec. They are 
> likely to 
> contain up-to-date metadata.

Only if they were manually edited afterwards. FWIW, the tag editor I
use, kid3, doesn't even *recognize* IDv3 tags in FLAC files. I don't
have experience with other tag editors (well, Picard, but I don't use it
for editing so much as just populating tags).

> Personally I'd say lets not skip them if they exist unless AV_EF_COMPLIANT 
> was requested, 
> in which case we can either skip it or abort the entire demuxing process 
> depending if 
> AV_EF_EXPLODE was requested or not as well. Similar to what we do with crc 
> checks.
> At least one warning should be issued regardless of what the flags were set 
> by the user, 
> though.

The problem is that vorbis is going to merge the tags together then.
Merging tags, in the general case, is a good thing since Picard will
write out a tag per performer, etc., not a merged list and dropping
all-but-the-last isn't good either. Since IDv3 isn't technically
supported in FLAC, I'd rather drop them than skip the vorbis tags.

--Ben

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

Re: [FFmpeg-devel] [PATCHv2] flac: ignore IDv3 tags if vorbis tags exist

2015-02-02 Thread Michael Niedermayer 
On Tue, Feb 03, 2015 at 01:36:13AM +, Ben Boeckel wrote:
> On Tue, 03 Feb, 2015 at 00:40:46 GMT, Reimar Döffinger wrote:
> > Yes, and?
> > Point one: ID3 won, it is generally supported. Insisting on something
> > else IMHO is just being a pain on the user for little reason and
> > nothing we should strive to emulate.
> > Point two: If despite that warning a ID3 tag exists, it seems sensible
> > to assume it does so for a good reason and shouldn't be ignored. If it
> > contains wrong information it should be removed, and that is
> > relatively easy to do. I suspect removing FLAC tags isn't as easy in
> > case things are broken the other way round.
> > I don't really care much, but ignoring an ID3 tag to me seems like the
> > solution with much lower usability.
> 
> They're ignored only if vorbis tags exist. The problem is that they are
> likely to be largely duplicated and you hit the code where the vorbis
> parser will group values of tags with the save name together, so you end
> up with:
> 
> Title: Foo;Foo
> 
> I could blacklist tags this doesn't make sense for (probably just
> integer ones, and title), but that's hacky. Dedup is also a possibility,
> but since IDv3 isn't really meant to be in flac files to begin with...

isnt the id3 + vorbis tag issue the same as if the user would seek
back to the begin and read metadata afterwards ?


> Anyways, at least one user has hit this:
> 
> https://trac.ffmpeg.org/ticket/3799
> 
> Looking at it, the encoder is claimed to be flac.exe and seems to be the
> reference code (at least the options look valid), so I can only imagine

your patch drops the encoder id metadata, which seems to
also have contained the encoding parameters, is this intended ?


> the tags were added by EAC (running the same thing here doesn't produce
> IDv3 tags at least). Similar code might be needed for ogg decoding as
> well.
> 
> --Ben
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.


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

[FFmpeg-devel] 0001-avcodec-ppc-idctdsp.c-POWER-LE-support-idct_add_alti

2015-02-02 Thread rongyan 
Hi,
 
We present a patch to fix MPEG2 decoding bugs for POWER8 little endian. The 
function idct_add_altivec() in file /libavcodec/ppc/idctdsp.c is fixed.
The fate test  result can be found on website by searching  "ibmcrl", also 
attached in the below to facilitate the review. 

 

 Thanks.

 Rong Yan

0001-avcodec-ppc-idctdsp.c-POWER-LE-support-idct_add_alti.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2] flac: ignore IDv3 tags if vorbis tags exist

2015-02-02 Thread Ben Boeckel 
On Tue, 03 Feb, 2015 at 04:13:49 GMT, Michael Niedermayer wrote:
> isnt the id3 + vorbis tag issue the same as if the user would seek
> back to the begin and read metadata afterwards ?

Metadata isn't in-stream for flac (AFAICT, it is only read with the
header; I certainly can't get the code to re-execute with just a simple
seek in mpv at least). I can try and set up an mpd flac stream, but I
imagine it's just going to use vorbis comments if anything (and I don't
see ffmpeg code to handle such updates). It is in-stream for vorbis, but
vorbis will junk the current metadata when an update packet comes in
anyways and ogg just doesn't support IDv3 at all (assuming there's some
actual reasoning behind this Wikipedia quote from the ID3 page):

Other container-based formats use their own tagging formats. An
example of this is Ogg, which uses Vorbis comments. Adding ID3 tags
to these would break the container structure.

The only other place I see ff_vorbis_comment called is from Matroska,
but that reads it and looks for a specific tag then ignores the rest.

> your patch drops the encoder id metadata, which seems to
> also have contained the encoding parameters, is this intended ?

Currently, it ignores the whole IDv3 metadata block if vorbis tags are
found. I suppose it could be stored off then any field which is in IDv3,
but not in the vorbis one be added in (only if !compliant?). I'll try
that tomorrow (or Wednesday if I don't get time).

--Ben

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

Re: [FFmpeg-devel] 0001-avcodec-ppc-idctdsp.c-POWER-LE-support-idct_add_alti

2015-02-02 Thread Michael Niedermayer 
On Tue, Feb 03, 2015 at 12:33:08PM +0800, rongyan wrote:
> Hi,
>  
> We present a patch to fix MPEG2 decoding bugs for POWER8 little endian. The 
> function idct_add_altivec() in file /libavcodec/ppc/idctdsp.c is fixed.
> The fate test  result can be found on website by searching  "ibmcrl", also 
> attached in the below to facilitate the review. 
> 
>  
> 
>  Thanks.
> 
>  Rong Yan


>  idctdsp.c |   16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> f3bcbf63194c7c2efe91e43bfc00e614e814ef2b  
> 0001-avcodec-ppc-idctdsp.c-POWER-LE-support-idct_add_alti.patch
> From 88fc903a2f8475f98a531f4eb38ba8f7e8de4b80 Mon Sep 17 00:00:00 2001
> From: Rong Yan 
> Date: Tue, 3 Feb 2015 03:04:33 +
> Subject: [PATCH] avcodec/ppc/idctdsp.c: POWER LE support idct_add_altivec()
>  add GET_TMP2() macro

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