Re: [FFmpeg-devel] [PATCH] x86/hecv_res_add: add ff_hevc_transform_add{8, 16, 32}_8_avx
Patch ok
Mickael
Le mercredi 20 août 2014, James Almer a écrit :
> ~15% faster than sse2
>
> Signed-off-by: James Almer >
> ---
> libavcodec/x86/hevc_res_add.asm | 15 +++
> libavcodec/x86/hevcdsp.h| 4
> libavcodec/x86/hevcdsp_init.c | 4
> 3 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/x86/hevc_res_add.asm
> b/libavcodec/x86/hevc_res_add.asm
> index 47022d3..feea50c 100644
> --- a/libavcodec/x86/hevc_res_add.asm
> +++ b/libavcodec/x86/hevc_res_add.asm
> @@ -156,8 +156,8 @@ cglobal hevc_transform_add4_8, 3, 4, 6
> %endmacro
>
>
> -INIT_XMM sse2
> -; void ff_hevc_transform_add8_8_sse2(uint8_t *dst, int16_t *coeffs,
> ptrdiff_t stride)
> +%macro TRANSFORM_ADD_8 0
> +; void ff_hevc_transform_add8_8_(uint8_t *dst, int16_t *coeffs,
> ptrdiff_t stride)
> cglobal hevc_transform_add8_8, 3, 4, 8
> lea r3, [r2*3]
> TR_ADD_SSE_8_8
> @@ -167,7 +167,7 @@ cglobal hevc_transform_add8_8, 3, 4, 8
> RET
>
> %if ARCH_X86_64
> -; void ff_hevc_transform_add16_8_sse2(uint8_t *dst, int16_t *coeffs,
> ptrdiff_t stride)
> +; void ff_hevc_transform_add16_8_(uint8_t *dst, int16_t *coeffs,
> ptrdiff_t stride)
> cglobal hevc_transform_add16_8, 3, 4, 12
> lea r3, [r2*3]
> TR_ADD_SSE_16_8
> @@ -178,7 +178,7 @@ cglobal hevc_transform_add16_8, 3, 4, 12
> %endrep
> RET
>
> -; void ff_hevc_transform_add16_8_sse2(uint8_t *dst, int16_t *coeffs,
> ptrdiff_t stride)
> +; void ff_hevc_transform_add32_8_(uint8_t *dst, int16_t *coeffs,
> ptrdiff_t stride)
> cglobal hevc_transform_add32_8, 3, 4, 12
>
> TR_ADD_SSE_32_8
> @@ -190,6 +190,13 @@ cglobal hevc_transform_add32_8, 3, 4, 12
> RET
>
> %endif ;ARCH_X86_64
> +%endmacro
> +
> +INIT_XMM sse2
> +TRANSFORM_ADD_8
> +INIT_XMM avx
> +TRANSFORM_ADD_8
> +
>
>
> ;-
> ; void ff_hevc_transform_add_10(pixel *dst, int16_t *block, int stride)
>
>
> ;-
> diff --git a/libavcodec/x86/hevcdsp.h b/libavcodec/x86/hevcdsp.h
> index 7ced22c..74b5173 100644
> --- a/libavcodec/x86/hevcdsp.h
> +++ b/libavcodec/x86/hevcdsp.h
> @@ -139,6 +139,10 @@ void ff_hevc_transform_add8_8_sse2(uint8_t *dst,
> int16_t *coeffs, ptrdiff_t stri
> void ff_hevc_transform_add16_8_sse2(uint8_t *dst, int16_t *coeffs,
> ptrdiff_t stride);
> void ff_hevc_transform_add32_8_sse2(uint8_t *dst, int16_t *coeffs,
> ptrdiff_t stride);
>
> +void ff_hevc_transform_add8_8_avx(uint8_t *dst, int16_t *coeffs,
> ptrdiff_t stride);
> +void ff_hevc_transform_add16_8_avx(uint8_t *dst, int16_t *coeffs,
> ptrdiff_t stride);
> +void ff_hevc_transform_add32_8_avx(uint8_t *dst, int16_t *coeffs,
> ptrdiff_t stride);
> +
> void ff_hevc_transform_add4_10_mmxext(uint8_t *dst, int16_t *coeffs,
> ptrdiff_t stride);
> void ff_hevc_transform_add8_10_sse2(uint8_t *dst, int16_t *coeffs,
> ptrdiff_t stride);
> void ff_hevc_transform_add16_10_sse2(uint8_t *dst, int16_t *coeffs,
> ptrdiff_t stride);
> diff --git a/libavcodec/x86/hevcdsp_init.c b/libavcodec/x86/hevcdsp_init.c
> index 0f9fe7d..f6f0a4b 100644
> --- a/libavcodec/x86/hevcdsp_init.c
> +++ b/libavcodec/x86/hevcdsp_init.c
> @@ -509,7 +509,11 @@ void ff_hevc_dsp_init_x86(HEVCDSPContext *c, const
> int bit_depth)
> if (ARCH_X86_64) {
> c->hevc_v_loop_filter_luma =
> ff_hevc_v_loop_filter_luma_8_avx;
> c->hevc_h_loop_filter_luma =
> ff_hevc_h_loop_filter_luma_8_avx;
> +
> +c->transform_add[2]= ff_hevc_transform_add16_8_avx;
> +c->transform_add[3]= ff_hevc_transform_add32_8_avx;
> }
> +c->transform_add[1]= ff_hevc_transform_add8_8_avx;
> }
> if (EXTERNAL_AVX2(cpu_flags)) {
> c->idct_dc[2] = ff_hevc_idct16x16_dc_8_avx2;
> --
> 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] avcodec/hevc_ps: do cleanup in case of unsupported bit depth
Ok. Mickael Le mercredi 20 août 2014, Timothy Gu a écrit : > On Tue, Aug 19, 2014 at 6:49 PM, Michael Niedermayer > wrote: > > Fixes memleak > > Fixes CID1231989 > > > > Signed-off-by: Michael Niedermayer > > > --- > > libavcodec/hevc_ps.c |3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > Looks OK. > > > > > diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c > > index 163c5e4..2ccce5f 100644 > > --- a/libavcodec/hevc_ps.c > > +++ b/libavcodec/hevc_ps.c > > @@ -810,7 +810,8 @@ int ff_hevc_decode_nal_sps(HEVCContext *s) > > default: > > av_log(s->avctx, AV_LOG_ERROR, > > "4:2:0, 4:2:2, 4:4:4 supports are currently specified > for 8, 10 and 12 bits.\n"); > > -return AVERROR_PATCHWELCOME; > > +ret = AVERROR_PATCHWELCOME; > > +goto err; > > } > > > > desc = av_pix_fmt_desc_get(sps->pix_fmt); > > -- > > 1.7.9.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 > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/hecv_res_add: add ff_hevc_transform_add{8, 16, 32}_8_avx
Hi,
2014-08-20 4:55 GMT+02:00 James Almer :
> ~15% faster than sse2
[...]
> @@ -509,7 +509,11 @@ void ff_hevc_dsp_init_x86(HEVCDSPContext *c, const int
> bit_depth)
> if (ARCH_X86_64) {
> c->hevc_v_loop_filter_luma =
> ff_hevc_v_loop_filter_luma_8_avx;
> c->hevc_h_loop_filter_luma =
> ff_hevc_h_loop_filter_luma_8_avx;
> +
> +c->transform_add[2]= ff_hevc_transform_add16_8_avx;
> +c->transform_add[3]= ff_hevc_transform_add32_8_avx;
Does avx => ARCH_X86_64 (didn't know) ? Otherwise the reg count seems
fine, meaning the condition is unneeded.
> }
> +c->transform_add[1]= ff_hevc_transform_add8_8_avx;
I'm not entirely sure, but this is instantiated through INIT_YMM avx2,
and I wouldn't expect performance improvement past the 3-op-form?
So couldn't this one be instantiated to use xmm regs? (mmx may be a
burden eg need for emms and need to rewrite it).
--
Christophe
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Disable chunked output for Icecast
hi, attached patch fix input stream detection by Icecast that do not understand chunked http input. -- Maksym Veremeyenko >From e733ea6b31d341d2850070e378c2c841ebec0e35 Mon Sep 17 00:00:00 2001 From: Maksym Veremeyenko Date: Wed, 20 Aug 2014 12:15:14 +0300 Subject: [PATCH] Disable chunked output for Icecast --- libavformat/icecast.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/libavformat/icecast.c b/libavformat/icecast.c index 56a2976..5f6b83d 100644 --- a/libavformat/icecast.c +++ b/libavformat/icecast.c @@ -118,6 +118,7 @@ static int icecast_open(URLContext *h, const char *uri, int flags) av_dict_set(&opt_dict, "content_type", s->content_type, 0); if (NOT_EMPTY(s->user_agent)) av_dict_set(&opt_dict, "user_agent", s->user_agent, 0); +av_dict_set(&opt_dict, "chunked_post", "0", 0); // Parse URI av_url_split(NULL, 0, auth, sizeof(auth), host, sizeof(host), -- 1.7.7.6 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/5] RGB48/64 with bits_per_raw_sample
Depending on the input and/or filters, you sometime have an input or output pixel format like "rgb48le(12 bpc)". Unfortunately, most often, the 12 bpc information is ignored or stripped. This patchset modify some such cases, at the cost of increasing risks as patches go. 0001 is an actual bugfix to dpxenc for a misplaced hunk in 69849a2d. 0002 is more of a feature than anything. 0003 occurs with eg rgb48le(12 bpc): the code goes through the s->bits_per_component==12 case rather than ==16 0004 is a hack to conserve the 12bpc information across some conversions. 0005 respects bits_per_raw_sample but introduces potential issues The issues with 0005 is that some formats do not know how to encode bidepths between 9 and 15. And conversion from a form of rgb48 to another (stripping alpha or endianness or ...) does not rescale according to bits_per_raw_sample. ljpeg output for RGB and bits_per_raw_sample==12 is e.g. not rescaled to 16bits to match its rgb48 colorspace. One may argue that a proper solution is to reduce as often as possible references to bits_per_raw_sample and, instead, always use the colorspace information and to introduce new colorspaces as needed. Christophe Gisquet (5): dpxenc: fix padding in encode_gbrp12 pnmenc: use bits_per_raw_sample dpxenc: fix encoding of packed RGB48/64 ffmpeg: keep bitdepth where possible pnmdec: keep bitdepth rather than rescaling ffmpeg.c| 9 + libavcodec/dpxenc.c | 41 ++--- libavcodec/pnmdec.c | 6 -- libavcodec/pnmenc.c | 2 ++ 4 files changed, 49 insertions(+), 9 deletions(-) -- 1.9.2.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/5] dpxenc: fix padding in encode_gbrp12
It was added per pixel instead of per line. --- libavcodec/dpxenc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/dpxenc.c b/libavcodec/dpxenc.c index 059d8c6..aca745b 100644 --- a/libavcodec/dpxenc.c +++ b/libavcodec/dpxenc.c @@ -159,11 +159,11 @@ static void encode_gbrp12(AVCodecContext *avctx, const AVPicture *pic, uint16_t value[2] = AV_RL16(src[1] + x) << 4; value[0] = AV_RL16(src[2] + x) << 4; } -for (i = 0; i < pad; i++) -*dst++ = 0; for (i = 0; i < 3; i++) write16(dst++, value[i]); } +for (i = 0; i < pad; i++) +*dst++ = 0; for (i = 0; i < 3; i++) src[i] += pic->linesize[i]/2; } -- 1.9.2.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/5] dpxenc: fix encoding of packed RGB48/64
When input had 12 bits, it was invariably treated as packed RGB
with 12 bits per component.
---
libavcodec/dpxenc.c | 37 -
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/libavcodec/dpxenc.c b/libavcodec/dpxenc.c
index aca745b..d02684b 100644
--- a/libavcodec/dpxenc.c
+++ b/libavcodec/dpxenc.c
@@ -138,6 +138,38 @@ static void encode_gbrp10(AVCodecContext *avctx, const
AVPicture *pic, uint8_t *
}
}
+static void encode_rgb48_Nbits(AVCodecContext *avctx, const AVPicture *pic,
+ uint16_t *dst)
+{
+DPXContext *s = avctx->priv_data;
+const uint16_t *src = (uint16_t *)pic->data[0];
+int stride = pic->linesize[0]/2;
+int x, y, i, pad, shift = 16 - avctx->bits_per_raw_sample;
+
+pad = avctx->width*6;
+pad = (FFALIGN(pad, 4) - pad) >> 1;
+for (y = 0; y < avctx->height; y++) {
+for (x = 0; x < avctx->width; x++) {
+uint16_t value[3];
+// Input is RGB, encode as BGR
+if (s->big_endian) {
+value[0] = AV_RB16(src + 3*x+0) << shift;
+value[1] = AV_RB16(src + 3*x+1) << shift;
+value[2] = AV_RB16(src + 3*x+2) << shift;
+} else {
+value[0] = AV_RL16(src + 3*x+0) << shift;
+value[1] = AV_RL16(src + 3*x+1) << shift;
+value[2] = AV_RL16(src + 3*x+2) << shift;
+}
+for (i = 0; i < 3; i++)
+write16(dst++, value[i]);
+}
+for (i = 0; i < pad; i++)
+*dst++ = 0;
+src += stride;
+}
+}
+
static void encode_gbrp12(AVCodecContext *avctx, const AVPicture *pic,
uint16_t *dst)
{
DPXContext *s = avctx->priv_data;
@@ -254,7 +286,10 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
encode_rgb48_10bit(avctx, (const AVPicture*)frame, buf +
HEADER_SIZE);
break;
case 12:
-encode_gbrp12(avctx, (const AVPicture*)frame, (uint16_t*)(buf +
HEADER_SIZE));
+if (s->planar)
+encode_gbrp12(avctx, (const AVPicture*)frame, (uint16_t*)(buf +
HEADER_SIZE));
+else
+encode_rgb48_Nbits(avctx, (const AVPicture*)frame, (uint16_t*)(buf
+ HEADER_SIZE));
break;
default:
av_log(avctx, AV_LOG_ERROR, "Unsupported bit depth: %d\n",
s->bits_per_component);
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/5] pnmdec: keep bitdepth rather than rescaling
pnmdec currently respects the consign of rgb48 content. Instead, do not rescale and make the bits_per_raw_sample valid and useful. --- libavcodec/pnmdec.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/libavcodec/pnmdec.c b/libavcodec/pnmdec.c index c84b6eb..36bdfe7 100644 --- a/libavcodec/pnmdec.c +++ b/libavcodec/pnmdec.c @@ -67,15 +67,11 @@ static int pnm_decode_frame(AVCodecContext *avctx, void *data, n = avctx->width * 8; components=4; sample_len=16; -if (s->maxval < 65535) -upgrade = 2; goto do_read; case AV_PIX_FMT_RGB48: n = avctx->width * 6; components=3; sample_len=16; -if (s->maxval < 65535) -upgrade = 2; goto do_read; case AV_PIX_FMT_RGBA: n = avctx->width * 4; @@ -105,8 +101,6 @@ static int pnm_decode_frame(AVCodecContext *avctx, void *data, n = avctx->width * 2; components=1; sample_len=16; -if (s->maxval < 65535) -upgrade = 2; goto do_read; case AV_PIX_FMT_MONOWHITE: case AV_PIX_FMT_MONOBLACK: -- 1.9.2.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/5] pnmenc: use bits_per_raw_sample
This allows writing actual bitdepth in RGB48 when it isn't actually 16.
---
libavcodec/pnmenc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/pnmenc.c b/libavcodec/pnmenc.c
index e6c3635..9198ddb 100644
--- a/libavcodec/pnmenc.c
+++ b/libavcodec/pnmenc.c
@@ -84,6 +84,8 @@ static int pnm_encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
bytestream += strlen(bytestream);
if (avctx->pix_fmt != AV_PIX_FMT_MONOWHITE) {
int maxdepth = (1 <<
(av_pix_fmt_desc_get(avctx->pix_fmt)->comp[0].depth_minus1 + 1)) - 1;
+if( avctx->bits_per_raw_sample )
+maxdepth = (1 << avctx->bits_per_raw_sample) - 1;
snprintf(bytestream, bytestream_end - bytestream,
"%d\n", maxdepth);
bytestream += strlen(bytestream);
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/5] ffmpeg: keep bitdepth where possible
Thanks to av_get_pix_fmt_loss, we can determine more precisely if a
conversion will incur some kind of loss. If this loss doesn't modify
in particular bitdepth, the input bitdepth can be reused for the
output.
---
ffmpeg.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/ffmpeg.c b/ffmpeg.c
index fa907b4..2bfa047 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -2774,6 +2774,15 @@ static int transcode_init(void)
enc_ctx->bits_per_raw_sample = frame_bits_per_raw_sample;
}
+if (!(av_get_pix_fmt_loss(enc_ctx->pix_fmt, dec_ctx->pix_fmt,
0)
+ & (FF_LOSS_DEPTH|FF_LOSS_COLORSPACE|FF_LOSS_CHROMA))) {
+const AVPixFmtDescriptor *pix1 =
av_pix_fmt_desc_get(enc_ctx->pix_fmt);
+const AVPixFmtDescriptor *pix2 =
av_pix_fmt_desc_get(dec_ctx->pix_fmt);
+if (pix1 && pix2 &&
+av_get_bits_per_pixel(pix1) ==
av_get_bits_per_pixel(pix2))
+enc_ctx->bits_per_raw_sample =
dec_ctx->bits_per_raw_sample;
+}
+
if (ost->forced_keyframes) {
if (!strncmp(ost->forced_keyframes, "expr:", 5)) {
ret = av_expr_parse(&ost->forced_keyframes_pexpr,
ost->forced_keyframes+5,
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] ffmpeg: keep bitdepth where possible
Hi,
2014-08-20 10:10 GMT+02:00 Christophe Gisquet :
> +if (!(av_get_pix_fmt_loss(enc_ctx->pix_fmt,
> dec_ctx->pix_fmt, 0)
> + & (FF_LOSS_DEPTH|FF_LOSS_COLORSPACE|FF_LOSS_CHROMA))) {
If it was ever useful, this is probably wrong and should rather use
AVPixFmtDescriptor information of:
- is it rgb and planar ?
- are all the components using the same bitdepth?
--
Christophe
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/5] RGB48/64 with bits_per_raw_sample
Hi, 2014-08-20 10:10 GMT+02:00 Christophe Gisquet : > One may argue that a proper solution is to reduce as often as possible > references to bits_per_raw_sample and, instead, always use the > colorspace information and to introduce new colorspaces as needed. I'd prefer this solution although it's a much longer road. This requires modifying libavutil/pix* in a way that would remain compatible with several references, so if this is the road selected, I'd need a bit of advice here. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 08/19/2014 12:45 PM, Clément Bœsch wrote: > See: > http://fate.ffmpeg.org/ > http://coverage.ffmpeg.org/ The 2nd link to "coverage" (which should show the LCOV output, I guess) seems to be broken: I get a "404 Not Found" :( Regards, Pb ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avfilter/showwaves: add split_channels option.
On 8/19/14, Clement Boesch wrote: > From: Clement Boesch > > --- > doc/filters.texi| 3 +++ > libavfilter/avf_showwaves.c | 14 ++ > 2 files changed, 13 insertions(+), 4 deletions(-) > lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avfilter/showwaves: split out draw sample code.
On 8/19/14, Clement Boesch wrote: > From: Clement Boesch > > --- > libavfilter/avf_showwaves.c | 119 > +++- > 1 file changed, 74 insertions(+), 45 deletions(-) > lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] dpxenc: fix padding in encode_gbrp12
On 2014-08-20 10:10, Christophe Gisquet wrote: > It was added per pixel instead of per line. > --- > libavcodec/dpxenc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavcodec/dpxenc.c b/libavcodec/dpxenc.c > index 059d8c6..aca745b 100644 > --- a/libavcodec/dpxenc.c > +++ b/libavcodec/dpxenc.c > @@ -159,11 +159,11 @@ static void encode_gbrp12(AVCodecContext *avctx, const > AVPicture *pic, uint16_t > value[2] = AV_RL16(src[1] + x) << 4; > value[0] = AV_RL16(src[2] + x) << 4; > } > -for (i = 0; i < pad; i++) > -*dst++ = 0; > for (i = 0; i < 3; i++) > write16(dst++, value[i]); > } > +for (i = 0; i < pad; i++) > +*dst++ = 0; > for (i = 0; i < 3; i++) > src[i] += pic->linesize[i]/2; > } > (In an effort to help review...) This does move from per-pixel to per-line so if this is supposed to be correct then it looks good to me. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Wed, Aug 20, 2014 at 11:05:05AM +0200, Peter B. wrote: > On 08/19/2014 12:45 PM, Clément Bœsch wrote: > > See: > > http://fate.ffmpeg.org/ > > http://coverage.ffmpeg.org/ > > The 2nd link to "coverage" (which should show the LCOV output, I guess) > seems to be broken: > I get a "404 Not Found" :( > Sorry about that, should be fixed. [...] -- Clément B. pgpDggrAqpDYV.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Patch] [avfilter] refactor floating point based interpolation and introduce in vf_lenscorrection
On Wed, Aug 20, 2014 at 08:14:31AM +0200, Daniel Oberhoff wrote:
>
>
> Von meinem iPhone gesendet
>
> > Am 20.08.2014 um 03:16 schrieb Michael Niedermayer :
> >
> >> On Wed, Aug 20, 2014 at 12:12:49AM +0200, Daniel Oberhoff wrote:
> >> Hello,
> >>
> >> As a follow-up to my last patch I now factored out the floating point
> >> based interpolation from transform.h/transform.c and applied it in the
> >> vf_lenscorrection filter I introduced in my last patch. What I did not do
> >> is also factor out fixed point based interpolation as used in vf_rotate
> >> and vf_perspective and maybe others as could probably also be done. Also I
> >> did not look further for uses of floating point based interpolation.
> >> Basically I just wanted to introduce interpolation in vf_lenscorrection
> >> without code duplication. As a side note I also tried to introduce fixed
> >> point calculations to vf_lenscorrection but found myself effectively doing
> >> floating point “by hand” since due to the high order of the algorithm (up
> >> to 4th order) it is very hard to keep track of the right amount of
> >> pre/post-comma digits for a given step in the algorithm and given
> >> parameters and it felt rather futile after a while.
> >
> >> Looking forward to reviews :).
> >
> > why did you use the deshake code and not the vf_perspective code ?!
> > i suspect this will be quite a bit harder to get into shape for a
> > common API
> >
>
> As i Said, perspective does fixed point calculations. Also would you care to
> ekaborate what exactly are your whoes with this API?
there where further commments further down in the reply, that list
some problems
In addition, being float based is already a problem on its own,
we dont really want it to be float based. Its very likely slower and
its not bitexact making tests harder.
besides a API that works 1 sample at a time redundantly recalculates
the Coefficients for each color plane, also doing 1 sample per call
isnt very SIMD friendly
or to see this from another point of view
what we would like to have is a SSE*/AVX* based generic resampling
code using fixed point (with 16bit coeffs for 8bit samples for example)
Theres no need to implement SSE/AVX but the API should be a step
toward this, and the patch feels like its going the opposit direction
this is even worse as this is common API, so other filters could
start using this increasing the amount of code that would eventually
be changed/updated/rewritten
>
> >
> >>
> >> From 4b271f72946aeebf5603cc8779f6b61ff0c1bd49 Mon Sep 17 00:00:00 2001
> >> From: James Almer
> >> Date: Sun, 10 Aug 2014 02:24:01 -0300
> >> Subject: [PATCH] afvilter: re-factor/re-use floating point based
> >> interpolation
> >> from vf_perspective
> >>
> >> ---
> >> doc/filters.texi| 11 +++
> >> libavfilter/interpolate.h | 144
> >>
> >> libavfilter/transform.c | 91 ++---
> >> libavfilter/transform.h | 14 +---
> >> libavfilter/vf_lenscorrection.c | 21 --
> >> 5 files changed, 176 insertions(+), 105 deletions(-)
> >> create mode 100644 libavfilter/interpolate.h
> >>
> >> diff --git a/doc/filters.texi b/doc/filters.texi
> >> index 0ca1d6f..2edefc4 100644
> >> --- a/doc/filters.texi
> >> +++ b/doc/filters.texi
> >> @@ -5582,6 +5582,17 @@ height.
> >> Coefficient of the quadratic correction term. 0.5 means no correction.
> >> @item k2
> >> Coefficient of the double quadratic correction term. 0.5 means no
> >> correction.
> >> +@item interpolation
> >> +Set the interpolation method for the transformation
> >> +
> >> +It accepts the following values:
> >> +@table @samp
> >> +@item nearest
> >> +@item linear
> >> +@item cubic
> >> +@end table
> >> +Default value is @samp{linear}.
> >> +
> >> @end table
> >>
> >> The formula that generates the correction is:
> >> diff --git a/libavfilter/interpolate.h b/libavfilter/interpolate.h
> >> new file mode 100644
> >> index 000..6f7a849
> >> --- /dev/null
> >> +++ b/libavfilter/interpolate.h
> >> @@ -0,0 +1,144 @@
> >> +/*
> >> + * Copyright (C) 2010 Georg Martius
> >> + * Copyright (C) 2010 Daniel G. Taylor
> >> + *
> >> + * This file is part of FFmpeg.
> >> + *
> >> + * FFmpeg is free software; you can redistribute it and/or
> >> + * modify it under the terms of the GNU Lesser General Public
> >> + * License as published by the Free Software Foundation; either
> >> + * version 2.1 of the License, or (at your option) any later version.
> >> + *
> >> + * FFmpeg is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> >> + * Lesser General Public License for more details.
> >> + *
> >> + * You should have received a copy of the GNU Lesser General Public
> >> + * License along with FFmpeg; if not, write to the Free Software
> >> + * Foundation, Inc., 51 Frankli
Re: [FFmpeg-devel] [Patch] [avfilter] refactor floating point based interpolation and introduce in vf_lenscorrection
--- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 20, 2014, at 11:47 AM, Michael Niedermayer wrote: > On Wed, Aug 20, 2014 at 08:14:31AM +0200, Daniel Oberhoff wrote: >> >> >> Von meinem iPhone gesendet >> >>> Am 20.08.2014 um 03:16 schrieb Michael Niedermayer : >>> On Wed, Aug 20, 2014 at 12:12:49AM +0200, Daniel Oberhoff wrote: Hello, As a follow-up to my last patch I now factored out the floating point based interpolation from transform.h/transform.c and applied it in the vf_lenscorrection filter I introduced in my last patch. What I did not do is also factor out fixed point based interpolation as used in vf_rotate and vf_perspective and maybe others as could probably also be done. Also I did not look further for uses of floating point based interpolation. Basically I just wanted to introduce interpolation in vf_lenscorrection without code duplication. As a side note I also tried to introduce fixed point calculations to vf_lenscorrection but found myself effectively doing floating point “by hand” since due to the high order of the algorithm (up to 4th order) it is very hard to keep track of the right amount of pre/post-comma digits for a given step in the algorithm and given parameters and it felt rather futile after a while. >>> Looking forward to reviews :). >>> >>> why did you use the deshake code and not the vf_perspective code ?! >>> i suspect this will be quite a bit harder to get into shape for a >>> common API >>> >> >> As i Said, perspective does fixed point calculations. Also would you care to >> ekaborate what exactly are your whoes with this API? > > there where further commments further down in the reply, that list > some problems > > In addition, being float based is already a problem on its own, > we dont really want it to be float based. Its very likely slower and > its not bitexact making tests harder. Well, as I had outlined fixed point is not a viable option for my algorithm. > besides a API that works 1 sample at a time redundantly recalculates > the Coefficients for each color plane, also doing 1 sample per call > isnt very SIMD friendly > > or to see this from another point of view > what we would like to have is a SSE*/AVX* based generic resampling > code using fixed point (with 16bit coeffs for 8bit samples for example) > > Theres no need to implement SSE/AVX but the API should be a step > toward this, and the patch feels like its going the opposit direction > this is even worse as this is common API, so other filters could > start using this increasing the amount of code that would eventually > be changed/updated/rewritten There is some contradiction in your comments. You want to move towards vectorization (btw. how would you do that in ffmpeg? I had previously proposed an sse version using intrinsics and builtin operators, but that was dismissed as not being portable and I was asked to write assembly instead, which I am not proficient in), but you want to do all planes simultanously, even though they are far apart in memory. Imho the gain by being memory local (which is also what you want for vectorization) far outweights the calculation cost for the coefficients. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/filters/apad: extend documentation
On date Monday 2014-08-18 09:25:10 -0700, Timothy Gu encoded:
> On Mon, Aug 18, 2014 at 5:53 AM, Stefano Sabatini wrote:
> > ---
> > doc/filters.texi | 47 +--
> > 1 file changed, 45 insertions(+), 2 deletions(-)
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index 0ca1d6f..44eecca 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -742,8 +742,51 @@ Pass the audio source unchanged to the output.
> >
> > @section apad
> >
> > -Pad the end of a audio stream with silence, this can be used together with
> > --shortest to extend audio streams to the same length as the video stream.
> > +Pad the end of an audio stream with silence.
> > +
> > +This can be used together with @command{ffmpeg} @option{-shortest} to
> > +extend audio streams to the same length as the video stream.
> > +
>
> > +A description of the accepted parameters follows.
>
> @subsection Options
>
> I would also change "parameters" to "options", as it is more common in the
> doc.
Fixed.
>
> > +
> > +@table @option
> > +@item packet_size
> > +Set silence packet size. Default value is 4096.
> > +
>
> > +@item pad_len
> > +Set the number of samples of silence to add to the end. After the
> > +value is reached, the stream is terminated. This option is mutually
> > +exclusive with @option{whole_len}.
> > +
> > +@item whole_len
>
> > +Set the target number of sample in the audio stream. After the value
> > +is reached, the stream is terminated. This option is mutually
> > +exclusive with @option{pad_len}.
>
> How about:
>
> Set total number of samples in the audio stream. If the value is
> longer than input audio length, silence is added to the end, until the
> value is reached.
> If it is shorter, the stream is terminated after the
> value is reached.
Right now the filter will stop the stream with no padding *only* at the
end of the stream, that is it is not possible to cut the stream before
the end is reached. This is probably consistent with the filter
semantics, which is meant to *pad*, for padding+cutting the user can use
a combination of apad+atrim.
> This option is mutually exclusive with
> @option{pad_len}.
> What happens when neither of these are specified (like in your third example)?
The filter will pad forever. Now that I think at it I think that
pad_len=0 should not add any data, so it would be probably more
convenient to use -1 for "infinite". This is currently not documented
so changing it right should be safe. What do you think?
--
FFmpeg = Fostering & Foolish Mastodontic Power Enhanced Glue
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Compiling some files with DEBUG
Hi, the goal is to have av_dlog output something for the recompiled files. How are you doing it? I edit config.mak but when eg rebasing and recompiling, this may cause a lot of files to have av_dlog active and cause massive spamage. If it's not easy, could it be something like: rm make MY_FFMPEG_EXTRA_DEBUG=1 Then specific targets are used instead. Or, simpler, MY_FFMPEG_EXTRA_DEBUG="-DDEBUG=1" and have MY_FFMPEG_EXTRA_DEBUG added to CFLAGS Of course, building with MY_FFMPEG_EXTRA_DEBUG would be unsupported. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Patch] [avfilter] refactor floating point based interpolation and introduce in vf_lenscorrection
On Wed, Aug 20, 2014 at 11:54:08AM +0200, Daniel Oberhoff wrote: > > --- > Daniel Oberhoff > daniel.oberh...@gmail.com > > > > On Aug 20, 2014, at 11:47 AM, Michael Niedermayer wrote: > > > On Wed, Aug 20, 2014 at 08:14:31AM +0200, Daniel Oberhoff wrote: > >> > >> > >> Von meinem iPhone gesendet > >> > >>> Am 20.08.2014 um 03:16 schrieb Michael Niedermayer : > >>> > On Wed, Aug 20, 2014 at 12:12:49AM +0200, Daniel Oberhoff wrote: > Hello, > > As a follow-up to my last patch I now factored out the floating point > based interpolation from transform.h/transform.c and applied it in the > vf_lenscorrection filter I introduced in my last patch. What I did not > do is also factor out fixed point based interpolation as used in > vf_rotate and vf_perspective and maybe others as could probably also be > done. Also I did not look further for uses of floating point based > interpolation. Basically I just wanted to introduce interpolation in > vf_lenscorrection without code duplication. As a side note I also tried > to introduce fixed point calculations to vf_lenscorrection but found > myself effectively doing floating point “by hand” since due to the high > order of the algorithm (up to 4th order) it is very hard to keep track > of the right amount of pre/post-comma digits for a given step in the > algorithm and given parameters and it felt rather futile after a while. > >>> > Looking forward to reviews :). > >>> > >>> why did you use the deshake code and not the vf_perspective code ?! > >>> i suspect this will be quite a bit harder to get into shape for a > >>> common API > >>> > >> > >> As i Said, perspective does fixed point calculations. Also would you care > >> to ekaborate what exactly are your whoes with this API? > > > > there where further commments further down in the reply, that list > > some problems > > > > In addition, being float based is already a problem on its own, > > we dont really want it to be float based. Its very likely slower and > > its not bitexact making tests harder. > > Well, as I had outlined fixed point is not a viable option for my algorithm. blending 4 or 16 8bit samples linearly together works fine in fixed point. Please see the vf_perspective code, its exactly doing that. If you have a problem with fixed point, please show exactly where this problem is and ill try to help > > > besides a API that works 1 sample at a time redundantly recalculates > > the Coefficients for each color plane, also doing 1 sample per call > > isnt very SIMD friendly > > > > or to see this from another point of view > > what we would like to have is a SSE*/AVX* based generic resampling > > code using fixed point (with 16bit coeffs for 8bit samples for example) > > > > Theres no need to implement SSE/AVX but the API should be a step > > toward this, and the patch feels like its going the opposit direction > > this is even worse as this is common API, so other filters could > > start using this increasing the amount of code that would eventually > > be changed/updated/rewritten > > There is some contradiction in your comments. You want to move towards > vectorization (btw. how would you do that in ffmpeg? I had previously > proposed an sse version using intrinsics and builtin operators, but that was > dismissed as not being portable and I was asked to write assembly instead, > which I am not proficient in), but you want to do all planes simultanously, > even though they are far apart in memory. Imho the gain by being memory local > (which is also what you want for vectorization) far outweights the > calculation cost for the coefficients. I think you misunderstand how cpu caches work theres no reason why reading from 2 or 3 planes sequentially would be significnatly slower also i wonder if this filter shouldnt be working in RGB space. camera sensors work in RGB not YUV and correct gamma correction for interpolation also is a RGB space thing. now RGB is generally packed pixel which would avoid the multiple planes of course if someone wants to use the filter as a quick correction for a random video downloaded somewhere thats likely in YUV space [...] -- 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] [avfilter] refactor floating point based interpolation and introduce in vf_lenscorrection
--- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 20, 2014, at 12:15 PM, Michael Niedermayer wrote: > On Wed, Aug 20, 2014 at 11:54:08AM +0200, Daniel Oberhoff wrote: >> >> --- >> Daniel Oberhoff >> daniel.oberh...@gmail.com >> >> >> >> On Aug 20, 2014, at 11:47 AM, Michael Niedermayer wrote: >> >>> On Wed, Aug 20, 2014 at 08:14:31AM +0200, Daniel Oberhoff wrote: Von meinem iPhone gesendet > Am 20.08.2014 um 03:16 schrieb Michael Niedermayer : > >> On Wed, Aug 20, 2014 at 12:12:49AM +0200, Daniel Oberhoff wrote: >> Hello, >> >> As a follow-up to my last patch I now factored out the floating point >> based interpolation from transform.h/transform.c and applied it in the >> vf_lenscorrection filter I introduced in my last patch. What I did not >> do is also factor out fixed point based interpolation as used in >> vf_rotate and vf_perspective and maybe others as could probably also be >> done. Also I did not look further for uses of floating point based >> interpolation. Basically I just wanted to introduce interpolation in >> vf_lenscorrection without code duplication. As a side note I also tried >> to introduce fixed point calculations to vf_lenscorrection but found >> myself effectively doing floating point “by hand” since due to the high >> order of the algorithm (up to 4th order) it is very hard to keep track >> of the right amount of pre/post-comma digits for a given step in the >> algorithm and given parameters and it felt rather futile after a while. > >> Looking forward to reviews :). > > why did you use the deshake code and not the vf_perspective code ?! > i suspect this will be quite a bit harder to get into shape for a > common API > As i Said, perspective does fixed point calculations. Also would you care to ekaborate what exactly are your whoes with this API? >>> >>> there where further commments further down in the reply, that list >>> some problems >>> >>> In addition, being float based is already a problem on its own, >>> we dont really want it to be float based. Its very likely slower and >>> its not bitexact making tests harder. >> >> Well, as I had outlined fixed point is not a viable option for my algorithm. > > blending 4 or 16 8bit samples linearly together works fine in fixed > point. Please see the vf_perspective code, its exactly doing > that. > > If you have a problem with fixed point, please show exactly where this > problem is and ill try to help > > >> >>> besides a API that works 1 sample at a time redundantly recalculates >>> the Coefficients for each color plane, also doing 1 sample per call >>> isnt very SIMD friendly >>> >>> or to see this from another point of view >>> what we would like to have is a SSE*/AVX* based generic resampling >>> code using fixed point (with 16bit coeffs for 8bit samples for example) >>> >>> Theres no need to implement SSE/AVX but the API should be a step >>> toward this, and the patch feels like its going the opposit direction >>> this is even worse as this is common API, so other filters could >>> start using this increasing the amount of code that would eventually >>> be changed/updated/rewritten >> >> There is some contradiction in your comments. You want to move towards >> vectorization (btw. how would you do that in ffmpeg? I had previously >> proposed an sse version using intrinsics and builtin operators, but that was >> dismissed as not being portable and I was asked to write assembly instead, >> which I am not proficient in), but you want to do all planes simultanously, >> even though they are far apart in memory. Imho the gain by being memory >> local (which is also what you want for vectorization) far outweights the >> calculation cost for the coefficients. > > I think you misunderstand how cpu caches work > > theres no reason why reading from 2 or 3 planes sequentially would > be significnatly slower > also i wonder if this filter shouldnt be working in RGB space. Well, that would mean I would have to significantly rewrite my algorithm, leading to the question why this was not brought up before. > camera sensors work in RGB not YUV and correct gamma correction > for interpolation also is a RGB space thing. > now RGB is generally packed pixel which would avoid the multiple > planes But the codecs work in YUV planar, and filtering is most efficiently done there, betwen the decoder and the encoder, right? Also modern networked cameras all stream h246 and not packed RGB. > of course if someone wants to use the filter as a quick correction > for a random video downloaded somewhere thats likely in YUV space For me going to YUV made everyting around 4x faster.. Anyhow, this starts to feel a little like “perfect is the enemy of good” and would lead me to drop this refactoring and instead hack interpolation into vf_lenscorrection directly...
Re: [FFmpeg-devel] [PATCH 0/5] RGB48/64 with bits_per_raw_sample
On Wed, Aug 20, 2014 at 10:16:25AM +0200, Christophe Gisquet wrote: > Hi, > > 2014-08-20 10:10 GMT+02:00 Christophe Gisquet : > > One may argue that a proper solution is to reduce as often as possible > > references to bits_per_raw_sample and, instead, always use the > > colorspace information and to introduce new colorspaces as needed. > > I'd prefer this solution although it's a much longer road. This > requires modifying libavutil/pix* in a way that would remain > compatible with several references, so if this is the road selected, > I'd need a bit of advice here. iam happy with either, just please dont do and post both solutions as then i cannot apply either as i have to expect libav to apply the other causing conflicts Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. 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] refactor floating point based interpolation and introduce in vf_lenscorrection
>> of course if someone wants to use the filter as a quick correction >> for a random video downloaded somewhere thats likely in YUV space > > For me going to YUV made everyting around 4x faster.. And this is not for “random downloads” but a complete real-time video broadcast/archival solution with up to 4 cameras and online access via specialized tablet apps based around ffmpeg that we are currently deploying... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Compiling some files with DEBUG
On Wed, Aug 20, 2014 at 12:07:10PM +0200, Christophe Gisquet wrote: > Hi, > > the goal is to have av_dlog output something for the recompiled files. > How are you doing it? I edit config.mak but when eg rebasing and > recompiling, this may cause a lot of files to have av_dlog active and > cause massive spamage. > > If it's not easy, could it be something like: > rm > make MY_FFMPEG_EXTRA_DEBUG=1 > Then specific targets are used instead. > > Or, simpler, MY_FFMPEG_EXTRA_DEBUG="-DDEBUG=1" > and have MY_FFMPEG_EXTRA_DEBUG added to CFLAGS > > Of course, building with MY_FFMPEG_EXTRA_DEBUG would be unsupported. iam probably missing something but why not add #define DEBUG 1 to the specific file or header for which to enable av_dlog() ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Compiling some files with DEBUG
Hi, 2014-08-20 12:25 GMT+02:00 Michael Niedermayer : > iam probably missing something but why not add > #define DEBUG 1 > to the specific file or header for which to enable av_dlog() ? That's a possibility, but an example is working on aac, where you need to do this on around 4 files. Having them rebuild is easy, editing them all to add what I want is cumbersome. Editing a common header may have unintended consequences, like causing a lot more debug info. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/apad: fix logic when whole_len or pad_len options are specified
On date Tuesday 2014-08-19 01:29:42 +0200, Michael Niedermayer encoded:
> On Mon, Aug 18, 2014 at 02:53:45PM +0200, Stefano Sabatini wrote:
> > ---
> > libavfilter/af_apad.c | 29 +
> > 1 file changed, 17 insertions(+), 12 deletions(-)
>
> probably ok
With more changes.
--
FFmpeg = Fundamental Foolish Magnificient Portable Exxagerate God
>From e81a186aee715c0481df21cf982121736c67e75f Mon Sep 17 00:00:00 2001
From: Stefano Sabatini
Date: Mon, 18 Aug 2014 14:51:25 +0200
Subject: [PATCH] lavfi/apad: fix logic when whole_len or pad_len options are
specified
In particular, allow pad_len and whole_len to have value set to 0, which
means that no padding will be added. Previously a value set to 0 meant
that that the filter had to pad forever.
The new semantics is clearer, also simplifies scripting since the option
value might be automatically computed, so that no checks need to be done
in case it is 0.
The old semantics was never documented and the logic was broken (the
filter was always adding samples indefinitely), so this should not break
backward compatibility.
TODO: bump micro version
---
libavfilter/af_apad.c | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/libavfilter/af_apad.c b/libavfilter/af_apad.c
index 6b2c8b1..eafc705 100644
--- a/libavfilter/af_apad.c
+++ b/libavfilter/af_apad.c
@@ -39,17 +39,17 @@ typedef struct {
int64_t next_pts;
int packet_size;
-int64_t pad_len;
-int64_t whole_len;
+int64_t pad_len, pad_len_left;
+int64_t whole_len, whole_len_left;
} APadContext;
#define OFFSET(x) offsetof(APadContext, x)
#define A AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
static const AVOption apad_options[] = {
-{ "packet_size", "set silence packet size", OFFSET(packet_size), AV_OPT_TYPE_INT, { .i64 = 4096 }, 0, INT_MAX, A },
-{ "pad_len", "number of samples of silence to add", OFFSET(pad_len), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, A },
-{ "whole_len", "target number of samples in the audio stream", OFFSET(whole_len), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, A },
+{ "packet_size", "set silence packet size", OFFSET(packet_size), AV_OPT_TYPE_INT, { .i64 = 4096 }, 0, INT_MAX, A },
+{ "pad_len", "set number of samples of silence to add", OFFSET(pad_len), AV_OPT_TYPE_INT64, { .i64 = -1 }, -1, INT64_MAX, A },
+{ "whole_len", "set minimum target number of samples in the audio stream", OFFSET(whole_len), AV_OPT_TYPE_INT64, { .i64 = -1 }, -1, INT64_MAX, A },
{ NULL }
};
@@ -60,10 +60,12 @@ static av_cold int init(AVFilterContext *ctx)
APadContext *apad = ctx->priv;
apad->next_pts = AV_NOPTS_VALUE;
-if (apad->whole_len && apad->pad_len) {
+if (apad->whole_len >= 0 && apad->pad_len >= 0) {
av_log(ctx, AV_LOG_ERROR, "Both whole and pad length are set, this is not possible\n");
return AVERROR(EINVAL);
}
+apad->pad_len_left = apad->pad_len;
+apad->whole_len_left = apad->whole_len;
return 0;
}
@@ -73,8 +75,11 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
AVFilterContext *ctx = inlink->dst;
APadContext *apad = ctx->priv;
-if (apad->whole_len)
-apad->whole_len -= frame->nb_samples;
+if (apad->whole_len >= 0) {
+apad->whole_len_left = FFMAX(apad->whole_len_left - frame->nb_samples, 0);
+av_log(ctx, AV_LOG_DEBUG,
+ "n_out:%d whole_len_left:%"PRId64"\n", frame->nb_samples, apad->whole_len_left);
+}
apad->next_pts = frame->pts + av_rescale_q(frame->nb_samples, (AVRational){1, inlink->sample_rate}, inlink->time_base);
return ff_filter_frame(ctx->outputs[0], frame);
@@ -92,13 +97,14 @@ static int request_frame(AVFilterLink *outlink)
int n_out = apad->packet_size;
AVFrame *outsamplesref;
-if (apad->whole_len > 0) {
-apad->pad_len = apad->whole_len;
-apad->whole_len = 0;
+if (apad->whole_len >= 0 && apad->pad_len < 0) {
+apad->pad_len = apad->pad_len_left = apad->whole_len_left;
}
-if (apad->pad_len > 0) {
-n_out = FFMIN(n_out, apad->pad_len);
-apad->pad_len -= n_out;
+if (apad->pad_len >=0 || apad->whole_len >= 0) {
+n_out = FFMIN(n_out, apad->pad_len_left);
+apad->pad_len_left -= n_out;
+av_log(ctx, AV_LOG_DEBUG,
+ "padding n_out:%d pad_len_left:%"PRId64"\n", n_out, apad->pad_len_left);
}
if (!n_out)
--
1.8.3.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/filters/apad: extend documentation
On date Monday 2014-08-18 14:53:52 +0200, Stefano Sabatini encoded:
> ---
> doc/filters.texi | 47 +--
> 1 file changed, 45 insertions(+), 2 deletions(-)
Up.
--
FFmpeg = Fundamentalist & Fiendish Mega Powered Encoding/decoding Gorilla
>From 17eecedf1bcd23187deca859b377cf53323b5b1b Mon Sep 17 00:00:00 2001
From: Stefano Sabatini
Date: Mon, 18 Aug 2014 14:52:08 +0200
Subject: [PATCH] doc/filters/apad: extend documentation
---
doc/filters.texi | 51 +--
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 0ca1d6f..aa221c8 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -742,8 +742,55 @@ Pass the audio source unchanged to the output.
@section apad
-Pad the end of a audio stream with silence, this can be used together with
--shortest to extend audio streams to the same length as the video stream.
+Pad the end of an audio stream with silence.
+
+This can be used together with @command{ffmpeg} @option{-shortest} to
+extend audio streams to the same length as the video stream.
+
+A description of the accepted options follows.
+
+@table @option
+@item packet_size
+Set silence packet size. Default value is 4096.
+
+@item pad_len
+Set the number of samples of silence to add to the end. After the
+value is reached, the stream is terminated. This option is mutually
+exclusive with @option{whole_len}.
+
+@item whole_len
+Set the minimum total number of samples in the output audio stream. If
+the value is longer than the input audio length, silence is added to
+the end, until the value is reached. This option is mutually exclusive
+with @option{pad_len}.
+@end table
+
+If neither @option{pad_len} nor @option{whole_len} option is set, the
+filter will add silence to the end of the input stream indefinitely.
+
+@subsection Examples
+
+@itemize
+@item
+Add 1024 samples of silence to the end of the input:
+@example
+apad=pad_len=1024
+@end example
+
+@item
+Make sure the audio output will contain at least 1 samples, pad
+the input with silence if required:
+@example
+apad=whole_len=1
+@end example
+
+@item
+Use @command{ffmpeg} to pad the audio input with silence, so that the
+video stream will be converted in the output until the end:
+@example
+ffmpeg -i VIDEO -i AUDIO -filter_complex "[1:0]apad" -shortest OUTPUT
+@end example
+@end itemize
@section aphaser
Add a phasing effect to the input audio.
--
1.8.3.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/5] RGB48/64 with bits_per_raw_sample
Hi, 2014-08-20 12:19 GMT+02:00 Michael Niedermayer : > iam happy with either, just please dont do and post both solutions > as then i cannot apply either as i have to expect libav to apply > the other causing conflicts To summarize without aggravating anyone: I don't think I can manage both projects with this, nor developing further both solutions either. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Patch] [avfilter] refactor floating point based interpolation and introduce in vf_lenscorrection
On Wed, Aug 20, 2014 at 12:20:06PM +0200, Daniel Oberhoff wrote: > > --- > Daniel Oberhoff > daniel.oberh...@gmail.com > > > > On Aug 20, 2014, at 12:15 PM, Michael Niedermayer wrote: > > > On Wed, Aug 20, 2014 at 11:54:08AM +0200, Daniel Oberhoff wrote: > >> > >> --- > >> Daniel Oberhoff > >> daniel.oberh...@gmail.com > >> > >> > >> > >> On Aug 20, 2014, at 11:47 AM, Michael Niedermayer wrote: > >> > >>> On Wed, Aug 20, 2014 at 08:14:31AM +0200, Daniel Oberhoff wrote: > > > Von meinem iPhone gesendet > > > Am 20.08.2014 um 03:16 schrieb Michael Niedermayer : > > > >> On Wed, Aug 20, 2014 at 12:12:49AM +0200, Daniel Oberhoff wrote: > >> Hello, > >> > >> As a follow-up to my last patch I now factored out the floating point > >> based interpolation from transform.h/transform.c and applied it in the > >> vf_lenscorrection filter I introduced in my last patch. What I did not > >> do is also factor out fixed point based interpolation as used in > >> vf_rotate and vf_perspective and maybe others as could probably also > >> be done. Also I did not look further for uses of floating point based > >> interpolation. Basically I just wanted to introduce interpolation in > >> vf_lenscorrection without code duplication. As a side note I also > >> tried to introduce fixed point calculations to vf_lenscorrection but > >> found myself effectively doing floating point “by hand” since due to > >> the high order of the algorithm (up to 4th order) it is very hard to > >> keep track of the right amount of pre/post-comma digits for a given > >> step in the algorithm and given parameters and it felt rather futile > >> after a while. > > > >> Looking forward to reviews :). > > > > why did you use the deshake code and not the vf_perspective code ?! > > i suspect this will be quite a bit harder to get into shape for a > > common API > > > > As i Said, perspective does fixed point calculations. Also would you > care to ekaborate what exactly are your whoes with this API? > >>> > >>> there where further commments further down in the reply, that list > >>> some problems > >>> > >>> In addition, being float based is already a problem on its own, > >>> we dont really want it to be float based. Its very likely slower and > >>> its not bitexact making tests harder. > >> > >> Well, as I had outlined fixed point is not a viable option for my > >> algorithm. > > > > blending 4 or 16 8bit samples linearly together works fine in fixed > > point. Please see the vf_perspective code, its exactly doing > > that. > > > > If you have a problem with fixed point, please show exactly where this > > problem is and ill try to help > > > > > >> > >>> besides a API that works 1 sample at a time redundantly recalculates > >>> the Coefficients for each color plane, also doing 1 sample per call > >>> isnt very SIMD friendly > >>> > >>> or to see this from another point of view > >>> what we would like to have is a SSE*/AVX* based generic resampling > >>> code using fixed point (with 16bit coeffs for 8bit samples for example) > >>> > >>> Theres no need to implement SSE/AVX but the API should be a step > >>> toward this, and the patch feels like its going the opposit direction > >>> this is even worse as this is common API, so other filters could > >>> start using this increasing the amount of code that would eventually > >>> be changed/updated/rewritten > >> > >> There is some contradiction in your comments. You want to move towards > >> vectorization (btw. how would you do that in ffmpeg? I had previously > >> proposed an sse version using intrinsics and builtin operators, but that > >> was dismissed as not being portable and I was asked to write assembly > >> instead, which I am not proficient in), but you want to do all planes > >> simultanously, even though they are far apart in memory. Imho the gain by > >> being memory local (which is also what you want for vectorization) far > >> outweights the calculation cost for the coefficients. > > > > I think you misunderstand how cpu caches work > > > > theres no reason why reading from 2 or 3 planes sequentially would > > be significnatly slower > > also i wonder if this filter shouldnt be working in RGB space. > > Well, that would mean I would have to significantly rewrite my algorithm, > leading to the question why this was not brought up before. The only difference between a packed RGB plane and planar YUV is the step between pixels, which would be 1 for YUV planar and 3 or 4 for packed RGB thats not significantly rewriting anything the whole yuv filter code is *out++ = isvalid ? indata[y * inlinesize + x] : 0; in rgb you do *out++ = isvalid ? indata[y * inlinesize + 3*x+0] : 0; *out++ = isvalid ? indata[y * inlinesize + 3*x+1] : 0; *out++ = isvalid ? indata[y * inlinesize + 3*x+2] : 0; thats 3 lines >
Re: [FFmpeg-devel] [Patch] [avfilter] refactor floating point based interpolation and introduce in vf_lenscorrection
--- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 20, 2014, at 12:51 PM, Michael Niedermayer wrote: > On Wed, Aug 20, 2014 at 12:20:06PM +0200, Daniel Oberhoff wrote: >> >> --- >> Daniel Oberhoff >> daniel.oberh...@gmail.com >> >> >> >> On Aug 20, 2014, at 12:15 PM, Michael Niedermayer wrote: >> >>> On Wed, Aug 20, 2014 at 11:54:08AM +0200, Daniel Oberhoff wrote: --- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 20, 2014, at 11:47 AM, Michael Niedermayer wrote: > On Wed, Aug 20, 2014 at 08:14:31AM +0200, Daniel Oberhoff wrote: >> >> >> Von meinem iPhone gesendet >> >>> Am 20.08.2014 um 03:16 schrieb Michael Niedermayer : >>> On Wed, Aug 20, 2014 at 12:12:49AM +0200, Daniel Oberhoff wrote: Hello, As a follow-up to my last patch I now factored out the floating point based interpolation from transform.h/transform.c and applied it in the vf_lenscorrection filter I introduced in my last patch. What I did not do is also factor out fixed point based interpolation as used in vf_rotate and vf_perspective and maybe others as could probably also be done. Also I did not look further for uses of floating point based interpolation. Basically I just wanted to introduce interpolation in vf_lenscorrection without code duplication. As a side note I also tried to introduce fixed point calculations to vf_lenscorrection but found myself effectively doing floating point “by hand” since due to the high order of the algorithm (up to 4th order) it is very hard to keep track of the right amount of pre/post-comma digits for a given step in the algorithm and given parameters and it felt rather futile after a while. >>> Looking forward to reviews :). >>> >>> why did you use the deshake code and not the vf_perspective code ?! >>> i suspect this will be quite a bit harder to get into shape for a >>> common API >>> >> >> As i Said, perspective does fixed point calculations. Also would you >> care to ekaborate what exactly are your whoes with this API? > > there where further commments further down in the reply, that list > some problems > > In addition, being float based is already a problem on its own, > we dont really want it to be float based. Its very likely slower and > its not bitexact making tests harder. Well, as I had outlined fixed point is not a viable option for my algorithm. >>> >>> blending 4 or 16 8bit samples linearly together works fine in fixed >>> point. Please see the vf_perspective code, its exactly doing >>> that. >>> >>> If you have a problem with fixed point, please show exactly where this >>> problem is and ill try to help >>> >>> > besides a API that works 1 sample at a time redundantly recalculates > the Coefficients for each color plane, also doing 1 sample per call > isnt very SIMD friendly > > or to see this from another point of view > what we would like to have is a SSE*/AVX* based generic resampling > code using fixed point (with 16bit coeffs for 8bit samples for example) > > Theres no need to implement SSE/AVX but the API should be a step > toward this, and the patch feels like its going the opposit direction > this is even worse as this is common API, so other filters could > start using this increasing the amount of code that would eventually > be changed/updated/rewritten There is some contradiction in your comments. You want to move towards vectorization (btw. how would you do that in ffmpeg? I had previously proposed an sse version using intrinsics and builtin operators, but that was dismissed as not being portable and I was asked to write assembly instead, which I am not proficient in), but you want to do all planes simultanously, even though they are far apart in memory. Imho the gain by being memory local (which is also what you want for vectorization) far outweights the calculation cost for the coefficients. >>> >>> I think you misunderstand how cpu caches work >>> >>> theres no reason why reading from 2 or 3 planes sequentially would >>> be significnatly slower >>> also i wonder if this filter shouldnt be working in RGB space. >> >> Well, that would mean I would have to significantly rewrite my algorithm, >> leading to the question why this was not brought up before. > > The only difference between a packed RGB plane and planar YUV is > the step between pixels, which would be 1 for YUV planar and > 3 or 4 for packed RGB > > thats not significantly rewriting anything > the whole yuv filter code is > *out++ = isvalid ? indata[y * inlinesize + x] : 0; > > in rgb you do > *out++ = isvalid ? indata[y * inlinesize
Re: [FFmpeg-devel] [PATCH 1/3] avfilter/showwaves: add "center" mode.
On date Tuesday 2014-08-19 14:47:02 +0200, Clément Bœsch encoded:
> From: Clément Bœsch
>
> ---
> doc/filters.texi| 3 +++
> libavfilter/avf_showwaves.c | 24 +++-
> 2 files changed, 22 insertions(+), 5 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 0ca1d6f..828f2b4 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -10813,6 +10813,9 @@ Draw a vertical line for each sample.
>
> @item p2p
> Draw a point for each sample and a line between them.
> +
> +@item center
> +Draw a centered vertical line for each sample.
> @end table
>
> Default value is @code{point}.
> diff --git a/libavfilter/avf_showwaves.c b/libavfilter/avf_showwaves.c
> index e025663..e4911cc 100644
> --- a/libavfilter/avf_showwaves.c
> +++ b/libavfilter/avf_showwaves.c
> @@ -36,6 +36,7 @@ enum ShowWavesMode {
> MODE_POINT,
> MODE_LINE,
> MODE_P2P,
> +MODE_CENTER,
Nit: what about CENTERED_LINE, then you can use cl or cline as abbreviation.
> MODE_NB,
> };
>
> @@ -62,6 +63,7 @@ static const AVOption showwaves_options[] = {
> { "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"},
> +{ "center","draw a centered line for each sample", 0,
> AV_OPT_TYPE_CONST, {.i64=MODE_CENTER}, .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 },
> @@ -206,26 +208,30 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *insamples)
> memset(outpicref->data[0] + j * linesize, 0, outlink->w);
> }
> for (j = 0; j < nb_channels; j++) {
> -h = showwaves->h/2 - av_rescale(*p++, showwaves->h/2, MAX_INT16);
> +int start, end;
> switch (showwaves->mode) {
> case MODE_POINT:
> +h = showwaves->h/2 - av_rescale(*p++, showwaves->h/2,
> MAX_INT16);
> if (h >= 0 && h < outlink->h)
> *(outpicref->data[0] + showwaves->buf_idx + h *
> linesize) += x;
> break;
>
> case MODE_LINE:
> -{
> -int start = showwaves->h/2, end = av_clip(h, 0,
> outlink->h-1);
> +h = showwaves->h/2 - av_rescale(*p++, showwaves->h/2,
> MAX_INT16);
> +start = showwaves->h/2;
> +end = av_clip(h, 0, outlink->h-1);
> if (start > end) FFSWAP(int16_t, start, end);
> for (k = start; k < end; k++)
> *(outpicref->data[0] + showwaves->buf_idx + k *
> linesize) += x;
> break;
> -}
> +
> case MODE_P2P:
> +h = showwaves->h/2 - av_rescale(*p++, showwaves->h/2,
> MAX_INT16);
> 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);
> +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++)
> @@ -233,6 +239,14 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *insamples)
> }
> }
> break;
> +
> +case MODE_CENTER:
> +h = av_rescale(abs(*p++), showwaves->h, UINT16_MAX);
> +start = (showwaves->h - h) / 2;
> +end = start + h;
> +for (k = start; 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;
LGTM otherwise, thanks.
--
FFmpeg = Friendly Fierce Moronic Peaceless Extroverse Gigant
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avfilter/showwaves: split out draw sample code.
On date Tuesday 2014-08-19 14:47:03 +0200, Clément Bœsch encoded: > From: Clément Bœsch > > --- > libavfilter/avf_showwaves.c | 119 > +++- > 1 file changed, 74 insertions(+), 45 deletions(-) [...] LGTM as well. -- FFmpeg = Freak and Fancy Monstrous Powerful Encoding/decoding Gymnast ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avfilter/showwaves: add split_channels option.
On date Tuesday 2014-08-19 14:47:04 +0200, Clément Bœsch encoded: > From: Clément Bœsch > > --- > doc/filters.texi| 3 +++ > libavfilter/avf_showwaves.c | 14 ++ > 2 files changed, 13 insertions(+), 4 deletions(-) LGTM, thanks. (Please bump micro when pushing). -- FFmpeg = Fostering & Foolish Multipurpose Pitiless Evil Guide ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add codecview filter
On date Monday 2014-08-18 18:03:39 +0200, Clément Bœsch encoded:
> From: Clément Bœsch
>
> ---
> Note: I didn't use FF_API_DEBUG_MV because it seems to overlap with all
> kind of other things and I couldn't test properly the conditional
> compilation.
>
> BTW, I could add a FATE test easily, but I didn't find any relevant
> samples available.
>
> TODO: minor bump avfilter, micro bump avcodec
> ---
> Changelog | 1 +
> RELEASE_NOTES | 2 +
> doc/filters.texi | 36 +++
> libavcodec/mpegvideo.c | 13 ++-
> libavcodec/options_table.h | 4 +-
> libavcodec/utils.c | 6 ++
> libavcodec/version.h | 4 +
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/vf_codecview.c | 241
> +
> 10 files changed, 305 insertions(+), 4 deletions(-)
> create mode 100644 libavfilter/vf_codecview.c
[...]
> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
> index 7000531..ad3d52e 100644
> --- a/libavcodec/options_table.h
> +++ b/libavcodec/options_table.h
> @@ -262,10 +262,12 @@ static const AVOption avcodec_options[] = {
> {"buffers", "picture buffer allocations", 0, AV_OPT_TYPE_CONST, {.i64 =
> FF_DEBUG_BUFFERS }, INT_MIN, INT_MAX, V|D, "debug"},
> {"thread_ops", "threading operations", 0, AV_OPT_TYPE_CONST, {.i64 =
> FF_DEBUG_THREADS }, INT_MIN, INT_MAX, V|A|D, "debug"},
> {"nomc", "skip motion compensation", 0, AV_OPT_TYPE_CONST, {.i64 =
> FF_DEBUG_NOMC }, INT_MIN, INT_MAX, V|A|D, "debug"},
> -{"vismv", "visualize motion vectors (MVs)", OFFSET(debug_mv),
> AV_OPT_TYPE_FLAGS, {.i64 = DEFAULT }, 0, INT_MAX, V|D, "debug_mv"},
> +#if FF_API_VISMV
> +{"vismv", "visualize motion vectors (MVs) (deprecated)", OFFSET(debug_mv),
> AV_OPT_TYPE_FLAGS, {.i64 = DEFAULT }, 0, INT_MAX, V|D, "debug_mv"},
> {"pf", "forward predicted MVs of P-frames", 0, AV_OPT_TYPE_CONST, {.i64 =
> FF_DEBUG_VIS_MV_P_FOR }, INT_MIN, INT_MAX, V|D, "debug_mv"},
> {"bf", "forward predicted MVs of B-frames", 0, AV_OPT_TYPE_CONST, {.i64 =
> FF_DEBUG_VIS_MV_B_FOR }, INT_MIN, INT_MAX, V|D, "debug_mv"},
> {"bb", "backward predicted MVs of B-frames", 0, AV_OPT_TYPE_CONST, {.i64 =
> FF_DEBUG_VIS_MV_B_BACK }, INT_MIN, INT_MAX, V|D, "debug_mv"},
> +#endif
Note: you may mention that the option is deprecated in ffmpeg-codecs.
> {"cmp", "full-pel ME compare function", OFFSET(me_cmp), AV_OPT_TYPE_INT,
> {.i64 = DEFAULT }, INT_MIN, INT_MAX, V|E, "cmp_func"},
> {"subcmp", "sub-pel ME compare function", OFFSET(me_sub_cmp),
> AV_OPT_TYPE_INT, {.i64 = DEFAULT }, INT_MIN, INT_MAX, V|E, "cmp_func"},
> {"mbcmp", "macroblock compare function", OFFSET(mb_cmp), AV_OPT_TYPE_INT,
> {.i64 = DEFAULT }, INT_MIN, INT_MAX, V|E, "cmp_func"},
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 6a40a03..70f5734 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -1435,6 +1435,12 @@ int attribute_align_arg avcodec_open2(AVCodecContext
> *avctx, const AVCodec *code
> goto free_and_end;
> }
>
> +#if FF_API_VISMV
> +if (avctx->debug_mv)
> +av_log(avctx, AV_LOG_WARNING, "The 'vismv' option is deprecated, "
> + "see the codecview filter instead:
> http://ffmpeg.org/ffmpeg-filters.html#codecview\n";);
Please don't use links in code, as we don't want to update them (and
the user may have no Internet connectivity or no browser).
[...]
> diff --git a/libavfilter/vf_codecview.c b/libavfilter/vf_codecview.c
> new file mode 100644
> index 000..5749631
> --- /dev/null
> +++ b/libavfilter/vf_codecview.c
> @@ -0,0 +1,241 @@
> +/*
> + * Copyright (c) 2002-2004 Michael Niedermayer
> + * Copyright (c) 2014 Clément Bœsch
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +/**
> + * @file
> + * Codec debug viewer filter.
Please mention the file from which the code was taken
(libavcodec/mpegvideo.c).
> + *
> + * TODO: segmentation
> + * TODO: quantization
> + */
> +
[...]
LGTM, thanks.
--
FFmpeg = Fanciful and Freak Monstrous Political Ecumenical Genius
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinf
[FFmpeg-devel] [PATCH 1/3] avfilter/vf_lenscorrection: get rid of some floats
---
libavfilter/vf_lenscorrection.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/libavfilter/vf_lenscorrection.c b/libavfilter/vf_lenscorrection.c
index f4b1676..048820c 100644
--- a/libavfilter/vf_lenscorrection.c
+++ b/libavfilter/vf_lenscorrection.c
@@ -56,9 +56,9 @@ AVFILTER_DEFINE_CLASS(lenscorrection);
typedef struct ThreadData {
AVFrame *in, *out;
-float w, h;
+int w, h;
int plane;
-float xcenter, ycenter;
+int xcenter, ycenter;
float k1, k2;
} ThreadData;
@@ -68,9 +68,9 @@ static int filter_slice(AVFilterContext *ctx, void *arg, int
job, int nb_jobs)
AVFrame *in = td->in;
AVFrame *out = td->out;
-const float w = td->w, h = td->h;
-const float xcenter = td->xcenter;
-const float ycenter = td->ycenter;
+const int w = td->w, h = td->h;
+const int xcenter = td->xcenter;
+const int ycenter = td->ycenter;
const float r2inv = 4.0 / (w * w + h * h);
const float k1 = td->k1;
const float k2 = td->k2;
@@ -83,12 +83,12 @@ static int filter_slice(AVFilterContext *ctx, void *arg,
int job, int nb_jobs)
uint8_t *outrow = out->data[plane] + start * outlinesize;
int i;
for (i = start; i < end; i++, outrow += outlinesize) {
-const float off_y = i - ycenter;
-const float off_y2 = off_y * off_y;
+const int off_y = i - ycenter;
+const int off_y2 = off_y * off_y;
uint8_t *out = outrow;
int j;
for (j = 0; j < w; j++) {
-const float off_x = j - xcenter;
+const int off_x = j - xcenter;
const float r2 = (off_x * off_x + off_y2) * r2inv;
const float radius_mult = 1.0f + r2 * k1 + r2 * r2 * k2;
const int x = xcenter + radius_mult * off_x + 0.5f;
@@ -147,10 +147,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
for (plane = 0; plane < rect->nb_planes; ++plane) {
int hsub = plane == 1 || plane == 2 ? rect->hsub : 0;
int vsub = plane == 1 || plane == 2 ? rect->vsub : 0;
-float hdiv = 1 << hsub;
-float vdiv = 1 << vsub;
-float w = rect->width / hdiv;
-float h = rect->height / vdiv;
+int hdiv = 1 << hsub;
+int vdiv = 1 << vsub;
+int w = rect->width / hdiv;
+int h = rect->height / vdiv;
ThreadData td = {
.in = in,
.out = out,
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avfilter/vf_lenscorrection: get rid of all floats per frame
there are some still left for 1 time initialization
Signed-off-by: Michael Niedermayer
---
libavfilter/vf_lenscorrection.c | 45 ---
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/libavfilter/vf_lenscorrection.c b/libavfilter/vf_lenscorrection.c
index 048820c..11fa4c8 100644
--- a/libavfilter/vf_lenscorrection.c
+++ b/libavfilter/vf_lenscorrection.c
@@ -41,6 +41,7 @@ typedef struct LenscorrectionCtx {
int hsub, vsub;
int nb_planes;
double cx, cy, k1, k2;
+int32_t *correction[4];
} LenscorrectionCtx;
#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
@@ -59,7 +60,7 @@ typedef struct ThreadData {
int w, h;
int plane;
int xcenter, ycenter;
-float k1, k2;
+int32_t *correction;
} ThreadData;
static int filter_slice(AVFilterContext *ctx, void *arg, int job, int nb_jobs)
@@ -71,9 +72,6 @@ static int filter_slice(AVFilterContext *ctx, void *arg, int
job, int nb_jobs)
const int w = td->w, h = td->h;
const int xcenter = td->xcenter;
const int ycenter = td->ycenter;
-const float r2inv = 4.0 / (w * w + h * h);
-const float k1 = td->k1;
-const float k2 = td->k2;
const int start = (h * job ) / nb_jobs;
const int end = (h * (job+1)) / nb_jobs;
const int plane = td->plane;
@@ -84,15 +82,13 @@ static int filter_slice(AVFilterContext *ctx, void *arg,
int job, int nb_jobs)
int i;
for (i = start; i < end; i++, outrow += outlinesize) {
const int off_y = i - ycenter;
-const int off_y2 = off_y * off_y;
uint8_t *out = outrow;
int j;
for (j = 0; j < w; j++) {
const int off_x = j - xcenter;
-const float r2 = (off_x * off_x + off_y2) * r2inv;
-const float radius_mult = 1.0f + r2 * k1 + r2 * r2 * k2;
-const int x = xcenter + radius_mult * off_x + 0.5f;
-const int y = ycenter + radius_mult * off_y + 0.5f;
+const int64_t radius_mult = td->correction[j + i*w];
+const int x = xcenter + ((radius_mult * off_x + (1<<23))>>24);
+const int y = ycenter + ((radius_mult * off_y + (1<<23))>>24);
const char isvalid = x > 0 && x < w - 1 && y > 0 && y < h - 1;
*out++ = isvalid ? indata[y * inlinesize + x] : 0;
}
@@ -151,16 +147,39 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
int vdiv = 1 << vsub;
int w = rect->width / hdiv;
int h = rect->height / vdiv;
+int xcenter = rect->cx * w;
+int ycenter = rect->cy * h;
+float k1 = rect->k1;
+float k2 = rect->k2;
ThreadData td = {
.in = in,
.out = out,
.w = w,
.h = h,
-.xcenter = rect->cx * w,
-.ycenter = rect->cy * h,
-.k1 = rect->k1,
-.k2 = rect->k2,
+.xcenter = xcenter,
+.ycenter = ycenter,
.plane = plane};
+
+if (!rect->correction[plane]) {
+int i,j;
+const float r2inv = 4.0 / (w * w + h * h);
+
+rect->correction[plane] = av_malloc_array(w, h *
sizeof(**rect->correction));
+if (!rect->correction[plane])
+return AVERROR(ENOMEM);
+for (j = 0; j < h; j++) {
+const int off_y = j - ycenter;
+const int off_y2 = off_y * off_y;
+for (i = 0; i < w; i++) {
+const int off_x = i - xcenter;
+const float r2 = (off_x * off_x + off_y2) * r2inv;
+const float radius_mult = 1.0f + r2 * k1 + r2 * r2 * k2;
+rect->correction[plane][j * w + i] = lrintf(radius_mult *
(1<<24));
+}
+}
+}
+
+td.correction = rect->correction[plane];
ctx->internal->execute(ctx, filter_slice, &td, NULL, FFMIN(h,
ctx->graph->nb_threads));
}
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avfilter/vf_lenscorrection: get rid of floats i init code
The only remaining floats are in the user interface, they are left as they
should not cause a problem in practice
---
libavfilter/vf_lenscorrection.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/libavfilter/vf_lenscorrection.c b/libavfilter/vf_lenscorrection.c
index 11fa4c8..d30a81b 100644
--- a/libavfilter/vf_lenscorrection.c
+++ b/libavfilter/vf_lenscorrection.c
@@ -149,8 +149,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
int h = rect->height / vdiv;
int xcenter = rect->cx * w;
int ycenter = rect->cy * h;
-float k1 = rect->k1;
-float k2 = rect->k2;
+int k1 = rect->k1 * (1<<24);
+int k2 = rect->k2 * (1<<24);
ThreadData td = {
.in = in,
.out = out,
@@ -162,7 +162,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
if (!rect->correction[plane]) {
int i,j;
-const float r2inv = 4.0 / (w * w + h * h);
+const int64_t r2inv = (4LL<<60) / (w * w + h * h);
rect->correction[plane] = av_malloc_array(w, h *
sizeof(**rect->correction));
if (!rect->correction[plane])
@@ -172,9 +172,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
const int off_y2 = off_y * off_y;
for (i = 0; i < w; i++) {
const int off_x = i - xcenter;
-const float r2 = (off_x * off_x + off_y2) * r2inv;
-const float radius_mult = 1.0f + r2 * k1 + r2 * r2 * k2;
-rect->correction[plane][j * w + i] = lrintf(radius_mult *
(1<<24));
+const int64_t r2 = ((off_x * off_x + off_y2) * r2inv +
(1LL<<31)) >> 32;
+const int64_t r4 = (r2 * r2 + (1<<27)) >> 28;
+const int radius_mult = (r2 * k1 + r4 * k2 + (1LL<<27) +
(1LL<<52))>>28;
+rect->correction[plane][j * w + i] = radius_mult;
}
}
}
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Patch] [avfilter] refactor floating point based interpolation and introduce in vf_lenscorrection
On Wed, Aug 20, 2014 at 01:00:29PM +0200, Daniel Oberhoff wrote: [...] > > > > > >> > >>> of course if someone wants to use the filter as a quick correction > >>> for a random video downloaded somewhere thats likely in YUV space > >> > >> For me going to YUV made everyting around 4x faster.. > >> > >> Anyhow, this starts to feel a little like “perfect is the enemy of good” > >> and would lead me to drop this refactoring and instead hack interpolation > >> into vf_lenscorrection directly... > > > > what you write sounds a bit like you try to avoid making any > > improvments to the filter. Not sure i understand that > > > > Of course its work to add rgb support, of course its work to get > > I can do this, I simply did not understand that all this was about that. > > > gamma correction right, of course its work to implement a fixed point > > bicubic filter, … > > this will not help me at all, since the filter can not use fixed point. I > would rather leave this to someone who is more motivated. patchset posted that removes floats from the filter and makes it fixed point i think its better if further work is based on it and doesnt introduce more floats, that is if my patchset is ok for you ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_lenscorrection: get rid of floats i init code
So we prefer int64_t above float32? I assumed we stick with 32bits for
calculations. Did you test this with very large resolutions? I so
congratulation :). I am glad I could push you to finish what I failed to do :).
As I would still like to have interpolation, I assume I shall refactor the
interpolation out of perspective and rotation instead, right? Or should I just
make yet anothe impl inside the lenscorrection code?.
---
Daniel Oberhoff
daniel.oberh...@gmail.com
On Aug 20, 2014, at 2:17 PM, Michael Niedermayer wrote:
> The only remaining floats are in the user interface, they are left as they
> should not cause a problem in practice
> ---
> libavfilter/vf_lenscorrection.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/libavfilter/vf_lenscorrection.c b/libavfilter/vf_lenscorrection.c
> index 11fa4c8..d30a81b 100644
> --- a/libavfilter/vf_lenscorrection.c
> +++ b/libavfilter/vf_lenscorrection.c
> @@ -149,8 +149,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
> int h = rect->height / vdiv;
> int xcenter = rect->cx * w;
> int ycenter = rect->cy * h;
> -float k1 = rect->k1;
> -float k2 = rect->k2;
> +int k1 = rect->k1 * (1<<24);
> +int k2 = rect->k2 * (1<<24);
> ThreadData td = {
> .in = in,
> .out = out,
> @@ -162,7 +162,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
>
> if (!rect->correction[plane]) {
> int i,j;
> -const float r2inv = 4.0 / (w * w + h * h);
> +const int64_t r2inv = (4LL<<60) / (w * w + h * h);
>
> rect->correction[plane] = av_malloc_array(w, h *
> sizeof(**rect->correction));
> if (!rect->correction[plane])
> @@ -172,9 +172,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *in)
> const int off_y2 = off_y * off_y;
> for (i = 0; i < w; i++) {
> const int off_x = i - xcenter;
> -const float r2 = (off_x * off_x + off_y2) * r2inv;
> -const float radius_mult = 1.0f + r2 * k1 + r2 * r2 * k2;
> -rect->correction[plane][j * w + i] = lrintf(radius_mult
> * (1<<24));
> +const int64_t r2 = ((off_x * off_x + off_y2) * r2inv +
> (1LL<<31)) >> 32;
> +const int64_t r4 = (r2 * r2 + (1<<27)) >> 28;
> +const int radius_mult = (r2 * k1 + r4 * k2 + (1LL<<27) +
> (1LL<<52))>>28;
> +rect->correction[plane][j * w + i] = radius_mult;
> }
> }
> }
> --
> 1.7.9.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 3/3] avfilter/vf_lenscorrection: get rid of floats i init code
On Wed, Aug 20, 2014 at 02:23:10PM +0200, Daniel Oberhoff wrote: > So we prefer int64_t above float32? well, its not exactly making me happy either but its just 2 32x32->64 operations per pixel which shouldnt be that bad when we need to do 16 multiplications for bicubic per sample also at the expense of a bit more space they could be precalculated as they dont change between frames > I assumed we stick with 32bits for calculations. Did you test this with very > large resolutions? just tried: ./ffplay -f lavfi -i testsrc=s=16385x8192 -vf lenscorrection=0.3:0.2:0.2:0.9,scale=640x48 which seems working > I so congratulation :). I am glad I could push you to finish what I failed to > do :). > > As I would still like to have interpolation, I assume I shall refactor the > interpolation out of perspective and rotation instead, right? yes, please do thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_lenscorrection: get rid of floats i init code
--- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 20, 2014, at 2:33 PM, Michael Niedermayer wrote: > On Wed, Aug 20, 2014 at 02:23:10PM +0200, Daniel Oberhoff wrote: >> So we prefer int64_t above float32? > > well, its not exactly making me happy either but its just 2 32x32->64 > operations per pixel which shouldnt be that bad when we need to do > 16 multiplications for bicubic per sample > also at the expense of a bit more space they could be precalculated > as they dont change between frames > > >> I assumed we stick with 32bits for calculations. Did you test this with very >> large resolutions? > > just tried: > ./ffplay -f lavfi -i testsrc=s=16385x8192 -vf > lenscorrection=0.3:0.2:0.2:0.9,scale=640x48 > which seems working > > >> I so congratulation :). I am glad I could push you to finish what I failed >> to do :). >> >> As I would still like to have interpolation, I assume I shall refactor the >> interpolation out of perspective and rotation instead, right? Ok, but by default I would only refactor so far as to support all use cases currently in perspective/rotate/lens_correction, and none more. Do you still think there should be a version/versions of the algorithm for packed formats? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_lenscorrection: get rid of floats i init code
---
Daniel Oberhoff
daniel.oberh...@gmail.com
On Aug 20, 2014, at 2:17 PM, Michael Niedermayer wrote:
> The only remaining floats are in the user interface, they are left as they
> should not cause a problem in practice
> ---
> libavfilter/vf_lenscorrection.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/libavfilter/vf_lenscorrection.c b/libavfilter/vf_lenscorrection.c
> index 11fa4c8..d30a81b 100644
> --- a/libavfilter/vf_lenscorrection.c
> +++ b/libavfilter/vf_lenscorrection.c
> @@ -149,8 +149,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
> int h = rect->height / vdiv;
> int xcenter = rect->cx * w;
> int ycenter = rect->cy * h;
> -float k1 = rect->k1;
> -float k2 = rect->k2;
> +int k1 = rect->k1 * (1<<24);
> +int k2 = rect->k2 * (1<<24);
> ThreadData td = {
> .in = in,
> .out = out,
> @@ -162,7 +162,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
>
> if (!rect->correction[plane]) {
> int i,j;
> -const float r2inv = 4.0 / (w * w + h * h);
> +const int64_t r2inv = (4LL<<60) / (w * w + h * h);
>
> rect->correction[plane] = av_malloc_array(w, h *
> sizeof(**rect->correction));
> if (!rect->correction[plane])
> @@ -172,9 +172,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *in)
> const int off_y2 = off_y * off_y;
> for (i = 0; i < w; i++) {
> const int off_x = i - xcenter;
> -const float r2 = (off_x * off_x + off_y2) * r2inv;
> -const float radius_mult = 1.0f + r2 * k1 + r2 * r2 * k2;
> -rect->correction[plane][j * w + i] = lrintf(radius_mult
> * (1<<24));
> +const int64_t r2 = ((off_x * off_x + off_y2) * r2inv +
> (1LL<<31)) >> 32;
won’t this potentially overflow for large off_x if int is 32bit? (same above
for off_y2)
> +const int64_t r4 = (r2 * r2 + (1<<27)) >> 28;
> +const int radius_mult = (r2 * k1 + r4 * k2 + (1LL<<27) +
> (1LL<<52))>>28;
> +rect->correction[plane][j * w + i] = radius_mult;
> }
> }
> }
> --
> 1.7.9.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 3/3] avfilter/vf_lenscorrection: get rid of floats i init code
On Wed, Aug 20, 2014 at 02:42:35PM +0200, Daniel Oberhoff wrote:
>
> ---
> Daniel Oberhoff
> daniel.oberh...@gmail.com
>
>
>
> On Aug 20, 2014, at 2:17 PM, Michael Niedermayer wrote:
>
> > The only remaining floats are in the user interface, they are left as they
> > should not cause a problem in practice
> > ---
> > libavfilter/vf_lenscorrection.c | 13 +++--
> > 1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavfilter/vf_lenscorrection.c
> > b/libavfilter/vf_lenscorrection.c
> > index 11fa4c8..d30a81b 100644
> > --- a/libavfilter/vf_lenscorrection.c
> > +++ b/libavfilter/vf_lenscorrection.c
> > @@ -149,8 +149,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> > *in)
> > int h = rect->height / vdiv;
> > int xcenter = rect->cx * w;
> > int ycenter = rect->cy * h;
> > -float k1 = rect->k1;
> > -float k2 = rect->k2;
> > +int k1 = rect->k1 * (1<<24);
> > +int k2 = rect->k2 * (1<<24);
> > ThreadData td = {
> > .in = in,
> > .out = out,
> > @@ -162,7 +162,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> > *in)
> >
> > if (!rect->correction[plane]) {
> > int i,j;
> > -const float r2inv = 4.0 / (w * w + h * h);
> > +const int64_t r2inv = (4LL<<60) / (w * w + h * h);
> >
> > rect->correction[plane] = av_malloc_array(w, h *
> > sizeof(**rect->correction));
> > if (!rect->correction[plane])
> > @@ -172,9 +172,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> > *in)
> > const int off_y2 = off_y * off_y;
> > for (i = 0; i < w; i++) {
> > const int off_x = i - xcenter;
> > -const float r2 = (off_x * off_x + off_y2) * r2inv;
> > -const float radius_mult = 1.0f + r2 * k1 + r2 * r2 *
> > k2;
> > -rect->correction[plane][j * w + i] =
> > lrintf(radius_mult * (1<<24));
> > +const int64_t r2 = ((off_x * off_x + off_y2) * r2inv +
> > (1LL<<31)) >> 32;
>
> won’t this potentially overflow for large off_x if int is 32bit? (same above
> for off_y2)
yes, with images somewhere around 32k X 32k there will be problems
but images in that size range arent very well supported when pixels
are addressed by int, which they are all over the codebase
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_lenscorrection: get rid of floats i init code
On Wed, Aug 20, 2014 at 02:36:29PM +0200, Daniel Oberhoff wrote: > > --- > Daniel Oberhoff > daniel.oberh...@gmail.com > > > > On Aug 20, 2014, at 2:33 PM, Michael Niedermayer wrote: > > > On Wed, Aug 20, 2014 at 02:23:10PM +0200, Daniel Oberhoff wrote: > >> So we prefer int64_t above float32? > > > > well, its not exactly making me happy either but its just 2 32x32->64 > > operations per pixel which shouldnt be that bad when we need to do > > 16 multiplications for bicubic per sample > > also at the expense of a bit more space they could be precalculated > > as they dont change between frames > > > > > >> I assumed we stick with 32bits for calculations. Did you test this with > >> very large resolutions? > > > > just tried: > > ./ffplay -f lavfi -i testsrc=s=16385x8192 -vf > > lenscorrection=0.3:0.2:0.2:0.9,scale=640x48 > > which seems working > > > > > >> I so congratulation :). I am glad I could push you to finish what I failed > >> to do :). > >> > >> As I would still like to have interpolation, I assume I shall refactor the > >> interpolation out of perspective and rotation instead, right? > > Ok, but by default I would only refactor so far as to support all use cases > currently in perspective/rotate/lens_correction, and none more. sure > Do you still think there should be a version/versions of the algorithm for > packed formats? i think if we want to add gamma correct interpolation then yes otherwise its probably not worth the work thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. 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] avfilter/vf_lenscorrection: get rid of floats i init code
---
Daniel Oberhoff
daniel.oberh...@gmail.com
On Aug 20, 2014, at 2:54 PM, Michael Niedermayer wrote:
> On Wed, Aug 20, 2014 at 02:42:35PM +0200, Daniel Oberhoff wrote:
>>
>> ---
>> Daniel Oberhoff
>> daniel.oberh...@gmail.com
>>
>>
>>
>> On Aug 20, 2014, at 2:17 PM, Michael Niedermayer wrote:
>>
>>> The only remaining floats are in the user interface, they are left as they
>>> should not cause a problem in practice
>>> ---
>>> libavfilter/vf_lenscorrection.c | 13 +++--
>>> 1 file changed, 7 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/libavfilter/vf_lenscorrection.c
>>> b/libavfilter/vf_lenscorrection.c
>>> index 11fa4c8..d30a81b 100644
>>> --- a/libavfilter/vf_lenscorrection.c
>>> +++ b/libavfilter/vf_lenscorrection.c
>>> @@ -149,8 +149,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
>>> *in)
>>>int h = rect->height / vdiv;
>>>int xcenter = rect->cx * w;
>>>int ycenter = rect->cy * h;
>>> -float k1 = rect->k1;
>>> -float k2 = rect->k2;
>>> +int k1 = rect->k1 * (1<<24);
>>> +int k2 = rect->k2 * (1<<24);
>>>ThreadData td = {
>>>.in = in,
>>>.out = out,
>>> @@ -162,7 +162,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
>>> *in)
>>>
>>>if (!rect->correction[plane]) {
>>>int i,j;
>>> -const float r2inv = 4.0 / (w * w + h * h);
>>> +const int64_t r2inv = (4LL<<60) / (w * w + h * h);
>>>
>>>rect->correction[plane] = av_malloc_array(w, h *
>>> sizeof(**rect->correction));
>>>if (!rect->correction[plane])
>>> @@ -172,9 +172,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
>>> *in)
>>>const int off_y2 = off_y * off_y;
>>>for (i = 0; i < w; i++) {
>>>const int off_x = i - xcenter;
>>> -const float r2 = (off_x * off_x + off_y2) * r2inv;
>>> -const float radius_mult = 1.0f + r2 * k1 + r2 * r2 *
>>> k2;
>>> -rect->correction[plane][j * w + i] =
>>> lrintf(radius_mult * (1<<24));
>>> +const int64_t r2 = ((off_x * off_x + off_y2) * r2inv +
>>> (1LL<<31)) >> 32;
>>
>> won’t this potentially overflow for large off_x if int is 32bit? (same above
>> for off_y2)
>
> yes, with images somewhere around 32k X 32k there will be problems
> but images in that size range arent very well supported when pixels
> are addressed by int, which they are all over the codebase
Ok, get it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/hevc_ps: do cleanup in case of unsupported bit depth
On Wed, Aug 20, 2014 at 09:26:56AM +0200, Mickaël Raulet wrote: > Ok. > > Mickael > > Le mercredi 20 août 2014, Timothy Gu a écrit : > > > On Tue, Aug 19, 2014 at 6:49 PM, Michael Niedermayer > > wrote: > > > Fixes memleak > > > Fixes CID1231989 > > > > > > Signed-off-by: Michael Niedermayer > > > > --- > > > libavcodec/hevc_ps.c |3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > Looks OK. applied Thanks to both of you [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 3 "Rare item" - "Common item with rare defect or maybe just a lie" "Professional" - "'Toy' made in china, not functional except as doorstop" "Experts will know" - "The seller hopes you are not an expert" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_lenscorrection: get rid of floats i init code
--- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 20, 2014, at 2:55 PM, Michael Niedermayer wrote: > On Wed, Aug 20, 2014 at 02:36:29PM +0200, Daniel Oberhoff wrote: >> >> --- >> Daniel Oberhoff >> daniel.oberh...@gmail.com >> >> >> >> On Aug 20, 2014, at 2:33 PM, Michael Niedermayer wrote: >> >>> On Wed, Aug 20, 2014 at 02:23:10PM +0200, Daniel Oberhoff wrote: So we prefer int64_t above float32? >>> >>> well, its not exactly making me happy either but its just 2 32x32->64 >>> operations per pixel which shouldnt be that bad when we need to do >>> 16 multiplications for bicubic per sample >>> also at the expense of a bit more space they could be precalculated >>> as they dont change between frames >>> >>> I assumed we stick with 32bits for calculations. Did you test this with very large resolutions? >>> >>> just tried: >>> ./ffplay -f lavfi -i testsrc=s=16385x8192 -vf >>> lenscorrection=0.3:0.2:0.2:0.9,scale=640x48 >>> which seems working >>> >>> I so congratulation :). I am glad I could push you to finish what I failed to do :). As I would still like to have interpolation, I assume I shall refactor the interpolation out of perspective and rotation instead, right? >> >> Ok, but by default I would only refactor so far as to support all use cases >> currently in perspective/rotate/lens_correction, and none more. > > sure > > >> Do you still think there should be a version/versions of the algorithm for >> packed formats? > > i think if we want to add gamma correct interpolation then yes > otherwise its probably not worth the work to be honest: I have no idea about that, do you have pointers for that? I.e. what it is, how it works, when it is needed, how it correlates with the image representation (i.e. yuv vs rgb, compressed vs full, etc)? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_lenscorrection: get rid of floats i init code
On Wed, Aug 20, 2014 at 02:58:50PM +0200, Daniel Oberhoff wrote: > > --- > Daniel Oberhoff > daniel.oberh...@gmail.com > > > > On Aug 20, 2014, at 2:55 PM, Michael Niedermayer wrote: > > > On Wed, Aug 20, 2014 at 02:36:29PM +0200, Daniel Oberhoff wrote: > >> > >> --- > >> Daniel Oberhoff > >> daniel.oberh...@gmail.com > >> > >> > >> > >> On Aug 20, 2014, at 2:33 PM, Michael Niedermayer wrote: > >> > >>> On Wed, Aug 20, 2014 at 02:23:10PM +0200, Daniel Oberhoff wrote: > So we prefer int64_t above float32? > >>> > >>> well, its not exactly making me happy either but its just 2 32x32->64 > >>> operations per pixel which shouldnt be that bad when we need to do > >>> 16 multiplications for bicubic per sample > >>> also at the expense of a bit more space they could be precalculated > >>> as they dont change between frames > >>> > >>> > I assumed we stick with 32bits for calculations. Did you test this with > very large resolutions? > >>> > >>> just tried: > >>> ./ffplay -f lavfi -i testsrc=s=16385x8192 -vf > >>> lenscorrection=0.3:0.2:0.2:0.9,scale=640x48 > >>> which seems working > >>> > >>> > I so congratulation :). I am glad I could push you to finish what I > failed to do :). > > As I would still like to have interpolation, I assume I shall refactor > the interpolation out of perspective and rotation instead, right? > >> > >> Ok, but by default I would only refactor so far as to support all use > >> cases currently in perspective/rotate/lens_correction, and none more. > > > > sure > > > > > >> Do you still think there should be a version/versions of the algorithm for > >> packed formats? > > > > i think if we want to add gamma correct interpolation then yes > > otherwise its probably not worth the work > > to be honest: I have no idea about that, do you have pointers for that? I.e. > what it is, how it works, when it is needed, how it correlates with the image > representation (i.e. yuv vs rgb, compressed vs full, etc)? its very simple normal every day 8bit per sample rgb and yuv are not "linear", in the sense that twice the number of photons does not equal twice the integer value for , lets say red or y but interpolation, be that bilinear or bicubic assumes that it is so so it would be needed to first get linear rgb (which needs more than 8bits per sample to look good) then interpolate in that and then to convert back to everyday gamma corrected 8bit per sample rgb in principle these correction steps could be done by seperate filters and RGB48 could be used in vf_lenscorrection then vf_lenscorrection would not need to know about any of that [...] -- 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] lavfi/apad: fix logic when whole_len or pad_len options are specified
On Wed, Aug 20, 2014 at 12:43:22PM +0200, Stefano Sabatini wrote: > On date Tuesday 2014-08-19 01:29:42 +0200, Michael Niedermayer encoded: > > On Mon, Aug 18, 2014 at 02:53:45PM +0200, Stefano Sabatini wrote: > > > --- > > > libavfilter/af_apad.c | 29 + > > > 1 file changed, 17 insertions(+), 12 deletions(-) > > > > probably ok > > With more changes. > -- > FFmpeg = Fundamental Foolish Magnificient Portable Exxagerate God > af_apad.c | 34 -- > 1 file changed, 20 insertions(+), 14 deletions(-) > a953355f7237c81362322baa549621a35a92d537 > 0001-lavfi-apad-fix-logic-when-whole_len-or-pad_len-optio.patch > From e81a186aee715c0481df21cf982121736c67e75f Mon Sep 17 00:00:00 2001 > From: Stefano Sabatini > Date: Mon, 18 Aug 2014 14:51:25 +0200 > Subject: [PATCH] lavfi/apad: fix logic when whole_len or pad_len options are > specified probably still ok [...] -- 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 3/3] avfilter/vf_lenscorrection: get rid of floats i init code
--- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 20, 2014, at 3:11 PM, Michael Niedermayer wrote: > On Wed, Aug 20, 2014 at 02:58:50PM +0200, Daniel Oberhoff wrote: >> >> --- >> Daniel Oberhoff >> daniel.oberh...@gmail.com >> >> >> >> On Aug 20, 2014, at 2:55 PM, Michael Niedermayer wrote: >> >>> On Wed, Aug 20, 2014 at 02:36:29PM +0200, Daniel Oberhoff wrote: --- Daniel Oberhoff daniel.oberh...@gmail.com On Aug 20, 2014, at 2:33 PM, Michael Niedermayer wrote: > On Wed, Aug 20, 2014 at 02:23:10PM +0200, Daniel Oberhoff wrote: >> So we prefer int64_t above float32? > > well, its not exactly making me happy either but its just 2 32x32->64 > operations per pixel which shouldnt be that bad when we need to do > 16 multiplications for bicubic per sample > also at the expense of a bit more space they could be precalculated > as they dont change between frames > > >> I assumed we stick with 32bits for calculations. Did you test this with >> very large resolutions? > > just tried: > ./ffplay -f lavfi -i testsrc=s=16385x8192 -vf > lenscorrection=0.3:0.2:0.2:0.9,scale=640x48 > which seems working > > >> I so congratulation :). I am glad I could push you to finish what I >> failed to do :). >> >> As I would still like to have interpolation, I assume I shall refactor >> the interpolation out of perspective and rotation instead, right? Ok, but by default I would only refactor so far as to support all use cases currently in perspective/rotate/lens_correction, and none more. >>> >>> sure >>> >>> Do you still think there should be a version/versions of the algorithm for packed formats? >>> >>> i think if we want to add gamma correct interpolation then yes >>> otherwise its probably not worth the work >> >> to be honest: I have no idea about that, do you have pointers for that? I.e. >> what it is, how it works, when it is needed, how it correlates with the >> image representation (i.e. yuv vs rgb, compressed vs full, etc)? > > its very simple > normal every day 8bit per sample rgb and yuv are not "linear", in the > sense that twice the number of photons does not equal twice the > integer value for , lets say red or y > > but interpolation, be that bilinear or bicubic assumes that it is so > so it would be needed to first get linear rgb (which needs more than > 8bits per sample to look good) then interpolate in that and then > to convert back to everyday gamma corrected 8bit per sample rgb > > in principle these correction steps could be done by seperate filters > and RGB48 could be used in vf_lenscorrection then vf_lenscorrection > would not need to know about any of that Right, so by supporting rgb48 that would be effectively supported. Sounds ok to me for the time being as workaround for high quality operation. So I will see if rgb48 can be supported... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_lenscorrection: get rid of floats i init code
On Wed, Aug 20, 2014 at 03:48:39PM +0200, Daniel Oberhoff wrote: > > --- > Daniel Oberhoff > daniel.oberh...@gmail.com > > > > On Aug 20, 2014, at 3:11 PM, Michael Niedermayer wrote: > > > On Wed, Aug 20, 2014 at 02:58:50PM +0200, Daniel Oberhoff wrote: > >> > >> --- > >> Daniel Oberhoff > >> daniel.oberh...@gmail.com > >> > >> > >> > >> On Aug 20, 2014, at 2:55 PM, Michael Niedermayer wrote: > >> > >>> On Wed, Aug 20, 2014 at 02:36:29PM +0200, Daniel Oberhoff wrote: > > --- > Daniel Oberhoff > daniel.oberh...@gmail.com > > > > On Aug 20, 2014, at 2:33 PM, Michael Niedermayer > wrote: > > > On Wed, Aug 20, 2014 at 02:23:10PM +0200, Daniel Oberhoff wrote: > >> So we prefer int64_t above float32? > > > > well, its not exactly making me happy either but its just 2 32x32->64 > > operations per pixel which shouldnt be that bad when we need to do > > 16 multiplications for bicubic per sample > > also at the expense of a bit more space they could be precalculated > > as they dont change between frames > > > > > >> I assumed we stick with 32bits for calculations. Did you test this > >> with very large resolutions? > > > > just tried: > > ./ffplay -f lavfi -i testsrc=s=16385x8192 -vf > > lenscorrection=0.3:0.2:0.2:0.9,scale=640x48 > > which seems working > > > > > >> I so congratulation :). I am glad I could push you to finish what I > >> failed to do :). > >> > >> As I would still like to have interpolation, I assume I shall refactor > >> the interpolation out of perspective and rotation instead, right? > > Ok, but by default I would only refactor so far as to support all use > cases currently in perspective/rotate/lens_correction, and none more. > >>> > >>> sure > >>> > >>> > Do you still think there should be a version/versions of the algorithm > for packed formats? > >>> > >>> i think if we want to add gamma correct interpolation then yes > >>> otherwise its probably not worth the work > >> > >> to be honest: I have no idea about that, do you have pointers for that? > >> I.e. what it is, how it works, when it is needed, how it correlates with > >> the image representation (i.e. yuv vs rgb, compressed vs full, etc)? > > > > its very simple > > normal every day 8bit per sample rgb and yuv are not "linear", in the > > sense that twice the number of photons does not equal twice the > > integer value for , lets say red or y > > > > but interpolation, be that bilinear or bicubic assumes that it is so > > so it would be needed to first get linear rgb (which needs more than > > 8bits per sample to look good) then interpolate in that and then > > to convert back to everyday gamma corrected 8bit per sample rgb > > > > in principle these correction steps could be done by seperate filters > > and RGB48 could be used in vf_lenscorrection then vf_lenscorrection > > would not need to know about any of that > > Right, so by supporting rgb48 that would be effectively supported. Sounds ok > to me for the time being as workaround for high quality operation. yes, theoretically in practice we might need something to make it convenient to be used requiring the user the manually insert some kind of gamma correction filter before and afterwards is a bit inconvenient [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/hecv_res_add: add ff_hevc_transform_add{8, 16, 32}_8_avx
On 20/08/14 4:29 AM, Christophe Gisquet wrote:
> Hi,
>
> 2014-08-20 4:55 GMT+02:00 James Almer :
>> ~15% faster than sse2
> [...]
>> @@ -509,7 +509,11 @@ void ff_hevc_dsp_init_x86(HEVCDSPContext *c, const int
>> bit_depth)
>> if (ARCH_X86_64) {
>> c->hevc_v_loop_filter_luma =
>> ff_hevc_v_loop_filter_luma_8_avx;
>> c->hevc_h_loop_filter_luma =
>> ff_hevc_h_loop_filter_luma_8_avx;
>> +
>> +c->transform_add[2]= ff_hevc_transform_add16_8_avx;
>> +c->transform_add[3]= ff_hevc_transform_add32_8_avx;
>
> Does avx => ARCH_X86_64 (didn't know) ? Otherwise the reg count seems
> fine, meaning the condition is unneeded.
No, AVX does not imply x86_64. The reg count for these is currently 12 xmm
regs,
meaning x86_64 only.
I'll send a patch to get them down to 8 or so later.
>
>> }
>> +c->transform_add[1]= ff_hevc_transform_add8_8_avx;
>
> I'm not entirely sure, but this is instantiated through INIT_YMM avx2,
> and I wouldn't expect performance improvement past the 3-op-form?
>
> So couldn't this one be instantiated to use xmm regs? (mmx may be a
> burden eg need for emms and need to rewrite it).
Aren't you thinking about the 10bit functions? All three AVX I'm adding here
are 8bit
and using xmm. There are no 8bit AVX2 functions currently.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/matroskaenc: Check alpha_mode
Fixes CID1231992
Suggested-by: Timothy Gu
Signed-off-by: Michael Niedermayer
---
libavformat/matroskaenc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 7123ec6..98fe4af 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -874,8 +874,8 @@ static int mkv_write_track(AVFormatContext *s,
MatroskaMuxContext *mkv,
}
}
-if ((tag = av_dict_get(st->metadata, "alpha_mode", NULL, 0)) ||
-(tag = av_dict_get( s->metadata, "alpha_mode", NULL, 0)) ||
+if (((tag = av_dict_get(st->metadata, "alpha_mode", NULL, 0)) &&
atoi(tag->value)) ||
+((tag = av_dict_get( s->metadata, "alpha_mode", NULL, 0)) &&
atoi(tag->value)) ||
(codec->pix_fmt == AV_PIX_FMT_YUVA420P)) {
put_ebml_uint(pb, MATROSKA_ID_VIDEOALPHAMODE, 1);
}
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] set bitrate from rc_max_rate for duration estimation will fix ticket #3678
From: Marc-Antoine Arnaud
---
libavformat/utils.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index b4ca342..738d1f0 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2280,6 +2280,13 @@ static void
estimate_timings_from_bit_rate(AVFormatContext *ic)
}
bit_rate += st->codec->bit_rate;
}
+if (st->codec->rc_max_rate > 0) {
+if (INT_MAX - st->codec->rc_max_rate < bit_rate) {
+bit_rate = 0;
+break;
+}
+bit_rate += st->codec->rc_max_rate;
+}
}
ic->bit_rate = bit_rate;
}
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] build: rely on pkg-config for libx264 probing
On Tue, Jun 17, 2014 at 11:05:39PM +0200, Clément Bœsch wrote:
> ---
> Changelog | 2 ++
> configure | 4 +---
> doc/encoders.texi | 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Changelog b/Changelog
> index 40a7751..268205c 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -54,3 +54,5 @@
> │ ⚠ Behaviour changes │
> └┘
>
> + • libx264 is now detected through pkg-config.
> +
> diff --git a/configure b/configure
> index 4f909a0..6946133 100755
> --- a/configure
> +++ b/configure
> @@ -4731,9 +4731,7 @@ enabled libvpx&& {
> enabled libvpx_vp9_encoder && { check_lib2 "vpx/vpx_encoder.h
> vpx/vp8cx.h" "vpx_codec_vp9_cx VP9E_SET_SVC" -lvpx || disable
> libvpx_vp9_encoder; } }
> enabled libwavpack&& require libwavpack wavpack/wavpack.h
> WavpackOpenFileOutput -lwavpack
> enabled libwebp && require_pkg_config libwebp webp/encode.h
> WebPGetEncoderVersion
> -enabled libx264 && require libx264 x264.h x264_encoder_encode
> -lx264 &&
> - { check_cpp_condition x264.h "X264_BUILD >=
> 118" ||
> - die "ERROR: libx264 must be installed and
> version must be >= 0.118."; }
> +enabled libx264 && require_pkg_config "x264 >= 0.118" "stdint.h
> x264.h" x264_encoder_encode
> enabled libx265 && require_pkg_config x265 x265.h
> x265_encoder_encode &&
> { check_cpp_condition x265.h "X265_BUILD >= 17"
> ||
> die "ERROR: libx265 version must be >= 17."; }
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 2781574..3183027 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -1515,7 +1515,7 @@ x264 H.264/MPEG-4 AVC encoder wrapper.
>
> This encoder requires the presence of the libx264 headers and library
> during configuration. You need to explicitly configure the build with
> -@code{--enable-libx264}.
> +@code{--enable-libx264}. This library is detected through @code{pkg-config}.
>
> libx264 supports an impressive number of features, including 8x8 and
> 4x4 adaptive spatial transform, adaptive B-frame placement, CAVLC/CABAC
Note: will fix Ticket #3876:
[~]☭ pkg-config --libs x264
-lx264
[~]☭ pkg-config --static --libs x264
-lx264 -lpthread -lm -ldl
--
Clément B.
pgpcC3FQv6zj3.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] set bitrate from rc_max_rate for duration estimation will fix ticket #3678
Marc-Antoine Arnaud arkena.com> writes:
> +if (st->codec->rc_max_rate > 0) {
> +if (INT_MAX - st->codec->rc_max_rate < bit_rate) {
> +bit_rate = 0;
> +break;
> +}
> +bit_rate += st->codec->rc_max_rate;
Did you test this patch with the sample attached to
ticket #3678? I would expect that this only works
for video-only streams or am I wrong?
You could check if a video stream with rc_max_rate
but no bit_rate exists and use that information to
decide if the format bit_rate should be updated.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/5] RGB48/64 with bits_per_raw_sample
Christophe Gisquet gmail.com> writes: > Depending on the input and/or filters, you sometime > have an input or output pixel format like "rgb48le(12 > bpc)". Unfortunately, most often, the 12 bpc > information is ignored or stripped. Could you explain what command line you are trying to fix? I apparently misunderstand the patchset, I don't see how / what it fixes... Note that I believe it would be completely wrong to add additional colourspaces with 8http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/mpegvideo_parser: consider vbv_delay in bitrate heuristic also for mpeg2
Fixes bitrate detection in CBR mpeg2
Fixes ticket3678
---
libavcodec/mpegvideo_parser.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mpegvideo_parser.c b/libavcodec/mpegvideo_parser.c
index 7aa3660..44bf26d 100644
--- a/libavcodec/mpegvideo_parser.c
+++ b/libavcodec/mpegvideo_parser.c
@@ -145,8 +145,9 @@ static void mpegvideo_extract_headers(AVCodecParserContext
*s,
the_end: ;
if (avctx->codec_id == AV_CODEC_ID_MPEG2VIDEO && bit_rate) {
avctx->rc_max_rate = 400*bit_rate;
-} else if (avctx->codec_id == AV_CODEC_ID_MPEG1VIDEO && bit_rate &&
- (bit_rate != 0x3 || vbv_delay != 0x)) {
+}
+if (bit_rate &&
+((avctx->codec_id == AV_CODEC_ID_MPEG1VIDEO && bit_rate != 0x3) ||
vbv_delay != 0x)) {
avctx->bit_rate = 400*bit_rate;
}
}
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] set bitrate from rc_max_rate for duration estimation will fix ticket #3678
On Wed, Aug 20, 2014 at 03:37:58PM +0200, Marc-Antoine Arnaud wrote:
> From: Marc-Antoine Arnaud
>
> ---
> libavformat/utils.c |7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index b4ca342..738d1f0 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -2280,6 +2280,13 @@ static void
> estimate_timings_from_bit_rate(AVFormatContext *ic)
> }
> bit_rate += st->codec->bit_rate;
> }
> +if (st->codec->rc_max_rate > 0) {
> +if (INT_MAX - st->codec->rc_max_rate < bit_rate) {
> +bit_rate = 0;
> +break;
> +}
> +bit_rate += st->codec->rc_max_rate;
> +}
this is not correct, the bitrate and maxbitrate when summed do not
give the bitrate of a stream except by chance.
also the max bitrate is only equal the bitrate for CBR streams.
the case described by Ticket 3678, is about bitrate in MXF.
the solution for this is to set the bitrate based on some
header structures in MXF, or at MXF level.
a slightly different heuristic for the mpeg2 parser that also
improves this ive just posted, comments welcome
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/ffmpeg: fix metadata language example
On Tue, 19 Aug 2014 16:40:21 -0700, Timothy Gu wrote: > OK, of course. Thanks. Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] set bitrate from rc_max_rate for duration estimation will fix ticket #3678
Hi Carl,
Yes I test with the attached file.
The case is when the input video stream is in Mpeg2, the bitrate of the
stream was setup in rc_max_rate, not in bitrate
[https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/mpeg12dec.c#L1284].
For the remark you mean I can add an "else if (st->codec->rc_max_rate > 0)
{" ?
I'm agree with that, it was better.
I don't know also if I need to set the show_warning to true, because it can
be a longer duration if the real bitrate was not exactly equal to the
rc_max_rate.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] set bitrate from rc_max_rate for duration estimation will fix ticket #3678
Hi Michael, I agreed how we can take the information in the wrapper if it's present. In MXF case it can be done. But in other formats, this information is not necessary present ... The other possibility is to set the duration to -1 to disable print when we can't known exactly the duration. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/hecv_res_add: add ff_hevc_transform_add{8, 16, 32}_8_avx
Hi, 2014-08-20 17:36 GMT+02:00 James Almer : >> Does avx => ARCH_X86_64 (didn't know) ? Otherwise the reg count seems >> fine, meaning the condition is unneeded. > > No, AVX does not imply x86_64. The reg count for these is currently 12 xmm > regs, > meaning x86_64 only. > I'll send a patch to get them down to 8 or so later. I somehow completely misread the reg count. Indeed. >> So couldn't this one be instantiated to use xmm regs? (mmx may be a >> burden eg need for emms and need to rewrite it). > > Aren't you thinking about the 10bit functions? All three AVX I'm adding here > are 8bit > and using xmm. There are no 8bit AVX2 functions currently. You're right. At this point, I think I accidentally read pierre's original or something, where I saw "INIT_YMM avx2". Please disregard my previous mail, patch ok, and sorry. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/5] RGB48/64 with bits_per_raw_sample
Hi, 2014-08-20 20:26 GMT+02:00 Carl Eugen Hoyos : > Christophe Gisquet gmail.com> writes: > >> Depending on the input and/or filters, you sometime >> have an input or output pixel format like "rgb48le(12 >> bpc)". Unfortunately, most often, the 12 bpc >> information is ignored or stripped. > > Could you explain what command line you are trying > to fix? > I apparently misunderstand the patchset, I don't > see how / what it fixes... The biggest "issue" is that 10/12bits data is interpreted as 16bits: - cf. ticket #2966 (that's the remaining missing part) - png can only write 16bits data but sometimes it is not rescaled (image appears darker), cf. the above - ppm images are forcibly rescaled to fill the 16bits (probably lossless but still) etc. > Note that I believe it would be completely wrong to > add additional colourspaces with 8http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] build: rely on pkg-config for libx264 probing
On Sat, Aug 16, 2014 at 03:27:17PM +0200, Clément Bœsch wrote: > On Fri, Aug 15, 2014 at 06:49:39AM +, Carl Eugen Hoyos wrote: > [...] > > > But really that's insane, because I know you will > > > end-up hardcoding all kind of linker flags to > > > these fallback calls, > > > > Yes, some external libraries that never have > > additional dependencies currently depend on pkg-config. > > > > > and this defeat completely the purpose of such > > > simplified code. > > > > I thought the purpose is to allow educated developers > > to use pkg-config while (uneducated) users (like me) > > will not understand how this is easier than using > > configure parameters. > > Yes, it's also simpler for the users. > > > > > > They will also almost never be tested, > > > > I will care about the testing. > > Well, you probably won't test static linking of random libs on various > platforms typically. > > pkg-config makes possible to completely ignore that part since it moves > the responsibility away from us. > > That said, if you want to support a fallback as I suggested above, it > won't work as you expect:if you want to link with your custom flags and be > sure not to have pkg-config taking over your parameters (basically linking > to the system package instead of the one you specified through custom link > flags). > Carl, do you see a solution? [...] -- Clément B. pgp2zc5Kjm1Wb.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/hecv_res_add: add ff_hevc_transform_add{8, 16, 32}_8_avx
On 20/08/14 4:25 AM, Mickaël Raulet wrote: > Patch ok > > Mickael Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/hecv_res_add: add ff_hevc_transform_add{8, 16, 32}_8_avx
On 20/08/14 4:11 PM, Christophe Gisquet wrote: > Hi, > > 2014-08-20 17:36 GMT+02:00 James Almer : >>> Does avx => ARCH_X86_64 (didn't know) ? Otherwise the reg count seems >>> fine, meaning the condition is unneeded. >> >> No, AVX does not imply x86_64. The reg count for these is currently 12 xmm >> regs, >> meaning x86_64 only. >> I'll send a patch to get them down to 8 or so later. > > I somehow completely misread the reg count. Indeed. > >>> So couldn't this one be instantiated to use xmm regs? (mmx may be a >>> burden eg need for emms and need to rewrite it). >> >> Aren't you thinking about the 10bit functions? All three AVX I'm adding here >> are 8bit >> and using xmm. There are no 8bit AVX2 functions currently. > > You're right. At this point, I think I accidentally read pierre's > original or something, where I saw "INIT_YMM avx2". > > Please disregard my previous mail, patch ok, and sorry. Pushed then. Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avfilter/showwaves: split out draw sample code.
On Wed, Aug 20, 2014 at 11:28:40AM +0200, Paul B Mahol wrote: > On 8/19/14, Clement Boesch wrote: > > From: Clement Boesch > > > > --- > > libavfilter/avf_showwaves.c | 119 > > +++- > > 1 file changed, 74 insertions(+), 45 deletions(-) > > > > lgtm Applied, thanks -- Clément B. pgpx67ybQhaBB.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avfilter/showwaves: add "center" mode.
On Wed, Aug 20, 2014 at 01:02:21PM +0200, Stefano Sabatini wrote:
> On date Tuesday 2014-08-19 14:47:02 +0200, Clément Bœsch encoded:
> > From: Clément Bœsch
> >
> > ---
> > doc/filters.texi| 3 +++
> > libavfilter/avf_showwaves.c | 24 +++-
> > 2 files changed, 22 insertions(+), 5 deletions(-)
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index 0ca1d6f..828f2b4 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -10813,6 +10813,9 @@ Draw a vertical line for each sample.
> >
> > @item p2p
> > Draw a point for each sample and a line between them.
> > +
> > +@item center
> > +Draw a centered vertical line for each sample.
> > @end table
> >
> > Default value is @code{point}.
> > diff --git a/libavfilter/avf_showwaves.c b/libavfilter/avf_showwaves.c
> > index e025663..e4911cc 100644
> > --- a/libavfilter/avf_showwaves.c
> > +++ b/libavfilter/avf_showwaves.c
> > @@ -36,6 +36,7 @@ enum ShowWavesMode {
> > MODE_POINT,
> > MODE_LINE,
> > MODE_P2P,
>
> > +MODE_CENTER,
>
> Nit: what about CENTERED_LINE, then you can use cl or cline as abbreviation.
>
Sure whatever.
[...]
> LGTM otherwise, thanks.
Applied, thanks
--
Clément B.
pgpQp9M1gQ5Xv.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] avfilter/showwaves: add split_channels option.
On Wed, Aug 20, 2014 at 11:27:23AM +0200, Paul B Mahol wrote: > On 8/19/14, Clement Boesch wrote: > > From: Clement Boesch > > > > --- > > doc/filters.texi| 3 +++ > > libavfilter/avf_showwaves.c | 14 ++ > > 2 files changed, 13 insertions(+), 4 deletions(-) > > > > lgtm Applied with micro bump requested by Stefano. Thanks -- Clément B. pgpm5IU1Cona8.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] set bitrate from rc_max_rate for duration estimation will fix ticket #3678
On Wed, Aug 20, 2014 at 08:52:09PM +0200, Marc-Antoine ARNAUD wrote: > Hi Michael, > > > I agreed how we can take the information in the wrapper if it's present. In > MXF case it can be done. But in other formats, this information is not > necessary present ... yes, and thus it cannot be done reliably in these other cases. we can possibly improve the heuristics but for MXF this information should be extracted from MXF headers if its in there a patch along these lines is welcome, iam no mxf expert so dont wait for me to implement that ... [...] -- 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] A patch for gdigrab function
On Tue, 2014-08-19 at 07:44 -0600, Roger Pack wrote: > OK I was able to reproduce the problem. > Patch looks good, see attached, FWIW. > Thanks! > -roger- I suppose this was probably my fault originally; it was my first time programming the win32 api. ;) Thanks for the fix. -- Calvin Walton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: add fontcolor option
On Wed, Aug 20, 2014 at 07:10:56AM +0700, Muhammad Faiz wrote:
[...]
> +static double r_func(void *p, double x)
> +{
> +x = av_clipd(x, 0.0, 1.0);
> +return (int)(x*255.0+0.5) << 16;
You can probably use lrint() here:
return lrint(av_clipd(x, 0.0, 1.0) * 255.0) << 16;
[...]
> +av_expr_free(fontcolor_expr);
> av_expr_free(volume_expr);
> av_expr_free(tlength_expr);
drop these 3 lines...
> end_time = av_gettime_relative();
> @@ -482,6 +515,12 @@ static int config_output(AVFilterLink *outlink)
> outlink->time_base = av_make_q(1, s->fps);
> outlink->frame_rate = av_make_q(s->fps, 1);
> return 0;
...drop this line as well...
> +
> +eval_error:
...and rename this to "out" or something more generic
> +av_expr_free(fontcolor_expr);
> +av_expr_free(volume_expr);
> +av_expr_free(tlength_expr);
> +return ret;
> }
>
[...]
Please bump libavfilter/version.h micro and I'll probably apply this
version.
Thanks
--
Clément B.
pgpd5UwixfvxR.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add codecview filter
On Mon, Aug 18, 2014 at 06:03:39PM +0200, Clément Bœsch wrote:
> From: Clément Bœsch
>
> ---
> Note: I didn't use FF_API_DEBUG_MV because it seems to overlap with all
> kind of other things and I couldn't test properly the conditional
> compilation.
>
> BTW, I could add a FATE test easily, but I didn't find any relevant
> samples available.
hmm?
totally random pick:
fate-suite/real/spygames-2MB.rmvb
but anything mpeg/h263 based should work
>
> TODO: minor bump avfilter, micro bump avcodec
[...]
> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
> index 7000531..ad3d52e 100644
> --- a/libavcodec/options_table.h
> +++ b/libavcodec/options_table.h
> @@ -262,10 +262,12 @@ static const AVOption avcodec_options[] = {
> {"buffers", "picture buffer allocations", 0, AV_OPT_TYPE_CONST, {.i64 =
> FF_DEBUG_BUFFERS }, INT_MIN, INT_MAX, V|D, "debug"},
> {"thread_ops", "threading operations", 0, AV_OPT_TYPE_CONST, {.i64 =
> FF_DEBUG_THREADS }, INT_MIN, INT_MAX, V|A|D, "debug"},
> {"nomc", "skip motion compensation", 0, AV_OPT_TYPE_CONST, {.i64 =
> FF_DEBUG_NOMC }, INT_MIN, INT_MAX, V|A|D, "debug"},
> -{"vismv", "visualize motion vectors (MVs)", OFFSET(debug_mv),
> AV_OPT_TYPE_FLAGS, {.i64 = DEFAULT }, 0, INT_MAX, V|D, "debug_mv"},
> +#if FF_API_VISMV
> +{"vismv", "visualize motion vectors (MVs) (deprecated)", OFFSET(debug_mv),
> AV_OPT_TYPE_FLAGS, {.i64 = DEFAULT }, 0, INT_MAX, V|D, "debug_mv"},
> {"pf", "forward predicted MVs of P-frames", 0, AV_OPT_TYPE_CONST, {.i64 =
> FF_DEBUG_VIS_MV_P_FOR }, INT_MIN, INT_MAX, V|D, "debug_mv"},
> {"bf", "forward predicted MVs of B-frames", 0, AV_OPT_TYPE_CONST, {.i64 =
> FF_DEBUG_VIS_MV_B_FOR }, INT_MIN, INT_MAX, V|D, "debug_mv"},
> {"bb", "backward predicted MVs of B-frames", 0, AV_OPT_TYPE_CONST, {.i64 =
> FF_DEBUG_VIS_MV_B_BACK }, INT_MIN, INT_MAX, V|D, "debug_mv"},
> +#endif
> {"cmp", "full-pel ME compare function", OFFSET(me_cmp), AV_OPT_TYPE_INT,
> {.i64 = DEFAULT }, INT_MIN, INT_MAX, V|E, "cmp_func"},
> {"subcmp", "sub-pel ME compare function", OFFSET(me_sub_cmp),
> AV_OPT_TYPE_INT, {.i64 = DEFAULT }, INT_MIN, INT_MAX, V|E, "cmp_func"},
> {"mbcmp", "macroblock compare function", OFFSET(mb_cmp), AV_OPT_TYPE_INT,
> {.i64 = DEFAULT }, INT_MIN, INT_MAX, V|E, "cmp_func"},
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 6a40a03..70f5734 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -1435,6 +1435,12 @@ int attribute_align_arg avcodec_open2(AVCodecContext
> *avctx, const AVCodec *code
> goto free_and_end;
> }
>
> +#if FF_API_VISMV
> +if (avctx->debug_mv)
> +av_log(avctx, AV_LOG_WARNING, "The 'vismv' option is deprecated, "
> + "see the codecview filter instead:
> http://ffmpeg.org/ffmpeg-filters.html#codecview\n";);
> +#endif
ffmpeg could enable the filter automatically if vismv is used
similarly it could set the export flags if the filter is detected
these would simplify usage
of cousre thats not related to this patch
patch looks nice
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
There will always be a question for which you do not know the correct answer.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec: export motion vectors in frame side data on demand
From: Clément Bœsch
The reasoning behind this addition is that various third party
applications are interested in getting some motion information out of a
video "for free" when it is available.
It was considered to export other information as well (such as the intra
information about the block, or the quantization) but the structure
might have ended up into a half full-generic, half full of codec
specific cruft. If more information is necessary, it should either be
added in the "flags" field of the AVMotionVector structure, or in
another side-data.
This commit also includes an example exporting them in a CSV stream.
---
.gitignore | 1 +
configure | 2 +
doc/APIchanges | 3 +
doc/Makefile | 1 +
doc/codecs.texi| 3 +
doc/examples/Makefile | 1 +
doc/examples/extract_mvs.c | 185 +
libavcodec/avcodec.h | 1 +
libavcodec/mpegvideo.c | 103 -
libavcodec/options_table.h | 1 +
libavutil/Makefile | 1 +
libavutil/frame.c | 1 +
libavutil/frame.h | 7 ++
libavutil/motion_vector.h | 50
libavutil/version.h| 2 +-
15 files changed, 360 insertions(+), 2 deletions(-)
create mode 100644 doc/examples/extract_mvs.c
create mode 100644 libavutil/motion_vector.h
diff --git a/.gitignore b/.gitignore
index cb370bb..480fbe0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -39,6 +39,7 @@
/doc/examples/avio_reading
/doc/examples/decoding_encoding
/doc/examples/demuxing_decoding
+/doc/examples/extract_mvs
/doc/examples/filter_audio
/doc/examples/filtering_audio
/doc/examples/filtering_video
diff --git a/configure b/configure
index 1224362..f355dad 100755
--- a/configure
+++ b/configure
@@ -1305,6 +1305,7 @@ EXAMPLE_LIST="
avio_reading_example
decoding_encoding_example
demuxing_decoding_example
+extract_mvs_example
filter_audio_example
filtering_audio_example
filtering_video_example
@@ -2586,6 +2587,7 @@ zoompan_filter_deps="swscale"
avio_reading="avformat avcodec avutil"
avcodec_example_deps="avcodec avutil"
demuxing_decoding_example_deps="avcodec avformat avutil"
+extract_mvs_example_deps="avcodec avformat avutil"
filter_audio_example_deps="avfilter avutil"
filtering_audio_example_deps="avfilter avcodec avformat avutil"
filtering_video_example_deps="avfilter avcodec avformat avutil"
diff --git a/doc/APIchanges b/doc/APIchanges
index 8b3051c..1bed107 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2014-08-09
API changes, most recent first:
+2014-08-xx - xxx - lavu 54.5.100 - frame.h motion_vector.h
+ Add AV_FRAME_DATA_MOTION_VECTORS side data and AVMotionVector structure
+
2014-08-16 - xxx - lswr 1.1.100 - swresample.h
Add AVFrame based API
diff --git a/doc/Makefile b/doc/Makefile
index 99f588a..2fb9058 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -39,6 +39,7 @@ DOCS = $(DOCS-yes)
DOC_EXAMPLES-$(CONFIG_AVIO_READING_EXAMPLE) += avio_reading
DOC_EXAMPLES-$(CONFIG_AVCODEC_EXAMPLE) += avcodec
DOC_EXAMPLES-$(CONFIG_DEMUXING_DECODING_EXAMPLE) += demuxing_decoding
+DOC_EXAMPLES-$(CONFIG_EXTRACT_MVS_EXAMPLE) += extract_mvs
DOC_EXAMPLES-$(CONFIG_FILTER_AUDIO_EXAMPLE) += filter_audio
DOC_EXAMPLES-$(CONFIG_FILTERING_AUDIO_EXAMPLE) += filtering_audio
DOC_EXAMPLES-$(CONFIG_FILTERING_VIDEO_EXAMPLE) += filtering_video
diff --git a/doc/codecs.texi b/doc/codecs.texi
index 1160e5d..820dce5 100644
--- a/doc/codecs.texi
+++ b/doc/codecs.texi
@@ -797,6 +797,9 @@ Frame data might be split into multiple chunks.
Show all frames before the first keyframe.
@item skiprd
Deprecated, use mpegvideo private options instead.
+@item export_mvs
+Export motion vectors into frame side-data (see
@code{AV_FRAME_DATA_MOTION_VECTORS})
+for codecs that support it. See also @file{doc/examples/export_mvs.c}.
@end table
@item error @var{integer} (@emph{encoding,video})
diff --git a/doc/examples/Makefile b/doc/examples/Makefile
index 03c7021..07251fe 100644
--- a/doc/examples/Makefile
+++ b/doc/examples/Makefile
@@ -14,6 +14,7 @@ LDLIBS := $(shell pkg-config --libs $(FFMPEG_LIBS)) $(LDLIBS)
EXAMPLES= avio_reading \
decoding_encoding \
demuxing_decoding \
+extract_mvs\
filtering_video\
filtering_audio\
metadata \
diff --git a/doc/examples/extract_mvs.c b/doc/examples/extract_mvs.c
new file mode 100644
index 000..6056cce
--- /dev/null
+++ b/doc/examples/extract_mvs.c
@@ -0,0 +1,185 @@
+/*
+ * Copyright (c) 2012 Stefano Sabatini
+ * Copyright (c) 2014 Clément Bœsch
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ *
Re: [FFmpeg-devel] [PATCH] avcodec: export motion vectors in frame side data on demand
On Wed, Aug 20, 2014 at 11:28:42PM +0200, Clément Bœsch wrote: [...] I'm tired. Please ignore. Sorry for the noise. -- Clément B. pgp3CzeayEKnJ.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avutil/motion_vector.h: fix coordinate types
---
doc/APIchanges| 2 +-
libavutil/motion_vector.h | 8
libavutil/version.h | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 1bed107..1fbeb09 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,7 +15,7 @@ libavutil: 2014-08-09
API changes, most recent first:
-2014-08-xx - xxx - lavu 54.5.100 - frame.h motion_vector.h
+2014-08-xx - b0352b1,xxx - lavu 54.6.100 - frame.h motion_vector.h
Add AV_FRAME_DATA_MOTION_VECTORS side data and AVMotionVector structure
2014-08-16 - xxx - lswr 1.1.100 - swresample.h
diff --git a/libavutil/motion_vector.h b/libavutil/motion_vector.h
index 245e511..30cfb99 100644
--- a/libavutil/motion_vector.h
+++ b/libavutil/motion_vector.h
@@ -33,13 +33,13 @@ typedef struct AVMotionVector {
*/
uint8_t w, h;
/**
- * Absolute source position.
+ * Absolute source position. Can be outside the frame area.
*/
-uint16_t src_x, src_y;
+int16_t src_x, src_y;
/**
- * Absolute destination position.
+ * Absolute destination position. Can be outside the frame area.
*/
-uint16_t dst_x, dst_y;
+int16_t dst_x, dst_y;
/**
* Extra flag information.
* Currently unused.
diff --git a/libavutil/version.h b/libavutil/version.h
index d42209d..4236ed2 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -56,7 +56,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 54
-#define LIBAVUTIL_VERSION_MINOR 5
+#define LIBAVUTIL_VERSION_MINOR 6
#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
--
2.0.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/motion_vector.h: fix coordinate types
On Wed, Aug 20, 2014 at 11:30:27PM +0200, Clément Bœsch wrote: > --- > doc/APIchanges| 2 +- > libavutil/motion_vector.h | 8 > libavutil/version.h | 2 +- > 3 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/doc/APIchanges b/doc/APIchanges > index 1bed107..1fbeb09 100644 > --- a/doc/APIchanges > +++ b/doc/APIchanges > @@ -15,7 +15,7 @@ libavutil: 2014-08-09 > > API changes, most recent first: > > -2014-08-xx - xxx - lavu 54.5.100 - frame.h motion_vector.h > +2014-08-xx - b0352b1,xxx - lavu 54.6.100 - frame.h motion_vector.h what is "b0352b1,xxx" ? i think an API is only really available and stable after 1 revission rest LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] web/security: put CVE-2014-5271 in () for 1.2, as the encoder lacked alpha support back then
On Wed, Aug 20, 2014 at 02:03:13AM +0200, Michael Niedermayer wrote: patchset applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] x86/hevc_res_add: refactor ff_hevc_transform_add{16, 32}_8
* Reduced xmm register count to 7 (As such they are now enabled for x86_32).
* Removed four movdqa (affects the sse2 version only).
* pxor is now used to clear m0 only once.
~5% faster.
Signed-off-by: James Almer
---
libavcodec/x86/hevc_res_add.asm | 122
libavcodec/x86/hevcdsp_init.c | 10 ++--
2 files changed, 51 insertions(+), 81 deletions(-)
diff --git a/libavcodec/x86/hevc_res_add.asm b/libavcodec/x86/hevc_res_add.asm
index feea50c..7238fb3 100644
--- a/libavcodec/x86/hevc_res_add.asm
+++ b/libavcodec/x86/hevc_res_add.asm
@@ -88,71 +88,41 @@ cglobal hevc_transform_add4_8, 3, 4, 6
movhps [r0+r3 ], m1
%endmacro
-%macro TR_ADD_INIT_SSE_8 0
-pxor m0, m0
-
-mova m4, [r1]
-mova m1, [r1+16]
-psubw m2, m0, m1
-psubw m5, m0, m4
-packuswb m4, m1
-packuswb m5, m2
-
-mova m6, [r1+32]
-mova m1, [r1+48]
-psubw m2, m0, m1
-psubw m7, m0, m6
-packuswb m6, m1
-packuswb m7, m2
-
-mova m8, [r1+64]
-mova m1, [r1+80]
-psubw m2, m0, m1
-psubw m9, m0, m8
-packuswb m8, m1
-packuswb m9, m2
-
-mova m10, [r1+96]
-mova m1, [r1+112]
-psubw m2, m0, m1
-psubwm11, m0, m10
-packuswb m10, m1
-packuswb m11, m2
-%endmacro
-
-
-%macro TR_ADD_SSE_16_8 0
-TR_ADD_INIT_SSE_8
-
-paddusb m0, m4, [r0 ]
-paddusb m1, m6, [r0+r2 ]
-paddusb m2, m8, [r0+r2*2]
-paddusb m3, m10,[r0+r3 ]
-psubusb m0, m5
-psubusb m1, m7
-psubusb m2, m9
-psubusb m3, m11
-mova [r0 ], m0
-mova [r0+r2 ], m1
-mova [r0+2*r2], m2
-mova [r0+r3 ], m3
-%endmacro
-
-%macro TR_ADD_SSE_32_8 0
-TR_ADD_INIT_SSE_8
-
-paddusb m0, m4, [r0 ]
-paddusb m1, m6, [r0+16 ]
-paddusb m2, m8, [r0+r2 ]
-paddusb m3, m10,[r0+r2+16]
-psubusb m0, m5
-psubusb m1, m7
-psubusb m2, m9
-psubusb m3, m11
-mova [r0 ], m0
-mova [r0+16 ], m1
-mova [r0+r2 ], m2
-mova [r0+r2+16], m3
+%macro TR_ADD_SSE_16_32_8 3
+mova m2, [r1+%1 ]
+mova m6, [r1+%1+16]
+%if cpuflag(avx)
+psubw m1, m0, m2
+psubw m5, m0, m6
+%else
+mova m1, m0
+mova m5, m0
+psubw m1, m2
+psubw m5, m6
+%endif
+packuswb m2, m6
+packuswb m1, m5
+
+mova m4, [r1+%1+32]
+mova m6, [r1+%1+48]
+%if cpuflag(avx)
+psubw m3, m0, m4
+psubw m5, m0, m6
+%else
+mova m3, m0
+mova m5, m0
+psubw m3, m4
+psubw m5, m6
+%endif
+packuswb m4, m6
+packuswb m3, m5
+
+paddusb m2, [%2]
+paddusb m4, [%3]
+psubusb m2, m1
+psubusb m4, m3
+mova[%2], m2
+mova[%3], m4
%endmacro
@@ -166,30 +136,32 @@ cglobal hevc_transform_add8_8, 3, 4, 8
TR_ADD_SSE_8_8
RET
-%if ARCH_X86_64
; void ff_hevc_transform_add16_8_(uint8_t *dst, int16_t *coeffs,
ptrdiff_t stride)
-cglobal hevc_transform_add16_8, 3, 4, 12
+cglobal hevc_transform_add16_8, 3, 4, 7
+pxor m0, m0
lea r3, [r2*3]
-TR_ADD_SSE_16_8
+TR_ADD_SSE_16_32_8 0, r0, r0+r2
+TR_ADD_SSE_16_32_8 64, r0+r2*2, r0+r3
%rep 3
addr1, 128
lear0, [r0+r2*4]
-TR_ADD_SSE_16_8
+TR_ADD_SSE_16_32_8 0, r0, r0+r2
+TR_ADD_SSE_16_32_8 64, r0+r2*2, r0+r3
%endrep
RET
; void ff_hevc_transform_add32_8_(uint8_t *dst, int16_t *coeffs,
ptrdiff_t stride)
-cglobal hevc_transform_add32_8, 3, 4, 12
-
-TR_ADD_SSE_32_8
+cglobal hevc_transform_add32_8, 3, 4, 7
+pxor m0, m0
+TR_ADD_SSE_16_32_8 0, r0,r0+16
+TR_ADD_SSE_16_32_8 64, r0+r2, r0+r2+16
%rep 15
addr1, 128
lear0, [r0+r2*2]
-TR_ADD_SSE_32_8
+TR_ADD_SSE_16_32_8 0, r0,r0+16
+TR_ADD_SSE_16_32_8 64, r0+r2, r0+r2+16
%endrep
RET
-
-%endif ;ARCH_X86_64
%endmacro
INIT_XMM sse2
diff --git a/libavcodec/x86/hevcdsp_init.c b/libavcodec/x86/hevcdsp_init.c
index f6f0a4b..0709158 100644
--- a/libavcodec/x86/hevcdsp_init.c
+++ b/libavcodec/x86/hevcdsp_init.c
@@ -477,15 +477,14 @@ void ff_hevc_dsp_init_x86(HEVCDSPContext *c, const int
bit_depth)
if (ARCH_X86_64) {
c->hevc_v_loop_filter_luma = ff_hevc_
[FFmpeg-devel] [PATCH 1/2] fate: add test for old (v1) huffyuv and rgba
--- tests/fate/vcodec.mak| 4 +++- tests/ref/vsynth/vsynth1-huffyuvbgra | 4 tests/ref/vsynth/vsynth2-huffyuvbgra | 4 tests/ref/vsynth/vsynth3-huffyuvbgra | 4 4 files changed, 15 insertions(+), 1 deletion(-) create mode 100644 tests/ref/vsynth/vsynth1-huffyuvbgra create mode 100644 tests/ref/vsynth/vsynth2-huffyuvbgra create mode 100644 tests/ref/vsynth/vsynth3-huffyuvbgra diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak index cefd4d3..ec3155a 100644 --- a/tests/fate/vcodec.mak +++ b/tests/fate/vcodec.mak @@ -91,11 +91,13 @@ fate-vsynth%-h263: ENCOPTS = -qscale 10 fate-vsynth%-h263-obmc: ENCOPTS = -qscale 10 -obmc 1 fate-vsynth%-h263p: ENCOPTS = -qscale 2 -flags +aic -umv 1 -aiv 1 -ps 300 -FATE_VCODEC-$(call ENCDEC, HUFFYUV, AVI) += huffyuv huffyuvbgr24 +FATE_VCODEC-$(call ENCDEC, HUFFYUV, AVI) += huffyuv huffyuvbgr24 huffyuvbgra fate-vsynth%-huffyuv:ENCOPTS = -vcodec huffyuv -pix_fmt yuv422p -sws_flags neighbor fate-vsynth%-huffyuv:DECOPTS = -sws_flags neighbor fate-vsynth%-huffyuvbgr24: ENCOPTS = -vcodec huffyuv -pix_fmt bgr24 -sws_flags neighbor fate-vsynth%-huffyuvbgr24: DECOPTS = -sws_flags neighbor +fate-vsynth%-huffyuvbgra:ENCOPTS = -vcodec huffyuv -pix_fmt bgr32 -sws_flags neighbor +fate-vsynth%-huffyuvbgra:DECOPTS = -sws_flags neighbor FATE_VCODEC-$(call ENCDEC, JPEGLS, AVI) += jpegls fate-vsynth%-jpegls: ENCOPTS = -sws_flags neighbor+full_chroma_int diff --git a/tests/ref/vsynth/vsynth1-huffyuvbgra b/tests/ref/vsynth/vsynth1-huffyuvbgra new file mode 100644 index 000..8578b81 --- /dev/null +++ b/tests/ref/vsynth/vsynth1-huffyuvbgra @@ -0,0 +1,4 @@ +0a441061598152cd44ddc308076671c3 *tests/data/fate/vsynth1-huffyuvbgra.avi +14464166 tests/data/fate/vsynth1-huffyuvbgra.avi +49c03ab1b73b7cd3cabc3c77a9479c9e *tests/data/fate/vsynth1-huffyuvbgra.out.rawvideo +stddev:3.16 PSNR: 38.12 MAXDIFF: 50 bytes: 7603200/ 7603200 diff --git a/tests/ref/vsynth/vsynth2-huffyuvbgra b/tests/ref/vsynth/vsynth2-huffyuvbgra new file mode 100644 index 000..b37b49f --- /dev/null +++ b/tests/ref/vsynth/vsynth2-huffyuvbgra @@ -0,0 +1,4 @@ +e8c2dbe6ad5d273af2bdb2dc3a2a524d *tests/data/fate/vsynth2-huffyuvbgra.avi +10139598 tests/data/fate/vsynth2-huffyuvbgra.avi +0a8b7ddfec03622e37c869c5b552f9fc *tests/data/fate/vsynth2-huffyuvbgra.out.rawvideo +stddev:1.24 PSNR: 46.26 MAXDIFF: 17 bytes: 7603200/ 7603200 diff --git a/tests/ref/vsynth/vsynth3-huffyuvbgra b/tests/ref/vsynth/vsynth3-huffyuvbgra new file mode 100644 index 000..32eecd4 --- /dev/null +++ b/tests/ref/vsynth/vsynth3-huffyuvbgra @@ -0,0 +1,4 @@ +9d360ce029b5ec86f0f6c80c44edf9bd *tests/data/fate/vsynth3-huffyuvbgra.avi +179598 tests/data/fate/vsynth3-huffyuvbgra.avi +5d031d2e891b13593b8cd79e63d083b4 *tests/data/fate/vsynth3-huffyuvbgra.out.rawvideo +stddev:3.23 PSNR: 37.92 MAXDIFF: 50 bytes:86700/86700 -- 1.9.2.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/2] Test and fix old (v1) huffyuv rgba
Commit deadcf5e broke it, and fate didn't catch it. Christophe Gisquet (2): fate: add test for old (v1) huffyuv and rgba huffyuvdec: fix old (v1) rgba libavcodec/huffyuvdec.c | 17 - tests/fate/vcodec.mak| 4 +++- tests/ref/vsynth/vsynth1-huffyuvbgra | 4 tests/ref/vsynth/vsynth2-huffyuvbgra | 4 tests/ref/vsynth/vsynth3-huffyuvbgra | 4 5 files changed, 23 insertions(+), 10 deletions(-) create mode 100644 tests/ref/vsynth/vsynth1-huffyuvbgra create mode 100644 tests/ref/vsynth/vsynth2-huffyuvbgra create mode 100644 tests/ref/vsynth/vsynth3-huffyuvbgra -- 1.9.2.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] huffyuvdec: fix old (v1) rgba
Commit deadcf5e misplaced a hunk.
Fixes ticket #3877.
---
libavcodec/huffyuvdec.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
index e4e5ea0..bc5ad15 100644
--- a/libavcodec/huffyuvdec.c
+++ b/libavcodec/huffyuvdec.c
@@ -729,7 +729,7 @@ static av_always_inline void decode_bgr_1(HYuvContext *s,
int count,
for (i = 0; i < count && BITS_LEFT(re, &s->gb) > 0; i++) {
unsigned int index;
-int code, n;
+int code, n, nb_bits;
UPDATE_CACHE(re, &s->gb);
index = SHOW_UBITS(re, &s->gb, VLC_BITS);
@@ -740,7 +740,6 @@ static av_always_inline void decode_bgr_1(HYuvContext *s,
int count,
*(uint32_t *) &s->temp[0][4 * i] = s->pix_bgr_map[code];
LAST_SKIP_BITS(re, &s->gb, n);
} else {
-int nb_bits;
if (decorrelate) {
VLC_INTERN(s->temp[0][4 * i + G], s->vlc[1].table,
&s->gb, re, VLC_BITS, 3);
@@ -768,14 +767,14 @@ static av_always_inline void decode_bgr_1(HYuvContext *s,
int count,
VLC_INTERN(s->temp[0][4 * i + R], s->vlc[2].table,
&s->gb, re, VLC_BITS, 3);
}
-if (alpha) {
-UPDATE_CACHE(re, &s->gb);
-index = SHOW_UBITS(re, &s->gb, VLC_BITS);
-VLC_INTERN(s->temp[0][4 * i + A], s->vlc[2].table,
- &s->gb, re, VLC_BITS, 3);
-} else
-s->temp[0][4 * i + A] = 0;
}
+if (alpha) {
+UPDATE_CACHE(re, &s->gb);
+index = SHOW_UBITS(re, &s->gb, VLC_BITS);
+VLC_INTERN(s->temp[0][4 * i + A], s->vlc[2].table,
+ &s->gb, re, VLC_BITS, 3);
+} else
+s->temp[0][4 * i + A] = 0;
}
CLOSE_READER(re, &s->gb);
}
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [RFC] [PATCH] hevc_ps: reorder SPS reading to allow some errors
Hi,
ticket #3872 is about a regression on decoding of hevc:
https://trac.ffmpeg.org/ticket/3872
The reason is a stricter validation is now performed since 5ec85c97.
The sequence seems invalid to me, as it seems the SPS was truncated or
corrupted somewhere in the VUI. But if we ignore the a priori invalid
SPS, the sequence actually decodes fine.
It seems impossible to detect when this occurs:
- A local test by remuxing hevc ES streams into mkv with mkvtoolnix
7.1.0 yielded valid streams, so this muxer is maybe not responsible
(the file may have actually been transmuxed);
- I don't see any obvious extra/userdata or anything allowing to
identify the encoder (is it x265? the information has been stripped so
it may be another encoder).
The metadata (I bet irrelevant here) of this file, as found on
ffmpeg's stdout, can be seen in the attached metadata.txt file
I'm trying to dig more information to see how narrow a fix could be.
H.264 in that case simply rejects the data.
It's a pity here that the file is actually fine, but that it is
indistinguishable otherwise from a corrupt, undecodable stream.
The attached patch tries to be lenient about the VUI having errors,
but this is hardly tolerable either, as hevc extensions
(scalable/other profile data) signal their data afterwards.
--
Christophe
_STATISTICS_WRITING_APP: mkvmerge v7.1.0 ('Good Love') 32bit built on Jul
27 2014 12:59:18
_STATISTICS_WRITING_APP-eng: mkvmerge v7.1.0 ('Good Love') 32bit built on
Jul 27 2014 12:59:18
_STATISTICS_WRITING_DATE_UTC: 2014-08-19 19:23:56
_STATISTICS_WRITING_DATE_UTC-eng: 2014-08-19 19:23:56
_STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
BPS : 3979031
BPS-eng : 3979031
DURATION: 00:01:38.55700
DURATION-eng: 00:01:38.55700
NUMBER_OF_FRAMES: 2363
NUMBER_OF_FRAMES-eng: 2363
NUMBER_OF_BYTES : 49020173
NUMBER_OF_BYTES-eng: 49020173From dd2edff6495c1f94746c5bff0ff3ac52717b5347 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Thu, 21 Aug 2014 01:31:53 +0200
Subject: [PATCH] hevc_ps: reorder SPS reading to allow some errors
Some streams have been found to have their VUI truncated but still decode
fine. To handle them, only abort when incorrect data has been found before
the VUI. Warn if overread occurred afterwards.
However, HEVC extensions will not be correctly handled.
Fixes ticket #3872.
---
libavcodec/hevc_ps.c | 161 ---
1 file changed, 88 insertions(+), 73 deletions(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 2ccce5f..a74f60a 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -937,79 +937,6 @@ int ff_hevc_decode_nal_sps(HEVCContext *s)
sps->sps_temporal_mvp_enabled_flag = get_bits1(gb);
sps->sps_strong_intra_smoothing_enable_flag = get_bits1(gb);
-sps->vui.sar = (AVRational){0, 1};
-vui_present = get_bits1(gb);
-if (vui_present)
-decode_vui(s, sps);
-
-if (get_bits1(gb)) { // sps_extension_flag
-int sps_extension_flag[1];
-for (i = 0; i < 1; i++)
-sps_extension_flag[i] = get_bits1(gb);
-skip_bits(gb, 7); //sps_extension_7bits = get_bits(gb, 7);
-if (sps_extension_flag[0]) {
-int extended_precision_processing_flag;
-int high_precision_offsets_enabled_flag;
-int cabac_bypass_alignment_enabled_flag;
-
-sps->transform_skip_rotation_enabled_flag = get_bits1(gb);
-sps->transform_skip_context_enabled_flag = get_bits1(gb);
-sps->implicit_rdpcm_enabled_flag = get_bits1(gb);
-
-sps->explicit_rdpcm_enabled_flag = get_bits1(gb);
-
-extended_precision_processing_flag = get_bits1(gb);
-if (extended_precision_processing_flag)
-av_log(s->avctx, AV_LOG_WARNING,
- "extended_precision_processing_flag not yet implemented\n");
-
-sps->intra_smoothing_disabled_flag = get_bits1(gb);
-high_precision_offsets_enabled_flag = get_bits1(gb);
-if (high_precision_offsets_enabled_flag)
-av_log(s->avctx, AV_LOG_WARNING,
- "high_precision_offsets_enabled_flag not yet implemented\n");
-
-sps->persistent_rice_adaptation_enabled_flag = get_bits1(gb);
-
-cabac_bypass_alignment_enabled_flag = get_bits1(gb);
-if (cabac_bypass_alignment_enabled_flag)
-av_log(s->avctx, AV_LOG_WARNING,
- "cabac_bypass_alignment_enabled_flag not yet implemented\n");
-}
-}
-if (s->apply_defdispwin) {
-sps->output_window.left_offset += sps->vui.def_disp_win.left_offset;
-sps->output_window.right_offset += sps->vui.def_disp_win.right_offset;
-sps->output_window.top_of
Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: add fontcolor option
On Thu, Aug 21, 2014 at 3:49 AM, Clément Bœsch wrote:
> On Wed, Aug 20, 2014 at 07:10:56AM +0700, Muhammad Faiz wrote:
> [...]
> > +static double r_func(void *p, double x)
> > +{
> > +x = av_clipd(x, 0.0, 1.0);
> > +return (int)(x*255.0+0.5) << 16;
>
> You can probably use lrint() here:
> return lrint(av_clipd(x, 0.0, 1.0) * 255.0) << 16;
>
I don't think so. According to libc doc, lrint round to integer according
to rounding mode, so sometimes it doesn't round to nearest.
> > +av_expr_free(fontcolor_expr);
> > av_expr_free(volume_expr);
> > av_expr_free(tlength_expr);
>
> drop these 3 lines...
>
> > end_time = av_gettime_relative();
> > @@ -482,6 +515,12 @@ static int config_output(AVFilterLink *outlink)
> > outlink->time_base = av_make_q(1, s->fps);
> > outlink->frame_rate = av_make_q(s->fps, 1);
>
> > return 0;
>
> ...drop this line as well...
>
> > +
> > +eval_error:
>
> ...and rename this to "out" or something more generic
>
> > +av_expr_free(fontcolor_expr);
> > +av_expr_free(volume_expr);
> > +av_expr_free(tlength_expr);
> > +return ret;
> > }
> >
>
It's just programming style. And there are more lines that should be
changed:
s->outpicref = ff_get_video_buffer(outlink, outlink->w, outlink->h);
if (!s->outpicref)
return AVERROR(ENOMEM);
s->spectogram = av_calloc(spectogram_height, s->outpicref->linesize[0]);
if (!s->spectogram)
return AVERROR(ENOMEM);
Please bump libavfilter/version.h micro and I'll probably apply this
> version.
>
Incremented.
Thank's
Muhammad Faiz
---
doc/filters.texi | 26
libavfilter/avf_showcqt.c | 102 --
libavfilter/version.h | 2 +-
3 files changed, 98 insertions(+), 32 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index a20253a..108cb00 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10610,6 +10610,26 @@ Default value is @code{3.0}.
@item fontfile
Specify font file for use with freetype. If not specified, use embedded font.
+@item fontcolor
+Specify font color expression. This is arithmetic expression that should return
+integer value 0xRRGGBB. The expression can contain variables:
+@table @option
+@item frequency, freq, f
+the frequency where transform is evaluated
+@item timeclamp, tc
+value of timeclamp option
+@end table
+and functions:
+@table @option
+@item midi(f)
+midi number of frequency f, some midi numbers: E0(16), C1(24), C2(36), A4(69)
+@item r(x), g(x), b(x)
+red, green, and blue value of intensity x
+@end table
+Default value is @code{st(0, (midi(f)-59.5)/12);
+st(1, if(between(ld(0),0,1), 0.5-0.5*cos(2*PI*ld(0)), 0));
+r(1-ld(1)) + b(ld(1))}
+
@item fullhd
If set to 1 (the default), the video size is 1920x1080 (full HD),
if set to 0, the video size is 960x540. Use this option to make CPU usage
lower.
@@ -10671,6 +10691,12 @@ Lower Q factor
tlength=100/f*tc/(100/f+tc)
@end example
+@item
+Custom fontcolor, C-note is colored green, others are colored blue
+@example
+fontcolor='if(mod(floor(midi(f)+0.5),12), 0xFF, g(1))'
+@end example
+
@end itemize
@section showspectrum
diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
index 012362b..e650f74 100644
--- a/libavfilter/avf_showcqt.c
+++ b/libavfilter/avf_showcqt.c
@@ -54,6 +54,9 @@
#define TLENGTH_DEFAULT "384/f*tc/(384/f+tc)"
#define VOLUME_MIN 1e-10
#define VOLUME_MAX 100.0
+#define FONTCOLOR_DEFAULT "st(0, (midi(f)-59.5)/12);" \
+"st(1, if(between(ld(0),0,1), 0.5-0.5*cos(2*PI*ld(0)), 0));" \
+"r(1-ld(1)) + b(ld(1))"
typedef struct {
FFTSample value;
@@ -73,7 +76,7 @@ typedef struct {
uint8_t *font_alpha;
char *fontfile; /* using freetype */
int coeffs_len[VIDEO_WIDTH];
-uint8_t font_color[VIDEO_WIDTH];
+uint8_t fontcolor_value[VIDEO_WIDTH*3]; /* result of fontcolor option */
int64_t frame_count;
int spectogram_count;
int spectogram_index;
@@ -82,6 +85,7 @@ typedef struct {
int remaining_fill;
char *tlength;
char *volume;
+char *fontcolor;
double timeclamp; /* lower timeclamp, time-accurate, higher timeclamp,
freq-accurate (at low freq)*/
float coeffclamp; /* lower coeffclamp, more precise, higher coeffclamp,
faster */
int fullhd; /* if true, output video is at full HD resolution,
otherwise it will be halved */
@@ -103,6 +107,7 @@ static const AVOption showcqt_options[] = {
{ "fps", "set video fps", OFFSET(fps), AV_OPT_TYPE_INT, { .i64 = 25 }, 10,
100, FLAGS },
{ "count", "set number of transform per frame", OFFSET(count),
AV_OPT_TYPE_INT, { .i64 = 6 }, 1, 30, FLAGS },
{ "fontfile", "set font file", OFFSET(fontfile), AV_OPT_TYPE_STRING, {
.str = NULL }, CHAR_MIN, CHAR_MAX, FLAGS },
+{ "fontcolor", "set font color", OFFSET(fontcolor), AV_OPT_TYPE_STRING, {
.str = FONTCOLOR_DEFAULT }, CHAR_MIN, CHAR_MAX, FLAGS },
{ NULL }
};
@@ -275,6 +28
Re: [FFmpeg-devel] [PATCH 2/2] huffyuvdec: fix old (v1) rgba
On Wed, Aug 20, 2014 at 11:19:48PM +, Christophe Gisquet wrote: > Commit deadcf5e misplaced a hunk. > > Fixes ticket #3877. > --- > libavcodec/huffyuvdec.c | 17 - > 1 file changed, 8 insertions(+), 9 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] fate: add test for old (v1) huffyuv and rgba
On Wed, Aug 20, 2014 at 11:19:47PM +, Christophe Gisquet wrote: > --- > tests/fate/vcodec.mak| 4 +++- > tests/ref/vsynth/vsynth1-huffyuvbgra | 4 > tests/ref/vsynth/vsynth2-huffyuvbgra | 4 > tests/ref/vsynth/vsynth3-huffyuvbgra | 4 > 4 files changed, 15 insertions(+), 1 deletion(-) > create mode 100644 tests/ref/vsynth/vsynth1-huffyuvbgra > create mode 100644 tests/ref/vsynth/vsynth2-huffyuvbgra > create mode 100644 tests/ref/vsynth/vsynth3-huffyuvbgra applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Thu, 14 Aug 2014 13:58:07 +0200 Stefano Sabatini wrote: > > If you trully want to mend ways, then you and your fellow FFmpeg > > developers should stop this constant spreading of lies, this > > defamation campaing against libav and its developers that has > > been going on for the last 3 and a half years and show at least > > the minimum respect you would show to a stranger you meet on the > > street. Until you do this, i see very little chance for a healthy > > cooperation. > > Please refrain from claiming other people are spreading lies, > especially with no specific references (and this is not the place > where to discuss such things). Carl Eugen just recently (2014-06-22) wrote on ffmpeg-devel: "Sean supports the thieves [...]" (http://article.gmane.org/gmane.comp.video.ffmpeg.devel/179271) Do i need to say more? I guess i speak in the name of everyone related to libav, that we would not mind if you kept saying that ffmpeg is better, faster, has more features, etc. That could be at least discussed on a technical, neutral level. What we mind are comments like that above, targeted solely at insulting and slander individuals. And as we can see from what Joe Neal wrote, the often repeated lie becomes truth soon enough. > Then you should be aware > that the way the Libav fork was created was hostile towards FFmpeg Actually, no. The whole thing started as getting Michael off his throne and to stop him screwing the whole project. It was not ment to be a fork. Attila Kinali -- I pity people who can't find laughter or at least some bit of amusement in the little doings of the day. I believe I could find something ridiculous even in the saddest moment, if necessary. It has nothing to do with being superficial. It's a matter of joy in life. -- Sophie Scholl ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] [PATCH] hevc_ps: reorder SPS reading to allow some errors
On Thu, Aug 21, 2014 at 02:06:39AM +0200, Christophe Gisquet wrote:
> Hi,
>
> ticket #3872 is about a regression on decoding of hevc:
> https://trac.ffmpeg.org/ticket/3872
>
> The reason is a stricter validation is now performed since 5ec85c97.
>
> The sequence seems invalid to me, as it seems the SPS was truncated or
> corrupted somewhere in the VUI. But if we ignore the a priori invalid
> SPS, the sequence actually decodes fine.
>
> It seems impossible to detect when this occurs:
> - A local test by remuxing hevc ES streams into mkv with mkvtoolnix
> 7.1.0 yielded valid streams, so this muxer is maybe not responsible
> (the file may have actually been transmuxed);
> - I don't see any obvious extra/userdata or anything allowing to
> identify the encoder (is it x265? the information has been stripped so
> it may be another encoder).
>
> The metadata (I bet irrelevant here) of this file, as found on
> ffmpeg's stdout, can be seen in the attached metadata.txt file
>
> I'm trying to dig more information to see how narrow a fix could be.
> H.264 in that case simply rejects the data.
heres a narrower solution for this file
not sure its better
i can apply whichever you prefer, probably we wont find out which
is the best solution before pushing something and waiting for more
bug reports
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 2ccce5f..64fb04b 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -552,6 +552,13 @@ static void decode_vui(HEVCContext *s, HEVCSPS *sps)
vui->vui_timing_info_present_flag = get_bits1(gb);
if (vui->vui_timing_info_present_flag) {
+if (get_bits_left(gb) < 66) {
+av_log(s->avctx, AV_LOG_WARNING,
+ "VUI timing information truncated, %d bits left\n",
+ get_bits_left(gb)
+);
+return;
+}
vui->vui_num_units_in_tick = get_bits_long(gb, 32);
vui->vui_time_scale = get_bits_long(gb, 32);
vui->vui_poc_proportional_to_timing_flag = get_bits1(gb);
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sat, 16 Aug 2014 17:11:29 +0200 Nicolas George wrote: > The most galling in this issue is that there is no clear decision behind > this orientation. The fork's manifesto stated that everyone was equal > amongst equals, with or without commit rights, but the people who do have > the commit rights are few and of a common mind, they can just give the cold > shoulder to proposed changes that do not suit their personal view of the > project. Err... If i counted correctly, there are currently 21 people who have commit rights to the libav repo. If you call that "few" i would like to know what you would consider as "many"? Also, i can asure you, that they are not of one mind. There are many fights on how to do things and whether a patch should go in or not. Heck, they are visible even to someone like me, who sits at the sidelines (i'm not a developer and have not written one line of code for libav. i dont even read the mailinglists). > Considering these differences in policy, I do not believe the fork can be > merged. Speaking as someone who proposed a few of these "unnecessary" > features, because they were fun or immediately useful, I would not like to > work on a project that would reject them by principle. "Though a program be but three lines long, someday it will have to be maintained." -- The Tao of Programming Attila Kinali -- I pity people who can't find laughter or at least some bit of amusement in the little doings of the day. I believe I could find something ridiculous even in the saddest moment, if necessary. It has nothing to do with being superficial. It's a matter of joy in life. -- Sophie Scholl ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, 18 Aug 2014 13:42:36 +0200 Nicolas George wrote: > The reason for switching from FFmpeg to libav in the first place just after > the fork is much simpler than that. Yes, the reason was that Reinhard, who was the maintainer of the ffmpeg package back then, was on the libav side after the split. BTW: for those who do not know. Michael raised the issue of the ffmpeg -> libav switch at ubuntu back then [1]. The technical board decided to go with the decision of the package maintainer [2,3,4]. I think most people will find [3] the most interesting, as it explains why Reinhard thought (and still thinks) that libav was the better choice. Attila Kinali [1] https://lists.ubuntu.com/archives/technical-board/2011-April/000794.html [2] http://irclogs.ubuntu.com/2011/05/19/%23ubuntu-meeting.html#t19:10 [3] https://lists.ubuntu.com/archives/technical-board/2011-May/000891.html [4] http://irclogs.ubuntu.com/2011/06/02/%23ubuntu-meeting.html#t19:01 -- I pity people who can't find laughter or at least some bit of amusement in the little doings of the day. I believe I could find something ridiculous even in the saddest moment, if necessary. It has nothing to do with being superficial. It's a matter of joy in life. -- Sophie Scholl ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Attila, I will do a small self-intro, as you most likely don't know me: I am a high school student who mainly writes documentation for FFmpeg, but sometimes do small code fixes and patch review (mainly related to documentation), both for FFmpeg and Libav. I sent my first patch to FFmpeg last year in March. I don't know much about the split, but I have read the most important discussions on ffmpeg-devel on the split. On Wed, Aug 20, 2014 at 6:52 PM, Attila Kinali wrote: > On Mon, 18 Aug 2014 13:42:36 +0200 > Nicolas George wrote: > >> The reason for switching from FFmpeg to libav in the first place just after >> the fork is much simpler than that. > > Yes, the reason was that Reinhard, who was the maintainer of the > ffmpeg package back then, was on the libav side after the split. > > BTW: for those who do not know. Michael raised the issue of > the ffmpeg -> libav switch at ubuntu back then [1]. The technical board > decided to go with the decision of the package maintainer [2,3,4]. > I think most people will find [3] the most interesting, as it explains > why Reinhard thought (and still thinks) that libav was the better choice. Most, if not all of the reasons in [3] have been eliminated, so bringing this up only causes more confusion. Also, the discussion appeared during a time when FFmpeg had flamewars, mainly from Libav developers. Because the split was just forming, FFmpeg was not that different from Libav then. It is not fair therefore to compare the two projects at that time. However, there are technical advantages towards FFmpeg now. Also, keep in mind that Debian cares about maintainable (and maintained) code **now** more than how a project leader behaves (or rather, behave_d_). I will now quote and explain how Reinhard's mail does not apply to the current FFmpeg/Libav situation. Reinhard Tartler wrote (https://lists.ubuntu.com/archives/technical-board/2011-May/000891.html): > On various occasions [Michael Niedermayer's] quite strict rules on code > quality and reviews doesn't seem to apply to him This has not been the case since the split (at least within the past year, as I joined FFmpeg last year). There are still some post-commit oopses, but not nearly to a level that brings a discussion among developers. > After the fork, Michael has insulted almost everyone involved with > founding Libav at least once, used libel and death threats as 'jokes', I don't mean that I don't believe your insulting story, but there is no public mailing list archive or IRC log or anything that supports this. Even if Michael did these terrible things, he is certainly not doing it now. The only "insult" I can find is in the thread you mentioned https://lists.ubuntu.com/archives/technical-board/2011-May/000900.html , which is an insult from Mans Rullgard, a former Libav developer and former former FFmpeg developer. > but OTOH keeps merging the work done at Libav both with and without > insults. I am interested to see any evidences to back up this statement. Note that Michael does sometimes express disagreement with Libav commits, but that's only because of technical issues, at least within the past year. Also from this quote Reinhard seems to not like the spirit of LGPL... > Interestingly, his standards and attitude to external work have > totally changed: He has committed his mplayer filter wrapper despite > predominant rejections, This is one of the most significant sources of new filters, and one of the reasons users (like me) use FFmpeg. > ffmpeg-mt has been merged (partially with wrong > attribution!) I can't comment on the mistake in attribution as I was not involved in FFmpeg during that time, and I am sure it is fixed (besides Git history, which is unfortunately unfixable). But the only people I have seen stripping attribution is Libav during their "cleanups", and Michael is actively restoring lost attribution: http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=commit&s=attribution See for example http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=libavcodec/me_cmp.c;fp=libavcodec/dsputil.c;h=9fcc93739a7c76fea5906bae94c174de558c132b;hp=ba71a99852d8f3fbad25f8ea7b4947e18e5592cd;hb=2d60444331fca1910510038dd3817bea885c2367;hpb=a578b0407dc983aecd72028e1127062689b67089 among others. > despite various tests still failing (when running them > with more than one thread), just to name a few. Well it doesn't fail anymore now, so this is not a viable argument now. > Now he argues that the > merged external branches make 'his' tree 'superior'. Well, it is ;) > If you look at the git commit statistics, you'll notice that > the developers with most commits (both numbers of commits and lines of > changed code) in the last year and three years before the fork are in > the Libav camp now. Look at http://lucy.pkh.me/ffstats/authors.html now. The following list is sorted in number of commits. Michael Niedermayer <-- FFmpeg Diego Biurrun <-- Libav Stefano Sabatini <-- FFmpeg Anton Khir
Re: [FFmpeg-devel] [PATCH] avutil/motion_vector.h: fix coordinate types
On Thu, Aug 21, 2014 at 12:01:51AM +0200, Michael Niedermayer wrote: > On Wed, Aug 20, 2014 at 11:30:27PM +0200, Clément Bœsch wrote: > > --- > > doc/APIchanges| 2 +- > > libavutil/motion_vector.h | 8 > > libavutil/version.h | 2 +- > > 3 files changed, 6 insertions(+), 6 deletions(-) > > > > diff --git a/doc/APIchanges b/doc/APIchanges > > index 1bed107..1fbeb09 100644 > > --- a/doc/APIchanges > > +++ b/doc/APIchanges > > @@ -15,7 +15,7 @@ libavutil: 2014-08-09 > > > > API changes, most recent first: > > > > -2014-08-xx - xxx - lavu 54.5.100 - frame.h motion_vector.h > > +2014-08-xx - b0352b1,xxx - lavu 54.6.100 - frame.h motion_vector.h > > what is "b0352b1,xxx" ? > b0352b1 is the main commit, at 54.5.100 xxx would be this "fixup" commit, at 54.6.100 We wouldn't really want the users to use the feature in 54.5.100 because of the bug I'm fixing, but "b0352b1 - lavu 54.6.100" would leave a version inconsistency. And OTOH referencing only the new hash doesn't give much insight on the feature/change mentioned. > i think an API is only really available and stable after 1 revission Yes, I'm sorry about that mistake, but the code was pushed only very recently. What do you suggest? > > rest LGTM > [...] -- Clément B. pgpUPm0nQqZUb.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
