Re: [FFmpeg-devel] [PATCH 2/2] avcodec: loongson relocate constants of idctdsp and h264pred
sorry, the last patch aborded, please review this one.
because it could avoid to use load when use immediate value ff_pb_80 in
idctdsp_mmi.c.
---
From 40399677fd67087db950c7f0f8ca382e5bc2cfd2 Mon Sep 17 00:00:00 2001
From: ZhouXiaoyong
Date: Mon, 20 Jul 2015 11:07:05 +0800
Subject: [PATCH 2/2] avcodec: loongson relocate constants of idctdsp and
h264pred
Signed-off-by: ZhouXiaoyong
---
libavcodec/mips/constants.c| 5
libavcodec/mips/constants.h| 5
libavcodec/mips/h264pred_mmi.c | 61 --
libavcodec/mips/idctdsp_mmi.c | 8 +++---
4 files changed, 36 insertions(+), 43 deletions(-)
diff --git a/libavcodec/mips/constants.c b/libavcodec/mips/constants.c
index 84841c2..a25fd24 100644
--- a/libavcodec/mips/constants.c
+++ b/libavcodec/mips/constants.c
@@ -42,6 +42,8 @@ DECLARE_ALIGNED(8, const uint64_t, ff_pw_1to4) =
{0x0004000300020001ULL};
DECLARE_ALIGNED(8, const uint64_t, ff_pw_5to8) ={0x0008000700060005ULL};
DECLARE_ALIGNED(8, const uint64_t, ff_pw_0to3) ={0x000300020001ULL};
DECLARE_ALIGNED(8, const uint64_t, ff_pw_4to7) ={0x0007000600050004ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_8tob) ={0x000b000a00090008ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_ctof) ={0x000f000e000d000cULL};
DECLARE_ALIGNED(8, const uint64_t, ff_pb_1) = {0x0101010101010101ULL};
DECLARE_ALIGNED(8, const uint64_t, ff_pb_3) = {0x0303030303030303ULL};
@@ -51,3 +53,6 @@ DECLARE_ALIGNED(8, const uint64_t, ff_pb_A1) =
{0xA1A1A1A1A1A1A1A1ULL};
DECLARE_ALIGNED(8, const uint64_t, ff_rnd) ={0x0004000400040004ULL};
DECLARE_ALIGNED(8, const uint64_t, ff_rnd2) = {0x0040004000400040ULL};
DECLARE_ALIGNED(8, const uint64_t, ff_rnd3) = {0x0020002000200020ULL};
+
+DECLARE_ALIGNED(8, const uint64_t, ff_wm1010) = {0xULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_d4) = {0x0004ULL};
diff --git a/libavcodec/mips/constants.h b/libavcodec/mips/constants.h
index 8f5292e..571002f 100644
--- a/libavcodec/mips/constants.h
+++ b/libavcodec/mips/constants.h
@@ -43,6 +43,8 @@ extern const uint64_t ff_pw_1to4;
extern const uint64_t ff_pw_5to8;
extern const uint64_t ff_pw_0to3;
extern const uint64_t ff_pw_4to7;
+extern const uint64_t ff_pw_8tob;
+extern const uint64_t ff_pw_ctof;
extern const uint64_t ff_pb_1;
extern const uint64_t ff_pb_3;
@@ -53,4 +55,7 @@ extern const uint64_t ff_rnd;
extern const uint64_t ff_rnd2;
extern const uint64_t ff_rnd3;
+extern const uint64_t ff_wm1010;
+extern const uint64_t ff_d4;
+
#endif /* AVCODEC_MIPS_CONSTANTS_H */
diff --git a/libavcodec/mips/h264pred_mmi.c b/libavcodec/mips/h264pred_mmi.c
index b8c0676..c5ae796 100644
--- a/libavcodec/mips/h264pred_mmi.c
+++ b/libavcodec/mips/h264pred_mmi.c
@@ -23,6 +23,7 @@
*/
#include "h264pred_mips.h"
+#include "constants.h"
void ff_pred16x16_vertical_8_mmi(uint8_t *src, ptrdiff_t stride)
{
@@ -50,14 +51,12 @@ void ff_pred16x16_vertical_8_mmi(uint8_t *src, ptrdiff_t
stride)
void ff_pred16x16_horizontal_8_mmi(uint8_t *src, ptrdiff_t stride)
{
__asm__ volatile (
-".set arch=loongson3a \r\n"
"daddiu $2, %0, -1 \r\n"
"daddu $3, %0, $0 \r\n"
"dli $6, 0x10 \r\n"
-"dli $7, 0x0101010101010101 \r\n"
"1: \r\n"
"lbu $4, 0($2) \r\n"
-"dmul $5, $4, $7\r\n"
+"dmul $5, $4, %2\r\n"
"sdl $5, 7($3) \r\n"
"sdr $5, 0($3) \r\n"
"sdl $5, 15($3) \r\n"
@@ -66,7 +65,7 @@ void ff_pred16x16_horizontal_8_mmi(uint8_t *src, ptrdiff_t
stride)
"daddu $3, %1 \r\n"
"daddiu $6, -1 \r\n"
"bnez $6, 1b\r\n"
-::"r"(src),"r"(stride)
+::"r"(src),"r"(stride),"r"(ff_pb_1)
: "$2","$3","$4","$5","$6","memory"
);
}
@@ -74,7 +73,6 @@ void ff_pred16x16_horizontal_8_mmi(uint8_t *src, ptrdiff_t
stride)
void ff_pred16x16_dc_8_mmi(uint8_t *src, ptrdiff_t stride)
{
__asm__ volatile (
-".set arch=loongson3a \r\n"
"daddiu $2, %0, -1 \r\n"
"dli $6, 0x10 \r\n"
"xor $8, $8, $8 \r\n"
@@ -93,10 +91,9 @@ void ff_pred16x16_dc_8_mmi(uint8_t *src, ptrdiff_t stride)
"daddiu $2, $2, 1 \r\n"
"daddiu $6, $6, -1 \r\n"
"bnez $6, 2b\r\n"
-"dli $7, 0x0101010101010101 \r\n"
"daddiu $8, $8, 0x10\r\n"
"dsra $8, 5 \r\n"
-"dmul $5, $8, $7\r\n"
+"dmul $5, $8, %2\r\n"
[FFmpeg-devel] [PATCH 2/2] avfilter/x86/vf_ssim: add ff_ssim_4x4_line_xop
~20% faster than ssse3. Also enabled for x86_32 Signed-off-by: James Almer --- libavfilter/x86/vf_ssim.asm| 62 -- libavfilter/x86/vf_ssim_init.c | 5 2 files changed, 64 insertions(+), 3 deletions(-) diff --git a/libavfilter/x86/vf_ssim.asm b/libavfilter/x86/vf_ssim.asm index 6661987..3293e66 100644 --- a/libavfilter/x86/vf_ssim.asm +++ b/libavfilter/x86/vf_ssim.asm @@ -30,16 +30,50 @@ ssim_c2: times 4 dd 235963 ;(.03*.03*255*255*64*63 + .5) SECTION .text +%macro SSIM_4X4_LINE 1 %if ARCH_X86_64 - -INIT_XMM ssse3 -cglobal ssim_4x4_line, 6, 8, 16, buf, buf_stride, ref, ref_stride, sums, w, buf_stride3, ref_stride3 +cglobal ssim_4x4_line, 6, 8, %1, buf, buf_stride, ref, ref_stride, sums, w, buf_stride3, ref_stride3 +%else +cglobal ssim_4x4_line, 5, 7, %1, buf, buf_stride, ref, ref_stride, sums, buf_stride3, ref_stride3 +%define wd r5mp +%endif lea ref_stride3q, [ref_strideq*3] lea buf_stride3q, [buf_strideq*3] +%if notcpuflag(xop) pxor m7, m7 mova m15, [pw_1] +%endif .loop: +%if cpuflag(xop) +pmovzxbw m0, [bufq+buf_strideq*0] +pmovzxbw m1, [refq+ref_strideq*0] +pmaddwd m4, m0, m0 +pmaddwd m6, m0, m1 +pmovzxbw m2, [bufq+buf_strideq*1] +vpmadcswd m4, m1, m1, m4 +pmovzxbw m3, [refq+ref_strideq*1] +paddw m0, m2 +vpmadcswd m4, m2, m2, m4 +vpmadcswd m6, m2, m3, m6 +paddw m1, m3 +vpmadcswd m4, m3, m3, m4 + +pmovzxbw m2, [bufq+buf_strideq*2] +pmovzxbw m3, [refq+ref_strideq*2] +vpmadcswd m4, m2, m2, m4 +vpmadcswd m6, m2, m3, m6 +pmovzxbw m5, [bufq+buf_stride3q] +pmovzxbw m7, [refq+ref_stride3q] +vpmadcswd m4, m3, m3, m4 +vpmadcswd m6, m5, m7, m6 +paddw m0, m2 +paddw m1, m3 +vpmadcswd m4, m5, m5, m4 +paddw m0, m5 +paddw m1, m7 +vpmadcswd m4, m7, m7, m4 +%else movh m0, [bufq+buf_strideq*0] ; a1 movh m1, [refq+ref_strideq*0] ; b1 movh m2, [bufq+buf_strideq*1] ; a2 @@ -85,12 +119,25 @@ cglobal ssim_4x4_line, 6, 8, 16, buf, buf_stride, ref, ref_stride, sums, w, buf_ paddd m4, m9 paddd m6, m14 paddd m4, m12 +%endif ; m0 = [word] s1 a,a,a,a,b,b,b,b ; m1 = [word] s2 a,a,a,a,b,b,b,b ; m4 = [dword] ss a,a,b,b ; m6 = [dword] s12 a,a,b,b +%if cpuflag(xop) +vphaddwq m0, m0; [dword] s1 a, 0, b, 0 +vphaddwq m1, m1; [dword] s2 a, 0, b, 0 +vphadddq m4, m4; [dword] ss a, 0, b, 0 +vphadddq m6, m6; [dword] s12 a, 0, b, 0 +punpckhdq m2, m0, m1; [dword] s1 b, s2 b, 0, 0 +punpckldq m0, m1; [dword] s1 a, s2 a, 0, 0 +punpckhdq m3, m4, m6; [dword] ss b, s12 b, 0, 0 +punpckldq m4, m6; [dword] ss a, s12 a, 0, 0 +punpcklqdqm1, m2, m3; [dword] b s1, s2, ss, s12 +punpcklqdqm0, m4; [dword] a s1, s2, ss, s12 +%else pmaddwd m0, m15 ; [dword] s1 a,a,b,b pmaddwd m1, m15 ; [dword] s2 a,a,b,b phadddm0, m4; [dword] s1 a, b, ss a, b @@ -99,6 +146,7 @@ cglobal ssim_4x4_line, 6, 8, 16, buf, buf_stride, ref, ref_stride, sums, w, buf_ punpckldq m0, m1; [dword] s1 a, s2 a, s1 b, s2 b punpckhqdqm1, m0, m2; [dword] b s1, s2, ss, s12 punpcklqdqm0, m2; [dword] a s1, s2, ss, s12 +%endif mova [sumsq+ 0], m0 mova [sumsq+mmsize], m1 @@ -109,7 +157,15 @@ cglobal ssim_4x4_line, 6, 8, 16, buf, buf_stride, ref, ref_stride, sums, w, buf_ sub wd, mmsize/8 jg .loop RET +%endmacro +%if ARCH_X86_64 +INIT_XMM ssse3 +SSIM_4X4_LINE 16 +%endif +%if HAVE_XOP_EXTERNAL +INIT_XMM xop +SSIM_4X4_LINE 8 %endif INIT_XMM sse4 diff --git a/libavfilter/x86/vf_ssim_init.c b/libavfilter/x86/vf_ssim_init.c index 9514b25..599c928 100644 --- a/libavfilter/x86/vf_ssim_init.c +++ b/libavfilter/x86/vf_ssim_init.c @@ -25,6 +25,9 @@ void ff_ssim_4x4_line_ssse3(const uint8_t *buf, ptrdiff_t buf_stride, const uint8_t *ref, ptrdiff_t ref_stride, int (*sums)[4], int w); +void ff_ssim_4x4_line_xop (const uint8_t *buf, ptrdiff_t buf_stride, +const uint8_t *ref, ptrdiff_t ref_stride, +int (*sums)[4], int w); float ff_ssim_end_line_sse4(const in
[FFmpeg-devel] [PATCH 1/2] avfilter/x86/vf_ssim: fix some instruction comments
Signed-off-by: James Almer --- libavfilter/x86/vf_ssim.asm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavfilter/x86/vf_ssim.asm b/libavfilter/x86/vf_ssim.asm index be6a4d3..6661987 100644 --- a/libavfilter/x86/vf_ssim.asm +++ b/libavfilter/x86/vf_ssim.asm @@ -97,8 +97,8 @@ cglobal ssim_4x4_line, 6, 8, 16, buf, buf_stride, ref, ref_stride, sums, w, buf_ phadddm1, m6; [dword] s2 a, b, s12 a, b punpckhdq m2, m0, m1; [dword] ss a, s12 a, ss b, s12 b punpckldq m0, m1; [dword] s1 a, s2 a, s1 b, s2 b -punpckhqdqm1, m0, m2; [dword] a s1, s2, ss, s12 -punpcklqdqm0, m2; [dword] b s1, s2, ss, s12 +punpckhqdqm1, m0, m2; [dword] b s1, s2, ss, s12 +punpcklqdqm0, m2; [dword] a s1, s2, ss, s12 mova [sumsq+ 0], m0 mova [sumsq+mmsize], m1 -- 2.4.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec: loongson constants redefined with macros
From 9c95155e90ff5d083e56cdd2565792c9e314302a Mon Sep 17 00:00:00 2001
From: ZhouXiaoyong
Date: Mon, 20 Jul 2015 10:58:30 +0800
Subject: [PATCH 1/2] avcodec: loongson constants redefined with macros
Signed-off-by: ZhouXiaoyong
---
libavcodec/mips/constants.c | 52 ++---
libavcodec/mips/constants.h | 52 ++---
2 files changed, 52 insertions(+), 52 deletions(-)
diff --git a/libavcodec/mips/constants.c b/libavcodec/mips/constants.c
index 135b9d4..84841c2 100644
--- a/libavcodec/mips/constants.c
+++ b/libavcodec/mips/constants.c
@@ -23,31 +23,31 @@
#include "libavutil/mem.h"
#include "constants.h"
-const uint64_t __attribute__ ((aligned(8))) ff_pw_1 =
{0x0001000100010001ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pw_4 =
{0x0004000400040004ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pw_5 =
{0x0005000500050005ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pw_3 =
{0x0003000300030003ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pw_8 =
{0x0008000800080008ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pw_9 =
{0x0009000900090009ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pw_16 =
{0x0010001000100010ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pw_18 =
{0x0012001200120012ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pw_28 =
{0x001C001C001C001CULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pw_32 =
{0x0020002000200020ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pw_53 =
{0x0035003500350035ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pw_64 =
{0x0040004000400040ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pw_128 =
{0x0080008000800080ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pw_m8tom5 =
{0xFFFBFFFAFFF9FFF8ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pw_m4tom1 =
{0xFFFEFFFDFFFCULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pw_1to4 =
{0x0004000300020001ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pw_5to8 =
{0x0008000700060005ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pw_0to3 =
{0x000300020001ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pw_4to7 =
{0x0007000600050004ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_1) = {0x0001000100010001ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_4) = {0x0004000400040004ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_5) = {0x0005000500050005ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_3) = {0x0003000300030003ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_8) = {0x0008000800080008ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_9) = {0x0009000900090009ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_16) = {0x0010001000100010ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_18) = {0x0012001200120012ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_28) = {0x001C001C001C001CULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_32) = {0x0020002000200020ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_53) = {0x0035003500350035ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_64) = {0x0040004000400040ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_128) = {0x0080008000800080ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_m8tom5) = {0xFFFBFFFAFFF9FFF8ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_m4tom1) = {0xFFFEFFFDFFFCULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_1to4) ={0x0004000300020001ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_5to8) ={0x0008000700060005ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_0to3) ={0x000300020001ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_4to7) ={0x0007000600050004ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pb_1 =
{0x0101010101010101ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pb_3 =
{0x0303030303030303ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pb_80 =
{0x8080808080808080ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_pb_A1 =
{0xA1A1A1A1A1A1A1A1ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pb_1) = {0x0101010101010101ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pb_3) = {0x0303030303030303ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pb_80) = {0x8080808080808080ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pb_A1) = {0xA1A1A1A1A1A1A1A1ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_rnd =
{0x0004000400040004ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_rnd2 =
{0x0040004000400040ULL};
-const uint64_t __attribute__ ((aligned(8))) ff_rnd3 =
{0x0020002000200020ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_rnd) ={0x0004000400040004ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_rnd2) = {0x0040004000400040ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_rnd3) = {0x0020002000200020ULL};
diff --git a/
[FFmpeg-devel] [PATCH 2/2] avcodec: loongson relocate constants of idctdsp and h264pred
From 9eac81d24472916636f2b0ad21cf8560f0acf20a Mon Sep 17 00:00:00 2001
From: ZhouXiaoyong
Date: Mon, 20 Jul 2015 11:07:05 +0800
Subject: [PATCH 2/2] avcodec: loongson relocate constants of idctdsp and
h264pred
Signed-off-by: ZhouXiaoyong
---
libavcodec/mips/constants.c| 5
libavcodec/mips/constants.h| 5
libavcodec/mips/h264pred_mmi.c | 61 --
libavcodec/mips/idctdsp_mmi.c | 4 +--
4 files changed, 34 insertions(+), 41 deletions(-)
diff --git a/libavcodec/mips/constants.c b/libavcodec/mips/constants.c
index 84841c2..a25fd24 100644
--- a/libavcodec/mips/constants.c
+++ b/libavcodec/mips/constants.c
@@ -42,6 +42,8 @@ DECLARE_ALIGNED(8, const uint64_t, ff_pw_1to4) =
{0x0004000300020001ULL};
DECLARE_ALIGNED(8, const uint64_t, ff_pw_5to8) ={0x0008000700060005ULL};
DECLARE_ALIGNED(8, const uint64_t, ff_pw_0to3) ={0x000300020001ULL};
DECLARE_ALIGNED(8, const uint64_t, ff_pw_4to7) ={0x0007000600050004ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_8tob) ={0x000b000a00090008ULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_pw_ctof) ={0x000f000e000d000cULL};
DECLARE_ALIGNED(8, const uint64_t, ff_pb_1) = {0x0101010101010101ULL};
DECLARE_ALIGNED(8, const uint64_t, ff_pb_3) = {0x0303030303030303ULL};
@@ -51,3 +53,6 @@ DECLARE_ALIGNED(8, const uint64_t, ff_pb_A1) =
{0xA1A1A1A1A1A1A1A1ULL};
DECLARE_ALIGNED(8, const uint64_t, ff_rnd) ={0x0004000400040004ULL};
DECLARE_ALIGNED(8, const uint64_t, ff_rnd2) = {0x0040004000400040ULL};
DECLARE_ALIGNED(8, const uint64_t, ff_rnd3) = {0x0020002000200020ULL};
+
+DECLARE_ALIGNED(8, const uint64_t, ff_wm1010) = {0xULL};
+DECLARE_ALIGNED(8, const uint64_t, ff_d4) = {0x0004ULL};
diff --git a/libavcodec/mips/constants.h b/libavcodec/mips/constants.h
index 8f5292e..571002f 100644
--- a/libavcodec/mips/constants.h
+++ b/libavcodec/mips/constants.h
@@ -43,6 +43,8 @@ extern const uint64_t ff_pw_1to4;
extern const uint64_t ff_pw_5to8;
extern const uint64_t ff_pw_0to3;
extern const uint64_t ff_pw_4to7;
+extern const uint64_t ff_pw_8tob;
+extern const uint64_t ff_pw_ctof;
extern const uint64_t ff_pb_1;
extern const uint64_t ff_pb_3;
@@ -53,4 +55,7 @@ extern const uint64_t ff_rnd;
extern const uint64_t ff_rnd2;
extern const uint64_t ff_rnd3;
+extern const uint64_t ff_wm1010;
+extern const uint64_t ff_d4;
+
#endif /* AVCODEC_MIPS_CONSTANTS_H */
diff --git a/libavcodec/mips/h264pred_mmi.c b/libavcodec/mips/h264pred_mmi.c
index b8c0676..c5ae796 100644
--- a/libavcodec/mips/h264pred_mmi.c
+++ b/libavcodec/mips/h264pred_mmi.c
@@ -23,6 +23,7 @@
*/
#include "h264pred_mips.h"
+#include "constants.h"
void ff_pred16x16_vertical_8_mmi(uint8_t *src, ptrdiff_t stride)
{
@@ -50,14 +51,12 @@ void ff_pred16x16_vertical_8_mmi(uint8_t *src, ptrdiff_t
stride)
void ff_pred16x16_horizontal_8_mmi(uint8_t *src, ptrdiff_t stride)
{
__asm__ volatile (
-".set arch=loongson3a \r\n"
"daddiu $2, %0, -1 \r\n"
"daddu $3, %0, $0 \r\n"
"dli $6, 0x10 \r\n"
-"dli $7, 0x0101010101010101 \r\n"
"1: \r\n"
"lbu $4, 0($2) \r\n"
-"dmul $5, $4, $7\r\n"
+"dmul $5, $4, %2\r\n"
"sdl $5, 7($3) \r\n"
"sdr $5, 0($3) \r\n"
"sdl $5, 15($3) \r\n"
@@ -66,7 +65,7 @@ void ff_pred16x16_horizontal_8_mmi(uint8_t *src, ptrdiff_t
stride)
"daddu $3, %1 \r\n"
"daddiu $6, -1 \r\n"
"bnez $6, 1b\r\n"
-::"r"(src),"r"(stride)
+::"r"(src),"r"(stride),"r"(ff_pb_1)
: "$2","$3","$4","$5","$6","memory"
);
}
@@ -74,7 +73,6 @@ void ff_pred16x16_horizontal_8_mmi(uint8_t *src, ptrdiff_t
stride)
void ff_pred16x16_dc_8_mmi(uint8_t *src, ptrdiff_t stride)
{
__asm__ volatile (
-".set arch=loongson3a \r\n"
"daddiu $2, %0, -1 \r\n"
"dli $6, 0x10 \r\n"
"xor $8, $8, $8 \r\n"
@@ -93,10 +91,9 @@ void ff_pred16x16_dc_8_mmi(uint8_t *src, ptrdiff_t stride)
"daddiu $2, $2, 1 \r\n"
"daddiu $6, $6, -1 \r\n"
"bnez $6, 2b\r\n"
-"dli $7, 0x0101010101010101 \r\n"
"daddiu $8, $8, 0x10\r\n"
"dsra $8, 5 \r\n"
-"dmul $5, $8, $7\r\n"
+"dmul $5, $8, %2\r\n"
"daddu $2, %0, $0 \r\n"
"dli $6, 0x10 \r\n"
"3: \r\
Re: [FFmpeg-devel] [PATCH v2] Add support for TEA (Tiny Encryption Algorithm)
On Mon, Jul 20, 2015 at 02:16:28AM +0300, Vesselin Bontchev wrote: > Thanks for all the feedback. > > Vesselin > libavutil/Makefile |3 > libavutil/tea.c | 213 > +++ > libavutil/tea.h | 71 +++ > tests/fate/libavutil.mak |4 > 4 files changed, 291 insertions(+) > c45c9c49e7047bb643c2b86c20dea07ec0e7bf87 > 0001-Add-support-for-TEA-Tiny-Encryption-Algorithm.patch > From 6e427af7f9450856c5d96734647e760d1d0f7ce2 Mon Sep 17 00:00:00 2001 > From: Vesselin Bontchev > Date: Sun, 19 Jul 2015 22:25:53 +0200 > Subject: [PATCH] Add support for TEA (Tiny Encryption Algorithm) fails fate test reference file './tests/ref/fate/tea' not found [...] -- 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
[FFmpeg-devel] [PATCH v2] Add support for TEA (Tiny Encryption Algorithm)
Thanks for all the feedback.
VesselinFrom 6e427af7f9450856c5d96734647e760d1d0f7ce2 Mon Sep 17 00:00:00 2001
From: Vesselin Bontchev
Date: Sun, 19 Jul 2015 22:25:53 +0200
Subject: [PATCH] Add support for TEA (Tiny Encryption Algorithm)
---
libavutil/Makefile |3 +
libavutil/tea.c | 213 ++
libavutil/tea.h | 71
tests/fate/libavutil.mak |4 +
4 files changed, 291 insertions(+)
create mode 100644 libavutil/tea.c
create mode 100644 libavutil/tea.h
diff --git a/libavutil/Makefile b/libavutil/Makefile
index 6fa810e..70f8bae 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -63,6 +63,7 @@ HEADERS = adler32.h \
twofish.h \
version.h \
xtea.h\
+ tea.h \
HEADERS-$(CONFIG_LZO) += lzo.h
@@ -135,6 +136,7 @@ OBJS = adler32.o\
utils.o \
xga_font_data.o \
xtea.o \
+ tea.o\
OBJS-$(!HAVE_ATOMICS_NATIVE)+= atomic.o \
@@ -192,6 +194,7 @@ TESTPROGS = adler32 \
twofish \
utf8\
xtea\
+tea \
TESTPROGS-$(HAVE_LZO1X_999_COMPRESS) += lzo
diff --git a/libavutil/tea.c b/libavutil/tea.c
new file mode 100644
index 000..bf76718
--- /dev/null
+++ b/libavutil/tea.c
@@ -0,0 +1,213 @@
+/*
+ * A 32-bit implementation of the TEA algorithm
+ * Copyright (c) 2015 Vesselin Bontchev
+ *
+ * Loosely based on the implementation of David Wheeler and Roger Needham,
+ * https://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm#Reference_code
+ *
+ * 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 "avutil.h"
+#include "common.h"
+#include "intreadwrite.h"
+#include "tea.h"
+
+typedef struct AVTEA {
+uint32_t key[16];
+int rounds;
+} AVTEA;
+
+struct AVTEA *av_tea_alloc(void)
+{
+return av_mallocz(sizeof(struct AVTEA));
+}
+
+const int av_tea_size = sizeof(AVTEA);
+
+void av_tea_init(AVTEA *ctx, const uint8_t key[16], int rounds)
+{
+int i;
+
+for (i = 0; i < 4; i++)
+ctx->key[i] = AV_RB32(key + (i << 2));
+
+ctx->rounds = rounds;
+}
+
+static void tea_crypt_ecb(AVTEA *ctx, uint8_t *dst, const uint8_t *src,
+ int decrypt, uint8_t *iv)
+{
+uint32_t v0, v1;
+int rounds = ctx->rounds;
+uint32_t k0, k1, k2, k3;
+k0 = ctx->key[0];
+k1 = ctx->key[1];
+k2 = ctx->key[2];
+k3 = ctx->key[3];
+
+v0 = AV_RB32(src);
+v1 = AV_RB32(src + 4);
+
+if (decrypt) {
+int i;
+uint32_t delta = 0x9E3779B9U, sum = delta * (rounds / 2);
+
+for (i = 0; i < rounds / 2; i++) {
+v1 -= ((v0 << 4) + k2) ^ (v0 + sum) ^ ((v0 >> 5) + k3);
+v0 -= ((v1 << 4) + k0) ^ (v1 + sum) ^ ((v1 >> 5) + k1);
+sum -= delta;
+}
+if (iv) {
+v0 ^= AV_RB32(iv);
+v1 ^= AV_RB32(iv + 4);
+memcpy(iv, src, 8);
+}
+} else {
+int i;
+uint32_t sum = 0, delta = 0x9E3779B9U;
+
+for (i = 0; i < rounds / 2; i++) {
+sum += delta;
+v0 += ((v1 << 4) + k0) ^ (v1 + sum) ^ ((v1 >> 5) + k1);
+v1 += ((v0 << 4) + k2) ^ (v0 + sum) ^ ((v0 >> 5) + k3);
+}
+}
+
+AV_WB32(dst, v0);
+AV_WB32(dst + 4, v1);
+}
+
+void av_tea_crypt(AVTEA *ctx, uint8_t *dst, const uint8_t *src, int count,
+ uint8_t *iv, i
[FFmpeg-devel] [PATCH v1] Add support for TEA (Tiny Encryption Algorithm)
Hi,
I need support for TEA (Tiny Encryption Algorithm) in FFmpeg for my upcoming
patch (which makes Audible AA files playable).
Thanks,
VesselinFrom 491afe746e3a1f723798224ee56fd57a028ed4da Mon Sep 17 00:00:00 2001
From: Vesselin Bontchev
Date: Sun, 19 Jul 2015 22:25:53 +0200
Subject: [PATCH] Add support for TEA (Tiny Encryption Algorithm)
---
libavutil/Makefile |3 +
libavutil/tea.c| 203
libavutil/tea.h| 66 +
3 files changed, 272 insertions(+)
create mode 100644 libavutil/tea.c
create mode 100644 libavutil/tea.h
diff --git a/libavutil/Makefile b/libavutil/Makefile
index 6fa810e..70f8bae 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -63,6 +63,7 @@ HEADERS = adler32.h \
twofish.h \
version.h \
xtea.h\
+ tea.h \
HEADERS-$(CONFIG_LZO) += lzo.h
@@ -135,6 +136,7 @@ OBJS = adler32.o\
utils.o \
xga_font_data.o \
xtea.o \
+ tea.o\
OBJS-$(!HAVE_ATOMICS_NATIVE)+= atomic.o \
@@ -192,6 +194,7 @@ TESTPROGS = adler32 \
twofish \
utf8\
xtea\
+tea \
TESTPROGS-$(HAVE_LZO1X_999_COMPRESS) += lzo
diff --git a/libavutil/tea.c b/libavutil/tea.c
new file mode 100644
index 000..5d3954a
--- /dev/null
+++ b/libavutil/tea.c
@@ -0,0 +1,203 @@
+/*
+ * A 32-bit implementation of the TEA algorithm
+ * Copyright (c) 2015 Vesselin Bontchev
+ *
+ * Loosely based on the implementation of David Wheeler and Roger Needham,
+ * https://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm#Reference_code
+ *
+ * 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
+ * @brief TEA 32-bit implementation
+ * @author Vesselin Bontchev
+ * @ingroup lavu_tea
+ */
+
+#include "avutil.h"
+#include "common.h"
+#include "intreadwrite.h"
+#include "tea.h"
+
+void av_tea_init(AVTEA *ctx, const uint8_t key[16], int rounds)
+{
+int i;
+
+for (i = 0; i < 4; i++)
+ctx->key[i] = AV_RB32(key + (i << 2));
+
+ctx->rounds = rounds;
+}
+
+static void tea_crypt_ecb(AVTEA *ctx, uint8_t *dst, const uint8_t *src,
+ int decrypt, uint8_t *iv)
+{
+uint32_t v0, v1;
+int rounds = ctx->rounds;
+uint32_t k0, k1, k2, k3;
+k0 = ctx->key[0];
+k1 = ctx->key[1];
+k2 = ctx->key[2];
+k3 = ctx->key[3];
+
+v0 = AV_RB32(src);
+v1 = AV_RB32(src + 4);
+
+if (decrypt) {
+int i;
+uint32_t delta = 0x9E3779B9U, sum = delta * (rounds / 2);
+
+for (i = 0; i < rounds / 2; i++) {
+v1 -= ((v0 << 4) + k2) ^ (v0 + sum) ^ ((v0 >> 5) + k3);
+v0 -= ((v1 << 4) + k0) ^ (v1 + sum) ^ ((v1 >> 5) + k1);
+sum -= delta;
+}
+if (iv) {
+v0 ^= AV_RB32(iv);
+v1 ^= AV_RB32(iv + 4);
+memcpy(iv, src, 8);
+}
+} else {
+int i;
+uint32_t sum = 0, delta = 0x9E3779B9U;
+
+for (i = 0; i < 32; i++) {
+sum += delta;
+v0 += ((v1 << 4) + k0) ^ (v1 + sum) ^ ((v1 >> 5) + k1);
+v1 += ((v0 << 4) + k2) ^ (v0 + sum) ^ ((v0 >> 5) + k3);
+}
+}
+
+AV_WB32(dst, v0);
+AV_WB32(dst + 4, v1);
+}
+
+void av_tea_crypt(AVTEA *ctx, uint8_t *dst, const uint8_t *src, int count,
+ uint8_t *iv, int decrypt)
+{
+int i;
+
+if (
Re: [FFmpeg-devel] [PATCH v1] Add support for TEA (Tiny Encryption Algorithm)
On 19/07/15 6:08 PM, Vesselin Bontchev wrote:
> diff --git a/libavutil/tea.h b/libavutil/tea.h
> new file mode 100644
> index 000..1db6987
> --- /dev/null
> +++ b/libavutil/tea.h
> @@ -0,0 +1,66 @@
> +/*
> + * A 32-bit implementation of the TEA algorithm
> + * Copyright (c) 2015 Vesselin Bontchev
> + *
> + * 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
> + */
> +
> +#ifndef AVUTIL_TEA_H
> +#define AVUTIL_TEA_H
> +
> +#include
> +
> +/**
> + * @file
> + * @brief Public header for libavutil TEA algorithm
> + * @defgroup lavu_tea TEA
> + * @ingroup lavu_crypto
> + * @{
> + */
> +
> +typedef struct AVTEA {
> +uint32_t key[16];
> +int rounds;
> +} AVTEA;
This should be in the c file, and an av_tea_alloc() function and
av_camellia_size constant
added.
See how other cyphers do it (AES, Camellia, Cast, etc).
Also, you should add a FATE test that runs the test code (can be done in a
separate patch).
> +
> +/**
> + * Initialize an AVTEA context.
> + *
> + * @param ctx an AVTEA context
> + * @param key a key of 16 bytes used for encryption/decryption
> + * @param rounds the number of rounds in TEA (64 is the "standard")
> + */
> +void av_tea_init(struct AVTEA *ctx, const uint8_t key[16], int rounds);
> +
> +/**
> + * Encrypt or decrypt a buffer using a previously initialized context.
> + *
> + * @param ctx an AVTEA context
> + * @param dst destination array, can be equal to src
> + * @param src source array, can be equal to dst
> + * @param count number of 8 byte blocks
> + * @param iv initialization vector for CBC mode, if NULL then ECB will be
> used
> + * @param decrypt 0 for encryption, 1 for decryption
> + */
> +void av_tea_crypt(struct AVTEA *ctx, uint8_t *dst, const uint8_t *src,
> + int count, uint8_t *iv, int decrypt);
> +
> +/**
> + * @}
> + */
> +
> +#endif /* AVUTIL_TEA_H */
> -- 1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] apng: Fix typos in decoder causing incorrect results
On 7/19/15, Donny Yang wrote:
> Signed-off-by: Donny Yang
> ---
> libavcodec/pngdec.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> index eae778b..7a5c464 100644
> --- a/libavcodec/pngdec.c
> +++ b/libavcodec/pngdec.c
> @@ -856,13 +856,13 @@ static int decode_fctl_chunk(AVCodecContext *avctx,
> PNGDecContext *s,
> cur_w > s->width - x_offset|| cur_h > s->height - y_offset)
> return AVERROR_INVALIDDATA;
>
> -if (sequence_number == 0 && s->dispose_op == APNG_DISPOSE_OP_PREVIOUS)
> {
> +if (sequence_number == 0 && dispose_op == APNG_DISPOSE_OP_PREVIOUS) {
> // No previous frame to revert to for the first frame
> // Spec says to just treat it as a APNG_DISPOSE_OP_BACKGROUND
> -s->dispose_op = APNG_DISPOSE_OP_BACKGROUND;
> +dispose_op = APNG_DISPOSE_OP_BACKGROUND;
> }
>
> -if (s->dispose_op == APNG_BLEND_OP_OVER && !s->has_trns && (
> +if (blend_op == APNG_BLEND_OP_OVER && !s->has_trns && (
> avctx->pix_fmt == AV_PIX_FMT_RGB24 ||
> avctx->pix_fmt == AV_PIX_FMT_RGB48BE ||
> avctx->pix_fmt == AV_PIX_FMT_PAL8 ||
> @@ -870,8 +870,8 @@ static int decode_fctl_chunk(AVCodecContext *avctx,
> PNGDecContext *s,
> avctx->pix_fmt == AV_PIX_FMT_GRAY16BE ||
> avctx->pix_fmt == AV_PIX_FMT_MONOBLACK
> )) {
> -// APNG_DISPOSE_OP_OVER is the same as APNG_DISPOSE_OP_SOURCE when
> there is no alpha channel
> -s->dispose_op = APNG_BLEND_OP_SOURCE;
> +// APNG_BLEND_OP_OVER is the same as APNG_BLEND_OP_SOURCE when
> there is no alpha channel
> +blend_op = APNG_BLEND_OP_SOURCE;
Are you sure about this?
This silences error: Blending with pixel format rgb24 is not implemented.
such one can be created with
ffmpeg -f lavfi -i testsrc frames%3d.png
apngasm output.png frames*.png
When played back with ffplay you see black bars after 1 second.
Replacing blend_op with dispose_op put error back.
Also I sent you doom3 file with this bug.
> }
>
> s->cur_w = cur_w;
> --
> 2.4.6
> ___
> 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] apng: Fix decoding images with the PREVIOUS dispose op
On 7/19/15, Donny Yang wrote: > --- > libavcodec/pngdec.c | 47 +++ > 1 file changed, 27 insertions(+), 20 deletions(-) > Do you have samples this fix or way how to generate such samples? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/af_amerge: increase max number of channels from 32 to 64
Le primidi 1er thermidor, an CCXXIII, Paul B Mahol a écrit : > Signed-off-by: Paul B Mahol > --- > libavfilter/af_amerge.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Ok. 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] [PATCH] avfilter/af_amerge: increase max number of channels from 32 to 64
Signed-off-by: Paul B Mahol
---
libavfilter/af_amerge.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/af_amerge.c b/libavfilter/af_amerge.c
index 0a0a79f..62a11f7 100644
--- a/libavfilter/af_amerge.c
+++ b/libavfilter/af_amerge.c
@@ -32,7 +32,7 @@
#include "bufferqueue.h"
#include "internal.h"
-#define SWR_CH_MAX 32
+#define SWR_CH_MAX 64
typedef struct {
const AVClass *class;
--
1.7.11.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] avdevice/decklink: Fix build error caused by a change in the SDK.
In version 10.4 of the DeckLink SDK, GetBufferedAudioSampleFrameCount() was
changed to take an unsigned int instead of an unsigned long.
Signed-off-by: Chris Spencer
---
libavdevice/decklink_common.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 96912a7..3bc30f0 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -19,6 +19,8 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#include
+
#include "decklink_common_c.h"
class decklink_output_callback;
@@ -82,7 +84,11 @@ struct decklink_ctx {
typedef enum { DIRECTION_IN, DIRECTION_OUT} decklink_direction_t;
#ifdef _WIN32
+#if BLACKMAGIC_DECKLINK_API_VERSION < 0x0a04
typedef unsigned long buffercount_type;
+#else
+typedef unsigned int buffercount_type;
+#endif
IDeckLinkIterator *CreateDeckLinkIteratorInstance(void);
#else
typedef uint32_t buffercount_type;
--
1.9.5.msysgit.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Controlling the server reply (was: 9/9] doc/example: Add http multi-client) example code
Le primidi 1er thermidor, an CCXXIII, Stephan Holljes a écrit : > I'm having trouble accessing a client's private data in my sample > application. After forking I have an AVIOContext client, but how do I > access its HTTPContext's AVOption fields? For example, how do I get > the method or how do I set the http_code? It is hard to tell without seeing the code. The principle is not complex: declare the field in the options array in http.c. Then the application can access using av_opt_set*() and av_opt_get*() on the AVIOContext with AV_OPT_SEARCH_CHILDREN set. 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] [PATCH] apng: Fix typos in decoder causing incorrect results
On Sun, Jul 19, 2015 at 06:34:06PM +, Donny Yang wrote: > Signed-off-by: Donny Yang > --- > libavcodec/pngdec.c | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) works with the files i tested ill leave review and apply to paul thx [...] -- 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/3] avdevice/decklink: Fix build error caused by a change in the SDK.
On 19 July 2015 at 19:31, Michael Niedermayer wrote: > does this not need some version check so its correct for older SDK too > ? Probably a good idea, yes. I've just checked and it changed in 10.4 so I'll put that in. Chris ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avdevice/decklink: Add missing libraries when building with DeckLink support on Windows.
On Sat, Jul 18, 2015 at 08:20:25PM +0100, Chris Spencer wrote: > Signed-off-by: Chris Spencer > --- > configure | 2 ++ > 1 file changed, 2 insertions(+) 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
[FFmpeg-devel] [PATCH] apng: Fix typos in decoder causing incorrect results
Signed-off-by: Donny Yang
---
libavcodec/pngdec.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index eae778b..cb1cebb 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -856,13 +856,13 @@ static int decode_fctl_chunk(AVCodecContext *avctx,
PNGDecContext *s,
cur_w > s->width - x_offset|| cur_h > s->height - y_offset)
return AVERROR_INVALIDDATA;
-if (sequence_number == 0 && s->dispose_op == APNG_DISPOSE_OP_PREVIOUS) {
+if (sequence_number == 0 && dispose_op == APNG_DISPOSE_OP_PREVIOUS) {
// No previous frame to revert to for the first frame
// Spec says to just treat it as a APNG_DISPOSE_OP_BACKGROUND
-s->dispose_op = APNG_DISPOSE_OP_BACKGROUND;
+dispose_op = APNG_DISPOSE_OP_BACKGROUND;
}
-if (s->dispose_op == APNG_BLEND_OP_OVER && !s->has_trns && (
+if (blend_op == APNG_BLEND_OP_OVER && !s->has_trns && (
avctx->pix_fmt == AV_PIX_FMT_RGB24 ||
avctx->pix_fmt == AV_PIX_FMT_RGB48BE ||
avctx->pix_fmt == AV_PIX_FMT_PAL8 ||
@@ -870,8 +870,8 @@ static int decode_fctl_chunk(AVCodecContext *avctx,
PNGDecContext *s,
avctx->pix_fmt == AV_PIX_FMT_GRAY16BE ||
avctx->pix_fmt == AV_PIX_FMT_MONOBLACK
)) {
-// APNG_DISPOSE_OP_OVER is the same as APNG_DISPOSE_OP_SOURCE when
there is no alpha channel
-s->dispose_op = APNG_BLEND_OP_SOURCE;
+// APNG_BLEND_OP_OVER is the same as APNG_BLEND_OP_SOURCE when there
is no alpha channel
+blend_op = APNG_BLEND_OP_SOURCE;
}
s->cur_w = cur_w;
@@ -1284,6 +1284,7 @@ static int update_thread_context(AVCodecContext *dst,
const AVCodecContext *src)
pdst->cur_h = psrc->cur_h;
pdst->x_offset = psrc->x_offset;
pdst->y_offset = psrc->y_offset;
+pdst->has_trns = psrc->has_trns;
pdst->dispose_op = psrc->dispose_op;
--
2.4.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avdevice/decklink: Fix build error caused by a change in the SDK.
On Sat, Jul 18, 2015 at 08:20:24PM +0100, Chris Spencer wrote:
> GetBufferedAudioSampleFrameCount() used to take an unsigned long, but this
> changed at some point and the latest version of the DeckLink SDK (10.4.1)
> takes an unsigned int.
>
> Signed-off-by: Chris Spencer
> ---
> libavdevice/decklink_common.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
> index 96912a7..41fb5fb 100644
> --- a/libavdevice/decklink_common.h
> +++ b/libavdevice/decklink_common.h
> @@ -82,7 +82,7 @@ struct decklink_ctx {
> typedef enum { DIRECTION_IN, DIRECTION_OUT} decklink_direction_t;
>
> #ifdef _WIN32
> -typedef unsigned long buffercount_type;
> +typedef unsigned int buffercount_type;
> IDeckLinkIterator *CreateDeckLinkIteratorInstance(void);
does this not need some version check so its correct for older SDK too
?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v6] Add support for Audible AAX (and AAX+) files
On Sat, Jul 18, 2015 at 01:59:09PM +0300, Vesselin Bontchev wrote: > Thanks for all the feedback. > > Vesselin > doc/general.texi |2 > doc/muxers.texi|7 ++ > libavformat/isom.h |8 +++ > libavformat/mov.c | 128 > + > 4 files changed, 145 insertions(+) > 81909b7832fef3c66bb97a554342e3035e318212 > 0001-Add-support-for-Audible-AAX-and-AAX-files.patch > From 99d97f2d1f0a62fb75ba9af4c20edaa59f02bb51 Mon Sep 17 00:00:00 2001 > From: Vesselin Bontchev > Date: Sat, 11 Jul 2015 18:02:47 + > Subject: [PATCH] Add support for Audible AAX (and AAX+) files applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] apng: Fix typos in decoder causing incorrect results
On Sun, Jul 19, 2015 at 03:08:33AM +, Donny Yang wrote: > Signed-off-by: Donny Yang > --- > libavcodec/pngdec.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) this breaks playback of clock.png [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add sidechain compress audio filter
Signed-off-by: Paul B Mahol
---
Now with example.
---
doc/filters.texi | 57 +++
libavfilter/Makefile | 1 +
libavfilter/af_sidechaincompress.c | 328 +
libavfilter/allfilters.c | 1 +
4 files changed, 387 insertions(+)
create mode 100644 libavfilter/af_sidechaincompress.c
diff --git a/doc/filters.texi b/doc/filters.texi
index a0d323b..7f0e38c 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -622,6 +622,7 @@ slope
Specify the band-width of a filter in width_type units.
@end table
+@anchor{amerge}
@section amerge
Merge two or more audio streams into a single multi-channel stream.
@@ -2020,6 +2021,7 @@ Applies only to double-pole filter.
The default is 0.707q and gives a Butterworth response.
@end table
+@anchor{pan}
@section pan
Mix channels with specific gain levels. The filter accepts the output
@@ -2121,6 +2123,61 @@ At end of filtering it displays @code{track_gain} and
@code{track_peak}.
Convert the audio sample format, sample rate and channel layout. It is
not meant to be used directly.
+@section sidechaincompress
+
+This filter acts like normal compressor but has the ability to compress
+detected signal using second input signal.
+It needs two input streams and returns one output stream.
+First input stream will be processed depending on second stream signal.
+The filtered signal then can be filtered with other filters in later stages of
+processing. See @ref{pan} and @ref{amerge} filter.
+
+The filter accepts the following options:
+
+@table @option
+@item threshold
+If a signal of second stream raises above this level it will affect the gain
+reduction of first stream.
+By default is 0.125. Range is between 0.00097563 and 1.
+
+@item ratio
+Set a ratio about which the signal is reduced. 1:2 means that if the level
+raised 4dB above the threshold, it will be only 2dB above after the reduction.
+Default is 2. Range is between 1 and 20.
+
+@item attack
+Amount of milliseconds the signal has to rise above the threshold before gain
+reduction starts. Default is 20. Range is between 0.01 and 2000.
+
+@item release
+Amount of milliseconds the signal has to fall bellow the threshold before
+reduction is decreased again. Default is 250. Range is between 0.01 and 9000.
+
+@item makeup
+Set the amount by how much signal will be amplified after processing.
+Default is 2. Range is from 1 and 64.
+
+@item knee
+Curve the sharp knee around the threshold to enter gain reduction more softly.
+Default is 2.82843. Range is between 1 and 8.
+
+@item link
+Choose if the average level between all channels of side-chain stream or the
+louder channel of side-chain stream affects the reduction.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Full ffmpeg example taking 2 audio inputs, 1st input to be compressed
+depending on the signal of 2nd input and later compressed signal to be
+merged with 2nd input:
+@example
+ffmpeg -i main.flac -i sidechain.flac -filter_complex
"[1:a]asplit=2[sc][mix];[0:a][sc]sidechaincompress[compr];[compr][mix]amerge"
+@end example
+@end itemize
+
@section silencedetect
Detect silence in an audio stream.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 4687a26..5176099 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -79,6 +79,7 @@ OBJS-$(CONFIG_LOWPASS_FILTER)+= af_biquads.o
OBJS-$(CONFIG_PAN_FILTER)+= af_pan.o
OBJS-$(CONFIG_REPLAYGAIN_FILTER) += af_replaygain.o
OBJS-$(CONFIG_RESAMPLE_FILTER) += af_resample.o
+OBJS-$(CONFIG_SIDECHAINCOMPRESS_FILTER) += af_sidechaincompress.o
OBJS-$(CONFIG_SILENCEDETECT_FILTER) += af_silencedetect.o
OBJS-$(CONFIG_SILENCEREMOVE_FILTER) += af_silenceremove.o
OBJS-$(CONFIG_TREBLE_FILTER) += af_biquads.o
diff --git a/libavfilter/af_sidechaincompress.c
b/libavfilter/af_sidechaincompress.c
new file mode 100644
index 000..b082743
--- /dev/null
+++ b/libavfilter/af_sidechaincompress.c
@@ -0,0 +1,328 @@
+/*
+ * Copyright (C) 2001-2010 Krzysztof Foltman, Markus Schmidt, Thor Harald
Johansen and others
+ * Copyright (c) 2015 Paul B Mahol
+ *
+ * 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
+ */
+
+
[FFmpeg-devel] [PATCH] avfilter/WIP: add selectivecolor filter
---
This is an attempt to reproduce the exact same behaviour as the
selective color tool in photoshop (and maybe other adobe tool). Since
I didn't find time to write the documentation yet, the filter can be
summarized with something like: it allows you to adjust cyan, magenta,
yellow on only a certain ranges of colors (reds, yellows, darks, ...).
The adjustment range is defined by the "purity" of the color (that is,
how saturated it already is).
It's still incomplete (see @todo in the header and XXX in the code). If
anyone is feeling like helping in the reverse of the filter, it's very
welcome.
---
doc/filters.texi| 4 +
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/vf_selectivecolor.c | 373
4 files changed, 379 insertions(+)
create mode 100644 libavfilter/vf_selectivecolor.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 1bef836..747f573 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11917,6 +11917,10 @@ select=n=2:e='mod(n, 2)+1' [odd][even]; [odd]
pad=h=2*ih [tmp]; [tmp][even] over
@end example
@end itemize
+@section selectivecolor
+
+TODO
+
@section sendcmd, asendcmd
Send commands to filters in the filtergraph.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index a259851..4aebf4e 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -191,6 +191,7 @@ OBJS-$(CONFIG_SEPARATEFIELDS_FILTER) +=
vf_separatefields.o
OBJS-$(CONFIG_SAB_FILTER)+= vf_sab.o
OBJS-$(CONFIG_SCALE_FILTER) += vf_scale.o
OBJS-$(CONFIG_SELECT_FILTER) += f_select.o
+OBJS-$(CONFIG_SELECTIVECOLOR_FILTER) += vf_selectivecolor.o
OBJS-$(CONFIG_SENDCMD_FILTER)+= f_sendcmd.o
OBJS-$(CONFIG_SETDAR_FILTER) += vf_aspect.o
OBJS-$(CONFIG_SETFIELD_FILTER) += vf_setfield.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 01c9e38..e1e5162 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -205,6 +205,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(SAB,sab,vf);
REGISTER_FILTER(SCALE, scale, vf);
REGISTER_FILTER(SELECT, select, vf);
+REGISTER_FILTER(SELECTIVECOLOR, selectivecolor, vf);
REGISTER_FILTER(SENDCMD,sendcmd,vf);
REGISTER_FILTER(SEPARATEFIELDS, separatefields, vf);
REGISTER_FILTER(SETDAR, setdar, vf);
diff --git a/libavfilter/vf_selectivecolor.c b/libavfilter/vf_selectivecolor.c
new file mode 100644
index 000..a93de27
--- /dev/null
+++ b/libavfilter/vf_selectivecolor.c
@@ -0,0 +1,373 @@
+/*
+ * Copyright (c) 2015 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
+ */
+
+/**
+ * @todo
+ *
+ * - make sure code works properly (likely bugs everywhere)
+ * - use integers
+ * - fate test
+ * - PS param file input
+ * - doc
+ * - eval expressions?
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+enum color_range {
+RANGE_REDS,
+RANGE_YELLOWS,
+RANGE_GREENS,
+RANGE_CYANS,
+RANGE_BLUES,
+RANGE_MAGENTAS,
+RANGE_WHITES,
+RANGE_NEUTRALS,
+RANGE_BLACKS,
+NB_RANGES
+};
+
+typedef int (*get_adjust_range_func)(int r, int g, int b, int min_val, int
max_val);
+
+struct process_range {
+int range_id;
+uint32_t mask;
+get_adjust_range_func get_adjust_range;
+};
+
+typedef struct ThreadData {
+AVFrame *in, *out;
+} ThreadData;
+
+typedef struct {
+const AVClass *class;
+
+int relative;
+char *opt_cmyk_adjust[NB_RANGES];
+float cmyk_adjust[NB_RANGES][4];
+
+struct process_range process_ranges[NB_RANGES]; // color ranges to process
+int nb_process_ranges;
+
+} SelectiveColorContext;
+
+#define OFFSET(x) offsetof(SelectiveColorContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+#define RANGE_OPTION(color_name, range) \
+{ color_name"s", "adjust "color_name" regions",
OFFSET(opt_cmyk_adjust[range]), AV_OPT_TYPE_STRING, {.str=NULL}, CHAR_MIN,
CHAR_MAX, FLAGS }
+
+static const AV
Re: [FFmpeg-devel] FFmpeg/MPlayer/rtmpdump possibly searching for a new server and hosting
On Sun, Jul 19, 2015 at 05:43:41PM +0200, Michael Niedermayer wrote: [...] > we could even move trac to the 3.7ghz i7 hetzner box. if we wanted sorry mixed them up, hetzner is a E3-1246 v3 @ 3.50GHz the OVH one would be E5-1620 v2 3.7ghz not that it matters [...] -- 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] FFmpeg/MPlayer/rtmpdump possibly searching for a new server and hosting
On Sun, Jul 19, 2015 at 12:59:34PM +0200, Nicolas George wrote: > Le decadi 30 messidor, an CCXXIII, compn a écrit : > > I also trust JB. > > > > But I remember the libav fork and some vlc devels/admins during that > > time. > > > > http://ffmpeg.org/pipermail/ffmpeg-devel/2011-January/106458.html > > > > i think vlc would be a good host as long as JB is there. > > Sorry for not helping in this issue, but I have a few side projects that > really need to show progress before summer's end. > > Regarding the trust issue for accepting hosting: > > To avoid the project's servers from being hijacked by a rogue operator, I > believe the three following conditions are enough: > > C1. control of the DNS domain; > > C2. a working efficient deployment procedure; > > C3. up-to-date backups of the data (including the deployment procedure, but > the volatile data is the most important) kept by trusted people. > > If a project has that, then it can undermine any rogue operator's doings by > migrating the server to a new hosting in a few hours. technically yes, socially i think this can be very hard though Someone hypothetically trying such takeover will only do so if he has support from some developers already. And switching DNS and servers when there is no unanimous agreement would be a difficult step, a step that in itself could split the community. We should avoid this at "all costs". [...] > Why not accept both offers?: VLC for the main hosting, and a commercial > dedicated payed by a sponsor as a secondary, kept in sync and ready to take > over if the VLC hosting fails. The secondary does not need to be as powerful > as the primary, making it easier to find sponsors. there are more than these 2 offers theres also a offer from dreamhack and one from nexcess.net and another company which wants to sponsor us either financially or through a server IIUC and i agree we should pick 2 for redundancy. about powerfull our server which we used mostly in the last 4 years had 8gb ram and a X5355 @ 2.66GHz and the 2nd box 16gb ram and a E5345 @ 2.33GHz these where more than sufficient for our use. Only trac benefits from a fast cpu and memory, because trac is slow (this is mostly due to its rendering not the db actually IIRC) so while i sure prefer a powerfull box ... who would not. The only thing where anyone would ever notice a difference is trac unless we add more slow-ware. personally, and so far, the dreamhack hosting seemed like a rather interresting ofer to me, theres no trust issue i belive, we have a hoster we can talk to (dreamhack) if we need to. we could even move trac to the 3.7ghz i7 hetzner box. if we wanted maximum trac performance. That i7 might even beat a high end xeon with many cores but lower ghz for trac not that a few % is really important though [...] -- 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] Controlling the server reply (was: 9/9] doc/example: Add http multi-client) example code
Hi, I'm having trouble accessing a client's private data in my sample application. After forking I have an AVIOContext client, but how do I access its HTTPContext's AVOption fields? For example, how do I get the method or how do I set the http_code? Regards, Stephan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avdevice/decklink: Add support for decoding 8-bit RGB formats.
On 19 July 2015 at 15:13, Carl Eugen Hoyos wrote:
> Chris Spencer gmail.com> writes:
>
>> + This option is deprecated, use
>> + option{pixel_format=yuv422p10} instead.
>
> I just remembered this mail:
> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/190657
>
> v4l2 has an option input_format that accepts both
> (for decklink) "v210" and "uyvy422" as strings
> and the option has an alias "pixel_format". If
> nobody (including you) has a better suggestion,
> please copy this behaviour, because using the
> pix_fmt alias for v210 is not very intuitive and
> does not work well for mjpeg.
I'm not sure where that user was seeing MJPEG; I can't find any
reference to it in the SDK. Here is the full list of available pixel
formats:
bmdFormat8BitYUV
This is the default and maps to the uyvy422 pixel format in ffmpeg.
bmdFormat10BitYUV
This is currently controlled by bm_v210 and uses the v210 codec.
bmdFormat8BitARGB
bmdFormat8BitBGRA
This patch adds these pixel formats.
bmdFormat10BitRGB ('r210')
bmdFormat12BitRGB ('R12B')
bmdFormat12BitRGBLE ('R12L')
bmdFormat10BitRGBXLE ('R10l')
bmdFormat10BitRGBX ('R10b')
I guess the first one can be handled by the r210 codec, but I'm not
sure how to deal with the others.
I worry that input_format might create some confusion with the
unrelated list_formats option which deals with resolution and frame
rate, and should probably have been called 'list_modes' IMO.
Chris
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avdevice/decklink: Add support for decoding 8-bit RGB formats.
Chris Spencer gmail.com> writes:
> + This option is deprecated, use
> + option{pixel_format=yuv422p10} instead.
I just remembered this mail:
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/190657
v4l2 has an option input_format that accepts both
(for decklink) "v210" and "uyvy422" as strings
and the option has an alias "pixel_format". If
nobody (including you) has a better suggestion,
please copy this behaviour, because using the
pix_fmt alias for v210 is not very intuitive and
does not work well for mjpeg.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avdevice/decklink: Add support for decoding 8-bit RGB formats.
Chris Spencer gmail.com> writes: > Ok so with the HDMI input connected to my graphics card > the alpha channel is zero with both ARGB and BGRA Then please (only) use 0RGB and BGR0. > I don't really know what the codec_tag does; I just > copied the values from raw.c. What do I need to do > with these? Imo, do not set them unless there is a reason. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avdevice/decklink: Add support for decoding 8-bit RGB formats.
On 19 July 2015 at 14:30, Carl Eugen Hoyos wrote:
> Chris Spencer gmail.com> writes:
>
>> > > -On Windows, you need to run the IDL files
>> > > through command{widl}.
>> > > +On Windows, you need to run the IDL files
>> > > through command{midl}.
>> >
>> > Is this intended?
>>
>> Yes, widl doesn't exist. The tool is called midl.
>
> Then please send a separate patch.
Ok.
>> > > +} else if (cctx->pixel_format == AV_PIX_FMT_ARGB) {
>> > > +ctx->bmd_format = bmdFormat8BitARGB;
>> > > +} else if (cctx->pixel_format == AV_PIX_FMT_BGRA) {
>> > > +ctx->bmd_format = bmdFormat8BitBGRA;
>> >
>> > > +} else if (ctx->bmd_format == bmdFormat8BitARGB) {
>> > > +st->codec->codec_id= AV_CODEC_ID_RAWVIDEO;
>> > > +st->codec->pix_fmt = AV_PIX_FMT_ARGB;
>> > > +st->codec->codec_tag = MKTAG('A', 'R', 'G', 'B');
>> > > +} else if (ctx->bmd_format == bmdFormat8BitBGRA) {
>> > > +st->codec->codec_id= AV_CODEC_ID_RAWVIDEO;
>> > > +st->codec->pix_fmt = AV_PIX_FMT_BGRA;
>> > > +st->codec->codec_tag = MKTAG('B', 'G', 'R', 'A');
>> >
>> > I would have expected these to be AV_PIX_FMT_0RGB and
>> > AV_PIX_FMT_BGR0.
>>
>> The Blackmagic documentation is kind of strange on this
>> one actually. For bmdFormat8BitBGRA it says "alpha
>> channel is valid". For bmdFormat8BitBGRA it says "alpha
>> channel may be valid". Not sure how best to deal with
>> that to be honest.
>
> Can you test?
> Is there a theoretical possibility that the content
> contains valid alpha? If yes, please use ARGB.
> If not and if you can confirm that the alpha channel
> is correctly set to 0xFF, then you may use ARGB but I
> wonder what the usecase would be (and how probable it
> is that a future driver would not set it to 0xFF).
> The codec_tag looks wrong to me because it would be
> 0x00 for AV_PIX_FMT_ARGB and AV_PIX_FMT_BGRA. I think
> it should only be set if needed (for YV12 or similar).
Ok so with the HDMI input connected to my graphics card the alpha
channel is zero with both ARGB and BGRA (which explains why I couldn't
get the overlay filter to work with it now that I think about it). I
will add bgr0 and 0rgb, but I wonder if it's worth leaving bgra and
argb in, as the Blackmagic documentation seems to imply the alpha
channel might be present in some situation.
I don't really know what the codec_tag does; I just copied the values
from raw.c. What do I need to do with these?
Thanks,
Chris
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avdevice/decklink: Add support for decoding 8-bit RGB formats.
Chris Spencer gmail.com> writes:
> > > -On Windows, you need to run the IDL files
> > > through command{widl}.
> > > +On Windows, you need to run the IDL files
> > > through command{midl}.
> >
> > Is this intended?
>
> Yes, widl doesn't exist. The tool is called midl.
Then please send a separate patch.
> > > -DeckLink is very picky about the formats it supports. Pixel format is
> > > +DeckLink is very picky about the formats it supports. Pixel
> > > format is uyvy422,
> >
> > Imo, please do not change this line:
> > Going through old commits is not unusual,
> > such changes make this much more difficult.
>
> So I'm clear, you mean the text is fine, but
> avoid changing the position of the line breaks?
I am not a native speaker (so I cannot really
comment on the actual text) but yes, I have no
objections.
> > > +} else if (cctx->pixel_format == AV_PIX_FMT_ARGB) {
> > > +ctx->bmd_format = bmdFormat8BitARGB;
> > > +} else if (cctx->pixel_format == AV_PIX_FMT_BGRA) {
> > > +ctx->bmd_format = bmdFormat8BitBGRA;
> >
> > > +} else if (ctx->bmd_format == bmdFormat8BitARGB) {
> > > +st->codec->codec_id= AV_CODEC_ID_RAWVIDEO;
> > > +st->codec->pix_fmt = AV_PIX_FMT_ARGB;
> > > +st->codec->codec_tag = MKTAG('A', 'R', 'G', 'B');
> > > +} else if (ctx->bmd_format == bmdFormat8BitBGRA) {
> > > +st->codec->codec_id= AV_CODEC_ID_RAWVIDEO;
> > > +st->codec->pix_fmt = AV_PIX_FMT_BGRA;
> > > +st->codec->codec_tag = MKTAG('B', 'G', 'R', 'A');
> >
> > I would have expected these to be AV_PIX_FMT_0RGB and
> > AV_PIX_FMT_BGR0.
>
> The Blackmagic documentation is kind of strange on this
> one actually. For bmdFormat8BitBGRA it says "alpha
> channel is valid". For bmdFormat8BitBGRA it says "alpha
> channel may be valid". Not sure how best to deal with
> that to be honest.
Can you test?
Is there a theoretical possibility that the content
contains valid alpha? If yes, please use ARGB.
If not and if you can confirm that the alpha channel
is correctly set to 0xFF, then you may use ARGB but I
wonder what the usecase would be (and how probable it
is that a future driver would not set it to 0xFF).
The codec_tag looks wrong to me because it would be
0x00 for AV_PIX_FMT_ARGB and AV_PIX_FMT_BGRA. I think
it should only be set if needed (for YV12 or similar).
> > > +{ "pixel_format", "set video pixel format" ,
> >
> > Should be pix_fmt imo.
>
> I was going to do this, but avfoundation, dshow and
> v4l have similar options all called pixel_format,
> so I used that for consistency.
Thank you for reminding me!
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] apng: Support inter-frame compression
Hi Donny,
On Sat, Jul 18, 2015 at 9:48 PM, Donny Yang wrote:
> +uint32_t x, y;
> +uint32_t leftmost_x = input->width;
> +uint32_t rightmost_x = 0;
> +uint32_t topmost_y = input->height;
> +uint32_t bottommost_y = 0;
> +const uint8_t *input_data = input->data[0];
> +uint8_t *output_data = output->data[0];
> +size_t input_linesize = input->linesize[0];
> +size_t output_linesize = output->linesize[0];
> +
> +// Find bounding box of changes
> +for (y = 0; y < input->height; ++y) {
> +for (x = 0; x < input->width; ++x) {
These kind of variables should not be fixed-size (uintN_t), but should be
native-size (e.g. unsigned). In practice that means the same on most
machines (e.g. x86-32, x86-64), but on some machines unsigned will be
faster. uintN_t should only be used for arrays in which you want the size
to be exactly N bits, e.g. uint8_t pixeldata_8bits[w * h] or int16_t
pcmdata_16bits[n_samples * n_channels] or stuff like that. You don't care
that the counter is exactly 32bits.
(Related: linesize should be ptrdiff_t, not size_t.)
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avdevice/decklink: Add support for decoding 8-bit RGB formats.
On 19 July 2015 at 14:08, Chris Spencer wrote: > The Blackmagic documentation is kind of strange on this one actually. > For bmdFormat8BitBGRA it says "alpha channel is valid". For > bmdFormat8BitBGRA it says "alpha channel may be valid". Not sure how > best to deal with that to be honest. Sorry, I meant bmdFormat8BitARGB is listed as "alpha channel is valid". Chris ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avdevice/decklink: Add support for decoding 8-bit RGB formats.
Hi Carl,
On 19 July 2015 at 13:53, Carl Eugen Hoyos wrote:
>
> Chris Spencer gmail.com> writes:
>
> > -On Windows, you need to run the IDL files through command{widl}.
> > +On Windows, you need to run the IDL files through command{midl}.
>
> Is this intended?
Yes, widl doesn't exist. The tool is called midl.
> > -DeckLink is very picky about the formats it supports. Pixel format is
>
> > +DeckLink is very picky about the formats it supports. Pixel
> > format is uyvy422,
>
> Imo, please do not change this line:
> Going through old commits is not unusual,
> such changes make this much more difficult.
So I'm clear, you mean the text is fine, but avoid changing the
position of the line breaks?
> > +} else if (cctx->pixel_format == AV_PIX_FMT_ARGB) {
> > +ctx->bmd_format = bmdFormat8BitARGB;
> > +} else if (cctx->pixel_format == AV_PIX_FMT_BGRA) {
> > +ctx->bmd_format = bmdFormat8BitBGRA;
>
> > +} else if (ctx->bmd_format == bmdFormat8BitARGB) {
> > +st->codec->codec_id= AV_CODEC_ID_RAWVIDEO;
> > +st->codec->pix_fmt = AV_PIX_FMT_ARGB;
> > +st->codec->codec_tag = MKTAG('A', 'R', 'G', 'B');
> > +} else if (ctx->bmd_format == bmdFormat8BitBGRA) {
> > +st->codec->codec_id= AV_CODEC_ID_RAWVIDEO;
> > +st->codec->pix_fmt = AV_PIX_FMT_BGRA;
> > +st->codec->codec_tag = MKTAG('B', 'G', 'R', 'A');
>
> I would have expected these to be AV_PIX_FMT_0RGB and
> AV_PIX_FMT_BGR0.
The Blackmagic documentation is kind of strange on this one actually.
For bmdFormat8BitBGRA it says "alpha channel is valid". For
bmdFormat8BitBGRA it says "alpha channel may be valid". Not sure how
best to deal with that to be honest.
> > +{ "pixel_format", "set video pixel format" ,
>
> Should be pix_fmt imo.
I was going to do this, but avfoundation, dshow and v4l have similar
options all called pixel_format, so I used that for consistency.
Thanks,
Chris
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avdevice/decklink: Add support for decoding 8-bit RGB formats.
Chris Spencer gmail.com> writes:
> -On Windows, you need to run the IDL files through command{widl}.
> +On Windows, you need to run the IDL files through command{midl}.
Is this intended?
> -DeckLink is very picky about the formats it supports. Pixel format is
> +DeckLink is very picky about the formats it supports. Pixel
> format is uyvy422,
Imo, please do not change this line:
Going through old commits is not unusual,
such changes make this much more difficult.
> +} else if (cctx->pixel_format == AV_PIX_FMT_ARGB) {
> +ctx->bmd_format = bmdFormat8BitARGB;
> +} else if (cctx->pixel_format == AV_PIX_FMT_BGRA) {
> +ctx->bmd_format = bmdFormat8BitBGRA;
> +} else if (ctx->bmd_format == bmdFormat8BitARGB) {
> +st->codec->codec_id= AV_CODEC_ID_RAWVIDEO;
> +st->codec->pix_fmt = AV_PIX_FMT_ARGB;
> +st->codec->codec_tag = MKTAG('A', 'R', 'G', 'B');
> +} else if (ctx->bmd_format == bmdFormat8BitBGRA) {
> +st->codec->codec_id= AV_CODEC_ID_RAWVIDEO;
> +st->codec->pix_fmt = AV_PIX_FMT_BGRA;
> +st->codec->codec_tag = MKTAG('B', 'G', 'R', 'A');
I would have expected these to be AV_PIX_FMT_0RGB and
AV_PIX_FMT_BGR0.
> +{ "pixel_format", "set video pixel format" ,
Should be pix_fmt imo.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: Add reverse filter
On Sun, Jul 19, 2015 at 1:13 PM, Clément Bœsch wrote: >> Is there any reasonable way to determine when to print such a warning? Seems >> silly to warn over e.g. 40 frames. > > I meant in the documentation. I don't know for the code. OK. >> How does this look: >> >> -vf trim=end=10,reverse >> > > Sure. Look how other examples are formatted and fine with me. OK. >> So the other option is to remove the check for it? > > Yes, it's always 0 currently since you didn't add the timeline flag. OK. Removed. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: Add reverse filter
On Thu, Jul 16, 2015 at 09:01:53PM +0100, Derek Buitenhuis wrote:
> On Thu, Jul 16, 2015 at 7:43 PM, Clément Bœsch wrote:
> >> +Reverses a clip. Requires memory to buffer the entire clip, so trimming
> >> is suggested.
> >
> > We use infinitive form, so "Reverse".
>
> Done locally.
>
> > You might want to print "Warning: this filter requires ..."
>
> Is there any reasonable way to determine when to print such a warning? Seems
> silly to warn over e.g. 40 frames.
>
I meant in the documentation. I don't know for the code.
> > Can you add an example to make sure users don't membomb too much their
> > OS?
>
> How does this look:
>
> -vf trim=end=10,reverse
>
Sure. Look how other examples are formatted and fine with me.
> >> +if (ret == AVERROR_EOF && !ctx->is_disabled && s->nb_frames > 0) {
> >
> > is_disabled suggest a timeline support. You could add that if you feel
> > like it. That way, "reverse=enable='between(t,30,40)'" would reverse only
> > between t=30 and t=40 and pass through the rest of the time.
>
> So the other option is to remove the check for it?
>
Yes, it's always 0 currently since you didn't add the timeline flag.
> - Derek
--
Clément B.
pgpSdCMm38CUX.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] can amerge use .needs_fifo?
Dana 19. 7. 2015. 12:28 osoba "Nicolas George" napisala je: > > Le decadi 30 messidor, an CCXXIII, Paul B Mahol a écrit : > > Subject: can amerge use .needs_fifo? > > .needs_fifo is evil, it breaks normal scheduling and thus can cause > unlimited memory consumption even in normal filter graphs. > > Why do you want to know? Is there a particular case that is not working for > you? > I need fifo to get same number of samples from 2 inputs. And duplicating amerge fifo code seemed poor choice. So I picked using .needs_fifo. In what exact case .need_fifo cause problems? > I have a solution in mind for the whole issue, but it is a lot of work, > especially to keep compatibility during the transition. In the meantime, > users can explicitly insert fifo if needed. > You mean explicitly insert fifo filter? > Regards, > > -- > Nicolas George > > ___ > 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] FFmpeg/MPlayer/rtmpdump possibly searching for a new server and hosting
Le decadi 30 messidor, an CCXXIII, compn a écrit : > I also trust JB. > > But I remember the libav fork and some vlc devels/admins during that > time. > > http://ffmpeg.org/pipermail/ffmpeg-devel/2011-January/106458.html > > i think vlc would be a good host as long as JB is there. Sorry for not helping in this issue, but I have a few side projects that really need to show progress before summer's end. Regarding the trust issue for accepting hosting: To avoid the project's servers from being hijacked by a rogue operator, I believe the three following conditions are enough: C1. control of the DNS domain; C2. a working efficient deployment procedure; C3. up-to-date backups of the data (including the deployment procedure, but the volatile data is the most important) kept by trusted people. If a project has that, then it can undermine any rogue operator's doings by migrating the server to a new hosting in a few hours. And of course, a project should have that even if it does not fear rogue operators. As far as I understand, FFmpeg is lacking C2, and possibly C3, because the admins never got on to it; I definitely can not blame people for procrastinating. And I read in this thread that the current hosting crisis is motivating them to actually do it. Therefore, I believe the trust issue, the fear of rogue operators, should not be the main guide of the choice. Regarding OVH: About a year ago, a group of people I belong to lost their hosting brutally and decided to switch to a commercial dedicated server. The discussion went between OVH and Online, the two major French host providers. Online was finally chosen, because a few members had a better experience with it, but I do not remember the specifics. Personally, I consider JB's offer to be very interesting, even if JB were to leave. After all, it would only cause a problem if he were to leave abruptly AND if his replacement were untrustworthy AND if an attempt at hijacking happened soon after. I do not believe that anyone would want to hijack FFmpeg badly enough to infiltrate VLC and then assassinate JB. I also consider sponsors offers "we pay a dedicated server but the contract is in your name" to be very good: if the sponsor stops, we have until the end of the payed term to find new hosting. Why not accept both offers?: VLC for the main hosting, and a commercial dedicated payed by a sponsor as a secondary, kept in sync and ready to take over if the VLC hosting fails. The secondary does not need to be as powerful as the primary, making it easier to find sponsors. Well, since I am not actually helping in the work, this is a bunch of yakafokon¹, I hope some of it was useful. Regards, -- Nicolas George 1 : yakafokon = "'y a qu'à, 'faut qu'on" = "there's only to, we must" in French. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] can amerge use .needs_fifo?
Le decadi 30 messidor, an CCXXIII, Paul B Mahol a écrit : > Subject: can amerge use .needs_fifo? .needs_fifo is evil, it breaks normal scheduling and thus can cause unlimited memory consumption even in normal filter graphs. Why do you want to know? Is there a particular case that is not working for you? I have a solution in mind for the whole issue, but it is a lot of work, especially to keep compatibility during the transition. In the meantime, users can explicitly insert fifo if needed. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
