Re: [FFmpeg-devel] [PATCH] lavfi/avf_showspectrum: use automatic framing.
On Sun, Aug 3, 2014 at 7:51 PM, Nicolas George 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 > --- > 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
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
On Mon, Aug 4, 2014 at 9:24 AM, mrskman 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;
> +
Re: [FFmpeg-devel] [PATCH] New p2p mode for showwaves filter
On Mon, Aug 4, 2014 at 9:34 AM, Paul B Mahol wrote:
>
>
>
> On Mon, Aug 4, 2014 at 9:24 AM, mrskman 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 >
Re: [FFmpeg-devel] [PATCH 1/3] x86/hevc_mc: remove an unnecessary pxor
Patch ok. Mickael Le lundi 4 août 2014, James Almer a écrit : > Signed-off-by: James Almer > > --- > 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 > 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
Hi, 2014-08-02 14:48 GMT+02:00 Michael Niedermayer : > 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 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, 9, 11, 16, dst, dststride, src, srcstride
[FFmpeg-devel] [PATCH] New p2p mode for showwaves filter
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
Re: [FFmpeg-devel] [PATCH] x86/hevc_mc: use fewer instructions in hevc_put_hevc_{uni, bi}_w[24]_{8, 10, 12}
Hi, 2014-08-04 6:18 GMT+02:00 James Almer : > Signed-off-by: James Almer Looks good to me. Tested on top of my patches, too. IIRC, this should be evaluated by the WP_ test sequences. On another hand, I expect to have little to no measurable impact, as this is weighted prediction for small PUs (4xH). -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] x86: hevc_deblock: remove unnecessary masking
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 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] libavformat/icecast.c Add Icecast protocol
Hi Marvin On Mon, Aug 04, 2014 at 12:51:46AM +0200, Michael Niedermayer wrote: > On Mon, Aug 04, 2014 at 12:24:27AM +0200, Marvin Scholz wrote: > > >av_freep() should be safe to be used with NULL > > > > Since av_freep takes a pointer I am nearly sure that it doesn't, at > > least I remember that I had some issues without the if's… But please > > correct me if I'm wrong. > > in the quoted code you pass the address of a pointer to av_freep() > the address of a pointer is never NULL. > The check checks if the pointer is NULL, which is passed to free() > POSIX, says about free() that > "If ptr is a null pointer, no action shall occur." > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/free.html > > ill make sure this is explicitly mentioned for av_freep() and not > just av_free() fixed the remaining nitpicks/comments and applied the patch If you want to maintain icecast, then please send a patch which adds yourself to MAINTAINERs Thanks [...] -- 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] [PATCH 1/3] x86/hevc_mc: remove an unnecessary pxor
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}
On Mon, Aug 04, 2014 at 12:32:05PM +0200, Christophe Gisquet wrote: > Hi, > > 2014-08-04 6:18 GMT+02:00 James Almer : > > Signed-off-by: James Almer > > 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
On Mon, Aug 04, 2014 at 10:31:52AM +0200, Christophe Gisquet wrote: > Hi, > > 2014-08-02 14:48 GMT+02:00 Michael Niedermayer : > > 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 0/4] Exploit compile-time constant
On Sun, Aug 03, 2014 at 07:10:13PM +0200, Christophe Gisquet wrote: > Hi, > > 2014-08-02 14:48 GMT+02:00 Michael Niedermayer : > > is this for apply/push or just RFC/WIP ? > > in-between. I had expected Mickael Raulet to comment if he was seeing > something not compatible with this. I think the bipred code is a bit > more mature since Ronald comments (iirc), so premature optimization is > probably a bit strong. Once Mickael is OK, then I'd agree with you > about applying it. cc-ing Mickael, so its not missed > > > you say "Premature optimization and overall not that useful." > > i would tend to suggest to apply it as it improves speed ... > > I was saying this mostly because it doesn't really register overall: > MC is around 20% in ffhevc for starters. [...] thanks -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 3 "Rare item" - "Common item with rare defect or maybe just a lie" "Professional" - "'Toy' made in china, not functional except as doorstop" "Experts will know" - "The seller hopes you are not an expert" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/hevc_mc: use fewer instructions in hevc_put_hevc_{uni, bi}_w[24]_{8, 10, 12}
2014-08-04 15:04 GMT+02:00 Michael Niedermayer : >> 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 Agreed. I meant: don't expect an easily benchmarkable difference. -- Christophe ___ 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
Hi, On Sun, Aug 3, 2014 at 10:53 PM, James Almer wrote: > Signed-off-by: James Almer > --- > 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
On Mon, Aug 04, 2014 at 01:14:37AM +0200, Michael Niedermayer wrote:
> On Mon, Aug 04, 2014 at 12:44:48AM +0200, Michael Niedermayer wrote:
> > On Sun, Aug 03, 2014 at 10:27:21PM +0200, Clément Bœsch 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(-)
> > >
> > > diff --git a/configure b/configure
> > > index 9c3af50..6196b2a 100755
> > > --- a/configure
> > > +++ b/configure
> > > @@ -2526,8 +2526,6 @@ boxblur_filter_deps="gpl"
> > > bs2b_filter_deps="libbs2b"
> > > colormatrix_filter_deps="gpl"
> > > cropdetect_filter_deps="gpl"
> > > -dctdnoiz_filter_deps="avcodec"
> > > -dctdnoiz_filter_select="dct"
> > > delogo_filter_deps="gpl"
> > > deshake_filter_deps="avcodec"
> > > deshake_filter_select="me_cmp"
> > > diff --git a/libavfilter/vf_dctdnoiz.c b/libavfilter/vf_dctdnoiz.c
> > > index 71b8536..6d24934 100644
> > > --- a/libavfilter/vf_dctdnoiz.c
> > > +++ b/libavfilter/vf_dctdnoiz.c
> > > @@ -1,5 +1,5 @@
> > > /*
> > > - * Copyright (c) 2013 Clément Bœsch
> > > + * Copyright (c) 2013-2014 Clément Bœsch
> > > *
> > > * This file is part of FFmpeg.
> > > *
> > > @@ -23,7 +23,6 @@
> > > * @see http://www.ipol.im/pub/art/2011/ys-dct/
> > > */
> > >
> > > -#include "libavcodec/avfft.h"
> > > #include "libavutil/eval.h"
> > > #include "libavutil/opt.h"
> > > #include "drawutils.h"
> > > @@ -35,7 +34,7 @@
> > > static const char *const var_names[] = { "c", NULL };
> > > enum { VAR_C, VAR_VARS_NB };
> > >
> > > -typedef struct {
> > > +typedef struct DCTdnoizContext {
> > > const AVClass *class;
> > >
> > > /* coefficient factor expression */
> > > @@ -52,8 +51,9 @@ typedef struct {
> > > int p_linesize; // line sizes for color and weights
> > > int overlap;// number of block overlapping pixels
> > > int step; // block step increment (BSIZE - overlap)
> > > -DCTContext *dct, *idct; // DCT and inverse DCT contexts
> > > -float *block, *tmp_block; // two BSIZE x BSIZE block buffers
> > > +void (*filter_freq_func)(struct DCTdnoizContext *s,
> > > + const float *src, int src_linesize,
> > > + float *dst, int dst_linesize);
> > > } DCTdnoizContext;
> > >
> > > #define OFFSET(x) offsetof(DCTdnoizContext, x)
> > > @@ -69,66 +69,245 @@ static const AVOption dctdnoiz_options[] = {
> > >
> > > AVFILTER_DEFINE_CLASS(dctdnoiz);
> > >
> > > -static float *dct_block(DCTdnoizContext *ctx, const float *src, int
> > > src_linesize)
> > > +static void av_always_inline fdct16_1d(float *dst, const float *src,
> > > + int dst_stridea, int dst_strideb,
> > > + int src_stridea, int src_strideb)
> > > {
> > > -int x, y;
> > > -float *column;
> > > -
> > > -for (y = 0; y < BSIZE; y++) {
> > > -float *line = ctx->block;
> > > +int i;
> > >
> > > -memcpy(line, src, BSIZE * sizeof(*line));
> > > -src += src_linesize;
> > > -av_dct_calc(ctx->dct, line);
> > > -
> > > -column = ctx->tmp_block + y;
> > > -column[0] = line[0] * (1. / sqrt(BSIZE));
> > > -column += BSIZE;
> > > -for (x = 1; x < BSIZE; x++) {
> > > -*column = line[x] * sqrt(2. / BSIZE);
> > > -column += BSIZE;
> > > -}
> > > +for (i = 0; i < BSIZE; i++) {
> > > +const float x0_0 = src[ 0*src_stridea] + src[15*src_stridea];
> > > +const float x0_1 = src[ 1*src_stridea] + src[14*src_stridea];
> > > +const float x0_2 = src[ 2*src_stridea] + src[13*src_stridea];
> > > +const float x0_3 = src[ 3*src_stridea] + src[12*src_stridea];
> > > +const float x0_4 = src[ 4*src_stridea] + src[11*src_stridea];
> > > +const float x0_5 = src[ 5*src_stridea] + src[10*src_stridea];
> > > +const float x0_6 = src[ 6*src_stridea] + src[ 9*src_stridea];
> > > +const float x0_7 = src[ 7*src_stridea] + src[ 8*src_stridea];
> > > +const float x0_8 = src[ 0*src_stridea] - src[15*src_stridea];
> > > +const float x0_9 = src[ 1*src_stridea] - src[14*src_stridea];
> > > +const float x0_a = src[ 2*src_stridea] - src[13*src_stridea];
> > > +const float x0_b = src[ 3*src_stridea] - src[12*src_stridea];
> > > +const float x0_c = src[ 4*src_stridea] - src[11*src_stridea];
> > > +const float x0_d = src[ 5*src_stridea] - src[10*src_stridea];
> > > +const float x0_e = src[
Re: [FFmpeg-devel] [PATCH] avfilter/dctdnoiz: rewrite [f/i]dct
Hi, On Sun, Aug 3, 2014 at 4:27 PM, Clément Bœsch 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
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 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. Now I also like the idea of implementing a specific [F/I]DCT for the filter and not something codec specific, where the accuracy might have been adjusted for very specific cases/environment. The algorithm I followed is supposed to be very stable numerically (and it indeed looks like so according to my tests), and still propose a nice optimized factorization form. Basically, it looked like to me like a really good trade-off between speed and ideal DCT. > Ronald -- Clément B. pgpJbhnRMQu4X.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86: hevc_deblock: remove unnecessary masking
On Mon, Aug 04, 2014 at 12:38:28PM +0200, Christophe Gisquet wrote: > 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 > hevc_deblock.asm |4 > 1 file changed, 4 deletions(-) > 2b7b65f4d59200e87cbe4d0d1c318c4889c2e141 > 0008-x86-hevc_deblock-remove-unnecessary-masking.patch > From 57819727586c186bfea733a8f06eead22ac6a1f2 Mon Sep 17 00:00:00 2001 > From: Christophe Gisquet > 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. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: Digital 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
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 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 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
Hi, On Mon, Aug 4, 2014 at 11:59 AM, Clément Bœsch 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 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 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
Hi, On Mon, Aug 4, 2014 at 11:42 AM, Clément Bœsch 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 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] [PATCH 3/3] x86/vp9lpf: use fewer instructions in SPLATB_MIX
On 04/08/14 10:27 AM, Ronald S. Bultje wrote: > Hi, > > > On Sun, Aug 3, 2014 at 10:53 PM, James Almer wrote: > >> Signed-off-by: James Almer >> --- >> 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 ___ 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
On Sun, Aug 3, 2014 at 7:24 PM, Kieran Kunhya 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 k&r 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
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 > --- > 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().
On Sun, 3 Aug 2014 15:15:37 +0200 Nicolas George 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
Hi, On Mon, Aug 4, 2014 at 12:17 PM, James Almer wrote: > On 04/08/14 10:27 AM, Ronald S. Bultje wrote: > > Hi, > > > > > > On Sun, Aug 3, 2014 at 10:53 PM, James Almer wrote: > > > >> Signed-off-by: James Almer > >> --- > >> 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-07-28 19:17 GMT+02:00 Christophe Gisquet :
> ---
> 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
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 (*put_hevc_epel[10][2][2])(int16
Re: [FFmpeg-devel] [PATCH 3/3] x86/vp9lpf: use fewer instructions in SPLATB_MIX
On Sun, Aug 03, 2014 at 11:53:40PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > 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] [PATCH 3/3] x86/vp9lpf: use fewer instructions in SPLATB_MIX
On 04/08/14 2:03 PM, Clément Bœsch wrote: > On Sun, Aug 03, 2014 at 11:53:40PM -0300, James Almer wrote: >> Signed-off-by: James Almer >> --- >> 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? No, SPLATW splats a word to the entire register whereas this splats one byte to the lower half of the register and another to the upper half. The code above turns AB into while SPLATW (with implied 0 as third argument) should output ABABABABABABABAB. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [RFC] Implementation of closed caption support
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
Re: [FFmpeg-devel] [RFC] Implementation of closed caption support
Am 04.08.2014 19:59 schrieb "Gisle Sælensminde" : > > 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
On Mon, Aug 04, 2014 at 08:19:38PM +0200, Hendrik Leppkes wrote: > Am 04.08.2014 19:59 schrieb "Gisle Sælensminde" : > > > > 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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Implementation of closed caption support
On Mon, 4 Aug 2014 20:47:37 +0200 Reimar Döffinger wrote: > On Mon, Aug 04, 2014 at 08:19:38PM +0200, Hendrik Leppkes wrote: > > Am 04.08.2014 19:59 schrieb "Gisle Sælensminde" : > > > > > > 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
> 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
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.
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 --- 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
On Mon, Aug 04, 2014 at 08:51:57PM +0200, wm4 wrote: > On Mon, 4 Aug 2014 20:47:37 +0200 > Reimar Döffinger wrote: > > > On Mon, Aug 04, 2014 at 08:19:38PM +0200, Hendrik Leppkes wrote: > > > Am 04.08.2014 19:59 schrieb "Gisle Sælensminde" : > > > > > > > > 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. 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 still is the only proper solution, its simplicity is the only thing that makes the current hack acceptable. And I can't see how it could be called anything but a hack. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Implementation of closed caption support
> 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
Michael Niedermayer 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
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
On Mon, 04 Aug 2014 21:25:12 +0200 Bernd Kuhls wrote: > Michael Niedermayer 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
> 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
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.
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
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
> [...] > 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] [RFC] Implementation of closed caption support
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. 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. -Gisle ___ 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
On Sun, Aug 03, 2014 at 01:59:25PM -0700, Timothy Gu wrote:
> On Aug 3, 2014 1:27 PM, "Clément Bœsch" 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
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.
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 > 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.
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 > --- > 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
On Sun, Aug 03, 2014 at 11:53:40PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > 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
Re: [FFmpeg-devel] [PATCH] New p2p mode for showwaves filter
On Mon, Aug 4, 2014 at 11:40 AM, mrskman wrote: > New patch attached. > > Thank you. > > --- > doc/filters.texi|3 +++ > libavfilter/avf_showwaves.c | 30 +- > 2 files changed, 32 insertions(+), 1 deletions(-) lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
