Re: [FFmpeg-devel] [PATCH] lavfi/avf_showspectrum: use automatic framing.

2014-08-04 Thread Paul B Mahol
On Sun, Aug 3, 2014 at 7:51 PM, Nicolas George geo...@nsup.org wrote:

 The framework can ensure that each input frame has exactly
 the correct number of samples, except the last one.

 Signed-off-by: Nicolas George geo...@nsup.org
 ---
  libavfilter/avf_showspectrum.c | 48
 +++---
  1 file changed, 17 insertions(+), 31 deletions(-)

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


[FFmpeg-devel] [PATCH] New p2p mode for showwaves filter

2014-08-04 Thread mrskman
New patch attached.

Thank you.

---
 doc/filters.texi|3 +++
 libavfilter/avf_showwaves.c |   33 -
 2 files changed, 35 insertions(+), 1 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index a7919a3..145acbf 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10698,6 +10698,9 @@ Draw a point for each sample.
 
 @item line
 Draw a vertical line for each sample.
+
+@item p2p
+Draw a point for each sample and a line between them.
 @end table
 
 Default value is @code{point}.
diff --git a/libavfilter/avf_showwaves.c b/libavfilter/avf_showwaves.c
index 0b45bd0..e6158b2 100644
--- a/libavfilter/avf_showwaves.c
+++ b/libavfilter/avf_showwaves.c
@@ -35,6 +35,7 @@
 enum ShowWavesMode {
 MODE_POINT,
 MODE_LINE,
+MODE_P2P,
 MODE_NB,
 };
 
@@ -43,6 +44,7 @@ typedef struct {
 int w, h;
 AVRational rate;
 int buf_idx;
+int *buf_idy;/* y coordinate of previous sample for each channel */
 AVFrame *outpicref;
 int req_fullfilled;
 int n;
@@ -59,6 +61,7 @@ static const AVOption showwaves_options[] = {
 { mode, select display mode, OFFSET(mode), AV_OPT_TYPE_INT, 
{.i64=MODE_POINT}, 0, MODE_NB-1, FLAGS, mode},
 { point, draw a point for each sample, 0, AV_OPT_TYPE_CONST, 
{.i64=MODE_POINT}, .flags=FLAGS, .unit=mode},
 { line,  draw a line for each sample,  0, AV_OPT_TYPE_CONST, 
{.i64=MODE_LINE},  .flags=FLAGS, .unit=mode},
+{ p2p, draw a line between samples, 0, AV_OPT_TYPE_CONST, 
{.i64=MODE_P2P}, .flags=FLAGS, .unit=mode},
 { n,set how many samples to show in the same point, OFFSET(n), 
AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, FLAGS },
 { rate, set video rate, OFFSET(rate), AV_OPT_TYPE_VIDEO_RATE, {.str = 
25}, 0, 0, FLAGS },
 { r,set video rate, OFFSET(rate), AV_OPT_TYPE_VIDEO_RATE, {.str = 
25}, 0, 0, FLAGS },
@@ -72,6 +75,8 @@ static av_cold void uninit(AVFilterContext *ctx)
 ShowWavesContext *showwaves = ctx-priv;
 
 av_frame_free(showwaves-outpicref);
+if (showwaves-buf_idy)
+av_freep(showwaves-buf_idy);
 }
 
 static int query_formats(AVFilterContext *ctx)
@@ -110,14 +115,22 @@ static int query_formats(AVFilterContext *ctx)
 
 static int config_output(AVFilterLink *outlink)
 {
+int i;
 AVFilterContext *ctx = outlink-src;
 AVFilterLink *inlink = ctx-inputs[0];
 ShowWavesContext *showwaves = ctx-priv;
+int nb_channels = inlink-channels;
 
 if (!showwaves-n)
 showwaves-n = FFMAX(1, ((double)inlink-sample_rate / (showwaves-w * 
av_q2d(showwaves-rate))) + 0.5);
 
 showwaves-buf_idx = 0;
+if (!(showwaves-buf_idy = av_malloc_array(nb_channels, 1))) {
+av_log(NULL, AV_LOG_ERROR, Could not allocate showwaves buffer\n);
+return AVERROR(ENOMEM);
+}
+for (i = 0; i = nb_channels; i++)
+showwaves-buf_idy[i] = 0;
 outlink-w = showwaves-w;
 outlink-h = showwaves-h;
 outlink-sample_aspect_ratio = (AVRational){1,1};
@@ -132,13 +145,18 @@ static int config_output(AVFilterLink *outlink)
 
 inline static int push_frame(AVFilterLink *outlink)
 {
+AVFilterContext *ctx = outlink-src;
+AVFilterLink *inlink = ctx-inputs[0];
 ShowWavesContext *showwaves = outlink-src-priv;
-int ret;
+int nb_channels = inlink-channels;
+int ret, i;
 
 if ((ret = ff_filter_frame(outlink, showwaves-outpicref)) = 0)
 showwaves-req_fullfilled = 1;
 showwaves-outpicref = NULL;
 showwaves-buf_idx = 0;
+for (i = 0; i = nb_channels; i++)
+showwaves-buf_idy[i] = 0;
 return ret;
 }
 
@@ -207,7 +225,20 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*insamples)
 *(outpicref-data[0] + showwaves-buf_idx + k * linesize) 
+= x;
 break;
 }
+case MODE_P2P:
+if (h = 0  h  outlink-h) {
+*(outpicref-data[0] + showwaves-buf_idx + h * linesize) 
+= x;
+if (showwaves-buf_idy[j]  h != showwaves-buf_idy[j]) {
+int start = showwaves-buf_idy[j], end = av_clip(h, 0, 
outlink-h-1);
+if (start  end) FFSWAP(int16_t, start, end);
+for (k = start + 1; k  end; k++)
+*(outpicref-data[0] + showwaves-buf_idx + k * 
linesize) += x;
+}
+}
+break;
 }
+/* store current y coordinate for this channel */
+showwaves-buf_idy[j] = h;
 }
 
 showwaves-sample_count_mod++;
-- 
1.7.1

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


Re: [FFmpeg-devel] [PATCH] New p2p mode for showwaves filter

2014-08-04 Thread Paul B Mahol
On Mon, Aug 4, 2014 at 9:24 AM, mrskman mrsk...@gmail.com wrote:

 New patch attached.

 Thank you.

 ---
  doc/filters.texi|3 +++
  libavfilter/avf_showwaves.c |   33 -
  2 files changed, 35 insertions(+), 1 deletions(-)

 diff --git a/doc/filters.texi b/doc/filters.texi
 index a7919a3..145acbf 100644
 --- a/doc/filters.texi
 +++ b/doc/filters.texi
 @@ -10698,6 +10698,9 @@ Draw a point for each sample.

  @item line
  Draw a vertical line for each sample.
 +
 +@item p2p
 +Draw a point for each sample and a line between them.
  @end table

  Default value is @code{point}.
 diff --git a/libavfilter/avf_showwaves.c b/libavfilter/avf_showwaves.c
 index 0b45bd0..e6158b2 100644
 --- a/libavfilter/avf_showwaves.c
 +++ b/libavfilter/avf_showwaves.c
 @@ -35,6 +35,7 @@
  enum ShowWavesMode {
  MODE_POINT,
  MODE_LINE,
 +MODE_P2P,
  MODE_NB,
  };

 @@ -43,6 +44,7 @@ typedef struct {
  int w, h;
  AVRational rate;
  int buf_idx;
 +int *buf_idy;/* y coordinate of previous sample for each channel
 */
  AVFrame *outpicref;
  int req_fullfilled;
  int n;
 @@ -59,6 +61,7 @@ static const AVOption showwaves_options[] = {
  { mode, select display mode, OFFSET(mode), AV_OPT_TYPE_INT,
 {.i64=MODE_POINT}, 0, MODE_NB-1, FLAGS, mode},
  { point, draw a point for each sample, 0, AV_OPT_TYPE_CONST,
 {.i64=MODE_POINT}, .flags=FLAGS, .unit=mode},
  { line,  draw a line for each sample,  0, AV_OPT_TYPE_CONST,
 {.i64=MODE_LINE},  .flags=FLAGS, .unit=mode},
 +{ p2p, draw a line between samples, 0, AV_OPT_TYPE_CONST,
 {.i64=MODE_P2P}, .flags=FLAGS, .unit=mode},
  { n,set how many samples to show in the same point,
 OFFSET(n), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, FLAGS },
  { rate, set video rate, OFFSET(rate), AV_OPT_TYPE_VIDEO_RATE,
 {.str = 25}, 0, 0, FLAGS },
  { r,set video rate, OFFSET(rate), AV_OPT_TYPE_VIDEO_RATE,
 {.str = 25}, 0, 0, FLAGS },
 @@ -72,6 +75,8 @@ static av_cold void uninit(AVFilterContext *ctx)
  ShowWavesContext *showwaves = ctx-priv;

  av_frame_free(showwaves-outpicref);
 +if (showwaves-buf_idy)
 +av_freep(showwaves-buf_idy);
  }

  static int query_formats(AVFilterContext *ctx)
 @@ -110,14 +115,22 @@ static int query_formats(AVFilterContext *ctx)

  static int config_output(AVFilterLink *outlink)
  {
 +int i;

Could you put this one down where nb_channels is.


  AVFilterContext *ctx = outlink-src;
  AVFilterLink *inlink = ctx-inputs[0];
  ShowWavesContext *showwaves = ctx-priv;
 +int nb_channels = inlink-channels;

  if (!showwaves-n)
  showwaves-n = FFMAX(1, ((double)inlink-sample_rate /
 (showwaves-w * av_q2d(showwaves-rate))) + 0.5);

  showwaves-buf_idx = 0;
 +if (!(showwaves-buf_idy = av_malloc_array(nb_channels, 1))) {


Use calloc, or av_mallocz_array.


 +av_log(NULL, AV_LOG_ERROR, Could not allocate showwaves
 buffer\n);


This can use ctx : av_log(ctx,..


  +return AVERROR(ENOMEM);
 +}
 +for (i = 0; i = nb_channels; i++)
 +showwaves-buf_idy[i] = 0;


Not needed to manually do this if you use one of above mentioned functions.


   outlink-w = showwaves-w;
  outlink-h = showwaves-h;
  outlink-sample_aspect_ratio = (AVRational){1,1};
 @@ -132,13 +145,18 @@ static int config_output(AVFilterLink *outlink)

  inline static int push_frame(AVFilterLink *outlink)
  {
 +AVFilterContext *ctx = outlink-src;
 +AVFilterLink *inlink = ctx-inputs[0];
  ShowWavesContext *showwaves = outlink-src-priv;
 -int ret;
 +int nb_channels = inlink-channels;
 +int ret, i;

  if ((ret = ff_filter_frame(outlink, showwaves-outpicref)) = 0)
  showwaves-req_fullfilled = 1;
  showwaves-outpicref = NULL;
  showwaves-buf_idx = 0;
 +for (i = 0; i = nb_channels; i++)
 +showwaves-buf_idy[i] = 0;
  return ret;
  }

 @@ -207,7 +225,20 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
 *insamples)
  *(outpicref-data[0] + showwaves-buf_idx + k *
 linesize) += x;
  break;
  }
 +case MODE_P2P:
 +if (h = 0  h  outlink-h) {
 +*(outpicref-data[0] + showwaves-buf_idx + h *
 linesize) += x;
 +if (showwaves-buf_idy[j]  h !=
 showwaves-buf_idy[j]) {
 +int start = showwaves-buf_idy[j], end =
 av_clip(h, 0, outlink-h-1);
 +if (start  end) FFSWAP(int16_t, start, end);

FFSWAP.. should be on its own line

+for (k = start + 1; k  end; k++)
 +*(outpicref-data[0] + showwaves-buf_idx + k
 * linesize) += x;
 +}
 +}
 +break;
  }
 +/* store current y coordinate for this channel */
 +showwaves-buf_idy[j] = h;
  }

  

