[FFmpeg-devel] [PATCH] x86: hevc_mc: load less data in epel filters
This is already used for qpel/luma filters. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] x86: hevc_mc: replace one lea by add
Hi, I missed that occurrence in the previous patch. -- Christophe From 673b18b88e80650bfc7f898f2ac000147d2d71eb Mon Sep 17 00:00:00 2001 From: Christophe Gisquet Date: Fri, 25 Jul 2014 19:07:27 +0200 Subject: [PATCH 11/13] x86: hevc_mc: replace one lea by add Should have been in 036f11bdb565. --- libavcodec/x86/hevc_mc.asm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/x86/hevc_mc.asm b/libavcodec/x86/hevc_mc.asm index f0ef6a2..9cfebb8 100644 --- a/libavcodec/x86/hevc_mc.asm +++ b/libavcodec/x86/hevc_mc.asm @@ -378,7 +378,7 @@ QPEL_TABLE 12, 4, w, sse4 %macro LOOP_END 4 lea %1q, [%1q+2*%2q]; dst += dststride -lea %3q, [%3q+ %4q]; src += srcstride +add %3q, %4q; src += srcstride dec heightd ; cmp height jnz .loop ; height loop %endmacro -- 1.9.2.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86: hevc_mc: load less data in epel filters
2014-07-27 10:20 GMT+02:00 Christophe Gisquet : > This is already used for qpel/luma filters. And with patch. From 4c9ef00c805b5ea81d96955bdfbc57ab7b383934 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet Date: Fri, 25 Jul 2014 15:08:49 +0200 Subject: [PATCH 10/13] x86: hevc_mc: load less data in epel filters Before: 5679 decicycles in epel_bi, 2059976 runs, 37176 skips 3468 decicycles in epel_uni, 1040886 runs, 7690 skips After: 5323 decicycles in epel_bi, 2059493 runs, 37659 skips 3262 decicycles in epel_uni, 1040871 runs, 7705 skips --- libavcodec/x86/hevc_mc.asm | 22 +++--- 1 file changed, 15 insertions(+), 7 deletions(-) diff --git a/libavcodec/x86/hevc_mc.asm b/libavcodec/x86/hevc_mc.asm index a4b7a03..f0ef6a2 100644 --- a/libavcodec/x86/hevc_mc.asm +++ b/libavcodec/x86/hevc_mc.asm @@ -176,15 +176,23 @@ QPEL_TABLE 12, 4, w, sse4 %else %define rfilterq %2 %endif -movdqum0, [rfilterq ];load 128bit of x +%if (%1 == 8 && %4 <= 4) +%define %%load movd +%elif (%1 == 8 && %4 <= 8) || (%1 > 8 && %4 <= 4) +%define %%load movq +%else +%define %%load movdqu +%endif + +%%loadm0, [rfilterq ] %ifnum %3 -movdqum1, [rfilterq+ %3];load 128bit of x+stride -movdqum2, [rfilterq+2*%3];load 128bit of x+2*stride -movdqum3, [rfilterq+3*%3];load 128bit of x+3*stride +%%loadm1, [rfilterq+ %3] +%%loadm2, [rfilterq+2*%3] +%%loadm3, [rfilterq+3*%3] %else -movdqum1, [rfilterq+ %3q] ;load 128bit of x+stride -movdqum2, [rfilterq+2*%3q] ;load 128bit of x+2*stride -movdqum3, [rfilterq+r3srcq] ;load 128bit of x+2*stride +%%loadm1, [rfilterq+ %3q] +%%loadm2, [rfilterq+2*%3q] +%%loadm3, [rfilterq+r3srcq] %endif %if %1 == 8 -- 1.9.2.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] hevc_mc: reduce stride for bidir temp buffers
The stride is sometimes way bigger than actually needed. ptrdiff_t is
the actual type used. Aligning to 8 is needed as the lines must have
aligned addresses for SIMD.
--
Christophe
From 126adf820bc54c2d00f794629595ad6310fbfc37 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Sat, 26 Jul 2014 17:17:18 +0200
Subject: [PATCH 12/13] hevc_mc: reduce stride for bidir temp buffers
It is unconditionally set to 64, which is quite higher than the
actual block size.
---
libavcodec/hevc.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index a775f26..0f87b33 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -1357,6 +1357,7 @@ static void luma_mc_uni(HEVCContext *s, uint8_t *dst, ptrdiff_t dststride,
{
HEVCLocalContext *lc = s->HEVClc;
DECLARE_ALIGNED(16, int16_t, tmp[MAX_PB_SIZE * MAX_PB_SIZE]);
+ptrdiff_t tmpstride = FFALIGN(block_w, 8);
ptrdiff_t src0stride = ref0->linesize[0];
ptrdiff_t src1stride = ref1->linesize[0];
int pic_width= s->sps->width;
@@ -1410,13 +1411,13 @@ static void luma_mc_uni(HEVCContext *s, uint8_t *dst, ptrdiff_t dststride,
src1stride = edge_emu_stride;
}
-s->hevcdsp.put_hevc_qpel[idx][!!my0][!!mx0](tmp, MAX_PB_SIZE, src0, src0stride,
+s->hevcdsp.put_hevc_qpel[idx][!!my0][!!mx0](tmp, tmpstride, src0, src0stride,
block_h, mx0, my0, block_w);
if (!weight_flag)
-s->hevcdsp.put_hevc_qpel_bi[idx][!!my1][!!mx1](dst, dststride, src1, src1stride, tmp, MAX_PB_SIZE,
+s->hevcdsp.put_hevc_qpel_bi[idx][!!my1][!!mx1](dst, dststride, src1, src1stride, tmp, tmpstride,
block_h, mx1, my1, block_w);
else
-s->hevcdsp.put_hevc_qpel_bi_w[idx][!!my1][!!mx1](dst, dststride, src1, src1stride, tmp, MAX_PB_SIZE,
+s->hevcdsp.put_hevc_qpel_bi_w[idx][!!my1][!!mx1](dst, dststride, src1, src1stride, tmp, tmpstride,
block_h, s->sh.luma_log2_weight_denom,
s->sh.luma_weight_l0[current_mv->ref_idx[0]],
s->sh.luma_weight_l1[current_mv->ref_idx[1]],
@@ -1512,7 +1513,7 @@ static void chroma_mc_bi(HEVCContext *s, uint8_t *dst0, ptrdiff_t dststride, AVF
int x_off, int y_off, int block_w, int block_h, struct MvField *current_mv, int cidx)
{
DECLARE_ALIGNED(16, int16_t, tmp [MAX_PB_SIZE * MAX_PB_SIZE]);
-int tmpstride = MAX_PB_SIZE;
+ptrdiff_t tmpstride = FFALIGN(block_w, 8);
HEVCLocalContext *lc = s->HEVClc;
uint8_t *src1= ref0->data[cidx+1];
uint8_t *src2= ref1->data[cidx+1];
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] hevc_filter: run vertical and horizontal together
One may interleave even more vertical and horizontal passes, but this
is less straightforward (more code changes than just moves).
--
Christophe
From b48828b956d3a183d358ef9ad8a12f354c87da7d Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Sat, 26 Jul 2014 21:40:53 +0200
Subject: [PATCH 13/13] hevc_filter: run vertical and horizontal together
This should help cache locality. On win64:
Before: 1397x cycles, 16216 bytes
After: 1369x cycles, 16040 bytes
---
libavcodec/hevc_filter.c | 90
1 file changed, 45 insertions(+), 45 deletions(-)
diff --git a/libavcodec/hevc_filter.c b/libavcodec/hevc_filter.c
index 7a25b9f..d98f04c 100644
--- a/libavcodec/hevc_filter.c
+++ b/libavcodec/hevc_filter.c
@@ -375,8 +375,11 @@ static void deblocking_filter_CTB(HEVCContext *s, int x0, int y0)
tc_offset = cur_tc_offset;
beta_offset = cur_beta_offset;
-// vertical filtering luma
+x_end2 = x_end;
+if (x_end2 != s->sps->width)
+x_end2 -= 8;
for (y = y0; y < y_end; y += 8) {
+// vertical filtering luma
for (x = x0 ? x0 : 8; x < x_end; x += 8) {
const int bs0 = s->vertical_bs[(x + y * s->bs_width) >> 2];
const int bs1 = s->vertical_bs[(x + (y + 4) * s->bs_width) >> 2];
@@ -402,47 +405,12 @@ static void deblocking_filter_CTB(HEVCContext *s, int x0, int y0)
beta, tc, no_p, no_q);
}
}
-}
-
-// vertical filtering chroma
-for (chroma = 1; chroma <= 2; chroma++) {
-int h = 1 << s->sps->hshift[chroma];
-int v = 1 << s->sps->vshift[chroma];
-for (y = y0; y < y_end; y += (8 * v)) {
-for (x = x0 ? x0 : 8 * h; x < x_end; x += (8 * h)) {
-const int bs0 = s->vertical_bs[(x + y* s->bs_width) >> 2];
-const int bs1 = s->vertical_bs[(x + (y + (4 * v)) * s->bs_width) >> 2];
-if ((bs0 == 2) || (bs1 == 2)) {
-const int qp0 = (get_qPy(s, x - 1, y) + get_qPy(s, x, y) + 1) >> 1;
-const int qp1 = (get_qPy(s, x - 1, y + (4 * v)) + get_qPy(s, x, y + (4 * v)) + 1) >> 1;
+if(!y)
+ continue;
-c_tc[0] = (bs0 == 2) ? chroma_tc(s, qp0, chroma, tc_offset) : 0;
-c_tc[1] = (bs1 == 2) ? chroma_tc(s, qp1, chroma, tc_offset) : 0;
-src = &s->frame->data[chroma][(y >> s->sps->vshift[chroma]) * s->frame->linesize[chroma] + ((x >> s->sps->hshift[chroma]) << s->sps->pixel_shift)];
-if (pcmf) {
-no_p[0] = get_pcm(s, x - 1, y);
-no_p[1] = get_pcm(s, x - 1, y + (4 * v));
-no_q[0] = get_pcm(s, x, y);
-no_q[1] = get_pcm(s, x, y + (4 * v));
-s->hevcdsp.hevc_v_loop_filter_chroma_c(src,
- s->frame->linesize[chroma],
- c_tc, no_p, no_q);
-} else
-s->hevcdsp.hevc_v_loop_filter_chroma(src,
- s->frame->linesize[chroma],
- c_tc, no_p, no_q);
-}
-}
-}
-}
-
-// horizontal filtering luma
-x_end2 = x_end;
-if (x_end != s->sps->width)
-x_end -= 8;
-for (y = y0 ? y0 : 8; y < y_end; y += 8) {
-for (x = x0 ? x0 - 8 : 0; x < x_end; x += 8) {
+// horizontal filtering luma
+for (x = x0 ? x0 - 8 : 0; x < x_end2; x += 8) {
const int bs0 = s->horizontal_bs[( x + y * s->bs_width) >> 2];
const int bs1 = s->horizontal_bs[((x + 4) + y * s->bs_width) >> 2];
if (bs0 || bs1) {
@@ -471,15 +439,47 @@ static void deblocking_filter_CTB(HEVCContext *s, int x0, int y0)
}
}
-// horizontal filtering chroma
for (chroma = 1; chroma <= 2; chroma++) {
int h = 1 << s->sps->hshift[chroma];
int v = 1 << s->sps->vshift[chroma];
-if (x_end2 != s->sps->width)
- x_end = x_end2 - 8 * h;
-for (y = y0 ? y0 : 8 * v; y < y_end; y += (8 * v)) {
+
+// vertical filtering chroma
+for (y = y0; y < y_end; y += (8 * v)) {
+for (x = x0 ? x0 : 8 * h; x < x_end; x += (8 * h)) {
+const int bs0 = s->vertical_bs[(x + y* s->bs_width) >> 2];
+const int bs1 = s->vertical_bs[(x + (y + (4 * v)) * s->bs_width) >> 2];
+
+if ((bs0 == 2) || (bs1 == 2)) {
+const int qp0 = (get_qPy(s, x - 1, y) + get_qPy(s, x, y) + 1) >> 1;
+const int qp1 = (get_qPy(s, x - 1, y + (4 * v)) + get_qPy(s, x, y + (4 * v)) + 1) >> 1;
[FFmpeg-devel] [PATCH] avcodec: add avdct
This provides a public sustainable API/ABI for DCT functions.
Only externally used dct functions are included.
The structure is extensible without ABI issues compared to the
existing dct contexts.
See Mailing list and IRC log of 2014-07-26/27
Signed-off-by: Michael Niedermayer
---
libavcodec/Makefile |1 +
libavcodec/avdct.c | 119 +++
libavcodec/avdct.h | 76
3 files changed, 196 insertions(+)
create mode 100644 libavcodec/avdct.c
create mode 100644 libavcodec/avdct.h
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index c3e4f5d..814d43f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -15,6 +15,7 @@ HEADERS = avcodec.h
\
OBJS = allcodecs.o \
audioconvert.o \
+ avdct.o \
avpacket.o \
avpicture.o \
bitstream.o \
diff --git a/libavcodec/avdct.c b/libavcodec/avdct.c
new file mode 100644
index 000..75cb972
--- /dev/null
+++ b/libavcodec/avdct.c
@@ -0,0 +1,119 @@
+/*
+ * Copyright (c) 2014 Michael Niedermayer
+ *
+ * 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
+ */
+
+#include "avcodec.h"
+#include "idctdsp.h"
+#include "fdctdsp.h"
+#include "avdct.h"
+
+#define OFFSET(x) offsetof(AVDCT,x)
+#define DEFAULT 0 //should be NAN but it does not work as it is not a constant
in glibc as required by ANSI/ISO C
+//these names are too long to be readable
+#define V AV_OPT_FLAG_VIDEO_PARAM
+#define A AV_OPT_FLAG_AUDIO_PARAM
+#define E AV_OPT_FLAG_ENCODING_PARAM
+#define D AV_OPT_FLAG_DECODING_PARAM
+
+static const AVOption avdct_options[] = {
+{"dct", "DCT algorithm", OFFSET(dct_algo), AV_OPT_TYPE_INT, {.i64 = DEFAULT },
0, INT_MAX, V|E, "dct"},
+{"auto", "autoselect a good one (default)", 0, AV_OPT_TYPE_CONST, {.i64 =
FF_DCT_AUTO }, INT_MIN, INT_MAX, V|E, "dct"},
+{"fastint", "fast integer (expermintal / for debuging)", 0, AV_OPT_TYPE_CONST,
{.i64 = FF_DCT_FASTINT }, INT_MIN, INT_MAX, V|E, "dct"},
+{"int", "accurate integer", 0, AV_OPT_TYPE_CONST, {.i64 = FF_DCT_INT },
INT_MIN, INT_MAX, V|E, "dct"},
+{"mmx", "expermintal / for debuging", 0, AV_OPT_TYPE_CONST, {.i64 = FF_DCT_MMX
}, INT_MIN, INT_MAX, V|E, "dct"},
+{"altivec", "expermintal / for debuging", 0, AV_OPT_TYPE_CONST, {.i64 =
FF_DCT_ALTIVEC }, INT_MIN, INT_MAX, V|E, "dct"},
+{"faan", "floating point AAN DCT (expermintal / for debuging)", 0,
AV_OPT_TYPE_CONST, {.i64 = FF_DCT_FAAN }, INT_MIN, INT_MAX, V|E, "dct"},
+
+{"idct", "select IDCT implementation", OFFSET(idct_algo), AV_OPT_TYPE_INT,
{.i64 = DEFAULT }, 0, INT_MAX, V|E|D, "idct"},
+{"auto", "autoselect a good one (default)", 0, AV_OPT_TYPE_CONST, {.i64 =
FF_IDCT_AUTO }, INT_MIN, INT_MAX, V|E|D, "idct"},
+{"int", "expermintal / for debuging", 0, AV_OPT_TYPE_CONST, {.i64 =
FF_IDCT_INT }, INT_MIN, INT_MAX, V|E|D, "idct"},
+{"simple", "expermintal / for debuging", 0, AV_OPT_TYPE_CONST, {.i64 =
FF_IDCT_SIMPLE }, INT_MIN, INT_MAX, V|E|D, "idct"},
+{"simplemmx", "expermintal / for debuging", 0, AV_OPT_TYPE_CONST, {.i64 =
FF_IDCT_SIMPLEMMX }, INT_MIN, INT_MAX, V|E|D, "idct"},
+{"arm", "expermintal / for debuging", 0, AV_OPT_TYPE_CONST, {.i64 =
FF_IDCT_ARM }, INT_MIN, INT_MAX, V|E|D, "idct"},
+{"altivec", "expermintal / for debuging", 0, AV_OPT_TYPE_CONST, {.i64 =
FF_IDCT_ALTIVEC }, INT_MIN, INT_MAX, V|E|D, "idct"},
+#if FF_API_ARCH_SH4
+{"sh4", "expermintal / for debuging", 0, AV_OPT_TYPE_CONST, {.i64 =
FF_IDCT_SH4 }, INT_MIN, INT_MAX, V|E|D, "idct"},
+#endif
+{"simplearm", "expermintal / for debuging", 0, AV_OPT_TYPE_CONST, {.i64 =
FF_IDCT_SIMPLEARM }, INT_MIN, INT_MAX, V|E|D, "idct"},
+{"simplearmv5te", "expermintal / for debuging", 0, AV_OPT_TYPE_CONST, {.i64 =
FF_IDCT_SIMPLEARMV5TE }, INT_MIN, INT_MAX, V|E|D, "idct"},
+{"simplearmv6", "expermintal / for debuging", 0, AV_OPT_TYPE_CONST, {.i64 =
FF_IDCT_SIMPLEARMV6 }, INT_MIN, INT_MAX, V|E|D, "idct"},
+{"simplen
Re: [FFmpeg-devel] [PATCH] avcodec: add avdct
On Sun, Jul 27, 2014 at 03:41:55PM +0200, Michael Niedermayer wrote: > This provides a public sustainable API/ABI for DCT functions. > Only externally used dct functions are included. > The structure is extensible without ABI issues compared to the > existing dct contexts. > > See Mailing list and IRC log of 2014-07-26/27 > > Signed-off-by: Michael Niedermayer reviewed by ubitux applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avfilter: use AVDSP
On Sat, Jul 26, 2014 at 06:59:49PM +0200, Paul B Mahol wrote: > On Sat, Jul 26, 2014 at 3:34 PM, Michael Niedermayer > wrote: > > > Signed-off-by: Michael Niedermayer > > --- > > libavfilter/deshake.h |5 ++--- > > libavfilter/f_select.c | 20 > > libavfilter/vf_deshake.c| 16 +++- > > libavfilter/vf_mpdecimate.c | 26 +- > > libavfilter/vf_spp.c| 21 - > > libavfilter/vf_spp.h|9 ++--- > > 6 files changed, 36 insertions(+), 61 deletions(-) > > > lgtm applied the dct related part after elsewhere requested renamings and splitings [...] -- 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] x86: hevc_mc: replace one lea by add
On Sun, Jul 27, 2014 at 10:21:55AM +0200, Christophe Gisquet wrote: > Hi, > > I missed that occurrence in the previous patch. > > -- > Christophe > hevc_mc.asm |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > 38b1567fedb7e062334194ff364f14c5e7c99494 > 0011-x86-hevc_mc-replace-one-lea-by-add.patch > From 673b18b88e80650bfc7f898f2ac000147d2d71eb Mon Sep 17 00:00:00 2001 > From: Christophe Gisquet > Date: Fri, 25 Jul 2014 19:07:27 +0200 > Subject: [PATCH 11/13] x86: hevc_mc: replace one lea by add > > Should have been in 036f11bdb565. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/4] frame-mt: hevc: implement and use step progress API
On Wed, Jul 23, 2014 at 07:13:42PM +, Christophe Gisquet wrote: > The idea is that the current granularity is too small for bigger > coding structures, than can be 64x64 for both hevc and vp9. Instead, > the simplest way to describe the new type of progress is that of > a step function. > > I bet the patchset will be far from consensual, and it's unlikely I'll > get it through in a shape that satisfies everyone. It's mostly a > proof of concept. > > In the table below, 1T indicates the performance on one core, while > max means the default thread count. Furthermore, to benchmark the > modification, I also added some intrinsics (denoted by +idct). The > effect of the patchset is in the column +patch. > > The configurations tested are: > 1) HEAD on a 6-cores system > 2) HEAD + intrinsics (~openhevc) on the same system > 3) HEAD + intrinsics on a 2-cores system (with hyperthreading) > > Finally, the numbers reported are the decoding times in seconds. > > 1Tmax +idct +patch > 1: 26.2 9.5 7.26.2 > 2: 5.74.9 > 3: 13.2 6.56.3 > > Christophe Gisquet (4): > libavcodec: new API for frame threading by step > hevc: use new step progress API > hevc: actual benefits from new step threading API > hevc: use new step threading API for DBF-only cases > > libavcodec/hevc.c | 19 +++-- > libavcodec/hevc_filter.c | 26 -- > libavcodec/hevc_mvs.c | 4 +-- > libavcodec/hevc_refs.c | 2 +- > libavcodec/pthread_frame.c | 68 > -- > libavcodec/thread.h| 24 > 6 files changed, 121 insertions(+), 22 deletions(-) fails to build without pthreads ./configure --disable-pthreads && make libavcodec/libavcodec.a(hevc.o): In function `hevc_await_progress': ffmpeg/libavcodec/hevc.c:1609: undefined reference to `ff_thread_await_progress3' ffmpeg/libavcodec/hevc.c:1609: undefined reference to `ff_thread_await_progress3' libavcodec/libavcodec.a(hevc.o): In function `decode_nal_units': ffmpeg/libavcodec/hevc.c:2978: undefined reference to `ff_thread_report_progress3_raster_end' libavcodec/libavcodec.a(hevc.o): In function `hevc_frame_start': ffmpeg/libavcodec/hevc.c:2619: undefined reference to `ff_thread_report_progress3_raster_end' libavcodec/libavcodec.a(hevc_filter.o): In function `ff_hevc_hls_filter': ffmpeg/libavcodec/hevc_filter.c:724: undefined reference to `ff_thread_report_progress3_increment' ffmpeg/libavcodec/hevc_filter.c:718: undefined reference to `ff_thread_report_progress3_raster_end' ffmpeg/libavcodec/hevc_filter.c:703: undefined reference to `ff_thread_report_progress3_increment' ffmpeg/libavcodec/hevc_filter.c:708: undefined reference to `ff_thread_report_progress3_increment' ffmpeg/libavcodec/hevc_filter.c:713: undefined reference to `ff_thread_report_progress3_raster_end' ffmpeg/libavcodec/hevc_filter.c:722: undefined reference to `ff_thread_report_progress3_raster_end' libavcodec/libavcodec.a(hevc_mvs.o): In function `temporal_luma_motion_vector': ffmpeg/libavcodec/hevc_mvs.c:261: undefined reference to `ff_thread_await_progress3' ffmpeg/libavcodec/hevc_mvs.c:247: undefined reference to `ff_thread_await_progress3' libavcodec/libavcodec.a(hevc_refs.o): In function `generate_missing_ref': ffmpeg/libavcodec/hevc_refs.c:416: undefined reference to `ff_thread_report_progress3_raster_end' collect2: ld returned 1 exit status [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86: hevc_mc: load less data in epel filters
On Sun, Jul 27, 2014 at 10:22:26AM +0200, Christophe Gisquet wrote: > 2014-07-27 10:20 GMT+02:00 Christophe Gisquet : > > This is already used for qpel/luma filters. > > And with patch. > hevc_mc.asm | 22 +++--- > 1 file changed, 15 insertions(+), 7 deletions(-) > 91c1f7b09674819ea03b161f4a99b41cd64e5c77 > 0010-x86-hevc_mc-load-less-data-in-epel-filters.patch > From 4c9ef00c805b5ea81d96955bdfbc57ab7b383934 Mon Sep 17 00:00:00 2001 > From: Christophe Gisquet > Date: Fri, 25 Jul 2014 15:08:49 +0200 > Subject: [PATCH 10/13] x86: hevc_mc: load less data in epel filters > > Before: > 5679 decicycles in epel_bi, 2059976 runs, 37176 skips > 3468 decicycles in epel_uni, 1040886 runs, 7690 skips > > After: > 5323 decicycles in epel_bi, 2059493 runs, 37659 skips > 3262 decicycles in epel_uni, 1040871 runs, 7705 skips > --- > libavcodec/x86/hevc_mc.asm | 22 +++--- > 1 file changed, 15 insertions(+), 7 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hevc_mc: reduce stride for bidir temp buffers
On Sun, Jul 27, 2014 at 10:24:43AM +0200, Christophe Gisquet wrote: > The stride is sometimes way bigger than actually needed. ptrdiff_t is > the actual type used. Aligning to 8 is needed as the lines must have > aligned addresses for SIMD. > > -- > Christophe > hevc.c |9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > 2445ba15d38b2472f8f1b24aa75e63c089971480 > 0012-hevc_mc-reduce-stride-for-bidir-temp-buffers.patch > From 126adf820bc54c2d00f794629595ad6310fbfc37 Mon Sep 17 00:00:00 2001 > From: Christophe Gisquet > Date: Sat, 26 Jul 2014 17:17:18 +0200 > Subject: [PATCH 12/13] hevc_mc: reduce stride for bidir temp buffers > > It is unconditionally set to 64, which is quite higher than the > actual block size. is this faster? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/setpts: allow to parse a metadata tag as a timestamp.
On Thu, Jul 24, 2014 at 08:01:24PM +0200, Nicolas George wrote: > Signed-off-by: Nicolas George > --- > doc/filters.texi | 22 ++ > libavfilter/setpts.c | 64 > ++- > libavfilter/version.h | 2 +- > 3 files changed, 86 insertions(+), 2 deletions(-) probably ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hevc_mc: reduce stride for bidir temp buffers
Hi Christophe >> hevc.c |9 + >> 1 file changed, 5 insertions(+), 4 deletions(-) >> 2445ba15d38b2472f8f1b24aa75e63c089971480 >> 0012-hevc_mc-reduce-stride-for-bidir-temp-buffers.patch >> From 126adf820bc54c2d00f794629595ad6310fbfc37 Mon Sep 17 00:00:00 2001 >> From: Christophe Gisquet >> Date: Sat, 26 Jul 2014 17:17:18 +0200 >> Subject: [PATCH 12/13] hevc_mc: reduce stride for bidir temp buffers >> >> It is unconditionally set to 64, which is quite higher than the >> actual block size. > > is this faster? > > [...] I have the same concern. what is the gain? Mickaël ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] ABI (in)stability of FFmpeg
Hi, the commit message of 6e8e9f1e517ee52fe439f3e8ca762f09d235f21e reads: "Merge commit '8c02adc62d71dfbb079a04753d8c16152c49de88' * commit '8c02adc62d71dfbb079a04753d8c16152c49de88': lavu: add all color-related enums to AVFrame Conflicts: libavcodec/avcodec.h libavutil/frame.c libavutil/frame.h libavutil/version.h The version check is changed so they are available with the current ABI FFmpeg libs should have no problems with added fields, nor should any application using the libs, and we regularly added fields in the past. We also moved 2 of these fields to AVFrame already previously without issues." This seems to be wrong, at least vlc has a problem with this. If you compile it against 2.2 and then install a version of FFmpeg containing this commit, without recompiling vlc against it, the following crash can be observed: $ vlc Test.wmv VLC media player 2.1.4 Rincewind (revision 2.1.4-0-g2a072be) [0x74c6b8] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. *** Error in `Fontconfig warning: FcPattern object size does not accept value "0" vlc': free(): invalid pointer: 0x7f0e20d7db38 *** Aborted (core dumped) The backtrace is: #0 0x7f0e5b77e407 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x7f0e5b77f7e8 in __GI_abort () at abort.c:89 #2 0x7f0e5b7bc394 in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7f0e5b8af010 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175 #3 0x7f0e5b7c1b6e in malloc_printerr (action=1, str=0x7f0e5b8ab0c8 "free(): invalid pointer", ptr=) at malloc.c:4996 #4 0x7f0e5b7c2876 in _int_free (av=, p=out>, have_lock=0) at malloc.c:3840 #5 0x7f0e1e5b9d80 in av_freep (arg=arg@entry=0x7f0e1bd50da8) at libavutil/mem.c:239 #6 0x7f0e1e5aaa0d in av_buffer_unref (buf=buf@entry=0x7f0e1bd50da8) at libavutil/buffer.c:112 #7 0x7f0e1e5b2806 in av_frame_unref (frame=0x7f0e1bd50b30) at libavutil/frame.c:382 #8 0x7f0e1ed1e429 in avcodec_decode_audio4 (avctx=0x7f0e20d7e620, frame=0x7f0e1bd50b30, got_frame_ptr=0x7f0e1bd50acc, avpkt=0x7f0e1bd50ad0) at libavcodec/utils.c:2412 #9 0x7f0e1f9e3977 in DecodeAudio (p_dec=0x7f0e20d7db38, pp_block=0x7f0e1bd50e28) at avcodec/audio.c:287 #10 0x7f0e5b49a61e in DecoderDecodeAudio (p_dec=p_dec@entry=0x7f0e20d7db38, p_block=p_block@entry=0x7f0e20dbd520) at input/decoder.c:1259 #11 0x7f0e5b49c1a1 in DecoderProcessAudio (b_flush=false, p_block=0x7f0e20dbd520, p_dec=) at input/decoder.c:1889 #12 DecoderProcess (p_block=, p_dec=) at input/decoder.c:2010 #13 DecoderThread (p_data=0x7f0e20d7db38) at input/decoder.c:936 #14 0x7f0e5bcfe0a4 in start_thread (arg=0x7f0e1bd51700) at pthread_create.c:309 #15 0x7f0e5b82f04d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 So I suggest to revert to the old ABI until the next soversion bump. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc/decoders: mention native Opus decoder
Signed-off-by: Lou Logan
---
doc/decoders.texi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 9309b82..6910dc1 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -163,6 +163,9 @@ Requires the presence of the libopus headers and library
during
configuration. You need to explicitly configure the build with
@code{--enable-libopus}.
+An FFmpeg native decoder for Opus exists, so users can decode Opus
+without this library.
+
@c man end AUDIO DECODERS
@chapter Subtitles Decoders
--
2.0.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [RFC]Add int64_t probesize2 to AVFormatContext
Hi!
Some DVD dumps contain subtitles that start after more than 2G,
attached patch should allow to specify sufficiently large
values for -probesize.
Please review, Carl Eugen
diff --git a/doc/APIchanges b/doc/APIchanges
index c4e7790..e114df4 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2012-10-22
API changes, most recent first:
+2014-07-27 - XXX - lavf 55.50.100 - avformat.h
+ New field int64_t probesize2 instead of deprecated
+ int probesize.
+
2014-07-27 - XXX - lavc 55.70.100 - avdct.h
Add AVDCT / avcodec_dct_alloc() / avcodec_dct_init().
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 66638c8..483eb8f 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1285,9 +1285,7 @@ typedef struct AVFormatContext {
#define AVFMT_FLAG_KEEP_SIDE_DATA 0x4 ///< Don't merge side data but keep
it separate.
/**
- * Maximum size of the data read from input for determining
- * the input container format.
- * Demuxing only, set by the caller before avformat_open_input().
+ * @deprecated deprecated in favor of probesize2
*/
unsigned int probesize;
@@ -1660,6 +1658,14 @@ typedef struct AVFormatContext {
* Can be set to 0 to let avformat choose using a heuristic.
*/
int64_t max_analyze_duration2;
+
+/**
+ * Maximum size of the data read from input for determining
+ * the input container format.
+ * Demuxing only, set by the caller before avformat_open_input()
+ * via AVOptions (NO direct access).
+ */
+int64_t probesize2;
} AVFormatContext;
int av_format_get_probe_score(const AVFormatContext *s);
diff --git a/libavformat/avio_internal.h b/libavformat/avio_internal.h
index bb25127..5864048 100644
--- a/libavformat/avio_internal.h
+++ b/libavformat/avio_internal.h
@@ -95,7 +95,7 @@ int ffio_set_buf_size(AVIOContext *s, int buf_size);
* within the current pos and pos+buf_size is possible.
* Once the stream position moves outside this window this guarantee is lost.
*/
-int ffio_ensure_seekback(AVIOContext *s, int buf_size);
+int ffio_ensure_seekback(AVIOContext *s, int64_t buf_size);
int ffio_limit(AVIOContext *s, int size);
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 24c6b79..c7e9203 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -767,7 +767,7 @@ int ffio_fdopen(AVIOContext **s, URLContext *h)
return 0;
}
-int ffio_ensure_seekback(AVIOContext *s, int buf_size)
+int ffio_ensure_seekback(AVIOContext *s, int64_t buf_size)
{
uint8_t *buffer;
int max_buffer_size = s->max_packet_size ?
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 04bc865..405cade 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2242,12 +2242,13 @@ static void finished_reading_packet(AVFormatContext *s,
int raw_packet_size)
avio_skip(pb, skip);
}
-static int handle_packets(MpegTSContext *ts, int nb_packets)
+static int handle_packets(MpegTSContext *ts, int64_t nb_packets)
{
AVFormatContext *s = ts->stream;
uint8_t packet[TS_PACKET_SIZE + FF_INPUT_BUFFER_PADDING_SIZE];
const uint8_t *data;
-int packet_num, ret = 0;
+int64_t packet_num;
+int ret = 0;
if (avio_tell(s->pb) != ts->last_pos) {
int i;
@@ -2369,9 +2370,9 @@ static int mpegts_read_header(AVFormatContext *s)
AVIOContext *pb = s->pb;
uint8_t buf[8 * 1024] = {0};
int len;
-int64_t pos;
+int64_t pos, probesize = s->probesize ? s->probesize : s->probesize2;
-ffio_ensure_seekback(pb, s->probesize);
+ffio_ensure_seekback(pb, probesize);
/* read the first 8192 bytes to get packet size */
pos = avio_tell(pb);
@@ -2394,7 +2395,7 @@ static int mpegts_read_header(AVFormatContext *s)
mpegts_open_section_filter(ts, PAT_PID, pat_cb, ts, 1);
-handle_packets(ts, s->probesize / ts->raw_packet_size);
+handle_packets(ts, probesize / ts->raw_packet_size);
/* if could not find service, enable auto_guess */
ts->auto_guess = 1;
diff --git a/libavformat/options_table.h b/libavformat/options_table.h
index e3943fd..94cd65c 100644
--- a/libavformat/options_table.h
+++ b/libavformat/options_table.h
@@ -36,7 +36,7 @@
static const AVOption avformat_options[] = {
{"avioflags", NULL, OFFSET(avio_flags), AV_OPT_TYPE_FLAGS, {.i64 = DEFAULT },
INT_MIN, INT_MAX, D|E, "avioflags"},
{"direct", "reduce buffering", 0, AV_OPT_TYPE_CONST, {.i64 = AVIO_FLAG_DIRECT
}, INT_MIN, INT_MAX, D|E, "avioflags"},
-{"probesize", "set probing size", OFFSET(probesize), AV_OPT_TYPE_INT, {.i64 =
500 }, 32, INT_MAX, D},
+{"probesize", "set probing size", OFFSET(probesize2), AV_OPT_TYPE_INT64, {.i64
= 500 }, 32, INT64_MAX, D},
{"formatprobesize", "number of bytes to probe file format",
OFFSET(format_probesize), AV_OPT_TYPE_INT, {.i64 = PROBE_BUF_MAX}, 0,
INT_MAX-1, D},
{"packetsize", "set packet size", OFFSET(packe
Re: [FFmpeg-devel] [PATCH] doc/decoders: mention native Opus decoder
On Sun, Jul 27, 2014 at 1:48 PM, Lou Logan wrote: > Signed-off-by: Lou Logan > --- > doc/decoders.texi | 3 +++ > 1 file changed, 3 insertions(+) OK. [...] Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/decoders: mention native Opus decoder
On Sun, 27 Jul 2014 14:33:54 -0700, Timothy Gu wrote: > OK. Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Add int64_t probesize2 to AVFormatContext
On Sun, 27 Jul 2014 22:52:26 +0200 Carl Eugen Hoyos wrote: > Hi! > > Some DVD dumps contain subtitles that start after more than 2G, > attached patch should allow to specify sufficiently large > values for -probesize. > > Please review, Carl Eugen DVD images have metadata that tell you the number of subtitles in advance. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Add int64_t probesize2 to AVFormatContext
Le nonidi 9 thermidor, an CCXXII, wm4 a écrit : > DVD images have metadata that tell you the number of subtitles in > advance. Surely you are aware that ffmpeg is not capable to read it? Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Add int64_t probesize2 to AVFormatContext
On Sun, 27 Jul 2014 23:56:21 +0200 Nicolas George wrote: > Le nonidi 9 thermidor, an CCXXII, wm4 a écrit : > > DVD images have metadata that tell you the number of subtitles in > > advance. > > Surely you are aware that ffmpeg is not capable to read it? I have the impression that there are big hacks going on to compensate for that, such as trying to read 2GB without doing anything just to find all subtitle streams. A proper approach would probably involve adding libdvdread support or such to ffmpeg. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Add int64_t probesize2 to AVFormatContext
Le decadi 10 thermidor, an CCXXII, wm4 a écrit : > I have the impression that there are big hacks going on to compensate > for that, such as trying to read 2GB without doing anything just to > find all subtitle streams. The IFO files of a DVD structure are already a big hack, because MPEG-PS is a crappy format. > A proper approach would probably involve adding libdvdread support or > such to ffmpeg. That would be nice, thanks for proposing. But that would not fix the issue: not all MPEG-PS files come with a DVD structure, even ones with subtitles, people often dump the MPEG-PS stream and discard the corresponding IFO files. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi all,
some of you may have noticed a weird ffmpeg package in the NEW queue[1].
Let me explain:
In 2011 Libav[2] was forked from FFmpeg[3]. It was a time of great
uncertainty, the fork happened with much drama that didn't help making a
technical cut, and at that peculiar time Debian switched to Libav.
Since then the two projects evolved differently, and we have now a
clearer view.
Some short answers to questions you might have now:
* Why is FFmpeg needed in Debian?
- It has features our users are asking for (mostly support for more
codecs, formats and filters)[4-6].
- Some applications break when built against Libav on Debian,
because they are developed using FFmpeg[7-10].
- There are issues[11-12] in Libav's command line tools, that can't
be reproduced with FFmpeg's tools.
- It has a big and active user and developer community. Those of
them who want to use Debian currently need to install FFmpeg from
third parties or compile their own version from source.
* Do you intend to replace Libav by FFmpeg in Debian?
No, there is no need to replace anything as long as it is maintained.
Currently the main goal is to give multimedia maintainers a choice
between the two sets of libraries to link against, and our users the
choice to use the 'ffmpeg' utility. That is possible, because the
packages are co-installable. (Only the *-dev packages conflict.)
* But I thought they were forks, why don't you just create conflicting
packages?
- Because it can't really work! If we do that, packages built with
FFmpeg won't be installable next to packages built with Libav
unless we have full binary compatibility.
- Binary compatibility can only be achieved with some tradeoffs:
a) Not all soversions of the libraries match, so we would have
to patch that away.
b) FFmpeg would have to be compiled with the configure option
--enable-incompatible-libav-abi, resulting in less tested
code paths.
c) FFmpeg and Libav would need to be updated at the same time.
d) The biggest problem is that this would allow applications only
to use the minimal set of the ABI supported by both.
* I do not believe you, explain that voodoo to me: How is it that it
won't break all of Debian and make kittens cry?
(aka: How is FFmpeg packaged for Debian?)
- We built the packages in a way that avoids filename conflicts.
The sonames of the FFmpeg libraries are suffixed with '-ffmpeg',
e.g. libavcodec-ffmpeg.so.55 instead of libavcodec.so.55.
This also means that only if a package uses pkg-config to detect
the correct linker flags, you can simply install e.g. the
libavcodec-ffmpeg-dev package and it will work transparently.
(About half the packages build with no further change, see
stats below.)
- From a user point of view, the tools have different names anyway,
e.g. ffmpeg and avconv, except for qt-faststart, which is
therefore packaged in a separate binary package that diverts
the Libav version to qt-faststart.libav.
Yes, you can have /usr/bin/ffmpeg and /usr/bin/avconv at the same
time without conflicts.
- The development packages have to conflict, because they provide
header files (and pkg-config files) with identical names in
identical locations.
- To avoid potential problems when a program is linked against
FFmpeg libraries and other libraries, which in turn are linked
against Libav, the symbol versions are changed to e.g.
LIBAVCODEC_FFMPEG_55 instead of LIBAVCODEC_55.
* Ok, let's say I'm a multimedia maintainer and want to try out
building my package against your ffmpeg, what should I do?
- If your package uses pkg-config, which is commonly the case, all
you have to do is to replace all lib{av,swscale,postproc}*-dev
build-dependencies by lib{av,swscale,postproc}*-ffmpeg-dev.
You can keep the Libav build-dependencies as alternatives.
- In the (odd) case your upstream doesn't use pkg-config
(52 packages), it's probably a good idea to start using it, so
that the program can be easily built with both.
The patches are usually quite simple as you can see in this
example:
--- squeezelite-1.6.orig/Makefile
+++ squeezelite-1.6/Makefile
@@ -26,7 +26,7 @@ LINK_ALSA= -lasound
LINK_PORTAUDIO = -lportaudio
LINKALL = -lFLAC -lmad -lvorbisfile -lfaad -lmpg123
-LINKALL_FF = -lavcodec -lavformat -lavutil
+LINKALL_FF = $(shell pkg-config --libs libavcodec libavformat
libavutil)
LINKALL_RESAMPLE = -lsoxr
DEPS = squeezelite.h slimproto.h
Patches for packages using Autoconf or Cmake are similarly
straight-forward.
- Sometimes other minor adjustments are needed. (13 packages)
- There are only 2 packages (opencv and ffms2) that would trigger a
needed transition, but that woul
[FFmpeg-devel] [PATCH 1/2] remove VERSION file
it overrides what version.sh prints and thus makes its output from release branches rather useless Signed-off-by: Michael Niedermayer --- VERSION |1 - 1 file changed, 1 deletion(-) delete mode 100644 VERSION diff --git a/VERSION b/VERSION deleted file mode 100644 index bb576db..000 --- a/VERSION +++ /dev/null @@ -1 +0,0 @@ -2.3 -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] version.sh: Print versions based on the last git tag for release branches
release branches are detected by checking if "git" is not in RELEASE This changes "N-64706-g2f71aeb" to "n2.3-8-g2f71aeb" for git master theres no change This should improve the readability of lists of versions which come from more than 1 release branch or master + release. fate.ffmpeg.org is one possible example Signed-off-by: Michael Niedermayer --- version.sh |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/version.sh b/version.sh index 92edcb9..f9754eb 100755 --- a/version.sh +++ b/version.sh @@ -4,7 +4,11 @@ # check for git short hash if ! test "$revision"; then -revision=$(cd "$1" && git describe --tags --match N 2> /dev/null) +if (cd "$1" && grep git RELEASE 2> /dev/null >/dev/null) ; then +revision=$(cd "$1" && git describe --tags --match N 2> /dev/null) +else +revision=$(cd "$1" && git describe --tags --always 2> /dev/null) +fi fi # Shallow Git clones (--depth) do not have the N tag: -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] ABI (in)stability of FFmpeg
On Sun, Jul 27, 2014 at 10:18:16PM +0200, Andreas Cadhalpun wrote: > Hi, > > the commit message of 6e8e9f1e517ee52fe439f3e8ca762f09d235f21e reads: > "Merge commit '8c02adc62d71dfbb079a04753d8c16152c49de88' > > * commit '8c02adc62d71dfbb079a04753d8c16152c49de88': > lavu: add all color-related enums to AVFrame > > Conflicts: > libavcodec/avcodec.h > libavutil/frame.c > libavutil/frame.h > libavutil/version.h > > The version check is changed so they are available with the current ABI > FFmpeg libs should have no problems with added fields, nor should any > application using the libs, and we regularly added fields in the past. > We also moved 2 of these fields to AVFrame already previously > without issues." > > This seems to be wrong, at least vlc has a problem with this. > If you compile it against 2.2 and then install a version of FFmpeg > containing this commit, without recompiling vlc against it, the > following crash can be observed: :( i see: 2a072be:modules/codec/avcodec/audio.c:AVFrame frame; 2a072be:modules/codec/avcodec/audio.c-memset( &frame, 0, sizeof( frame ) ); That looks like there is code that depends on sizeof(AVFrame) in vlc 2.1.4, that is upstream vlc, i didnt check if this is also in debian both ffmpeg since 1.1 and libav since v9 contain this: "* sizeof(AVFrame) is not a part of the public ABI, so new fields may be added" also there where fields added to AVFrame between each release since at least FFmpeg 2.0 [...] > So I suggest to revert to the old ABI until the next soversion bump. This would be possible, i will send a patch for discussion [...] -- 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
[FFmpeg-devel] [PATCH] Delay FF_API_AVFRAME_COLORSPACE until the next libavutil soname bump
This works around ABI issues with applications which depend on libavutil
internal values like sizeof(AVFrame)
One such application is VLC 2.1.4 as well as 2.1.5
Found-by: Andreas Cadhalpun
Signed-off-by: Michael Niedermayer
---
libavcodec/utils.c |8
libavutil/frame.c |8
libavutil/frame.h | 20
libavutil/version.h |2 +-
4 files changed, 29 insertions(+), 9 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 6071380..26baa94 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -780,15 +780,15 @@ int ff_init_buffer_info(AVCodecContext *avctx, AVFrame
*frame)
}
frame->reordered_opaque = avctx->reordered_opaque;
+if (av_frame_get_colorspace(frame) == AVCOL_SPC_UNSPECIFIED)
+av_frame_set_colorspace(frame, avctx->colorspace);
+if (av_frame_get_color_range(frame) == AVCOL_RANGE_UNSPECIFIED)
+av_frame_set_color_range(frame, avctx->color_range);
#if FF_API_AVFRAME_COLORSPACE
if (frame->color_primaries == AVCOL_PRI_UNSPECIFIED)
frame->color_primaries = avctx->color_primaries;
if (frame->color_trc == AVCOL_TRC_UNSPECIFIED)
frame->color_trc = avctx->color_trc;
-if (av_frame_get_colorspace(frame) == AVCOL_SPC_UNSPECIFIED)
-av_frame_set_colorspace(frame, avctx->colorspace);
-if (av_frame_get_color_range(frame) == AVCOL_RANGE_UNSPECIFIED)
-av_frame_set_color_range(frame, avctx->color_range);
if (frame->chroma_location == AVCHROMA_LOC_UNSPECIFIED)
frame->chroma_location = avctx->chroma_sample_location;
#endif
diff --git a/libavutil/frame.c b/libavutil/frame.c
index fdfbc46..f18f9c1 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -104,11 +104,11 @@ static void get_frame_defaults(AVFrame *frame)
frame->sample_aspect_ratio = (AVRational){ 0, 1 };
frame->format = -1; /* unknown */
frame->extended_data = frame->data;
+frame->colorspace = AVCOL_SPC_UNSPECIFIED;
+frame->color_range = AVCOL_RANGE_UNSPECIFIED;
#if FF_API_AVFRAME_COLORSPACE
frame->color_primaries = AVCOL_PRI_UNSPECIFIED;
frame->color_trc = AVCOL_TRC_UNSPECIFIED;
-frame->colorspace = AVCOL_SPC_UNSPECIFIED;
-frame->color_range = AVCOL_RANGE_UNSPECIFIED;
frame->chroma_location = AVCHROMA_LOC_UNSPECIFIED;
#endif
}
@@ -482,11 +482,11 @@ int av_frame_copy_props(AVFrame *dst, const AVFrame *src)
dst->display_picture_number = src->display_picture_number;
dst->flags = src->flags;
dst->decode_error_flags = src->decode_error_flags;
+dst->colorspace = src->colorspace;
+dst->color_range= src->color_range;
#if FF_API_AVFRAME_COLORSPACE
dst->color_primaries= src->color_primaries;
dst->color_trc = src->color_trc;
-dst->colorspace = src->colorspace;
-dst->color_range= src->color_range;
dst->chroma_location= src->chroma_location;
#endif
diff --git a/libavutil/frame.h b/libavutil/frame.h
index a39c8d0..93d27ad 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -526,6 +526,26 @@ typedef struct AVFrame {
*/
int pkt_size;
+#if !FF_API_AVFRAME_COLORSPACE
+/**
+ * MPEG vs JPEG YUV range.
+ * It must be accessed using av_frame_get_color_range() and
+ * av_frame_set_color_range().
+ * - encoding: Set by user
+ * - decoding: Set by libavcodec
+ */
+enum AVColorRange color_range;
+
+/**
+ * YUV colorspace type.
+ * It must be accessed using av_frame_get_colorspace() and
+ * av_frame_set_colorspace().
+ * - encoding: Set by user
+ * - decoding: Set by libavcodec
+ */
+enum AVColorSpace colorspace;
+#endif
+
/**
* Not to be accessed directly from outside libavutil
*/
diff --git a/libavutil/version.h b/libavutil/version.h
index 6d8d6f0..1deb6e4 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -138,7 +138,7 @@
#define FF_API_OPT_TYPE_METADATA(LIBAVUTIL_VERSION_MAJOR < 54)
#endif
#ifndef FF_API_AVFRAME_COLORSPACE
-#define FF_API_AVFRAME_COLORSPACE (LIBAVUTIL_VERSION_MAJOR >= 52)
+#define FF_API_AVFRAME_COLORSPACE (LIBAVUTIL_VERSION_MAJOR >= 53)
#endif
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] version.sh: Print versions based on the last git tag for release branches
On Sun, Jul 27, 2014 at 5:49 PM, Michael Niedermayer wrote: > release branches are detected by checking if "git" is not in RELEASE > This changes "N-64706-g2f71aeb" to "n2.3-8-g2f71aeb" > for git master theres no change > > This should improve the readability of lists of versions which come from > more than 1 release branch or master + release. fate.ffmpeg.org is > one possible example Preferably this change also applies to master branch so that version is like 2.3.git-N-*, but this patch is OK for me. [...] Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