Re: [FFmpeg-devel] [PATCH] New p2p mode for showwaves filter

2014-08-04 Thread Paul B Mahol
On Mon, Aug 4, 2014 at 9:34 AM, Paul B Mahol one...@gmail.com wrote:




 On Mon, Aug 4, 2014 at 9:24 AM, mrskman mrsk...@gmail.com wrote:

 New patch attached.

 Thank you.

 ---
  doc/filters.texi|3 +++
  libavfilter/avf_showwaves.c |   33 -
  2 files changed, 35 insertions(+), 1 deletions(-)

 diff --git a/doc/filters.texi b/doc/filters.texi
 index a7919a3..145acbf 100644
 --- a/doc/filters.texi
 +++ b/doc/filters.texi
 @@ -10698,6 +10698,9 @@ Draw a point for each sample.

  @item line
  Draw a vertical line for each sample.
 +
 +@item p2p
 +Draw a point for each sample and a line between them.
  @end table

  Default value is @code{point}.
 diff --git a/libavfilter/avf_showwaves.c b/libavfilter/avf_showwaves.c
 index 0b45bd0..e6158b2 100644
 --- a/libavfilter/avf_showwaves.c
 +++ b/libavfilter/avf_showwaves.c
 @@ -35,6 +35,7 @@
  enum ShowWavesMode {
  MODE_POINT,
  MODE_LINE,
 +MODE_P2P,
  MODE_NB,
  };

 @@ -43,6 +44,7 @@ typedef struct {
  int w, h;
  AVRational rate;
  int buf_idx;
 +int *buf_idy;/* y coordinate of previous sample for each channel
 */
  AVFrame *outpicref;
  int req_fullfilled;
  int n;
 @@ -59,6 +61,7 @@ static const AVOption showwaves_options[] = {
  { mode, select display mode, OFFSET(mode), AV_OPT_TYPE_INT,
 {.i64=MODE_POINT}, 0, MODE_NB-1, FLAGS, mode},
  { point, draw a point for each sample, 0, AV_OPT_TYPE_CONST,
 {.i64=MODE_POINT}, .flags=FLAGS, .unit=mode},
  { line,  draw a line for each sample,  0, AV_OPT_TYPE_CONST,
 {.i64=MODE_LINE},  .flags=FLAGS, .unit=mode},
 +{ p2p, draw a line between samples, 0, AV_OPT_TYPE_CONST,
 {.i64=MODE_P2P}, .flags=FLAGS, .unit=mode},
  { n,set how many samples to show in the same point,
 OFFSET(n), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, FLAGS },
  { rate, set video rate, OFFSET(rate), AV_OPT_TYPE_VIDEO_RATE,
 {.str = 25}, 0, 0, FLAGS },
  { r,set video rate, OFFSET(rate), AV_OPT_TYPE_VIDEO_RATE,
 {.str = 25}, 0, 0, FLAGS },
 @@ -72,6 +75,8 @@ static av_cold void uninit(AVFilterContext *ctx)
  ShowWavesContext *showwaves = ctx-priv;

  av_frame_free(showwaves-outpicref);
 +if (showwaves-buf_idy)
 +av_freep(showwaves-buf_idy);
  }

  static int query_formats(AVFilterContext *ctx)
 @@ -110,14 +115,22 @@ static int query_formats(AVFilterContext *ctx)

  static int config_output(AVFilterLink *outlink)
  {
 +int i;

 Could you put this one down where nb_channels is.


   AVFilterContext *ctx = outlink-src;
  AVFilterLink *inlink = ctx-inputs[0];
  ShowWavesContext *showwaves = ctx-priv;
 +int nb_channels = inlink-channels;

  if (!showwaves-n)
  showwaves-n = FFMAX(1, ((double)inlink-sample_rate /
 (showwaves-w * av_q2d(showwaves-rate))) + 0.5);

  showwaves-buf_idx = 0;
 +if (!(showwaves-buf_idy = av_malloc_array(nb_channels, 1))) {


 Use calloc, or av_mallocz_array.


by calloc i mean av_calloc




 +av_log(NULL, AV_LOG_ERROR, Could not allocate showwaves
 buffer\n);


 This can use ctx : av_log(ctx,..


  +return AVERROR(ENOMEM);
 +}
 +for (i = 0; i = nb_channels; i++)
 +showwaves-buf_idy[i] = 0;


 Not needed to manually do this if you use one of above mentioned functions.


   outlink-w = showwaves-w;
  outlink-h = showwaves-h;
  outlink-sample_aspect_ratio = (AVRational){1,1};
 @@ -132,13 +145,18 @@ static int config_output(AVFilterLink *outlink)

  inline static int push_frame(AVFilterLink *outlink)
  {
 +AVFilterContext *ctx = outlink-src;
 +AVFilterLink *inlink = ctx-inputs[0];
  ShowWavesContext *showwaves = outlink-src-priv;
 -int ret;
 +int nb_channels = inlink-channels;
 +int ret, i;

  if ((ret = ff_filter_frame(outlink, showwaves-outpicref)) = 0)
  showwaves-req_fullfilled = 1;
  showwaves-outpicref = NULL;
  showwaves-buf_idx = 0;
 +for (i = 0; i = nb_channels; i++)
 +showwaves-buf_idy[i] = 0;
  return ret;
  }

 @@ -207,7 +225,20 @@ static int filter_frame(AVFilterLink *inlink,
 AVFrame *insamples)
  *(outpicref-data[0] + showwaves-buf_idx + k *
 linesize) += x;
  break;
  }
 +case MODE_P2P:
 +if (h = 0  h  outlink-h) {
 +*(outpicref-data[0] + showwaves-buf_idx + h *
 linesize) += x;
 +if (showwaves-buf_idy[j]  h !=
 showwaves-buf_idy[j]) {
 +int start = showwaves-buf_idy[j], end =
 av_clip(h, 0, outlink-h-1);
 +if (start  end) FFSWAP(int16_t, start, end);

 FFSWAP.. should be on its own line

 +for (k = start + 1; k  end; k++)
 +*(outpicref-data[0] + showwaves-buf_idx +
 k * linesize) += x;
 +}
 +}
 +break;
  }
 +/* store current y 

Re: [FFmpeg-devel] [PATCH 1/3] x86/hevc_mc: remove an unnecessary pxor

2014-08-04 Thread Mickaël Raulet
Patch ok.

Mickael

Le lundi 4 août 2014, James Almer jamr...@gmail.com a écrit :

 Signed-off-by: James Almer jamr...@gmail.com javascript:;
 ---
  libavcodec/x86/hevc_mc.asm | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

 diff --git a/libavcodec/x86/hevc_mc.asm b/libavcodec/x86/hevc_mc.asm
 index fc78062..a16b0ab 100644
 --- a/libavcodec/x86/hevc_mc.asm
 +++ b/libavcodec/x86/hevc_mc.asm
 @@ -551,8 +551,7 @@ cglobal hevc_put_hevc_pel_pixels%1_%2, 5, 5, 3, dst,
 dststride, src, srcstride,h
  LOOP_END dst, dststride, src, srcstride
  RET

 -cglobal hevc_put_hevc_uni_pel_pixels%1_%2, 5, 5, 3, dst, dststride, src,
 srcstride,height
 -pxor  m2, m2
 +cglobal hevc_put_hevc_uni_pel_pixels%1_%2, 5, 5, 2, dst, dststride, src,
 srcstride,height
  .loop
  SIMPLE_LOAD   %1, %2, srcq, m0
  PEL_%2STORE%1   dstq, m0, m1
 --
 1.8.5.5

 ___
 ffmpeg-devel mailing list
 ffmpeg-devel@ffmpeg.org javascript:;
 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 0/4] Exploit compile-time constant

2014-08-04 Thread Christophe Gisquet
Hi,

2014-08-02 14:48 GMT+02:00 Michael Niedermayer michae...@gmx.at:
 seems to fail with
 libavcodec/x86/hevc_mc.asm:1258: error: (add:2) cannot reference symbol 
 `MAX_PB_SIZE' in preprocessor

I forgot the initial patch when generating the patchset, that you can
find here. I expect no changes for the others, so I didn't bother
resending them/starting another thread.

-- 
Christophe
From 8b13e4350c6662ca4bd2bcab443a1e62f7751b30 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet christophe.gisq...@gmail.com
Date: Mon, 28 Jul 2014 08:55:26 +0200
Subject: [PATCH 1/5] x86: hevc_mc: assume 2nd source stride is 64

---
 libavcodec/x86/hevc_mc.asm | 36 +---
 1 file changed, 21 insertions(+), 15 deletions(-)

diff --git a/libavcodec/x86/hevc_mc.asm b/libavcodec/x86/hevc_mc.asm
index fc78062..51017cf 100644
--- a/libavcodec/x86/hevc_mc.asm
+++ b/libavcodec/x86/hevc_mc.asm
@@ -75,6 +75,8 @@ QPEL_TABLE  8, 8, b, sse4
 QPEL_TABLE 10, 4, w, sse4
 QPEL_TABLE 12, 4, w, sse4
 
+%define MAX_PB_SIZE  64
+
 %define hevc_qpel_filters_sse4_14 hevc_qpel_filters_sse4_10
 
 %if ARCH_X86_64
@@ -377,7 +379,11 @@ QPEL_TABLE 12, 4, w, sse4
 %endmacro
 
 %macro LOOP_END 4
+%ifnum %2
+add  %1q, 2*%2   ; dst += dststride
+%else
 lea  %1q, [%1q+2*%2q]; dst += dststride
+%endif
 add  %3q, %4q; src += srcstride
 dec  heightd ; cmp height
 jnz   .loop  ; height loop
@@ -548,7 +554,7 @@ cglobal hevc_put_hevc_pel_pixels%1_%2, 5, 5, 3, dst, dststride, src, srcstride,h
 SIMPLE_LOAD   %1, %2, srcq, m0
 MC_PIXEL_COMPUTE  %1, %2
 PEL_10STORE%1 dstq, m0, m1
-LOOP_END dst, dststride, src, srcstride
+LOOP_END dst, MAX_PB_SIZE, src, srcstride
 RET
 
 cglobal hevc_put_hevc_uni_pel_pixels%1_%2, 5, 5, 3, dst, dststride, src, srcstride,height
@@ -573,7 +579,7 @@ cglobal hevc_put_hevc_bi_pel_pixels%1_%2, 7, 7, 6, dst, dststride, src, srcstrid
 PEL_%2STORE%1   dstq, m0, m1
 add dstq, dststrideq ; dst += dststride
 add srcq, srcstrideq ; src += srcstride
-leasrc2q, [src2q+2*src2strideq]  ; src += srcstride
+addsrc2q, 2*MAX_PB_SIZE  ; src += srcstride
 dec  heightd ; cmp height
 jnz   .loop  ; height loop
 RET
@@ -597,7 +603,7 @@ cglobal hevc_put_hevc_epel_h%1_%2, 6, 7, 6, dst, dststride, src, srcstride, heig
 EPEL_LOAD %2, srcq-%%stride, %%stride, %1
 EPEL_COMPUTE  %2, %1, m4, m5
 PEL_10STORE%1  dstq, m0, m1
-LOOP_END dst, dststride, src, srcstride
+LOOP_END dst, MAX_PB_SIZE, src, srcstride
 RET
 
 cglobal hevc_put_hevc_uni_epel_h%1_%2, 6, 7, 7, dst, dststride, src, srcstride, height, mx, rfilter
@@ -626,7 +632,7 @@ cglobal hevc_put_hevc_bi_epel_h%1_%2, 8, 9, 7, dst, dststride, src, srcstride, s
 PEL_%2STORE%1   dstq, m0, m1
 add dstq, dststrideq ; dst += dststride
 add srcq, srcstrideq ; src += srcstride
-leasrc2q, [src2q+2*src2strideq]  ; src += srcstride
+addsrc2q, 2*MAX_PB_SIZE  ; src += srcstride
 dec  heightd ; cmp height
 jnz   .loop  ; height loop
 RET
@@ -646,7 +652,7 @@ cglobal hevc_put_hevc_epel_v%1_%2, 7, 8, 6, dst, dststride, src, srcstride, heig
 EPEL_LOAD %2, srcq, srcstride, %1
 EPEL_COMPUTE  %2, %1, m4, m5
 PEL_10STORE%1 dstq, m0, m1
-LOOP_END  dst, dststride, src, srcstride
+LOOP_END  dst, MAX_PB_SIZE, src, srcstride
 RET
 
 cglobal hevc_put_hevc_uni_epel_v%1_%2, 7, 8, 7, dst, dststride, src, srcstride, height, r3src, my, rfilter
@@ -679,7 +685,7 @@ cglobal hevc_put_hevc_bi_epel_v%1_%2, 9, 10, 7, dst, dststride, src, srcstride,
 PEL_%2STORE%1   dstq, m0, m1
 add dstq, dststrideq ; dst += dststride
 add srcq, srcstrideq ; src += srcstride
-leasrc2q, [src2q+2*src2strideq]  ; src += srcstride
+addsrc2q, 2*MAX_PB_SIZE  ; src += srcstride
 dec  heightd ; cmp height
 jnz   .loop  ; height loop
 RET
@@ -724,7 +730,7 @@ cglobal hevc_put_hevc_epel_hv%1_%2, 7, 9, 12 , dst, dststride, src, srcstride, h
 movdqam4, m5
 movdqam5, m6
 movdqam6, m7
-LOOP_END dst, dststride, src, srcstride
+LOOP_END dst, MAX_PB_SIZE, src, srcstride
 RET
 
 cglobal hevc_put_hevc_uni_epel_hv%1_%2, 7, 9, 12 , dst, dststride, src, srcstride, height, mx, my, r3src, rfilter
@@ -801,7 +807,7 @@ cglobal hevc_put_hevc_bi_epel_hv%1_%2, 

[FFmpeg-devel] [PATCH] New p2p mode for showwaves filter

2014-08-04 Thread mrskman
New patch attached.

Thank you.

---
 doc/filters.texi|3 +++
 libavfilter/avf_showwaves.c |   30 +-
 2 files changed, 32 insertions(+), 1 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index a7919a3..145acbf 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10698,6 +10698,9 @@ Draw a point for each sample.
 
 @item line
 Draw a vertical line for each sample.
+
+@item p2p
+Draw a point for each sample and a line between them.
 @end table
 
 Default value is @code{point}.
diff --git a/libavfilter/avf_showwaves.c b/libavfilter/avf_showwaves.c
index 0b45bd0..e025663 100644
--- a/libavfilter/avf_showwaves.c
+++ b/libavfilter/avf_showwaves.c
@@ -35,6 +35,7 @@
 enum ShowWavesMode {
 MODE_POINT,
 MODE_LINE,
+MODE_P2P,
 MODE_NB,
 };
 
@@ -43,6 +44,7 @@ typedef struct {
 int w, h;
 AVRational rate;
 int buf_idx;
+int16_t *buf_idy;/* y coordinate of previous sample for each channel */
 AVFrame *outpicref;
 int req_fullfilled;
 int n;
@@ -59,6 +61,7 @@ static const AVOption showwaves_options[] = {
 { mode, select display mode, OFFSET(mode), AV_OPT_TYPE_INT, 
{.i64=MODE_POINT}, 0, MODE_NB-1, FLAGS, mode},
 { point, draw a point for each sample, 0, AV_OPT_TYPE_CONST, 
{.i64=MODE_POINT}, .flags=FLAGS, .unit=mode},
 { line,  draw a line for each sample,  0, AV_OPT_TYPE_CONST, 
{.i64=MODE_LINE},  .flags=FLAGS, .unit=mode},
+{ p2p, draw a line between samples, 0, AV_OPT_TYPE_CONST, 
{.i64=MODE_P2P}, .flags=FLAGS, .unit=mode},
 { n,set how many samples to show in the same point, OFFSET(n), 
AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, FLAGS },
 { rate, set video rate, OFFSET(rate), AV_OPT_TYPE_VIDEO_RATE, {.str = 
25}, 0, 0, FLAGS },
 { r,set video rate, OFFSET(rate), AV_OPT_TYPE_VIDEO_RATE, {.str = 
25}, 0, 0, FLAGS },
@@ -72,6 +75,7 @@ static av_cold void uninit(AVFilterContext *ctx)
 ShowWavesContext *showwaves = ctx-priv;
 
 av_frame_free(showwaves-outpicref);
+av_freep(showwaves-buf_idy);
 }
 
 static int query_formats(AVFilterContext *ctx)
@@ -113,11 +117,16 @@ static int config_output(AVFilterLink *outlink)
 AVFilterContext *ctx = outlink-src;
 AVFilterLink *inlink = ctx-inputs[0];
 ShowWavesContext *showwaves = ctx-priv;
+int nb_channels = inlink-channels;
 
 if (!showwaves-n)
 showwaves-n = FFMAX(1, ((double)inlink-sample_rate / (showwaves-w * 
av_q2d(showwaves-rate))) + 0.5);
 
 showwaves-buf_idx = 0;
+if (!(showwaves-buf_idy = av_mallocz_array(nb_channels, 
sizeof(*showwaves-buf_idy {
+av_log(ctx, AV_LOG_ERROR, Could not allocate showwaves buffer\n);
+return AVERROR(ENOMEM);
+}
 outlink-w = showwaves-w;
 outlink-h = showwaves-h;
 outlink-sample_aspect_ratio = (AVRational){1,1};
@@ -132,13 +141,18 @@ static int config_output(AVFilterLink *outlink)
 
 inline static int push_frame(AVFilterLink *outlink)
 {
+AVFilterContext *ctx = outlink-src;
+AVFilterLink *inlink = ctx-inputs[0];
 ShowWavesContext *showwaves = outlink-src-priv;
-int ret;
+int nb_channels = inlink-channels;
+int ret, i;
 
 if ((ret = ff_filter_frame(outlink, showwaves-outpicref)) = 0)
 showwaves-req_fullfilled = 1;
 showwaves-outpicref = NULL;
 showwaves-buf_idx = 0;
+for (i = 0; i = nb_channels; i++)
+showwaves-buf_idy[i] = 0;
 return ret;
 }
 
@@ -207,7 +221,21 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*insamples)
 *(outpicref-data[0] + showwaves-buf_idx + k * linesize) 
+= x;
 break;
 }
+case MODE_P2P:
+if (h = 0  h  outlink-h) {
+*(outpicref-data[0] + showwaves-buf_idx + h * linesize) 
+= x;
+if (showwaves-buf_idy[j]  h != showwaves-buf_idy[j]) {
+int start = showwaves-buf_idy[j], end = av_clip(h, 0, 
outlink-h-1);
+if (start  end)
+FFSWAP(int16_t, start, end);
+for (k = start + 1; k  end; k++)
+*(outpicref-data[0] + showwaves-buf_idx + k * 
linesize) += x;
+}
+}
+break;
 }
+/* store current y coordinate for this channel */
+showwaves-buf_idy[j] = h;
 }
 
 showwaves-sample_count_mod++;
-- 
1.7.1

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


[FFmpeg-devel] [PATCH] x86: hevc_deblock: remove unnecessary masking

2014-08-04 Thread Christophe Gisquet
Hi,

the attached patch is a low-hanging fruit.

I think the code using the computed values could be improved (eg you
probably need half the GPRs to store results and you can probably
shuffle more efficiently data), but this requires more effort.

I'm mostly submitting it because it still applies, and I can't really
spend more time on it.

-- 
Christophe
From 57819727586c186bfea733a8f06eead22ac6a1f2 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet christophe.gisq...@gmail.com
Date: Wed, 23 Jul 2014 23:21:20 +0200
Subject: [PATCH 08/13] x86: hevc_deblock: remove unnecessary masking

The unpacks/shuffles later on makes it unnecessary.

Before:
1508 decicycles in h, 2096759 runs, 393 skips
2512 decicycles in v, 2095422 runs, 1730 skips

After:
1477 decicycles in h, 2096745 runs, 407 skips
2484 decicycles in v, 2095297 runs, 1855 skips
---
 libavcodec/x86/hevc_deblock.asm | 4 
 1 file changed, 4 deletions(-)

diff --git a/libavcodec/x86/hevc_deblock.asm b/libavcodec/x86/hevc_deblock.asm
index 89c0f9b..7fa0803 100644
--- a/libavcodec/x86/hevc_deblock.asm
+++ b/libavcodec/x86/hevc_deblock.asm
@@ -355,19 +355,15 @@ ALIGN 16
 psrldm8, 16
 paddwm8, m10
 movdr7d, m8
-and  r7, 0x; 1dp0 + 1dp3
 pshufd   m8, m8, 0x4E
 movdr8d, m8
-and  r8, 0x; 0dp0 + 0dp3
 
 pshufd   m8, m11, 0x31
 psrldm8, 16
 paddwm8, m11
 movdr9d, m8
-and  r9, 0x; 1dq0 + 1dq3
 pshufd   m8, m8, 0x4E
 movd   r10d, m8
-and r10, 0x; 0dq0 + 0dq3
 ; end calc for weak filter
 
 ; filtering mask
-- 
1.9.2.msysgit.0

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


Re: [FFmpeg-devel] [PATCH 1/3] x86/hevc_mc: remove an unnecessary pxor

2014-08-04 Thread Michael Niedermayer
On Mon, Aug 04, 2014 at 10:27:44AM +0200, Mickaël Raulet wrote:
 Patch ok.

applied

thanks

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

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


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


Re: [FFmpeg-devel] [PATCH] x86/hevc_mc: use fewer instructions in hevc_put_hevc_{uni, bi}_w[24]_{8, 10, 12}

2014-08-04 Thread Michael Niedermayer
On Mon, Aug 04, 2014 at 12:32:05PM +0200, Christophe Gisquet wrote:
 Hi,
 
 2014-08-04 6:18 GMT+02:00 James Almer jamr...@gmail.com:
  Signed-off-by: James Almer jamr...@gmail.com
 
 Looks good to me.
 
 Tested on top of my patches, too. IIRC, this should be evaluated by
 the WP_ test sequences.

applied



 On another hand, I expect to have little to no measurable impact, as
 this is weighted prediction for small PUs (4xH).

id say, every bit helps

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


Re: [FFmpeg-devel] [PATCH 0/4] Exploit compile-time constant

2014-08-04 Thread Michael Niedermayer
On Mon, Aug 04, 2014 at 10:31:52AM +0200, Christophe Gisquet wrote:
 Hi,
 
 2014-08-02 14:48 GMT+02:00 Michael Niedermayer michae...@gmx.at:
  seems to fail with
  libavcodec/x86/hevc_mc.asm:1258: error: (add:2) cannot reference symbol 
  `MAX_PB_SIZE' in preprocessor
 
 I forgot the initial patch when generating the patchset, that you can
 find here. I expect no changes for the others, so I didn't bother
 resending them/starting another thread.

yes, builds  works fine now with that patch

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange


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


Re: [FFmpeg-devel] [PATCH 3/3] x86/vp9lpf: use fewer instructions in SPLATB_MIX

2014-08-04 Thread Ronald S. Bultje
Hi,


On Sun, Aug 3, 2014 at 10:53 PM, James Almer jamr...@gmail.com wrote:

 Signed-off-by: James Almer jamr...@gmail.com
 ---
  libavcodec/x86/vp9lpf.asm | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

 diff --git a/libavcodec/x86/vp9lpf.asm b/libavcodec/x86/vp9lpf.asm
 index c5db0ca..def7d5a 100644
 --- a/libavcodec/x86/vp9lpf.asm
 +++ b/libavcodec/x86/vp9lpf.asm
 @@ -302,9 +302,8 @@ SECTION .text
  pshufb %1, %2
  %else
  punpcklbw  %1, %1
 -punpcklqdq %1, %1
 -pshuflw%1, %1, 0
 -pshufhw%1, %1, 0x55
 +punpcklwd  %1, %1
 +punpckldq  %1, %1


Doesn't this miss the upper half of the register?

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


Re: [FFmpeg-devel] [PATCH] avfilter/dctdnoiz: rewrite [f/i]dct

2014-08-04 Thread Ronald S. Bultje
Hi,

On Sun, Aug 3, 2014 at 4:27 PM, Clément Bœsch u...@pkh.me wrote:

 This removes the avcodec dependency and make the code almost twice as
 fast. More to come.

 The DCT factorization is based on Fast and numerically stable
 algorithms for discrete cosine transforms from Gerlind Plonkaa 
 Manfred Tasche (DOI: 10.1016/j.laa.2004.07.015).


I have no comments on the patch itself, but can you explain why we're
re-implementing a custom f/idct rather than using the one provided in
lavcodec? It seems to me that going from fixedpoint/simd'ed to float/c
would be slower, not faster, so there must be more to this patch than what
I'm getting from it...

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


Re: [FFmpeg-devel] [PATCH] avfilter/dctdnoiz: rewrite [f/i]dct

2014-08-04 Thread Clément Bœsch
On Mon, Aug 04, 2014 at 11:44:43AM -0400, Ronald S. Bultje wrote:
 Hi,
 
 On Mon, Aug 4, 2014 at 11:42 AM, Clément Bœsch u...@pkh.me wrote:
 
  On Mon, Aug 04, 2014 at 11:17:29AM -0400, Ronald S. Bultje wrote:
   Hi,
  
   On Sun, Aug 3, 2014 at 4:27 PM, Clément Bœsch u...@pkh.me wrote:
  
This removes the avcodec dependency and make the code almost twice as
fast. More to come.
   
The DCT factorization is based on Fast and numerically stable
algorithms for discrete cosine transforms from Gerlind Plonkaa 
Manfred Tasche (DOI: 10.1016/j.laa.2004.07.015).
  
  
   I have no comments on the patch itself, but can you explain why we're
   re-implementing a custom f/idct rather than using the one provided in
   lavcodec? It seems to me that going from fixedpoint/simd'ed to float/c
   would be slower, not faster, so there must be more to this patch than
  what
   I'm getting from it...
  
 
  OK so as said in private, I didn't find an accurate (not wrongly JPEG
  like I originally said) 16x16 DCT in libavcodec.
 
  You suggested to use the HEVC or VP9 DCT. That's indeed one solution, but
  we currently have only IDCT for those (AFAIK), and I needed a float
  implementation.
 
 
 You mean forward. idct is inverse, fdct is forward, such that
 idct(fdct(data[][])) =~ data[][].

Yeah sure I meant we have only the IDCT and I also needed the FDCT. The
float implementation was another point.

 You can use the forward transforms
 provided in libvpx (for vp9) or x265 (hevc), they're quite precise, and
 already optimized.

Yeah so basically I would have to maintain that port instead of my
implementation, which doesn't look ideal either (the point of using an
existing code in FFmpeg is that its maintenance would have been shared).

Also, in order to use them, it would make sense to port the whole filter
to fixed point. And unfortunately between the IDCT-average part and the
DCT 3x3 for color [de]correlation, I wasn't really confident to do that
regarding the accuracy (which you definitely wants for a non real-time
denoiser)

 
 Ronald

-- 
Clément B.


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


Re: [FFmpeg-devel] [PATCH] avfilter/dctdnoiz: rewrite [f/i]dct

2014-08-04 Thread Ronald S. Bultje
Hi,

On Mon, Aug 4, 2014 at 11:59 AM, Clément Bœsch u...@pkh.me wrote:

 On Mon, Aug 04, 2014 at 11:44:43AM -0400, Ronald S. Bultje wrote:
  Hi,
 
  On Mon, Aug 4, 2014 at 11:42 AM, Clément Bœsch u...@pkh.me wrote:
 
   On Mon, Aug 04, 2014 at 11:17:29AM -0400, Ronald S. Bultje wrote:
Hi,
   
On Sun, Aug 3, 2014 at 4:27 PM, Clément Bœsch u...@pkh.me wrote:
   
 This removes the avcodec dependency and make the code almost twice
 as
 fast. More to come.

 The DCT factorization is based on Fast and numerically stable
 algorithms for discrete cosine transforms from Gerlind Plonkaa 
 Manfred Tasche (DOI: 10.1016/j.laa.2004.07.015).
   
   
I have no comments on the patch itself, but can you explain why we're
re-implementing a custom f/idct rather than using the one provided in
lavcodec? It seems to me that going from fixedpoint/simd'ed to
 float/c
would be slower, not faster, so there must be more to this patch than
   what
I'm getting from it...
   
  
   OK so as said in private, I didn't find an accurate (not wrongly JPEG
   like I originally said) 16x16 DCT in libavcodec.
  
   You suggested to use the HEVC or VP9 DCT. That's indeed one solution,
 but
   we currently have only IDCT for those (AFAIK), and I needed a float
   implementation.
 
 
  You mean forward. idct is inverse, fdct is forward, such that
  idct(fdct(data[][])) =~ data[][].

 Yeah sure I meant we have only the IDCT and I also needed the FDCT. The
 float implementation was another point.

  You can use the forward transforms
  provided in libvpx (for vp9) or x265 (hevc), they're quite precise, and
  already optimized.

 Yeah so basically I would have to maintain that port instead of my
 implementation, which doesn't look ideal either (the point of using an
 existing code in FFmpeg is that its maintenance would have been shared).


Right, but it means one half (idct) is fully shared, with optimizations
etc. - and only one half is unshared-but-forked-with-optimizations.

Whereas right now, it's fully unshared and unoptimized...

I agree the 3x3 makes it a little more tricky, so do whatever you feel is
right; we don't want to have to convert datatypes 4x just so we can fit an
integer fdct/idct pair between an otherwise full float chain. If the
overall ultimate goal is for everything to be int, it makes sense, but I
don't know what the plan is.

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


Re: [FFmpeg-devel] [PATCH] avfilter/dctdnoiz: rewrite [f/i]dct

2014-08-04 Thread Ronald S. Bultje
Hi,

On Mon, Aug 4, 2014 at 11:42 AM, Clément Bœsch u...@pkh.me wrote:

 On Mon, Aug 04, 2014 at 11:17:29AM -0400, Ronald S. Bultje wrote:
  Hi,
 
  On Sun, Aug 3, 2014 at 4:27 PM, Clément Bœsch u...@pkh.me wrote:
 
   This removes the avcodec dependency and make the code almost twice as
   fast. More to come.
  
   The DCT factorization is based on Fast and numerically stable
   algorithms for discrete cosine transforms from Gerlind Plonkaa 
   Manfred Tasche (DOI: 10.1016/j.laa.2004.07.015).
 
 
  I have no comments on the patch itself, but can you explain why we're
  re-implementing a custom f/idct rather than using the one provided in
  lavcodec? It seems to me that going from fixedpoint/simd'ed to float/c
  would be slower, not faster, so there must be more to this patch than
 what
  I'm getting from it...
 

 OK so as said in private, I didn't find an accurate (not wrongly JPEG
 like I originally said) 16x16 DCT in libavcodec.

 You suggested to use the HEVC or VP9 DCT. That's indeed one solution, but
 we currently have only IDCT for those (AFAIK), and I needed a float
 implementation.


You mean forward. idct is inverse, fdct is forward, such that
idct(fdct(data[][])) =~ data[][]. You can use the forward transforms
provided in libvpx (for vp9) or x265 (hevc), they're quite precise, and
already optimized.

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


Re: [FFmpeg-devel] [libav-devel] [PATCHv3] Deprecate AFD field and add AFD as side-data

2014-08-04 Thread Vittorio Giovara
On Sun, Aug 3, 2014 at 7:24 PM, Kieran Kunhya kier...@obe.tv wrote:
 ---
  doc/APIchanges|4 
  libavcodec/avcodec.h  |5 -
  libavcodec/mpeg12dec.c|   20 +++-
  libavcodec/version.h  |5 -
  libavfilter/vf_showinfo.c |3 +++
  libavutil/frame.h |   16 
  libavutil/version.h   |2 +-
  7 files changed, 51 insertions(+), 4 deletions(-)

Looks good, I'll amend a few kr before pushing, thanks!
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avformat/util: change av_find_default_stream_index() to use a score based system

2014-08-04 Thread Michael Niedermayer
On Fri, Aug 01, 2014 at 10:29:25PM +0200, Michael Niedermayer wrote:
 Disfavor video streams with unknown resolution and no packets
 Fixes seeking in audio-only-speex.flv
 
 Signed-off-by: Michael Niedermayer michae...@gmx.at
 ---
  libavformat/utils.c |   20 ++--
  1 file changed, 14 insertions(+), 6 deletions(-)

applied


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

The worst form of inequality is to try to make unequal things equal.
-- 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 2/5] lavfi/buffersrc: add add av_buffersrc_close().

2014-08-04 Thread wm4
On Sun,  3 Aug 2014 15:15:37 +0200
Nicolas George geo...@nsup.org wrote:

 diff --git a/libavfilter/buffersrc.h b/libavfilter/buffersrc.h
 index ea34c04..28ca545 100644
 --- a/libavfilter/buffersrc.h
 +++ b/libavfilter/buffersrc.h
 @@ -145,6 +145,8 @@ int av_buffersrc_add_frame(AVFilterContext *ctx, AVFrame 
 *frame);
   *
   * @param buffer_src  pointer to a buffer source context
   * @param frame   a frame, or NULL to mark EOF
 + *(Using NULL to mark EOF is deprecated, use
 + *av_buffersrc_close() instead.)
   * @param flags   a combination of AV_BUFFERSRC_FLAG_*
   * @return= 0 in case of success, a negative AVERROR code
   *in case of failure

Please make clear that even though it's deprecated, these semantics
won't ever get removed from the API.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 3/3] x86/vp9lpf: use fewer instructions in SPLATB_MIX

2014-08-04 Thread Ronald S. Bultje
Hi,

On Mon, Aug 4, 2014 at 12:17 PM, James Almer jamr...@gmail.com wrote:

 On 04/08/14 10:27 AM, Ronald S. Bultje wrote:
  Hi,
 
 
  On Sun, Aug 3, 2014 at 10:53 PM, James Almer jamr...@gmail.com wrote:
 
  Signed-off-by: James Almer jamr...@gmail.com
  ---
   libavcodec/x86/vp9lpf.asm | 5 ++---
   1 file changed, 2 insertions(+), 3 deletions(-)
 
  diff --git a/libavcodec/x86/vp9lpf.asm b/libavcodec/x86/vp9lpf.asm
  index c5db0ca..def7d5a 100644
  --- a/libavcodec/x86/vp9lpf.asm
  +++ b/libavcodec/x86/vp9lpf.asm
  @@ -302,9 +302,8 @@ SECTION .text
   pshufb %1, %2
   %else
   punpcklbw  %1, %1
  -punpcklqdq %1, %1
  -pshuflw%1, %1, 0
  -pshufhw%1, %1, 0x55
  +punpcklwd  %1, %1
  +punpckldq  %1, %1
 
 
  Doesn't this miss the upper half of the register?
 
  Ronald

 Using the example above the macro

 ..AB (start value)
 punpcklbw
 AABB
 punpcklwd
 
 punpckldq
 


Oh I see not a byte-splat, my bad, sorry please ignore my comment.

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


Re: [FFmpeg-devel] [PATCH 3/4] hevcdsp: remove more instances of compile-time-fixed parameters

2014-08-04 Thread Christophe Gisquet
2014-07-28 19:17 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com:
 ---
  libavcodec/hevc.c |  8 +++
  libavcodec/hevcdsp.h  |  8 +++
  libavcodec/hevcdsp_template.c | 56 
 +--
  libavcodec/x86/hevc_mc.asm| 18 +++---
  libavcodec/x86/hevcdsp.h  |  6 ++---
  libavcodec/x86/hevcdsp_init.c | 12 +-
  6 files changed, 54 insertions(+), 54 deletions(-)

Update patch with a warning fixed and cleaned an asm macro.

-- 
Christophe
From 73c99b093fb6c74706ac311b76bd0f4afb61f550 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet christophe.gisq...@gmail.com
Date: Mon, 28 Jul 2014 12:13:06 +0200
Subject: [PATCH 3/4] hevcdsp: remove more instances of compile-time-fixed
 parameters

---
 libavcodec/hevc.c |  9 ---
 libavcodec/hevcdsp.h  |  8 +++
 libavcodec/hevcdsp_template.c | 56 +--
 libavcodec/x86/hevc_mc.asm| 42 +++-
 libavcodec/x86/hevcdsp.h  |  6 ++---
 libavcodec/x86/hevcdsp_init.c | 12 +-
 6 files changed, 64 insertions(+), 69 deletions(-)

diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index 1323c07..6806dc3 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -1384,10 +1384,10 @@ static void luma_mc_uni(HEVCContext *s, uint8_t *dst, ptrdiff_t dststride,
 s-hevcdsp.put_hevc_qpel[idx][!!my0][!!mx0](tmp, src0, src0stride,
 block_h, mx0, my0, block_w);
 if (!weight_flag)
-s-hevcdsp.put_hevc_qpel_bi[idx][!!my1][!!mx1](dst, dststride, src1, src1stride, tmp, MAX_PB_SIZE,
+s-hevcdsp.put_hevc_qpel_bi[idx][!!my1][!!mx1](dst, dststride, src1, src1stride, tmp,
block_h, mx1, my1, block_w);
 else
-s-hevcdsp.put_hevc_qpel_bi_w[idx][!!my1][!!mx1](dst, dststride, src1, src1stride, tmp, MAX_PB_SIZE,
+s-hevcdsp.put_hevc_qpel_bi_w[idx][!!my1][!!mx1](dst, dststride, src1, src1stride, tmp,
  block_h, s-sh.luma_log2_weight_denom,
  s-sh.luma_weight_l0[current_mv-ref_idx[0]],
  s-sh.luma_weight_l1[current_mv-ref_idx[1]],
@@ -1483,7 +1483,6 @@ static void chroma_mc_bi(HEVCContext *s, uint8_t *dst0, ptrdiff_t dststride, AVF
  int x_off, int y_off, int block_w, int block_h, struct MvField *current_mv, int cidx)
 {
 DECLARE_ALIGNED(16, int16_t, tmp [MAX_PB_SIZE * MAX_PB_SIZE]);
-int tmpstride = MAX_PB_SIZE;
 HEVCLocalContext *lc = s-HEVClc;
 uint8_t *src1= ref0-data[cidx+1];
 uint8_t *src2= ref1-data[cidx+1];
@@ -1557,11 +1556,11 @@ static void chroma_mc_bi(HEVCContext *s, uint8_t *dst0, ptrdiff_t dststride, AVF
 block_h, _mx0, _my0, block_w);
 if (!weight_flag)
 s-hevcdsp.put_hevc_epel_bi[idx][!!my1][!!mx1](dst0, s-frame-linesize[cidx+1],
-   src2, src2stride, tmp, tmpstride,
+   src2, src2stride, tmp,
block_h, _mx1, _my1, block_w);
 else
 s-hevcdsp.put_hevc_epel_bi_w[idx][!!my1][!!mx1](dst0, s-frame-linesize[cidx+1],
- src2, src2stride, tmp, tmpstride,
+ src2, src2stride, tmp,
  block_h,
  s-sh.chroma_log2_weight_denom,
  s-sh.chroma_weight_l0[current_mv-ref_idx[0]][cidx],
diff --git a/libavcodec/hevcdsp.h b/libavcodec/hevcdsp.h
index 122501f..716c29e 100644
--- a/libavcodec/hevcdsp.h
+++ b/libavcodec/hevcdsp.h
@@ -75,10 +75,10 @@ typedef struct HEVCDSPContext {
   int height, int denom, int wx, int ox, intptr_t mx, intptr_t my, int width);
 
 void (*put_hevc_qpel_bi[10][2][2])(uint8_t *dst, ptrdiff_t dststride, uint8_t *_src, ptrdiff_t _srcstride,
-   int16_t *src2, ptrdiff_t src2stride,
+   int16_t *src2,
int height, intptr_t mx, intptr_t my, int width);
 void (*put_hevc_qpel_bi_w[10][2][2])(uint8_t *dst, ptrdiff_t dststride, uint8_t *_src, ptrdiff_t _srcstride,
- int16_t *src2, ptrdiff_t src2stride,
+ int16_t *src2,
  int height, int denom, int wx0, int wx1,
  int ox0, int ox1, intptr_t mx, intptr_t my, int width);
 void 

Re: [FFmpeg-devel] [PATCH 3/3] x86/vp9lpf: use fewer instructions in SPLATB_MIX

2014-08-04 Thread Clément Bœsch
On Sun, Aug 03, 2014 at 11:53:40PM -0300, James Almer wrote:
 Signed-off-by: James Almer jamr...@gmail.com
 ---
  libavcodec/x86/vp9lpf.asm | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)
 
 diff --git a/libavcodec/x86/vp9lpf.asm b/libavcodec/x86/vp9lpf.asm
 index c5db0ca..def7d5a 100644
 --- a/libavcodec/x86/vp9lpf.asm
 +++ b/libavcodec/x86/vp9lpf.asm
 @@ -302,9 +302,8 @@ SECTION .text
  pshufb %1, %2
  %else
  punpcklbw  %1, %1
 -punpcklqdq %1, %1
 -pshuflw%1, %1, 0
 -pshufhw%1, %1, 0x55
 +punpcklwd  %1, %1
 +punpckldq  %1, %1

IIRC I based this on what I found in x86util.asm:SPLATW; would that apply
there as well?

-- 
Clément B.


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


Re: [FFmpeg-devel] [RFC] Implementation of closed caption support

2014-08-04 Thread Hendrik Leppkes
Am 04.08.2014 19:59 schrieb Gisle Sælensminde gi...@snirklasjon.no:

 I'm trying to add support for closed captions in ffmpeg, namely cea608 and
 cea708. Unlike normal subtitles, these are embedded in the video frames
 themselves rather than a separate track or file. As a first step I try to
write
 bitstreams filters for extraction and inserting closed captions into
h.264 and
 mpeg2 videos. For cea608, I use .scc files to represent the cea608 data.
 Later an interpreter and producer of scc files can be made as a subtitle
 codec.

 I have already written a cea 608 tools for my employer, but that is in
 python, so not suitable for inclusion in ffmpeg, so this will be a
 new implementation.

 I'm currently writing the extraction filter and I had hoped that I could
use
 it as a filter with parameters as follows.

 ffmpeg -i vid_with_cc.ts -acodec copy -vcodec copy -bsf
cea680_extract?scc=out.scc -f null /dev/null

 This is not possible, since bitstream filters don't have parameters. The
main
 problems can be summarized as follows:

 - The lack of parameters means that I don't have a way to specify where
to store
   the .scc file. How can I do that?

 - I can't find a way to get out the timestamps (pts and dts) in a
bitstream
   filter. The cea 608 and 708 data is stored in pts order in the frames,
so
   I need to reorder the data before writing them to file. Also, the scc
files
   have timestamps, so I need timestamps for that too. I can only find the
   timebase in AVCodecContext, and the AVFormatContext or AVPacket is not
passed
   in to the bitstream filter. The AVPacket is a deprecated field, but it
is
   NULL, so of no use. Is there something I have overlooked here?

 I may be missing something, and it is of cause possible that the
bitstream filter
 approch is misguided, but as far as I can tell, that is the best option.
Does anyone
 have a clear idea of how this should be done?

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

Its probably a better idea to export the CC data during video decoding as
side data, like the mpeg2 decoder already does today. That way you get it
reordered and with timestamps, but of course it means you need to perform
decoding.

I have a patch flying around for h264 that does this. I could send it soon.

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


Re: [FFmpeg-devel] [RFC] Implementation of closed caption support

2014-08-04 Thread wm4
On Mon, 4 Aug 2014 20:47:37 +0200
Reimar Döffinger reimar.doeffin...@gmx.de wrote:

 On Mon, Aug 04, 2014 at 08:19:38PM +0200, Hendrik Leppkes wrote:
  Am 04.08.2014 19:59 schrieb Gisle Sælensminde gi...@snirklasjon.no:
  
   I'm trying to add support for closed captions in ffmpeg, namely cea608 and
   cea708. Unlike normal subtitles, these are embedded in the video frames
   themselves rather than a separate track or file. As a first step I try to
  write
   bitstreams filters for extraction and inserting closed captions into
  h.264 and
   mpeg2 videos. For cea608, I use .scc files to represent the cea608 data.
   Later an interpreter and producer of scc files can be made as a subtitle
   codec.
  
   I have already written a cea 608 tools for my employer, but that is in
   python, so not suitable for inclusion in ffmpeg, so this will be a
   new implementation.
  
   I'm currently writing the extraction filter and I had hoped that I could
  use
   it as a filter with parameters as follows.
  
   ffmpeg -i vid_with_cc.ts -acodec copy -vcodec copy -bsf
  cea680_extract?scc=out.scc -f null /dev/null
  
   This is not possible, since bitstream filters don't have parameters. The
  main
   problems can be summarized as follows:
  
   - The lack of parameters means that I don't have a way to specify where
  to store
 the .scc file. How can I do that?
  
   - I can't find a way to get out the timestamps (pts and dts) in a
  bitstream
 filter. The cea 608 and 708 data is stored in pts order in the frames,
  so
 I need to reorder the data before writing them to file. Also, the scc
  files
 have timestamps, so I need timestamps for that too. I can only find the
 timebase in AVCodecContext, and the AVFormatContext or AVPacket is not
  passed
 in to the bitstream filter. The AVPacket is a deprecated field, but it
  is
 NULL, so of no use. Is there something I have overlooked here?
  
   I may be missing something, and it is of cause possible that the
  bitstream filter
   approch is misguided, but as far as I can tell, that is the best option.
  Does anyone
   have a clear idea of how this should be done?
  
  Its probably a better idea to export the CC data during video decoding as
  side data, like the mpeg2 decoder already does today. That way you get it
  reordered and with timestamps, but of course it means you need to perform
  decoding.
 
 It's also fairly silly, since it means you have to decode the video just
 to get the subtitle stream! And as far as I can tell if you want to remux
 but with separate subtitle stream that would even mean that you have to
 re-encode the video for no good reason.
 A _good_ (but complex/quite some effort) solution would be for the
 AVParser to extract it (optionally even removing it from the video frames?)
 and create a proper subtitle stream.

Isn't the problem with this that CC data needs to be reordered like the
video frames? That's AFAIK why it was made video frame side-data,
instead of extracting it with a parser.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [RFC] Implementation of closed caption support

2014-08-04 Thread Kieran Kunhya
 And as far as I can tell if you want to remux
 but with separate subtitle stream that would even mean that you have to
 re-encode the video for no good reason.

You can just swap out the caption data. It's guaranteed to be CBR anyway.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [RFC] Implementation of closed caption support

2014-08-04 Thread Reimar Döffinger
On Mon, Aug 04, 2014 at 08:04:39PM +0100, Kieran Kunhya wrote:
  And as far as I can tell if you want to remux
  but with separate subtitle stream that would even mean that you have to
  re-encode the video for no good reason.
 
 You can just swap out the caption data. It's guaranteed to be CBR anyway.

Uh, no.
The point is to get the CC data out you need to decode.
Now that you have the video decoded, if you want to mux it you have
to encode it again.
Though maybe it's possible to somehow use the same input stream twice as
input in FFmpeg and copy it once (for muxing) and decode it once (to get
the CC data).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 1/1] Fix compile error on bfin.

2014-08-04 Thread Bernd Kuhls
After the removal of all Blackfin architecture optimizations in
http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=b55d3bbeed375f7b74442c4dd274d116a3e3d2e1
some includes were left behind leading to a compile error:

CC  libavformat/adtsenc.o
In file included from ./libavcodec/get_bits.h:35,
 from ./libavcodec/ac3_parser.h:27,
 from libavformat/ac3dec.c:23:
./libavcodec/mathops.h:43:29: error: bfin/mathops.h: No such file or directory

This compile error was found by buildroot autobuild system:
http://autobuild.buildroot.net/results/ae0/ae056f267e907091d09d2a1546d6f1ae02fa23b9/

Signed-off-by: Bernd Kuhls bernd.ku...@t-online.de
---
 libavcodec/mathops.h |2 --
 libavutil/bswap.h|2 --
 libavutil/timer.h|2 --
 3 files changed, 6 deletions(-)

diff --git a/libavcodec/mathops.h b/libavcodec/mathops.h
index b0e48d8..87fca0c 100644
--- a/libavcodec/mathops.h
+++ b/libavcodec/mathops.h
@@ -39,8 +39,6 @@ extern const uint8_t ff_zigzag_direct[64];
 #   include arm/mathops.h
 #elif ARCH_AVR32
 #   include avr32/mathops.h
-#elif ARCH_BFIN
-#   include bfin/mathops.h
 #elif ARCH_MIPS
 #   include mips/mathops.h
 #elif ARCH_PPC
diff --git a/libavutil/bswap.h b/libavutil/bswap.h
index f38e1de..91cb795 100644
--- a/libavutil/bswap.h
+++ b/libavutil/bswap.h
@@ -40,8 +40,6 @@
 #   include arm/bswap.h
 #elif ARCH_AVR32
 #   include avr32/bswap.h
-#elif ARCH_BFIN
-#   include bfin/bswap.h
 #elif ARCH_SH4
 #   include sh4/bswap.h
 #elif ARCH_X86
diff --git a/libavutil/timer.h b/libavutil/timer.h
index 3fff77f..13a3c8c 100644
--- a/libavutil/timer.h
+++ b/libavutil/timer.h
@@ -40,8 +40,6 @@
 
 #if   ARCH_ARM
 #   include arm/timer.h
-#elif ARCH_BFIN
-#   include bfin/timer.h
 #elif ARCH_PPC
 #   include ppc/timer.h
 #elif ARCH_X86
-- 
1.7.10.4

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


Re: [FFmpeg-devel] [RFC] Implementation of closed caption support

2014-08-04 Thread Kieran Kunhya
 Uh, no.
 The point is to get the CC data out you need to decode.
 Now that you have the video decoded, if you want to mux it you have
 to encode it again.

Whether you decode the video or not is unrelated to your ability to
replace the SEI and replace the captions.
You'd still need to know the reordering though.

Unless you are talking about mov which is the only container that has
a special closed captions stream.

 Yes, that's one of the things that make it complex to implement.
 But the parser certainly has all the information to do the reordering.

It would have to do some low-level parsing to handle complex b-frame
patterns. VLC uses a guessed B-frame pattern and as a result is not
frame accurate.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/2] avutil/libm: Replace macro based fminf() by function

2014-08-04 Thread Bernd Kuhls
Michael Niedermayer michae...@gmx.at wrote in news:1402065736-24164-1-git-
send-email-michae...@gmx.at:

  libavutil/libm.h |5 -

Hi,

the current code in libm.h breaks compilation when the libc does not provide 
fminf, which is the case for uClibc. Here you will find a patch fixing the 
problem for me, although the problem should maybe be fixed in a different 
way:

http://git.buildroot.net/buildroot/tree/package/ffmpeg/ffmpeg-0001-
fminf.patch

For background discussion please look here:
http://thread.gmane.org/gmane.comp.lib.uclibc.buildroot/90973/focus=90994

Regards, Bernd

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


Re: [FFmpeg-devel] [RFC] Implementation of closed caption support

2014-08-04 Thread Gisle Sælensminde

Den 04. aug. 2014 21:11, skrev Reimar Döffinger:

On Mon, Aug 04, 2014 at 08:04:39PM +0100, Kieran Kunhya wrote:

And as far as I can tell if you want to remux
but with separate subtitle stream that would even mean that you have to
re-encode the video for no good reason.

You can just swap out the caption data. It's guaranteed to be CBR anyway.

Uh, no.
The point is to get the CC data out you need to decode.
Now that you have the video decoded, if you want to mux it you have
to encode it again.
Though maybe it's possible to somehow use the same input stream twice as
input in FFmpeg and copy it once (for muxing) and decode it once (to get
the CC data).


My current work in progress uses a bitstream filter and implements a 
partial parser for h.264 and mpeg2 frames. This is not all that much 
code, since most of the datastructures can be ignored. It also havce the 
advantage that the closed caption stuff can be kept in a separate 
module, and not mixed into the decoders. The decoder approch would also 
not work for insertion of closed captions (for h.264 that would be x264, 
and I can't see that CC has a place there really). I'm uncertain enough 
that I would prefere to here the opinion here before submitting a patch. 
As far as I can see it now:


Bitstream filter:

Pro:

- Modular, the CC code can be kept separate.
- Less complex code

Cons:

Need for features that I can't see is present in the bitstream filters:
- As far as I can see -no support for timestamps (PTS), required for 
reordering and timestams in the output file
- No support for  arguments to bitstream filters (unlike audio and video 
filters)


Decoder:

Pro:

- Parser already present. Easy to insert extraction code on the right spots

Cons:

- Less modular, CC code mixed with decoding code.
- Does not easily extend to encoders/insertion.
- Parameters (for input files)?







___
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 1/2] avutil/libm: Replace macro based fminf() by function

2014-08-04 Thread wm4
On Mon, 04 Aug 2014 21:25:12 +0200
Bernd Kuhls bernd.ku...@t-online.de wrote:

 Michael Niedermayer michae...@gmx.at wrote in news:1402065736-24164-1-git-
 send-email-michae...@gmx.at:
 
   libavutil/libm.h |5 -
 
 Hi,
 
 the current code in libm.h breaks compilation when the libc does not provide 
 fminf, which is the case for uClibc. Here you will find a patch fixing the 
 problem for me, although the problem should maybe be fixed in a different 
 way:
 
 http://git.buildroot.net/buildroot/tree/package/ffmpeg/ffmpeg-0001-
 fminf.patch
 
 For background discussion please look here:
 http://thread.gmane.org/gmane.comp.lib.uclibc.buildroot/90973/focus=90994
 
 Regards, Bernd

the problem is obviously that uclibc provides a fminf prorotype, but no
implementation. Obviously this breaks any application that attempts to
detect fminf, and provides its own fallback if it doesn't appear to
exist.

Why do you think ffmpeg should be patched for this, and not uclibc?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [RFC] Implementation of closed caption support

2014-08-04 Thread Kieran Kunhya
 into the decoders. The decoder approch would also not work for insertion of
 closed captions (for h.264 that would be x264, and I can't see that CC has a
 place there really). I'm uncertain enough that I would prefere to here the
 opinion here before submitting a patch. As far as I can see it now:

It would work with x264 actually because x264 could read the side data
from an AVFrame.
See how it's done here:

https://github.com/kierank/obe-vod/blob/master/input/scc.c

You will have problems making sure the input to x264 is cfr however.

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


Re: [FFmpeg-devel] [RFC] Implementation of closed caption support

2014-08-04 Thread Reimar Döffinger
On Mon, Aug 04, 2014 at 09:35:02PM +0200, Gisle Sælensminde wrote:
 Bitstream filter:
 
 Pro:
 
 - Modular, the CC code can be kept separate.
 - Less complex code
 
 Cons:
 
 Need for features that I can't see is present in the bitstream filters:
 - As far as I can see -no support for timestamps (PTS), required for
 reordering and timestams in the output file
 - No support for  arguments to bitstream filters (unlike audio and video
 filters)
 
 Decoder:
 
 Pro:
 
 - Parser already present. Easy to insert extraction code on the right spots
 
 Cons:
 
 - Less modular, CC code mixed with decoding code.
 - Does not easily extend to encoders/insertion.
 - Parameters (for input files)?

*scratches head* I wonder now if you misunderstood or if you discarded
the variant I pointed out due to effort/complexity?

Demuxer+Parser/Muxer:
Pro:
- Parsing is often done in demuxer anyway
- Appears as proper subtitle stream
- Same usage whether you want to mux into/demux from MPEG-TS or formats
  saving CC data separately like MOV and WTV
- Works without requiring decode/encode

Con:
- Needs reordering code in demuxer/parser
- Needs extra signalling code from parser to demuxer (probably)
- Custom code for partially rewriting frames in the muxer needed for
  MPEG containers
- Generally a good bit more of complexity.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] lavd/avfoundation: Add device category.

2014-08-04 Thread Thilo Borgmann
Hi,

as reported by David Favor, the AVFoundation device is not yet listed by ffmpeg
-devices.

This patch fixes that. Please Apply.

-Thilo
From c76b7ce3a2bceb13d273212ec7b5d3142691b24a Mon Sep 17 00:00:00 2001
From: Thilo Borgmann thilo.borgm...@mail.de
Date: Mon, 4 Aug 2014 22:06:59 +0200
Subject: [PATCH] lavd/avfoundation: Add device category.

---
 libavdevice/avfoundation.m | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 74d7811..4ac50a0 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -451,6 +451,7 @@ static const AVClass avf_class = {
 .item_name  = av_default_item_name,
 .option = options,
 .version= LIBAVUTIL_VERSION_INT,
+.category   = AV_CLASS_CATEGORY_DEVICE_VIDEO_INPUT,
 };
 
 AVInputFormat ff_avfoundation_demuxer = {
-- 
1.8.3.2

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


Re: [FFmpeg-devel] Mac/OSX question about clang + avfoundation + indev support

2014-08-04 Thread Thilo Borgmann
 [...]
 David-Favor-iMac# ffmpeg -devices
 ffmpeg version 2.3.1-2014-08-01-65165-g229a1e8 Copyright (c) 2000-2014 the
 FFmpeg developers
   built on Aug  1 2014 10:13:00 with Apple LLVM version 5.1 (clang-503.0.40)
 (based on LLVM 3.4svn)
   configuration: --cc=/usr/bin/clang --prefix=/david-favor-tools/osx-10.9
 --mandir=/david-favor-tools/osx-10.9/share/man --enable-gpl --enable-yasm
 --arch=x86_64 --enable-version3 --enable-pthreads --enable-shared
 --disable-static --disable-debug
 --extra-cflags='-I/david-favor-tools/osx-10.9/include -I/opt/local/include
 -I/usr/local/include -I/usr/include'
 --extra-ldflags='-Wl,-rpath,/david-favor-tools/osx-10.9/lib
 -Wl,-rpath,/opt/local/lib -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr/lib
 -L/david-favor-tools/osx-10.9/lib -L/opt/local/lib -L/usr/local/lib 
 -L/usr/lib'
 --enable-ffplay --enable-ffprobe --enable-ffserver --enable-indev=qtkit
 --enable-indev=avfoundation --enable-runtime-cpudetect --enable-nonfree
 --enable-zlib --enable-bzlib --enable-openssl --enable-gnutls --enable-swscale
 --enable-avfilter --enable-avresample --enable-postproc --enable-vda
 --enable-libfribidi --enable-libmp3lame --enable-libfaac --enable-libfdk_aac
 --enable-libvpx --enable-libtheora --enable-libvorbis --enable-libxvid
 --enable-libopus --enable-libopenjpeg --enable-libschroedinger 
 --enable-libspeex
 --enable-libbluray --enable-libx264 --enable-libx265 --enable-postproc
 --enable-frei0r --enable-libopencore-amrnb --enable-fontconfig
 --enable-libfreetype --enable-libmodplug --enable-libass
   libavutil  52. 94.100 / 52. 94.100
   libavcodec 55. 71.100 / 55. 71.100
   libavformat55. 50.100 / 55. 50.100
   libavdevice55. 13.102 / 55. 13.102
   libavfilter 4. 11.102 /  4. 11.102
   libavresample   1.  3.  0 /  1.  3.  0
   libswscale  2.  6.100 /  2.  6.100
   libswresample   0. 19.100 /  0. 19.100
   libpostproc52.  3.100 / 52.  3.100
 Devices:
  D. = Demuxing supported
  .E = Muxing supported
  --
  D  lavfi   Libavfilter virtual input device
  D  qtkit   QTKit input device
   E sdl SDL output device
   E xv  XV (XVideo) output device

I can reproduce that with the same clang version and current HEAD.

I have just posted a patch to fix that.

For the gcc problems I cannot tell, except that it might not be able to compile
the Apple API-headers. This is an issue for some compilers but nothing we can
fix afaik.

Thanks for reporting!

-Thilo

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


Re: [FFmpeg-devel] [PATCH] avfilter/dctdnoiz: rewrite [f/i]dct

2014-08-04 Thread Clément Bœsch
On Sun, Aug 03, 2014 at 01:59:25PM -0700, Timothy Gu wrote:
 On Aug 3, 2014 1:27 PM, Clément Bœsch u...@pkh.me wrote:
 
  This removes the avcodec dependency and make the code almost twice as
  fast. More to come.
 
  The DCT factorization is based on Fast and numerically stable
  algorithms for discrete cosine transforms from Gerlind Plonkaa 
  Manfred Tasche (DOI: 10.1016/j.laa.2004.07.015).
  ---
   configure |   2 -
   libavfilter/vf_dctdnoiz.c | 328
 +-
   2 files changed, 240 insertions(+), 90 deletions(-)
 
 This change warrants a Changelog entry.
 

Not yet; I'd like to fully optimize it first.

[...]
   static int config_input(AVFilterLink *inlink)
  @@ -194,18 +373,13 @@ static av_cold int init(AVFilterContext *ctx)
   NULL, NULL, NULL, NULL, 0, ctx);
   if (ret  0)
   return ret;
 
  +s-filter_freq_func = filter_freq_expr;
  +} else {
  +s-filter_freq_func = filter_freq_sigma;
   }
 
 Missing if (s-expr)?
 

You mean error checking? That should be handled by ret  0

[...]

-- 
Clément B.


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


Re: [FFmpeg-devel] [RFC] Implementation of closed caption support

2014-08-04 Thread Reimar Döffinger
On Mon, Aug 04, 2014 at 10:16:25PM +0200, Gisle Sælensminde wrote:
 Den 04. aug. 2014 21:58, skrev Reimar Döffinger:
 *scratches head* I wonder now if you misunderstood or if you discarded the
 variant I pointed out due to effort/complexity?
 
 Or because I don't know all the parts of the ffmpeg code well enough.

I grouped that under misunderstood :)

 Since both you and others has suggested that this is a good way to do it, I
 will look into it and see how it can be done. Thanks for your answers.

It would be very welcome (at least by me).
But, I have to say that it will lead down a path with lots of unknowns
and risks.
So while I'd be really happy for you to work in this direction,
I think I should be so fair to say there's a risk that you
might decide to give up on it in the end and then have to do one
of the other approaches anyway.

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


Re: [FFmpeg-devel] [PATCH] lavd/avfoundation: Add device category.

2014-08-04 Thread Michael Niedermayer
On Mon, Aug 04, 2014 at 10:10:12PM +0200, Thilo Borgmann wrote:
 Hi,
 
 as reported by David Favor, the AVFoundation device is not yet listed by 
 ffmpeg
 -devices.
 
 This patch fixes that. Please Apply.
 
 -Thilo

  avfoundation.m |1 +
  1 file changed, 1 insertion(+)
 62f49fcb277d0f6dc77f0eaee75f544d41116f7a  
 0001-lavd-avfoundation-Add-device-category.patch
 From c76b7ce3a2bceb13d273212ec7b5d3142691b24a Mon Sep 17 00:00:00 2001
 From: Thilo Borgmann thilo.borgm...@mail.de
 Date: Mon, 4 Aug 2014 22:06:59 +0200
 Subject: [PATCH] lavd/avfoundation: Add device category.

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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


Re: [FFmpeg-devel] [PATCH 1/1] Fix compile error on bfin.

2014-08-04 Thread Michael Niedermayer
On Mon, Aug 04, 2014 at 09:12:29PM +0200, Bernd Kuhls wrote:
 After the removal of all Blackfin architecture optimizations in
 http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=b55d3bbeed375f7b74442c4dd274d116a3e3d2e1
 some includes were left behind leading to a compile error:
 
 CC  libavformat/adtsenc.o
 In file included from ./libavcodec/get_bits.h:35,
  from ./libavcodec/ac3_parser.h:27,
  from libavformat/ac3dec.c:23:
 ./libavcodec/mathops.h:43:29: error: bfin/mathops.h: No such file or directory
 
 This compile error was found by buildroot autobuild system:
 http://autobuild.buildroot.net/results/ae0/ae056f267e907091d09d2a1546d6f1ae02fa23b9/
 
 Signed-off-by: Bernd Kuhls bernd.ku...@t-online.de
 ---
  libavcodec/mathops.h |2 --
  libavutil/bswap.h|2 --
  libavutil/timer.h|2 --
  3 files changed, 6 deletions(-)

applied

thanks

[...]
-- 
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 3/3] x86/vp9lpf: use fewer instructions in SPLATB_MIX

2014-08-04 Thread Michael Niedermayer
On Sun, Aug 03, 2014 at 11:53:40PM -0300, James Almer wrote:
 Signed-off-by: James Almer jamr...@gmail.com
 ---
  libavcodec/x86/vp9lpf.asm | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

applied

thanks

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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


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