Re: [FFmpeg-devel] [Patch] no_delay option for librtmp
It looks like #include netinet/tcp.h might work BUT
According to this page http://linux.die.net/man/7/tcp
it looks like this socket setting is not truly portable. :(
My intent was to offer some flexibility in what looks like a long standing
problem with rtmp streaming.
For my purposes, I can get by with changes I made to rtmpdump.
My sincere apologies for wasting your time.
On Thu, Feb 26, 2015 at 9:29 PM, Michael Niedermayer michae...@gmx.at
wrote:
On Thu, Feb 26, 2015 at 08:00:49PM -0600, Cary Tetrick wrote:
No, i just extended what Brian already had. Just an option to to control
the no delay. I put the changes inside you #if for networking config.
you misunderstood my question
my question is what #includes it needs and if this is portable and
available on all platforms which support CONFIG_NETWORK?
there certainly is something missing as it does not build.
libavformat/librtmp.c: In function ‘rtmp_open’:
libavformat/librtmp.c:246:52: error: ‘TCP_NODELAY’ undeclared (first use
in this function)
libavformat/librtmp.c:246:52: note: each undeclared identifier is reported
only once for each function it appears in
make: *** [libavformat/librtmp.o] Error 1
[...]
+
+if (flags AVIO_FLAG_WRITE) {
+int tmp = ctx-tcp_nodelay;
+setsockopt(r-m_sb.sb_socket, IPPROTO_TCP, TCP_NODELAY,
tmp,
sizeof(tmp));
does this need any #includes, any checks in configure?
[...]
--
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
___
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
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/palettegen/RFC: fix mem leak
I don't understand why I need to do that. The free is already present in
the uninit, and before every update of the prev_frame update.
---
libavfilter/vf_palettegen.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavfilter/vf_palettegen.c b/libavfilter/vf_palettegen.c
index fa8cc12a..bb22196 100644
--- a/libavfilter/vf_palettegen.c
+++ b/libavfilter/vf_palettegen.c
@@ -507,6 +507,7 @@ static int request_frame(AVFilterLink *outlink)
if (r == AVERROR_EOF !s-palette_pushed) {
r = ff_filter_frame(outlink, get_palette_frame(ctx));
s-palette_pushed = 1;
+av_frame_free(s-prev_frame);
return r;
}
return r;
--
2.3.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add erosion dilation filter
On 25/02/15 11:55 AM, Paul B Mahol wrote:
+static inline void line_copy8(uint8_t *line, const uint8_t *srcp, int width,
int mergin)
Unless I'm missing something, mergin seems to always be 1.
The code below could be simplified.
+{
+memcpy(line, srcp, width);
+
+for (int i = mergin; i 0; i--) {
+line[-i] = line[i];
+line[width - 1 + i] = line[width - 1 - i];
+}
+}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/palettegen: export color quantization ratio
On Wed, Feb 25, 2015 at 04:14:11PM +0100, Clément Bœsch wrote: On Wed, Feb 25, 2015 at 03:43:23PM +0100, Nicolas George wrote: Le septidi 7 ventôse, an CCXXIII, Clement Boesch a écrit : +float ratio = (float)nb_out / nb_in; +snprintf(buf, sizeof(buf), %f, ratio); I wonder if both values could be useful instead individually. If so, either set the string to %d/%d or set two metadata keys. The numerator is the user input, so only one value is necessary. We could export the number of colors found in the input (nb_in), but this code is all about the quantization process so I think the ratio is actually more relevant. If not, use double instead of float, float is very rarely useful. And in this particular case it will be converted to double by the vararg call. Sure, OK +av_log(ctx, AV_LOG_INFO, %d%s colors generated out of %d colors; ratio=%f\n, + s-nb_boxes, s-reserve_transparent ? (+1) : , s-nb_refs, + set_colorquant_ratio_meta(out, s-nb_boxes, s-nb_refs)); This is your code, but I must say that I find returning the double value as a secondary effect of a function called set_something() not very readable. The alternative was to have the ratio declared on top of the function (far away), or pass the context to set_colorquant_ratio_meta() to make it log as well. This is really a cosmetic issue, maybe I'll just declare ratio on top so it's more readable. Applied with these changes. -- Clément B. pgp3Vb3Rjb2_g.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 07/12] mips/aacdec: remove uses of mips32r2 specific ext instructions
Removing these removes the dependency of this code on mips32r2 which would allow it to be used on processors which have FPU instructions, but not r2 instructions (like the mips64el debian port for instance). Signed-off-by: James Cowgill james...@cowgill.org.uk --- libavcodec/mips/aacdec_mips.h | 49 ++- 1 file changed, 25 insertions(+), 24 deletions(-) diff --git a/libavcodec/mips/aacdec_mips.h b/libavcodec/mips/aacdec_mips.h index 9ba3079..c9efdbb 100644 --- a/libavcodec/mips/aacdec_mips.h +++ b/libavcodec/mips/aacdec_mips.h @@ -68,10 +68,10 @@ static inline float *VMUL2_mips(float *dst, const float *v, unsigned idx, float *ret; __asm__ volatile( -andi%[temp3], %[idx], 15 \n\t -ext %[temp4], %[idx], 4, 4\n\t +andi%[temp3], %[idx], 0x0F \n\t +andi%[temp4], %[idx], 0xF0 \n\t sll %[temp3], %[temp3], 2\n\t -sll %[temp4], %[temp4], 2\n\t +srl %[temp4], %[temp4], 2\n\t lwc1%[temp2], 0(%[scale])\n\t lwxc1 %[temp0], %[temp3](%[v]) \n\t lwxc1 %[temp1], %[temp4](%[v]) \n\t @@ -99,14 +99,13 @@ static inline float *VMUL4_mips(float *dst, const float *v, unsigned idx, float *ret; __asm__ volatile( -andi%[temp0], %[idx], 3 \n\t -ext %[temp1], %[idx], 2, 2 \n\t -ext %[temp2], %[idx], 4, 2 \n\t -ext %[temp3], %[idx], 6, 2 \n\t +andi%[temp0], %[idx], 0x03\n\t +andi%[temp1], %[idx], 0x0C\n\t +andi%[temp2], %[idx], 0x30\n\t +andi%[temp3], %[idx], 0xC0\n\t sll %[temp0], %[temp0], 2 \n\t -sll %[temp1], %[temp1], 2 \n\t -sll %[temp2], %[temp2], 2 \n\t -sll %[temp3], %[temp3], 2 \n\t +srl %[temp2], %[temp2], 2 \n\t +srl %[temp3], %[temp3], 4 \n\t lwc1%[temp4], 0(%[scale]) \n\t lwxc1 %[temp5], %[temp0](%[v])\n\t lwxc1 %[temp6], %[temp1](%[v])\n\t @@ -142,14 +141,14 @@ static inline float *VMUL2S_mips(float *dst, const float *v, unsigned idx, float *ret; __asm__ volatile( -andi%[temp0], %[idx], 15 \n\t -ext %[temp1], %[idx], 4, 4 \n\t +andi%[temp0], %[idx], 0x0F \n\t +andi%[temp1], %[idx], 0xF0 \n\t lw %[temp4], 0(%[scale]) \n\t srl %[temp2], %[sign], 1 \n\t sll %[temp3], %[sign], 31 \n\t sll %[temp2], %[temp2], 31 \n\t sll %[temp0], %[temp0], 2 \n\t -sll %[temp1], %[temp1], 2 \n\t +srl %[temp1], %[temp1], 2 \n\t lwxc1 %[temp8], %[temp0](%[v]) \n\t lwxc1 %[temp9], %[temp1](%[v]) \n\t xor %[temp5], %[temp4], %[temp2] \n\t @@ -185,22 +184,24 @@ static inline float *VMUL4S_mips(float *dst, const float *v, unsigned idx, __asm__ volatile( lw %[temp0], 0(%[scale]) \n\t -and %[temp1], %[idx], 3 \n\t -ext %[temp2], %[idx], 2, 2 \n\t -ext %[temp3], %[idx], 4, 2 \n\t -ext %[temp4], %[idx], 6, 2 \n\t -sll %[temp1], %[temp1], 2 \n\t -sll %[temp2], %[temp2], 2 \n\t -sll %[temp3], %[temp3], 2 \n\t -sll %[temp4], %[temp4], 2 \n\t +andi%[temp1], %[idx], 0x03 \n\t +andi%[temp2], %[idx], 0x0C \n\t +andi%[temp3], %[idx], 0x30 \n\t +andi%[temp4], %[idx], 0xC0 \n\t +sll %[temp1], %[temp1], 2\n\t +srl %[temp3], %[temp3], 2\n\t +srl %[temp4], %[temp4], 4\n\t lwxc1 %[temp10], %[temp1](%[v])\n\t lwxc1 %[temp11], %[temp2](%[v])\n\t lwxc1 %[temp12], %[temp3](%[v])\n\t lwxc1 %[temp13], %[temp4](%[v])\n\t and %[temp1], %[sign], %[mask] \n\t -ext %[temp2], %[idx], 12, 1 \n\t -ext %[temp3], %[idx], 13, 1 \n\t -ext %[temp4], %[idx], 14, 1 \n\t +srl %[temp2],
[FFmpeg-devel] [PATCH 03/12] mips/aacpsdsp: fix definition of ps_decorrelate_mips
Q_fract should have be declared as 'const float*'. Also fix the constness of some local variables affected by this. Signed-off-by: James Cowgill james...@cowgill.org.uk --- libavcodec/mips/aacpsdsp_mips.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavcodec/mips/aacpsdsp_mips.c b/libavcodec/mips/aacpsdsp_mips.c index 4730a7f..06d99d8 100644 --- a/libavcodec/mips/aacpsdsp_mips.c +++ b/libavcodec/mips/aacpsdsp_mips.c @@ -277,7 +277,7 @@ static void ps_mul_pair_single_mips(float (*dst)[2], float (*src0)[2], float *sr static void ps_decorrelate_mips(float (*out)[2], float (*delay)[2], float (*ap_delay)[PS_QMF_TIME_SLOTS + PS_MAX_AP_DELAY][2], - const float phi_fract[2], float (*Q_fract)[2], + const float phi_fract[2], const float (*Q_fract)[2], const float *transient_gain, float g_decay_slope, int len) @@ -285,8 +285,8 @@ static void ps_decorrelate_mips(float (*out)[2], float (*delay)[2], float *p_delay = delay[0][0]; float *p_out = out[0][0]; float *p_ap_delay = ap_delay[0][0][0]; -float *p_t_gain = (float*)transient_gain; -float *p_Q_fract = Q_fract[0][0]; +const float *p_t_gain = transient_gain; +const float *p_Q_fract = Q_fract[0][0]; float ag0, ag1, ag2; float phi_fract0 = phi_fract[0]; float phi_fract1 = phi_fract[1]; -- 2.1.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 08/12] configure, mips: remove MIPS32R2, merging it with MIPSFPU
There are no independant uses of mips32r2 instructions except for the
FPU parts. Due to the heavy use of mips32r2 specifc fpu extensions, I
am guessing the original author intended MIPSFPU to imply MIPS32R2 anyway.
Since these fpu instructions are available on mips64 (non-r2), enable them
there as well.
Also remove the last occurence of HAVE_MIPS32R2 (which is coupled to
HAVE_MIPSFPU anyway).
Signed-off-by: James Cowgill james...@cowgill.org.uk
---
Makefile | 2 +-
arch.mak | 1 -
configure | 19 +--
libavcodec/mips/ac3dsp_mips.c | 4 ++--
4 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/Makefile b/Makefile
index 845a274..ca2ce59 100644
--- a/Makefile
+++ b/Makefile
@@ -80,7 +80,7 @@ SUBDIR_VARS := CLEANFILES EXAMPLES FFLIBS HOSTPROGS TESTPROGS
TOOLS \
HEADERS ARCH_HEADERS BUILT_HEADERS SKIPHEADERS\
ARMV5TE-OBJS ARMV6-OBJS ARMV8-OBJS VFP-OBJS NEON-OBJS \
ALTIVEC-OBJS MMX-OBJS YASM-OBJS \
- MIPSFPU-OBJS MIPSDSPR2-OBJS MIPSDSPR1-OBJS MIPS32R2-OBJS \
+ MIPSFPU-OBJS MIPSDSPR2-OBJS MIPSDSPR1-OBJS\
OBJS SLIBOBJS HOSTOBJS TESTOBJS
define RESET
diff --git a/arch.mak b/arch.mak
index 0e866d8..48bc2d3 100644
--- a/arch.mak
+++ b/arch.mak
@@ -5,7 +5,6 @@ OBJS-$(HAVE_VFP) += $(VFP-OBJS) $(VFP-OBJS-yes)
OBJS-$(HAVE_NEON)+= $(NEON-OBJS)$(NEON-OBJS-yes)
OBJS-$(HAVE_MIPSFPU) += $(MIPSFPU-OBJS)$(MIPSFPU-OBJS-yes)
-OBJS-$(HAVE_MIPS32R2) += $(MIPS32R2-OBJS) $(MIPS32R2-OBJS-yes)
OBJS-$(HAVE_MIPSDSPR1) += $(MIPSDSPR1-OBJS) $(MIPSDSPR1-OBJS-yes)
OBJS-$(HAVE_MIPSDSPR2) += $(MIPSDSPR2-OBJS) $(MIPSDSPR2-OBJS-yes)
diff --git a/configure b/configure
index d037da1..6764830 100755
--- a/configure
+++ b/configure
@@ -358,7 +358,6 @@ Optimization options (experts only):
--disable-neon disable NEON optimizations
--disable-inline-asm disable use of inline assembly
--disable-yasm disable use of nasm/yasm assembly
- --disable-mips32r2 disable MIPS32R2 optimizations
--disable-mipsdspr1 disable MIPS DSP ASE R1 optimizations
--disable-mipsdspr2 disable MIPS DSP ASE R2 optimizations
--disable-mipsfpudisable floating point MIPS optimizations
@@ -1560,7 +1559,6 @@ ARCH_EXT_LIST_ARM=
ARCH_EXT_LIST_MIPS=
mipsfpu
-mips32r2
mipsdspr1
mipsdspr2
@@ -1996,7 +1994,6 @@ setend_deps=arm
map 'eval ${v}_inline_deps=inline_asm' $ARCH_EXT_LIST_ARM
mipsfpu_deps=mips
-mips32r2_deps=mips
mipsdspr1_deps=mips
mipsdspr2_deps=mips
@@ -4565,8 +4562,19 @@ EOF
elif enabled mips; then
check_inline_asm loongson 'dmult.g $1, $2, $3'
-enabled mips32r2 add_cflags -mips32r2 add_asflags -mips32r2
- check_inline_asm mips32r2 'rotr $t0, $t1, 1'
+
+# Enable minimum ISA based on selected options
+if enabled mips64 (enabled mipsdspr1 || enabled mipsdspr2); then
+add_cflags -mips64r2
+add_asflags -mips64r2
+elif enabled mips64 enabled mipsfpu; then
+add_cflags -mips64
+add_asflags -mips64
+elif enabled mipsfpu || enabled mipsdspr1 || enabled mipsdspr2; then
+add_cflags -mips32r2
+add_asflags -mips32r2
+fi
+
enabled mipsdspr1 add_cflags -mdsp add_asflags -mdsp
check_inline_asm mipsdspr1 'addu.qb $t0, $t1, $t2'
enabled mipsdspr2 add_cflags -mdspr2 add_asflags -mdspr2
@@ -5512,7 +5520,6 @@ if enabled arm; then
fi
if enabled mips; then
echo MIPS FPU enabled ${mipsfpu-no}
-echo MIPS32R2 enabled ${mips32r2-no}
echo MIPS DSP R1 enabled ${mipsdspr1-no}
echo MIPS DSP R2 enabled ${mipsdspr2-no}
fi
diff --git a/libavcodec/mips/ac3dsp_mips.c b/libavcodec/mips/ac3dsp_mips.c
index f33c6f1..bd2a611 100644
--- a/libavcodec/mips/ac3dsp_mips.c
+++ b/libavcodec/mips/ac3dsp_mips.c
@@ -199,7 +199,7 @@ static void ac3_update_bap_counts_mips(uint16_t
mant_cnt[16], uint8_t *bap,
}
#endif
-#if HAVE_MIPSFPU HAVE_MIPS32R2
+#if HAVE_MIPSFPU
static void float_to_fixed24_mips(int32_t *dst, const float *src, unsigned int
len)
{
const float scale = 1 24;
@@ -403,7 +403,7 @@ void ff_ac3dsp_init_mips(AC3DSPContext *c, int bit_exact) {
c-bit_alloc_calc_bap = ac3_bit_alloc_calc_bap_mips;
c-update_bap_counts = ac3_update_bap_counts_mips;
#endif
-#if HAVE_MIPSFPU HAVE_MIPS32R2
+#if HAVE_MIPSFPU
c-float_to_fixed24 = float_to_fixed24_mips;
c-downmix = ac3_downmix_mips;
#endif
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 04/12] mips/fft: remove some useless assembly
Remove some assembly that the compiler can easily handle optimally on its own.
GCC produces almost identical assembly.
Signed-off-by: James Cowgill james...@cowgill.org.uk
---
libavcodec/mips/fft_mips.c | 26 ++
1 file changed, 2 insertions(+), 24 deletions(-)
diff --git a/libavcodec/mips/fft_mips.c b/libavcodec/mips/fft_mips.c
index 691f2db..e12c33e 100644
--- a/libavcodec/mips/fft_mips.c
+++ b/libavcodec/mips/fft_mips.c
@@ -65,26 +65,12 @@ static void ff_fft_calc_mips(FFTContext *s, FFTComplex *z)
float w_re, w_im;
float *w_re_ptr, *w_im_ptr;
const int fft_size = (1 s-nbits);
-int s_n = s-nbits;
-int tem1, tem2;
float pom, pom1, pom2, pom3;
float temp, temp1, temp3, temp4;
FFTComplex * tmpz_n2, * tmpz_n34, * tmpz_n4;
FFTComplex * tmpz_n2_i, * tmpz_n34_i, * tmpz_n4_i, * tmpz_i;
-/**
-*num_transforms = (0x2aab (16 - s-nbits)) | 1;
-*/
-__asm__ volatile (
-li %[tem1], 16 \n\t
-sub %[s_n], %[tem1], %[s_n] \n\t
-li %[tem2], 10923 \n\t
-srav %[tem2], %[tem2], %[s_n] \n\t
-ori %[num_t],%[tem2], 1 \n\t
-: [num_t]=r(num_transforms), [s_n]+r(s_n),
- [tem1]=r(tem1), [tem2]=r(tem2)
-);
-
+num_transforms = (0x2aab (16 - s-nbits)) | 1;
for (n=0; nnum_transforms; n++) {
offset = ff_fft_offsets_lut[n] 2;
@@ -214,15 +200,7 @@ static void ff_fft_calc_mips(FFTContext *s, FFTComplex *z)
n4 = 4;
for (nbits=4; nbits=s-nbits; nbits++) {
-/*
-* num_transforms = (num_transforms 1) | 1;
-*/
-__asm__ volatile (
-sra %[num_t], %[num_t], 1 \n\t
-ori %[num_t], %[num_t], 1 \n\t
-
-: [num_t] +r (num_transforms)
-);
+num_transforms = (num_transforms 1) | 1;
n2 = 2 * n4;
n34 = 3 * n4;
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary
On 2/26/2015 4:04 PM, Nicolas George wrote: If we are talking about end-user interface, the changes should happen in cmdutils.c. Fair enough. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: Check linking against CoreGraphics or, ApplicationServices framework for avfoundation input device.
Am 09.02.15 um 21:55 schrieb Carl Eugen Hoyos: Thilo Borgmann thilo.borgmann at mail.de writes: Am 09.02.15 um 12:33 schrieb Carl Eugen Hoyos: On Monday 09 February 2015 11:26:57 am Thilo Borgmann wrote: do you really mean to check for CoreGraphics.h in case of lib ApplicationServices? New, simpler patch attached. This patch works locally for the build-only aarch64 fate slot. It builds a static libavdevice.a, so I think it works. It works fine here for iOS (as did the last iteration). Please apply but check for CoreGraphics first, please. Thanks, Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movenc: Write 'colr' box correctly for MP4
On 2/26/2015 4:10 PM, Clément Bœsch wrote: Yes, it will return an error and abort the operation. Be it done on the command line or via the API. So said differently it won't work anymore. I do wonder what the point of the whole AVOption API is then, if we can't break it any more than a struct. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary
L'octidi 8 ventôse, an CCXXIII, Derek Buitenhuis a écrit : I read it as a 'text stream', which isn't necessarily file i/o only, but I doubt it is worth bikeshedding over. You are probably right, I meant file I/O in the Unix sense. I think relying on the user to input a CR+LF cia command line program is insane in the first place... shouldn't the library do that / join headers properly? The major issue there is that the type of the headers option is really list of pairs of strings. The AVOption system does not have anything like that, not even list of strings, which would be the second best choice. Lacking that, we have to use the next best type, string, and require the user to serialize the list of pairs of strings into a single string. And since a line break is the only character that can not be present in the header value, using it as delimiter is a sane choice. Remember that we are talking about library API, not end-user interface. CR+LF is not harder to insert than any other sequence of bytes. If we are talking about end-user interface, the changes should happen in cmdutils.c. 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] movenc: Write 'colr' box correctly for MP4
On Thu, Feb 26, 2015 at 05:15:56PM +0100, Clément Bœsch wrote: On Thu, Feb 26, 2015 at 04:13:10PM +, Derek Buitenhuis wrote: On 2/26/2015 4:10 PM, Clément Bœsch wrote: Yes, it will return an error and abort the operation. Be it done on the command line or via the API. So said differently it won't work anymore. I do wonder what the point of the whole AVOption API is then, if we can't break it any more than a struct. No ABI constraints. ...and user input mapping (string) -- Clément B. pgp_dkgnnyYdS.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Set bits_per_raw_sample for hqx
Carl Eugen Hoyos cehoyos at ag.or.at writes: Attached patch sets bits_per_raw_sample when decoding hqx. I will push this if nobody objects. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Force __EXTENSIONS__ on Solaris
Hi! A user reported that the Solaris libc detection has never worked on all installations. Attached patch forces the definition of __EXTENSIONS__ which is needed for network compilation. This fixes the following error: libavformat/udp.c:174: error: storage size of 'mreq' isn't known Please comment, Carl Eugen diff --git a/configure b/configure index 1d14d0a..fcd065b 100755 --- a/configure +++ b/configure @@ -4027,6 +4027,7 @@ case $target_os in SHFLAGS='-shared -Wl,-h,$$(@F)' enabled x86 SHFLAGS=-mimpure-text $SHFLAGS network_extralibs=-lsocket -lnsl +add_cppflags -D__EXTENSIONS__ # When using suncc to build, the Solaris linker will mark # an executable with each instruction set encountered by # the Solaris assembler. As our libraries contain their own ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 11/12] mips/acelp_filters: fix incorrect register constraint
On Thu, Feb 26, 2015 at 01:42:52PM +, James Cowgill wrote: Change register constraint on the v variable from = to +. This was causing GCC to think that the v variable was never read and therefore not initialize it. This fixes about 20 fate failures on mips64el. Signed-off-by: James Cowgill james...@cowgill.org.uk --- libavcodec/mips/acelp_filters_mips.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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]Silence deprecation warnings when compiling qtkit
Am 11.02.15 um 11:33 schrieb Carl Eugen Hoyos: Hi! Attached patch silences many warnings that clang prints when compiling libavdevice/qtkit.o. I don't think the warnings are very helpful. OK. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movenc: Write 'colr' box correctly for MP4
On Thu, Feb 26, 2015 at 04:13:10PM +, Derek Buitenhuis wrote: On 2/26/2015 4:10 PM, Clément Bœsch wrote: Yes, it will return an error and abort the operation. Be it done on the command line or via the API. So said differently it won't work anymore. I do wonder what the point of the whole AVOption API is then, if we can't break it any more than a struct. No ABI constraints. -- Clément B. pgpVZN2sp9FzL.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 04/12] mips/fft: remove some useless assembly
On Thu, Feb 26, 2015 at 01:42:45PM +, James Cowgill wrote: Remove some assembly that the compiler can easily handle optimally on its own. GCC produces almost identical assembly. Signed-off-by: James Cowgill james...@cowgill.org.uk applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary
On Thursday 26 February 2015 03:31:39 pm Derek Buitenhuis wrote:
On 2/26/2015 2:09 PM, Carl Eugen Hoyos wrote:
+snprintf(header, len + 3, %s\r\n, s-headers);
This does not necessarily work on windows. The C standard idctates that in
text mode, \n is translated to the system's native newline.
Use memcpy and 0x0D / 0X0A / 0x00.
New patch attached.
This may also accidentally allow for headers to end with '\n\r\n',
wouldn't it?
Yes, I don't know if this is a problem.
Thank you, Carl Eugen
diff --git a/libavformat/http.c b/libavformat/http.c
index 55dcb6e..59e5acb 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -312,9 +312,17 @@ static int http_open(URLContext *h, const char *uri, int
flags,
if (s-headers) {
int len = strlen(s-headers);
-if (len 2 || strcmp(\r\n, s-headers + len - 2))
+if (len 2 || strcmp(\r\n, s-headers + len - 2)) {
+char *header = av_malloc(len + 3);
+if (!header)
+return AVERROR(ENOMEM);
+memcpy(header, s-headers, len);
+memcpy(header + len, \r\n\0, 3);
+av_free(s-headers);
+s-headers = header;
av_log(h, AV_LOG_WARNING,
- No trailing CRLF found in HTTP header.\n);
+ No trailing CRLF found in HTTP header, added \\r\\n at the
end.\n);
+}
}
ret = http_open_cnx(h, options);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movenc: Write 'colr' box correctly for MP4
On Thu, Feb 26, 2015 at 01:53:13PM +, Derek Buitenhuis wrote: On 2/26/2015 1:50 PM, Clément Bœsch wrote: If the option is set by default, you don't want to warn for no reason. It's not set by default. That patch never went in. Ah, my bad. I don't believe silently not writing it is a valid approach. Then again I think setting a default movflag like that instead of changing the option is also stupid. Well, breaking API on purpose when easily avoidable is kind of stupid too. You can also just deprecate the current flag and add yours. The point is to not make the option disappear because it will break callers. Changing the behaviour (enabling by default / making the old option void) is fine, breaking the API (removing the option) not so much. -- Clément B. pgpIwJvMX5kqc.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movenc: Write 'colr' box correctly for MP4
On Thu, Feb 26, 2015 at 4:54 PM, Clément Bœsch u...@pkh.me wrote: On Thu, Feb 26, 2015 at 01:53:13PM +, Derek Buitenhuis wrote: On 2/26/2015 1:50 PM, Clément Bœsch wrote: If the option is set by default, you don't want to warn for no reason. It's not set by default. That patch never went in. Ah, my bad. I don't believe silently not writing it is a valid approach. Then again I think setting a default movflag like that instead of changing the option is also stupid. Well, breaking API on purpose when easily avoidable is kind of stupid too. You can also just deprecate the current flag and add yours. The point is to not make the option disappear because it will break callers. Changing the behaviour (enabling by default / making the old option void) is fine, breaking the API (removing the option) not so much. Its an AVOption, isn't the whole point of this system to have a system that wouldn't break callers when an option is added or removed? How would a caller break? Calling a set operation on a non-existing option won't break, just return an error code. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 05/12] mips/sbrdsp: remove sbr_neg_odd_64_mips
On Thu, Feb 26, 2015 at 01:42:46PM +, James Cowgill wrote: The optimized C version of this code actually runs faster than this version, so remove it. Signed-off-by: James Cowgill james...@cowgill.org.uk --- libavcodec/mips/sbrdsp_mips.c | 34 -- 1 file changed, 34 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 100% positive feedback - All either got their money back or didnt complain Best seller ever, very honest - Seller refunded buyer after failed scam signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 03/12] mips/aacpsdsp: fix definition of ps_decorrelate_mips
On Thu, Feb 26, 2015 at 01:42:44PM +, James Cowgill wrote: Q_fract should have be declared as 'const float*'. Also fix the constness of some local variables affected by this. Signed-off-by: James Cowgill james...@cowgill.org.uk --- libavcodec/mips/aacpsdsp_mips.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary
L'octidi 8 ventôse, an CCXXIII, Derek Buitenhuis a écrit : This does not necessarily work on windows. The C standard idctates that in text mode, \n is translated to the system's native newline. Use memcpy and 0x0D / 0X0A / 0x00. I think you are confusing two subtly different issues and getting the result wrong. The first issue is that the C standard does not specify the byte value of '\n' and '\r', the most notable example being macos10 where '\n' is 0x0D instead of 0x0D everywhere else because apple never does anything like everyone else. But they still translate into a single byte value each, and POSIX specifies that '\n' = 0x0A and '\r' = 0x0D. The second issue is that with the windows file API, when the file is opened in the so-called text mode, there is an implicit conversion between '\n' in memory (which is actually exactly 0x0A) and \r\n in the file; there is also a conversion between 0x1A and EOF. It only happens with file I/O operations, not with simple string operations, even sprintf. On Unix, a similar conversion happens in the TTY layer. The TTY layer is something nobody should touch without a long pole and a hazmat suit; on windows, the hazmat is littered all over the API. Therefore, I believe Carl Eugen's original patch was technically correct. This may also accidentally allow for headers to end with '\n\r\n', wouldn't it? Well, the test as it is is half-assed, it checks for a specific common mistake but does not actually validate the format of the string. I am not in favour of fixing the shortcomings of the user's shell in FFmpeg's libraries, but if it is considered useful, I believe a more complete approach should be used: replace all occurrences of \n with CRLF, validate folded headers, etc. 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]Add one CRLF to http headers if necessary
On 2/26/2015 3:35 PM, Nicolas George wrote: The second issue is that with the windows file API, when the file is opened in the so-called text mode, there is an implicit conversion between '\n' in memory (which is actually exactly 0x0A) and \r\n in the file; there is also a conversion between 0x1A and EOF. It only happens with file I/O operations, not with simple string operations, even sprintf. On Unix, a similar conversion happens in the TTY layer. The TTY layer is something nobody should touch without a long pole and a hazmat suit; on windows, the hazmat is littered all over the API. I read it as a 'text stream', which isn't necessarily file i/o only, but I doubt it is worth bikeshedding over. Therefore, I believe Carl Eugen's original patch was technically correct. See below. This may also accidentally allow for headers to end with '\n\r\n', wouldn't it? Well, the test as it is is half-assed, it checks for a specific common mistake but does not actually validate the format of the string. Yes it's pretty bad, more on that below. I am not in favour of fixing the shortcomings of the user's shell in FFmpeg's libraries, but if it is considered useful, I believe a more complete approach should be used: replace all occurrences of \n with CRLF, validate folded headers, etc. I think relying on the user to input a CR+LF cia command line program is insane in the first place... shouldn't the library do that / join headers properly? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 01/12] mips/mathops: remove 64-bit code
On Thu, Feb 26, 2015 at 01:42:42PM +, James Cowgill wrote: GCC is perfectly happy generating optimized multiplication code on its own for 64-bit arches. GCC refuses to optimize the loongson code when in 32-bit mode, so I've left that. Signed-off-by: James Cowgill james...@cowgill.org.uk --- libavcodec/mips/mathops.h | 26 -- 1 file changed, 26 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movenc: Write 'colr' box correctly for MP4
On Thu, Feb 26, 2015 at 05:04:53PM +0100, Hendrik Leppkes wrote: On Thu, Feb 26, 2015 at 4:54 PM, Clément Bœsch u...@pkh.me wrote: On Thu, Feb 26, 2015 at 01:53:13PM +, Derek Buitenhuis wrote: On 2/26/2015 1:50 PM, Clément Bœsch wrote: If the option is set by default, you don't want to warn for no reason. It's not set by default. That patch never went in. Ah, my bad. I don't believe silently not writing it is a valid approach. Then again I think setting a default movflag like that instead of changing the option is also stupid. Well, breaking API on purpose when easily avoidable is kind of stupid too. You can also just deprecate the current flag and add yours. The point is to not make the option disappear because it will break callers. Changing the behaviour (enabling by default / making the old option void) is fine, breaking the API (removing the option) not so much. Its an AVOption, isn't the whole point of this system to have a system that wouldn't break callers when an option is added or removed? How would a caller break? Calling a set operation on a non-existing option won't break, just return an error code. Yes, it will return an error and abort the operation. Be it done on the command line or via the API. So said differently it won't work anymore. -- Clément B. pgpC5H_To78HW.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][RFC] Interpretation of duration field in AVI super index chunk
On 26.02.2015 00:51, Michael Niedermayer wrote:
On Wed, Feb 25, 2015 at 05:35:33PM +0100, Tobias Rapp wrote:
avienc.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
09f8c8250ce5ec1bdad79a1bf280028c9d3af376
0001-libavformat-avienc-Fix-duration-for-audio-stream-Ope.patch
From 3a8e15598fa3e044f3ef65b5063c633cb4b3afed Mon Sep 17 00:00:00 2001
From: Tobias Rapp t.r...@noa-audio.com
Date: Wed, 25 Feb 2015 17:10:13 +0100
Subject: [PATCH] libavformat/avienc: Fix duration for audio stream OpenDML
super index
Fixes the duration field of the OpenDML super index indx chunk to
contain the number of samples instead of the number of packets for
(linear/PCM) audio streams.
This matches the OpenDML V1.02 standard text which states that the
duration field shall contain time span in stream ticks.
---
libavformat/avienc.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index 53c2fe7..b77b295 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -49,6 +49,7 @@ typedef struct AVIIentry {
typedef struct AVIIndex {
int64_t indx_start;
+int64_t audio_strm_offset;
int entry;
int ents_allocated;
AVIIentry** cluster;
@@ -91,6 +92,7 @@ static int64_t avi_start_new_riff(AVFormatContext *s,
AVIOContext *pb,
avi-riff_id++;
for (i = 0; i s-nb_streams; i++) {
AVIStream *avist = s-streams[i]-priv_data;
+avist-indexes.audio_strm_offset = avist-audio_strm_length;
avist-indexes.entry = 0;
}
@@ -476,6 +478,7 @@ static int avi_write_ix(AVFormatContext *s)
for (i = 0; i s-nb_streams; i++) {
AVIStream *avist = s-streams[i]-priv_data;
int64_t ix, pos;
+int au_byterate, au_ssize, au_scale;
avi_stream2fourcc(tag, i, s-streams[i]-codec-codec_type);
ix_tag[3] = '0' + i;
@@ -511,7 +514,11 @@ static int avi_write_ix(AVFormatContext *s)
avio_skip(pb, 16 * avi-riff_id);
avio_wl64(pb, ix);/* qwOffset */
avio_wl32(pb, pos - ix); /* dwSize */
-avio_wl32(pb, avist-indexes.entry); /* dwDuration */
+ff_parse_specific_params(s-streams[i], au_byterate, au_ssize,
au_scale);
+if (au_ssize == 0)
+avio_wl32(pb, avist-indexes.entry); /* dwDuration (packet count)
*/
+else
+avio_wl32(pb, (avist-audio_strm_length -
avist-indexes.audio_strm_offset) / au_ssize); /* dwDuration (sample count) */
the rounding here is wrong
the index to be useable needs to have segments duration summable
as is this would lead to significangt errors if many of these
durations would be summed up
something like
avist-audio_strm_length / au_ssize - avist-indexes.audio_strm_offset /
au_ssize
might avoid that but ive not tested it
My assumption was that a stream packet contains only whole samples for
linear/uncompressed audio (PCM) and that only for linear audio the
expression au_ssize 0 evaluates to TRUE.
If that is not the case I can do the rounding as suggested or maybe
introduce some separate stream duration counter based on AVPacket.duration?
Regards,
Tobias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/palettegen: use AV_QSORT()
On Wed, Feb 25, 2015 at 06:55:48PM +0100, Michael Niedermayer wrote: On Wed, Feb 25, 2015 at 04:10:44PM +0100, Clément Bœsch wrote: From: Clément Bœsch clem...@stupeflix.com This makes the sorting of the colors along an axis (r, g or b) predictible, and thus testable under FATE. The performance is not really an issue here since the function is called only once at the end and will need to sort very small number of entries, so an alternative would be to make the sorting functions (see DECLARE_CMP_FUNC()) fallback on another axis in case of equality. This approach was actually simpler. I don't know if there is any advantage in using a multidimensional sort, but it will affect the final palette one way or another. --- libavfilter/vf_palettegen.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) LGTM Applied, thanks. -- Clément B. pgp0NKZn1MBa3.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 05/12] mips/sbrdsp: remove sbr_neg_odd_64_mips
The optimized C version of this code actually runs faster than this
version, so remove it.
Signed-off-by: James Cowgill james...@cowgill.org.uk
---
libavcodec/mips/sbrdsp_mips.c | 34 --
1 file changed, 34 deletions(-)
diff --git a/libavcodec/mips/sbrdsp_mips.c b/libavcodec/mips/sbrdsp_mips.c
index d4460ba..c76e709 100644
--- a/libavcodec/mips/sbrdsp_mips.c
+++ b/libavcodec/mips/sbrdsp_mips.c
@@ -58,39 +58,6 @@
#include libavcodec/sbrdsp.h
#if HAVE_INLINE_ASM
-static void sbr_neg_odd_64_mips(float *x)
-{
-int Temp1, Temp2, Temp3, Temp4, Temp5;
-float *x1= x[1];
-float *x_end = x1 + 64;
-
-/* loop unrolled 4 times */
-__asm__ volatile (
-lui%[Temp5], 0x8000 \n\t
-1: \n\t
-lw %[Temp1], 0(%[x1])\n\t
-lw %[Temp2], 8(%[x1])\n\t
-lw %[Temp3], 16(%[x1]) \n\t
-lw %[Temp4], 24(%[x1]) \n\t
-xor%[Temp1], %[Temp1], %[Temp5]\n\t
-xor%[Temp2], %[Temp2], %[Temp5]\n\t
-xor%[Temp3], %[Temp3], %[Temp5]\n\t
-xor%[Temp4], %[Temp4], %[Temp5]\n\t
-sw %[Temp1], 0(%[x1])\n\t
-sw %[Temp2], 8(%[x1])\n\t
-sw %[Temp3], 16(%[x1]) \n\t
-sw %[Temp4], 24(%[x1]) \n\t
-addiu %[x1], %[x1], 32 \n\t
-bne%[x1], %[x_end], 1b \n\t
-
-: [Temp1]=r(Temp1), [Temp2]=r(Temp2),
- [Temp3]=r(Temp3), [Temp4]=r(Temp4),
- [Temp5]=r(Temp5), [x1]+r(x1)
-: [x_end]r(x_end)
-: memory
-);
-}
-
static void sbr_qmf_pre_shuffle_mips(float *z)
{
int Temp1, Temp2, Temp3, Temp4, Temp5, Temp6;
@@ -920,7 +887,6 @@ static void sbr_hf_apply_noise_3_mips(float (*Y)[2], const
float *s_m,
void ff_sbrdsp_init_mips(SBRDSPContext *s)
{
#if HAVE_INLINE_ASM
-s-neg_odd_64 = sbr_neg_odd_64_mips;
s-qmf_pre_shuffle = sbr_qmf_pre_shuffle_mips;
s-qmf_post_shuffle = sbr_qmf_post_shuffle_mips;
#if HAVE_MIPSFPU
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 02/12] mips/float_dsp: replace assembly with C implementations
The assembly versions have a few problems
- They only work with mips32r2 enabled
- They don't work on 64-bits
- They're massive and complex
So replace them with C implementations which solve these problems and let GCC
magically optimize for different platforms. All the functions are manually
unrolled 4 times (like the assembly code). With the addition of a few restrict
keywords, the functions produce almost identical assembly to the original
versions when compiled with gcc -O3.
Since this code now uses no fpu assembly, drop the HAVE_MIPSFPU guard as well.
Signed-off-by: James Cowgill james...@cowgill.org.uk
---
libavutil/mips/float_dsp_mips.c | 354
1 file changed, 72 insertions(+), 282 deletions(-)
diff --git a/libavutil/mips/float_dsp_mips.c b/libavutil/mips/float_dsp_mips.c
index 06d52dc..31425de 100644
--- a/libavutil/mips/float_dsp_mips.c
+++ b/libavutil/mips/float_dsp_mips.c
@@ -52,332 +52,122 @@
*/
#include config.h
+#include libavutil/avassert.h
#include libavutil/float_dsp.h
-#if HAVE_INLINE_ASM HAVE_MIPSFPU
-static void vector_fmul_mips(float *dst, const float *src0, const float *src1,
- int len)
+// The functions here are basically the same as the C implementations but
+// unrolled 4 times to take advantage of pointer alignment + mips fpu registers
+
+static void vector_fmul_mips(
+float *av_restrict dst, const float *av_restrict src0,
+const float *av_restrict src1, int len)
{
int i;
-if (len 3) {
-for (i = 0; i len; i++)
-dst[i] = src0[i] * src1[i];
-} else {
-float *d = (float *)dst;
-float *d_end = d + len;
-float *s0= (float *)src0;
-float *s1= (float *)src1;
-
-float src0_0, src0_1, src0_2, src0_3;
-float src1_0, src1_1, src1_2, src1_3;
-
-__asm__ volatile (
-1: \n\t
-lwc1 %[src0_0], 0(%[s0])\n\t
-lwc1 %[src1_0], 0(%[s1])\n\t
-lwc1 %[src0_1], 4(%[s0])\n\t
-lwc1 %[src1_1], 4(%[s1])\n\t
-lwc1 %[src0_2], 8(%[s0])\n\t
-lwc1 %[src1_2], 8(%[s1])\n\t
-lwc1 %[src0_3], 12(%[s0]) \n\t
-lwc1 %[src1_3], 12(%[s1]) \n\t
-mul.s %[src0_0], %[src0_0], %[src1_0] \n\t
-mul.s %[src0_1], %[src0_1], %[src1_1] \n\t
-mul.s %[src0_2], %[src0_2], %[src1_2] \n\t
-mul.s %[src0_3], %[src0_3], %[src1_3] \n\t
-swc1 %[src0_0], 0(%[d]) \n\t
-swc1 %[src0_1], 4(%[d]) \n\t
-swc1 %[src0_2], 8(%[d]) \n\t
-swc1 %[src0_3], 12(%[d])\n\t
-addiu %[s0], %[s0], 16 \n\t
-addiu %[s1], %[s1], 16 \n\t
-addiu %[d], %[d], 16 \n\t
-bne%[d], %[d_end], 1b \n\t
+// input length must be a multiple of 4
+av_assert2(len % 4 == 0);
-: [src0_0]=f(src0_0), [src0_1]=f(src0_1),
- [src0_2]=f(src0_2), [src0_3]=f(src0_3),
- [src1_0]=f(src1_0), [src1_1]=f(src1_1),
- [src1_2]=f(src1_2), [src1_3]=f(src1_3),
- [d]+r(d), [s0]+r(s0), [s1]+r(s1)
-: [d_end]r(d_end)
-: memory
-);
+for (i = 0; i len; i += 4) {
+dst[i] = src0[i] * src1[i];
+dst[i + 1] = src0[i + 1] * src1[i + 1];
+dst[i + 2] = src0[i + 2] * src1[i + 2];
+dst[i + 3] = src0[i + 3] * src1[i + 3];
}
}
-static void vector_fmul_scalar_mips(float *dst, const float *src, float mul,
- int len)
+static void vector_fmul_scalar_mips(
+float *av_restrict dst, const float *av_restrict src, float mul, int len)
{
-float temp0, temp1, temp2, temp3;
-float *local_src = (float*)src;
-float *end = local_src + len;
+int i;
-/* loop unrolled 4 times */
-__asm__ volatile(
-.setpush \n\t
-.setnoreorder\n\t
-1: \n\t
-lwc1%[temp0], 0(%[src])\n\t
-lwc1%[temp1], 4(%[src])\n\t
-lwc1%[temp2], 8(%[src])\n\t
-lwc1%[temp3], 12(%[src]) \n\t
-addiu %[dst], %[dst], 16 \n\t
-mul.s %[temp0], %[temp0], %[mul] \n\t
-mul.s %[temp1], %[temp1], %[mul] \n\t
-mul.s %[temp2], %[temp2], %[mul] \n\t
-mul.s %[temp3], %[temp3], %[mul] \n\t
-addiu %[src], %[src], 16 \n\t
-swc1
[FFmpeg-devel] [PATCH] movenc: Write 'colr' box correctly for MP4
This also restricts it to MOV and MP4, since it is only
defined for those formats.
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavformat/movenc.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 210f78e..9c6e1be 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1500,7 +1500,8 @@ static int mov_write_pasp_tag(AVIOContext *pb, MOVTrack
*track)
static int mov_write_colr_tag(AVIOContext *pb, MOVTrack *track)
{
-// Ref:
https://developer.apple.com/library/mac/technotes/tn2162/_index.html#//apple_ref/doc/uid/DTS40013070-CH1-TNTAG9
+// Ref (MOV):
https://developer.apple.com/library/mac/technotes/tn2162/_index.html#//apple_ref/doc/uid/DTS40013070-CH1-TNTAG9
+// Ref (MP4): ISO/IEC 14496-12:2012
if (track-enc-color_primaries == AVCOL_PRI_UNSPECIFIED
track-enc-color_trc == AVCOL_TRC_UNSPECIFIED
@@ -1532,9 +1533,15 @@ static int mov_write_colr_tag(AVIOContext *pb, MOVTrack
*track)
}
}
-avio_wb32(pb, 18);
+/* We should only ever be called by MOV or MP4. */
+av_assert0(track-mode == MODE_MOV || track-mode == MODE_MP4);
+
+avio_wb32(pb, 18 + (track-mode == MODE_MP4));
ffio_wfourcc(pb, colr);
-ffio_wfourcc(pb, nclc);
+if (track-mode == MODE_MP4)
+ffio_wfourcc(pb, nclx);
+else
+ffio_wfourcc(pb, nclc);
switch (track-enc-color_primaries) {
case AVCOL_PRI_BT709: avio_wb16(pb, 1); break;
case AVCOL_PRI_SMPTE170M:
@@ -1555,7 +1562,13 @@ static int mov_write_colr_tag(AVIOContext *pb, MOVTrack
*track)
default: avio_wb16(pb, 2);
}
-return 18;
+if (track-mode == MODE_MP4) {
+int full_range = track-enc-color_range == AVCOL_RANGE_JPEG;
+avio_w8(pb, full_range 7);
+return 19;
+} else {
+return 18;
+}
}
static void find_compressor(char * compressor_name, int len, MOVTrack *track)
@@ -1666,8 +1679,12 @@ static int mov_write_video_tag(AVIOContext *pb,
MOVMuxContext *mov, MOVTrack *tr
if (track-enc-field_order != AV_FIELD_UNKNOWN)
mov_write_fiel_tag(pb, track);
-if (mov-flags FF_MOV_FLAG_WRITE_COLR)
-mov_write_colr_tag(pb, track);
+if (mov-flags FF_MOV_FLAG_WRITE_COLR) {
+if (track-mode == MODE_MOV || track-mode == MODE_MP4)
+mov_write_colr_tag(pb, track);
+else
+av_log(mov-fc, AV_LOG_WARNING, Not writing 'colr' atom. Format
is not MOV or MP4.\n);
+}
if (track-enc-sample_aspect_ratio.den
track-enc-sample_aspect_ratio.num
track-enc-sample_aspect_ratio.den !=
track-enc-sample_aspect_ratio.num) {
--
1.8.3.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 10/12] mips: use float* to hold pointer instead of int
This is obviously needed for 64-bit support.
Signed-off-by: James Cowgill james...@cowgill.org.uk
---
libavcodec/mips/aacdec_mips.c | 2 +-
libavcodec/mips/aacpsdsp_mips.c | 12 ++--
libavcodec/mips/sbrdsp_mips.c | 10 +-
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/libavcodec/mips/aacdec_mips.c b/libavcodec/mips/aacdec_mips.c
index 5e0a83d..b6eec53 100644
--- a/libavcodec/mips/aacdec_mips.c
+++ b/libavcodec/mips/aacdec_mips.c
@@ -344,7 +344,7 @@ static void update_ltp_mips(AACContext *ac,
SingleChannelElement *sce)
if (ics-window_sequence[0] == EIGHT_SHORT_SEQUENCE) {
float *p_saved_ltp = saved_ltp + 576;
-int loop_end1 = (int)(p_saved_ltp + 448);
+float *loop_end1 = p_saved_ltp + 448;
float_copy(saved_ltp, saved, 512);
diff --git a/libavcodec/mips/aacpsdsp_mips.c b/libavcodec/mips/aacpsdsp_mips.c
index 1175918..b03cc3f 100644
--- a/libavcodec/mips/aacpsdsp_mips.c
+++ b/libavcodec/mips/aacpsdsp_mips.c
@@ -293,7 +293,7 @@ static void ps_decorrelate_mips(float (*out)[2], float
(*delay)[2],
float phi_fract1 = phi_fract[1];
float temp0, temp1, temp2, temp3, temp4, temp5, temp6, temp7, temp8, temp9;
-len = (int)((int*)p_delay + (len 1));
+float *p_delay_end = (p_delay + (len 1));
/* merged 2 loops */
__asm__ volatile(
@@ -369,7 +369,7 @@ static void ps_decorrelate_mips(float (*out)[2], float
(*delay)[2],
swc1%[temp3], 628(%[p_ap_delay]) \n\t
swc1%[temp5], -8(%[p_out]) \n\t
swc1%[temp6], -4(%[p_out]) \n\t
-bne %[p_delay],%[len],1b\n\t
+bne %[p_delay],%[p_delay_end],1b\n\t
swc1 %[temp6], -4(%[p_out]) \n\t
.setpop \n\t
@@ -380,7 +380,7 @@ static void ps_decorrelate_mips(float (*out)[2], float
(*delay)[2],
[p_Q_fract]+r(p_Q_fract), [p_t_gain]+r(p_t_gain),
[p_out]+r(p_out),
[ag0]=f(ag0), [ag1]=f(ag1), [ag2]=f(ag2)
: [phi_fract0]f(phi_fract0), [phi_fract1]f(phi_fract1),
- [len]r(len), [g_decay_slope]f(g_decay_slope)
+ [p_delay_end]r(p_delay_end), [g_decay_slope]f(g_decay_slope)
: memory
);
}
@@ -400,7 +400,7 @@ static void ps_stereo_interpolate_mips(float (*l)[2], float
(*r)[2],
float temp0, temp1, temp2, temp3;
float l_re, l_im, r_re, r_im;
-len = (int)((int*)l + (len 1));
+float *l_end = ((float *)l + (len 1));
__asm__ volatile(
.setpush \n\t
@@ -427,7 +427,7 @@ static void ps_stereo_interpolate_mips(float (*l)[2], float
(*r)[2],
swc1%[temp0], -8(%[l]) \n\t
swc1%[temp2], -8(%[r]) \n\t
swc1%[temp1], -4(%[l]) \n\t
-bne %[l], %[len],1b \n\t
+bne %[l], %[l_end], 1b \n\t
swc1 %[temp3], -4(%[r]) \n\t
.setpop \n\t
@@ -438,7 +438,7 @@ static void ps_stereo_interpolate_mips(float (*l)[2], float
(*r)[2],
[l_re]=f(l_re), [l_im]=f(l_im),
[r_re]=f(r_re), [r_im]=f(r_im)
: [hs0]f(hs0), [hs1]f(hs1), [hs2]f(hs2),
- [hs3]f(hs3), [len]r(len)
+ [hs3]f(hs3), [l_end]r(l_end)
: memory
);
}
diff --git a/libavcodec/mips/sbrdsp_mips.c b/libavcodec/mips/sbrdsp_mips.c
index 5c21749..9f2d827 100644
--- a/libavcodec/mips/sbrdsp_mips.c
+++ b/libavcodec/mips/sbrdsp_mips.c
@@ -665,14 +665,14 @@ static void sbr_hf_gen_mips(float (*X_high)[2], const
float (*X_low)[2],
static void sbr_hf_g_filt_mips(float (*Y)[2], const float (*X_high)[40][2],
const float *g_filt, int m_max, intptr_t ixh)
{
-float *p_y, *p_x, *p_g;
+const float *p_x, *p_g, *loop_end;
+float *p_y;
float temp0, temp1, temp2;
-int loop_end;
-p_g = (float*)g_filt[0];
+p_g = g_filt[0];
p_y = Y[0][0];
-p_x = (float*)X_high[0][ixh][0];
-loop_end = (int)((int*)p_g + m_max);
+p_x = X_high[0][ixh][0];
+loop_end = p_g + m_max;
__asm__ volatile(
.setpush\n\t
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 12/12] mips/aaccoder: use variables instead of using register names directly
On mips64, the registers t[4-7] do not exist. Instead of using a lot of #ifdef
or defines to handle differing register names, use variables and let GCC
allocate the registers automatically (like in the other mips assembly files).
In get_band_cost_ESC_mips, t4 and t5 were renamed to t6 and t7 to avoid a
variable name conflict.
Signed-off-by: James Cowgill james...@cowgill.org.uk
---
libavcodec/mips/aaccoder_mips.c | 929 +---
1 file changed, 477 insertions(+), 452 deletions(-)
diff --git a/libavcodec/mips/aaccoder_mips.c b/libavcodec/mips/aaccoder_mips.c
index 8595913..ea0bf31 100644
--- a/libavcodec/mips/aaccoder_mips.c
+++ b/libavcodec/mips/aaccoder_mips.c
@@ -221,6 +221,7 @@ static void quantize_and_encode_band_cost_SQUAD_mips(struct
AACEncContext *s,
for (i = 0; i size; i += 4) {
int curidx;
int *in_int = (int *)in[i];
+int t0, t1, t2, t3, t4, t5, t6, t7;
qc1 = scaled[i ] * Q34 + 0.4054f;
qc2 = scaled[i+1] * Q34 + 0.4054f;
@@ -235,31 +236,31 @@ static void
quantize_and_encode_band_cost_SQUAD_mips(struct AACEncContext *s,
slt%[qc2], $zero, %[qc2] \n\t
slt%[qc3], $zero, %[qc3] \n\t
slt%[qc4], $zero, %[qc4] \n\t
-lw $t0,0(%[in_int])\n\t
-lw $t1,4(%[in_int])\n\t
-lw $t2,8(%[in_int])\n\t
-lw $t3,12(%[in_int]) \n\t
-srl$t0,$t0,31 \n\t
-srl$t1,$t1,31 \n\t
-srl$t2,$t2,31 \n\t
-srl$t3,$t3,31 \n\t
-subu $t4,$zero, %[qc1] \n\t
-subu $t5,$zero, %[qc2] \n\t
-subu $t6,$zero, %[qc3] \n\t
-subu $t7,$zero, %[qc4] \n\t
-movn %[qc1], $t4,$t0 \n\t
-movn %[qc2], $t5,$t1 \n\t
-movn %[qc3], $t6,$t2 \n\t
-movn %[qc4], $t7,$t3 \n\t
+lw %[t0], 0(%[in_int])\n\t
+lw %[t1], 4(%[in_int])\n\t
+lw %[t2], 8(%[in_int])\n\t
+lw %[t3], 12(%[in_int]) \n\t
+srl%[t0], %[t0], 31 \n\t
+srl%[t1], %[t1], 31 \n\t
+srl%[t2], %[t2], 31 \n\t
+srl%[t3], %[t3], 31 \n\t
+subu %[t4], $zero, %[qc1] \n\t
+subu %[t5], $zero, %[qc2] \n\t
+subu %[t6], $zero, %[qc3] \n\t
+subu %[t7], $zero, %[qc4] \n\t
+movn %[qc1], %[t4], %[t0] \n\t
+movn %[qc2], %[t5], %[t1] \n\t
+movn %[qc3], %[t6], %[t2] \n\t
+movn %[qc4], %[t7], %[t3] \n\t
.set pop \n\t
: [qc1]+r(qc1), [qc2]+r(qc2),
- [qc3]+r(qc3), [qc4]+r(qc4)
+ [qc3]+r(qc3), [qc4]+r(qc4),
+ [t0]=r(t0), [t1]=r(t1), [t2]=r(t2), [t3]=r(t3),
+ [t4]=r(t4), [t5]=r(t5), [t6]=r(t6), [t7]=r(t7)
: [in_int]r(in_int)
-: t0, t1, t2, t3,
- t4, t5, t6, t7,
- memory
+: memory
);
curidx = qc1;
@@ -295,6 +296,7 @@ static void quantize_and_encode_band_cost_UQUAD_mips(struct
AACEncContext *s,
int *in_int = (int *)in[i];
uint8_t v_bits;
unsigned int v_codes;
+int t0, t1, t2, t3, t4;
qc1 = scaled[i ] * Q34 + 0.4054f;
qc2 = scaled[i+1] * Q34 + 0.4054f;
@@ -305,50 +307,51 @@ static void
quantize_and_encode_band_cost_UQUAD_mips(struct AACEncContext *s,
.set push \n\t
.set noreorder \n\t
-ori$t4,$zero, 2 \n\t
+ori%[t4], $zero, 2 \n\t
ori%[sign],$zero, 0 \n\t
-slt$t0,$t4,%[qc1] \n\t
-slt$t1,$t4,%[qc2] \n\t
-slt$t2,$t4,%[qc3] \n\t
-slt$t3,$t4,%[qc4] \n\t
-movn %[qc1], $t4,$t0 \n\t
-movn %[qc2], $t4,$t1 \n\t
-movn %[qc3], $t4,$t2 \n\t
-movn %[qc4], $t4,$t3 \n\t
-lw $t0,0(%[in_int])\n\t
-lw $t1,4(%[in_int])\n\t
-lw $t2,8(%[in_int])\n\t
-lw $t3,12(%[in_int]) \n\t
-slt$t0,$t0,$zero \n\t
-movn %[sign],$t0,%[qc1] \n\t
-slt$t1,$t1,$zero \n\t
-slt$t2,$t2,$zero \n\t
-slt$t3,$t3,$zero
Re: [FFmpeg-devel] [PATCH] libavfilter:vf_thumbnail.c: Fix bug in buffer handling for RGB width
On Sun, Feb 22, 2015 at 7:26 AM, Clément Bœsch u...@pkh.me wrote: On Wed, Feb 18, 2015 at 06:20:54PM -0800, Chris Kennedy wrote: More details attached, debug level and gdb backtrace. Hopefully this helps, and I will work on getting a file I can share showing the issue. Thanks [...] #14 0x0042790c in process_input (file_index=0) at ffmpeg.c:3418 #15 0x00429397 in transcode_step () at ffmpeg.c:3719 #16 0x004294a5 in transcode () at ffmpeg.c:3771 #17 0x004299b3 in main (argc=21, argv=0x7fffdcf8) at ffmpeg.c:3951 This doesn't really look like an overread, more like you hit a memory limit and your malloc implementation doesn't like it, or something along these lines (178 frames is a lot). Keep in mind that thumbnail might not be the best solution to getting thumb. Using scene detection in select filter and pick the Nth scene change might pick a better one, with less memory usage. You might want to try valgrind to make sure it's not an overread/write. Yeah I am now going to just do the normal frame stuff with scene change or similar, as it seems I explored it deeper and hit yet another oddity in an email I sent last night about it where it crashed in a different way using hardly any memory and when the program exits (yet only when it is parsing the exact second that has some oddity, other video and other parts of the exact same video do not trigger, larger frame counts don't either like 300). Thanks for the help, yeah I wish I could send the video that triggers it, but it is one of our DVD rips of Rurouni Kenshin we did with handbreak or something years ago and must itself have some bad mpeg4 frame information causing this I guess. I am doubting this would be easy/humanly possible to recreate and find a non-copyrighted video doing it without spending day and night hunting something down (which the bug is so odd I can't really understand what it is doing, it seems to only crash now at the end IF the frame is extracted it always crashes on, odd). Thanks, Chris -- Clément B. ___ 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 02/12] mips/float_dsp: replace assembly with C implementations
On 2/26/2015 1:42 PM, James Cowgill wrote: The assembly versions have a few problems - They only work with mips32r2 enabled - They don't work on 64-bits - They're massive and complex So replace them with C implementations which solve these problems and let GCC magically optimize for different platforms. All the functions are manually unrolled 4 times (like the assembly code). With the addition of a few restrict keywords, the functions produce almost identical assembly to the original versions when compiled with gcc -O3. Why have C implementations in the *MIPS* DSP code? That's silly. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary
On 2/26/2015 2:09 PM, Carl Eugen Hoyos wrote: +snprintf(header, len + 3, %s\r\n, s-headers); This does not necessarily work on windows. The C standard idctates that in text mode, \n is translated to the system's native newline. Use memcpy and 0x0D / 0X0A / 0x00. This may also accidentally allow for headers to end with '\n\r\n', wouldn't it? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][RFC] Interpretation of duration field in AVI super index chunk
On Thu, Feb 26, 2015 at 02:14:33PM +0100, Tobias Rapp wrote:
On 26.02.2015 00:51, Michael Niedermayer wrote:
On Wed, Feb 25, 2015 at 05:35:33PM +0100, Tobias Rapp wrote:
avienc.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
09f8c8250ce5ec1bdad79a1bf280028c9d3af376
0001-libavformat-avienc-Fix-duration-for-audio-stream-Ope.patch
From 3a8e15598fa3e044f3ef65b5063c633cb4b3afed Mon Sep 17 00:00:00 2001
From: Tobias Rapp t.r...@noa-audio.com
Date: Wed, 25 Feb 2015 17:10:13 +0100
Subject: [PATCH] libavformat/avienc: Fix duration for audio stream OpenDML
super index
Fixes the duration field of the OpenDML super index indx chunk to
contain the number of samples instead of the number of packets for
(linear/PCM) audio streams.
This matches the OpenDML V1.02 standard text which states that the
duration field shall contain time span in stream ticks.
---
libavformat/avienc.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index 53c2fe7..b77b295 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -49,6 +49,7 @@ typedef struct AVIIentry {
typedef struct AVIIndex {
int64_t indx_start;
+int64_t audio_strm_offset;
int entry;
int ents_allocated;
AVIIentry** cluster;
@@ -91,6 +92,7 @@ static int64_t avi_start_new_riff(AVFormatContext *s,
AVIOContext *pb,
avi-riff_id++;
for (i = 0; i s-nb_streams; i++) {
AVIStream *avist = s-streams[i]-priv_data;
+avist-indexes.audio_strm_offset = avist-audio_strm_length;
avist-indexes.entry = 0;
}
@@ -476,6 +478,7 @@ static int avi_write_ix(AVFormatContext *s)
for (i = 0; i s-nb_streams; i++) {
AVIStream *avist = s-streams[i]-priv_data;
int64_t ix, pos;
+int au_byterate, au_ssize, au_scale;
avi_stream2fourcc(tag, i, s-streams[i]-codec-codec_type);
ix_tag[3] = '0' + i;
@@ -511,7 +514,11 @@ static int avi_write_ix(AVFormatContext *s)
avio_skip(pb, 16 * avi-riff_id);
avio_wl64(pb, ix);/* qwOffset */
avio_wl32(pb, pos - ix); /* dwSize */
-avio_wl32(pb, avist-indexes.entry); /* dwDuration */
+ff_parse_specific_params(s-streams[i], au_byterate, au_ssize,
au_scale);
+if (au_ssize == 0)
+avio_wl32(pb, avist-indexes.entry); /* dwDuration (packet
count) */
+else
+avio_wl32(pb, (avist-audio_strm_length -
avist-indexes.audio_strm_offset) / au_ssize); /* dwDuration (sample
count) */
the rounding here is wrong
the index to be useable needs to have segments duration summable
as is this would lead to significangt errors if many of these
durations would be summed up
something like
avist-audio_strm_length / au_ssize - avist-indexes.audio_strm_offset /
au_ssize
might avoid that but ive not tested it
My assumption was that a stream packet contains only whole samples
for linear/uncompressed audio (PCM) and that only for linear audio
the expression au_ssize 0 evaluates to TRUE.
We try to use au_ssize = 0 for compressed audio but i think it can be
non zero in some stream copy cases, iam not 100% sure though
If that is not the case I can do the rounding as suggested or maybe
introduce some separate stream duration counter based on
AVPacket.duration?
i think best to keep it simple and maybe print a request for a sample/
testcase if some combination of parameters is found which we are
unsure about if it works correctly
[...]
--
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
[FFmpeg-devel] [PATCH 00/12] mips cleanups and port to mips64
Hi, This patchset aims to cleanup the MIPS optimizations a bit and add support for 64-bit processors. I haven't attempted specifically to optimize any of this for 64-bit systems, except for the removal of some assembly blocks which GCC can optimize just as well itself. Also I havn't gone through and cleaned up everything, just the bits that make it easier to port to 64-bits or some things that were really bugging me :) I've run fate on both 32 and 64-bit mips machines and it passes all the tests on both. I don't have a machine with DSP instructions but I managed (with some effort) to run fate using qemu and it passed all the tests there as well. One thing I was sligly uneasy about in the change I made to the configure script was forcing specific ISA levels unless you pass --disable-xxx to configure. This has a habit of causing the final binaries not to run at all (eg I have to disable DSP otherwise I get a lot of SIGILL). Since this was what the code was doing before, I just left it instead of messing up all the MIPS configure options (more than I have done). Thanks, James James Cowgill (12): mips/mathops: remove 64-bit code mips/float_dsp: replace assembly with C implementations mips/aacpsdsp: fix definition of ps_decorrelate_mips mips/fft: remove some useless assembly mips/sbrdsp: remove sbr_neg_odd_64_mips mips/aacdec: refactor out duplicated assembly code mips/aacdec: remove uses of mips32r2 specific ext instructions configure, mips: remove MIPS32R2, merging it with MIPSFPU mips: port optimizations to mips n64 mips: use float* to hold pointer instead of int mips/acelp_filters: fix incorrect register constraint mips/aaccoder: use variables instead of using register names directly Makefile | 2 +- arch.mak | 1 - configure | 19 +- libavcodec/mips/aaccoder_mips.c | 929 +++--- libavcodec/mips/aacdec_mips.c | 623 libavcodec/mips/aacdec_mips.h | 58 +- libavcodec/mips/aacpsdsp_mips.c | 61 +- libavcodec/mips/aacpsy_mips.h | 6 +- libavcodec/mips/aacsbr_mips.c | 53 +- libavcodec/mips/aacsbr_mips.h | 17 +- libavcodec/mips/ac3dsp_mips.c | 63 +- libavcodec/mips/acelp_filters_mips.c | 15 +- libavcodec/mips/acelp_vectors_mips.c | 7 +- libavcodec/mips/asmdefs.h | 48 ++ libavcodec/mips/celp_filters_mips.c | 13 +- libavcodec/mips/celp_math_mips.c | 5 +- libavcodec/mips/compute_antialias_float.h | 4 +- libavcodec/mips/fft_mips.c| 39 +- libavcodec/mips/fmtconvert_mips.c | 33 +- libavcodec/mips/lsp_mips.h| 6 +- libavcodec/mips/mathops.h | 26 - libavcodec/mips/mpegaudiodsp_mips_fixed.c | 11 +- libavcodec/mips/mpegaudiodsp_mips_float.c | 25 +- libavcodec/mips/sbrdsp_mips.c | 89 +-- libavutil/mips/float_dsp_mips.c | 354 +++- 25 files changed, 963 insertions(+), 1544 deletions(-) create mode 100644 libavcodec/mips/asmdefs.h -- 2.1.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 01/12] mips/mathops: remove 64-bit code
GCC is perfectly happy generating optimized multiplication code on its own for
64-bit arches. GCC refuses to optimize the loongson code when in 32-bit mode,
so I've left that.
Signed-off-by: James Cowgill james...@cowgill.org.uk
---
libavcodec/mips/mathops.h | 26 --
1 file changed, 26 deletions(-)
diff --git a/libavcodec/mips/mathops.h b/libavcodec/mips/mathops.h
index 368290a..5673fc0 100644
--- a/libavcodec/mips/mathops.h
+++ b/libavcodec/mips/mathops.h
@@ -49,32 +49,6 @@ static inline av_const int64_t MLS64(int64_t d, int a, int b)
}
#define MLS64(d, a, b) ((d) = MLS64(d, a, b))
-#elif ARCH_MIPS64
-
-static inline av_const int64_t MAC64(int64_t d, int a, int b)
-{
-int64_t m;
-__asm__ (dmult %2, %3 \n\t
- mflo %1 \n\t
- daddu %0, %0, %1 \n\t
- : +r(d), =r(m) : r(a), r(b)
- : hi, lo);
-return d;
-}
-#define MAC64(d, a, b) ((d) = MAC64(d, a, b))
-
-static inline av_const int64_t MLS64(int64_t d, int a, int b)
-{
-int64_t m;
-__asm__ (dmult %2, %3 \n\t
- mflo %1 \n\t
- dsubu %0, %0, %1 \n\t
- : +r(d), =r(m) : r(a), r(b)
- : hi, lo);
-return d;
-}
-#define MLS64(d, a, b) ((d) = MLS64(d, a, b))
-
#endif
#endif /* HAVE_INLINE_ASM */
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 09/12] mips: port optimizations to mips n64
This mainly consists of replacing all the pointer arithmatic 'addiu' instructions with PTR_ADDIU which will handle the differences in pointer sizes when compiled on 64 bit mips systems. The header asmdefs.h contains the PTR_ macros which expend to the correct mips instructions to manipulate registers containing pointers. Signed-off-by: James Cowgill james...@cowgill.org.uk --- libavcodec/mips/aacdec_mips.c | 21 +-- libavcodec/mips/aacdec_mips.h | 9 ++--- libavcodec/mips/aacpsdsp_mips.c | 43 +++--- libavcodec/mips/aacpsy_mips.h | 6 ++-- libavcodec/mips/aacsbr_mips.c | 53 +-- libavcodec/mips/aacsbr_mips.h | 17 - libavcodec/mips/ac3dsp_mips.c | 59 --- libavcodec/mips/acelp_filters_mips.c | 13 +++ libavcodec/mips/acelp_vectors_mips.c | 7 ++-- libavcodec/mips/asmdefs.h | 48 + libavcodec/mips/celp_filters_mips.c | 13 +++ libavcodec/mips/celp_math_mips.c | 5 +-- libavcodec/mips/compute_antialias_float.h | 4 ++- libavcodec/mips/fft_mips.c| 13 +++ libavcodec/mips/fmtconvert_mips.c | 33 - libavcodec/mips/lsp_mips.h| 6 ++-- libavcodec/mips/mpegaudiodsp_mips_fixed.c | 11 +++--- libavcodec/mips/mpegaudiodsp_mips_float.c | 25 ++--- libavcodec/mips/sbrdsp_mips.c | 45 +++ 19 files changed, 250 insertions(+), 181 deletions(-) create mode 100644 libavcodec/mips/asmdefs.h diff --git a/libavcodec/mips/aacdec_mips.c b/libavcodec/mips/aacdec_mips.c index 909e22b..5e0a83d 100644 --- a/libavcodec/mips/aacdec_mips.c +++ b/libavcodec/mips/aacdec_mips.c @@ -56,6 +56,7 @@ #include aacdec_mips.h #include libavcodec/aactab.h #include libavcodec/sinewin.h +#include libavcodec/mips/asmdefs.h #if HAVE_INLINE_ASM static av_always_inline void float_copy(float *dst, const float *src, int count) @@ -80,7 +81,7 @@ static av_always_inline void float_copy(float *dst, const float *src, int count) lw %[temp5],20(%[src]) \n\t lw %[temp6],24(%[src]) \n\t lw %[temp7],28(%[src]) \n\t -addiu %[src], %[src], 32\n\t +PTR_ADDIU %[src],%[src], 32\n\t sw %[temp0],0(%[dst]) \n\t sw %[temp1],4(%[dst]) \n\t sw %[temp2],8(%[dst]) \n\t @@ -90,7 +91,7 @@ static av_always_inline void float_copy(float *dst, const float *src, int count) sw %[temp6],24(%[dst]) \n\t sw %[temp7],28(%[dst]) \n\t bne %[src], %[loop_end], 1b\n\t -addiu %[dst], %[dst], 32\n\t +PTR_ADDIU %[dst],%[dst], 32\n\t .set pop\n\t : [temp0]=r(temp[0]), [temp1]=r(temp[1]), @@ -250,7 +251,7 @@ static void apply_ltp_mips(AACContext *ac, SingleChannelElement *sce) sw $0, 4(%[p_predTime])\n\t sw $0, 8(%[p_predTime])\n\t sw $0, 12(%[p_predTime]) \n\t -addiu %[p_predTime], %[p_predTime], 16 \n\t +PTR_ADDIU %[p_predTime], %[p_predTime], 16 \n\t : [p_predTime]+r(p_predTime) : @@ -261,7 +262,7 @@ static void apply_ltp_mips(AACContext *ac, SingleChannelElement *sce) __asm__ volatile ( sw $0, 0(%[p_predTime])\n\t -addiu %[p_predTime], %[p_predTime], 4\n\t +PTR_ADDIU %[p_predTime], %[p_predTime], 4\n\t : [p_predTime]+r(p_predTime) : @@ -315,9 +316,9 @@ static av_always_inline void fmul_and_reverse(float *dst, const float *src0, con swc1%[temp9],4(%[ptr1])\n\t swc1%[temp10], 8(%[ptr1])\n\t swc1%[temp11], 12(%[ptr1]) \n\t -addiu %[ptr1], %[ptr1], 16 \n\t -addiu %[ptr2], %[ptr2], -16 \n\t -addiu %[ptr3], %[ptr3], -16 \n\t +PTR_ADDIU %[ptr1], %[ptr1], 16 \n\t +PTR_ADDIU %[ptr2], %[ptr2], -16 \n\t +PTR_ADDIU %[ptr3], %[ptr3], -16 \n\t : [temp0]=f(temp[0]), [temp1]=f(temp[1]), [temp2]=f(temp[2]), [temp3]=f(temp[3]), @@ -358,7 +359,7 @@ static void update_ltp_mips(AACContext *ac, SingleChannelElement *sce) sw $0, 20(%[p_saved_ltp]) \n\t sw $0,
Re: [FFmpeg-devel] [PATCH] movenc: Write 'colr' box correctly for MP4
On 2/26/2015 1:50 PM, Clément Bœsch wrote: If the option is set by default, you don't want to warn for no reason. It's not set by default. That patch never went in. I don't believe silently not writing it is a valid approach. Then again I think setting a default movflag like that instead of changing the option is also stupid. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movenc: Write 'colr' box correctly for MP4
On Thu, Feb 26, 2015 at 01:47:01PM +, Derek Buitenhuis wrote:
This also restricts it to MOV and MP4, since it is only
defined for those formats.
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavformat/movenc.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 210f78e..9c6e1be 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
[...]
+if (mov-flags FF_MOV_FLAG_WRITE_COLR) {
+if (track-mode == MODE_MOV || track-mode == MODE_MP4)
+mov_write_colr_tag(pb, track);
+else
+av_log(mov-fc, AV_LOG_WARNING, Not writing 'colr' atom. Format
is not MOV or MP4.\n);
If the option is set by default, you don't want to warn for no reason.
--
Clément B.
pgpTfpKSHNavO.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] palette{gen,use} FATE tests
On Mon, Feb 23, 2015 at 01:56:59PM +0100, Clément Bœsch wrote: Here are two tests for the recently added filters. I'm hopping that qsort will not cause any issue, otherwise we might need to switch to AV_QSORT (I'm thinking of the sort where multiple different values have the same score in palettegen). Also not sure whether framecrc needs a bitexact flag somewhere. The sample should be uploaded soon but I'll wait for at least 24 hours. Patchset applied with a few changes: - add pix_fmt bgra to make sure the checksum is in correct endianess - used AV_QSORT to make the output predictable and consistent over platforms (it was failing at least with musl apparently) -- Clément B. pgpp_7ScE7Ghe.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 06/12] mips/aacdec: refactor out duplicated assembly code
The float_copy and fmul_and_reverse functions are refactored out from the
multiple copies in this file.
Signed-off-by: James Cowgill james...@cowgill.org.uk
---
libavcodec/mips/aacdec_mips.c | 612 --
1 file changed, 111 insertions(+), 501 deletions(-)
diff --git a/libavcodec/mips/aacdec_mips.c b/libavcodec/mips/aacdec_mips.c
index 5db10f9..909e22b 100644
--- a/libavcodec/mips/aacdec_mips.c
+++ b/libavcodec/mips/aacdec_mips.c
@@ -58,6 +58,51 @@
#include libavcodec/sinewin.h
#if HAVE_INLINE_ASM
+static av_always_inline void float_copy(float *dst, const float *src, int
count)
+{
+// Copy 'count' floats from src to dst
+const float *loop_end = src + count;
+int temp[8];
+
+// count must be a multiple of 8
+av_assert2(count % 8 == 0);
+
+// loop unrolled 8 times
+__asm__ volatile (
+.set push \n\t
+.set noreorder \n\t
+1: \n\t
+lw %[temp0],0(%[src]) \n\t
+lw %[temp1],4(%[src]) \n\t
+lw %[temp2],8(%[src]) \n\t
+lw %[temp3],12(%[src]) \n\t
+lw %[temp4],16(%[src]) \n\t
+lw %[temp5],20(%[src]) \n\t
+lw %[temp6],24(%[src]) \n\t
+lw %[temp7],28(%[src]) \n\t
+addiu %[src], %[src], 32\n\t
+sw %[temp0],0(%[dst]) \n\t
+sw %[temp1],4(%[dst]) \n\t
+sw %[temp2],8(%[dst]) \n\t
+sw %[temp3],12(%[dst]) \n\t
+sw %[temp4],16(%[dst]) \n\t
+sw %[temp5],20(%[dst]) \n\t
+sw %[temp6],24(%[dst]) \n\t
+sw %[temp7],28(%[dst]) \n\t
+bne %[src], %[loop_end], 1b\n\t
+addiu %[dst], %[dst], 32\n\t
+.set pop\n\t
+
+: [temp0]=r(temp[0]), [temp1]=r(temp[1]),
+ [temp2]=r(temp[2]), [temp3]=r(temp[3]),
+ [temp4]=r(temp[4]), [temp5]=r(temp[5]),
+ [temp6]=r(temp[6]), [temp7]=r(temp[7]),
+ [src]+r(src), [dst]+r(dst)
+: [loop_end]r(loop_end)
+: memory
+);
+}
+
static av_always_inline int lcg_random(unsigned previous_val)
{
union { unsigned u; int s; } v = { previous_val * 1664525u + 1013904223 };
@@ -92,49 +137,7 @@ static void imdct_and_windowing_mips(AACContext *ac,
SingleChannelElement *sce)
(ics-window_sequence[0] == ONLY_LONG_SEQUENCE ||
ics-window_sequence[0] == LONG_START_SEQUENCE)) {
ac-fdsp-vector_fmul_window(out, saved,
buf, lwindow_prev, 512);
} else {
-{
-float *buf1 = saved;
-float *buf2 = out;
-int temp0, temp1, temp2, temp3, temp4, temp5, temp6, temp7;
-int loop_end;
-
-/* loop unrolled 8 times */
-__asm__ volatile (
-.set push \n\t
-.set noreorder \n\t
-addiu %[loop_end], %[src], 1792 \n\t
-1: \n\t
-lw %[temp0],0(%[src]) \n\t
-lw %[temp1],4(%[src]) \n\t
-lw %[temp2],8(%[src]) \n\t
-lw %[temp3],12(%[src]) \n\t
-lw %[temp4],16(%[src]) \n\t
-lw %[temp5],20(%[src]) \n\t
-lw %[temp6],24(%[src]) \n\t
-lw %[temp7],28(%[src]) \n\t
-addiu %[src], %[src], 32\n\t
-sw %[temp0],0(%[dst]) \n\t
-sw %[temp1],4(%[dst]) \n\t
-sw %[temp2],8(%[dst]) \n\t
-sw %[temp3],12(%[dst]) \n\t
-sw %[temp4],16(%[dst]) \n\t
-sw %[temp5],20(%[dst]) \n\t
-sw %[temp6],24(%[dst]) \n\t
-sw %[temp7],28(%[dst]) \n\t
-bne %[src], %[loop_end], 1b\n\t
- addiu %[dst], %[dst], 32\n\t
-.set pop\n\t
-
-: [temp0]=r(temp0), [temp1]=r(temp1),
- [temp2]=r(temp2), [temp3]=r(temp3),
- [temp4]=r(temp4), [temp5]=r(temp5),
- [temp6]=r(temp6), [temp7]=r(temp7),
- [loop_end]=r(loop_end), [src]+r(buf1),
- [dst]+r(buf2)
-:
-: memory
[FFmpeg-devel] [PATCH 11/12] mips/acelp_filters: fix incorrect register constraint
Change register constraint on the v variable from = to +. This was causing GCC to think that the v variable was never read and therefore not initialize it. This fixes about 20 fate failures on mips64el. Signed-off-by: James Cowgill james...@cowgill.org.uk --- libavcodec/mips/acelp_filters_mips.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/mips/acelp_filters_mips.c b/libavcodec/mips/acelp_filters_mips.c index 98ddc54..c77d37b 100644 --- a/libavcodec/mips/acelp_filters_mips.c +++ b/libavcodec/mips/acelp_filters_mips.c @@ -90,7 +90,7 @@ static void ff_acelp_interpolatef_mips(float *out, const float *in, PTR_ADDU %[p_filter_coeffs_m],%[p_filter_coeffs_m], %[prec] \n\t madd.s %[v],%[v],%[in_val_m], %[fc_val_m] \n\t -: [v] =f (v),[p_in_p] +r (p_in_p), [p_in_m] +r (p_in_m), +: [v] +f (v),[p_in_p] +r (p_in_p), [p_in_m] +r (p_in_m), [p_filter_coeffs_p] +r (p_filter_coeffs_p), [in_val_p] =f (in_val_p), [in_val_m] =f (in_val_m), [fc_val_p] =f (fc_val_p), [fc_val_m] =f (fc_val_m), -- 2.1.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 02/12] mips/float_dsp: replace assembly with C implementations
On Thu, 2015-02-26 at 13:51 +, Derek Buitenhuis wrote: On 2/26/2015 1:42 PM, James Cowgill wrote: The assembly versions have a few problems - They only work with mips32r2 enabled - They don't work on 64-bits - They're massive and complex So replace them with C implementations which solve these problems and let GCC magically optimize for different platforms. All the functions are manually unrolled 4 times (like the assembly code). With the addition of a few restrict keywords, the functions produce almost identical assembly to the original versions when compiled with gcc -O3. Why have C implementations in the *MIPS* DSP code? That's silly. Hmm maybe a little. I was just worried that if I moved all the loop unrolling stuff into generic code it might go slower on other arches I haven't tested. James ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movenc: Write 'colr' box correctly for MP4
On Thu, Feb 26, 2015 at 04:13:10PM +, Derek Buitenhuis wrote: On 2/26/2015 4:10 PM, Clément Bœsch wrote: Yes, it will return an error and abort the operation. Be it done on the command line or via the API. So said differently it won't work anymore. I do wonder what the point of the whole AVOption API is then, if we can't break it any more than a struct. just of the top of my head, i can think of: AVOptions allows listing the available options, like for automatically building a list of available options in a GUI it allows changing the type int-int64, int-double it stores default value, min and max allows access to substructures, one can in some cases move a field to s substructure one could dump and load settings of a struct in a generic way not needing to update the code after fields get added [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movenc: Write 'colr' box correctly for MP4
On Thu, Feb 26, 2015 at 01:47:01PM +, Derek Buitenhuis wrote: This also restricts it to MOV and MP4, since it is only defined for those formats. Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com --- libavformat/movenc.c | 29 +++-- 1 file changed, 23 insertions(+), 6 deletions(-) LGTM (the warning would have to be removed though if the specific codepath would be enabled by default) thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- 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] Live encoding into mxf...
Hello everyone,
I'm trying to encode video and audio directly from a capture board, 1 video
stream and 8 single channel audio streams into a MXF file encoding it in
Mpeg-2.
Everything is working fine except when I call av_write_trailer() at the end
(and before freeing CodecContext as stated in the documentation).
After using av_write_trailer, I end up with the whole video looking like
this http://i.imgur.com/M6HkcpR.jpg . It seems like the decoder is
misplacing the b-frames in the wrong position, but If i don't call this
function I can play the media file, with the image as it should be, in VLC
but the timestamp is completely wrong.
Looking at mediainfo I can see that my file doesn't have the file duration
(which later made sense when I looked inside the code.)
After a few hours with the file mxfenc.c found that if I comment the next
part inside the function mxf_write_footer(), the write trailer kinda
works,
(...)
if (mxf-edit_unit_byte_count s-oformat != ff_mxf_opatom_muxer) { //
no need to repeat index
if ((err = mxf_write_partition(s, 0, 0, footer_partition_key, 0))
0)
return err;
} /*else {
if ((err = mxf_write_partition(s, 0, 2, footer_partition_key, 0))
0)
return err;
mxf_write_klv_fill(s);
mxf_write_index_table_segment(s);
}*/
(...)
The kinda works part, its because I can play the file correctly in VLC
with the correct timestamps, and if I open it with Mediainfo everything
looks good, but If I try to open it with Sorenson Squeeze (for example), I
get a warning saying Squeeze does not support playing this file.
I carefully followed the documentation, samples, examples and I'm still
stuck :S.
I am using the ffmpeg 2.5.1 version and I also added a few changes that I
saw in the master, and nothing changed.
Additional info:
Target Output file format is a 1080i59.94, XDCam 30Mbit MXF op1a.
Regarding the 8 audio streams the codec options have the one provided by
avcodec_get_context_defaults3 plus this changes:
audio_codec_context-channels=1;
audio_codec_context-sample_rate = 48000;
audio_codec_context-bit_rate = 768000;
audio_codec_context-sample_fmt =AV_SAMPLE_FMT_S16;
audio_codec_context-flags= CODEC_FLAG_GLOBAL_HEADER;
audio_codec_context-time_base-num = 48000;
Regarding video I also do avcodec_get_context_defaults3 plus this:
video_codec_context- pix_fmt= AV_PIX_FMT_YUV422P;
video_codec_context-height = 1080;
video_codec_context-time_base-den = 3;
video_codec_context-time_base-num = 1001;
video_codec_context-field_order= AVFieldOrder.AV_FIELD_TB;
video_codec_context-width = 1920;
video_codec_context-codec_id= AV_CODEC_ID_MPEG2VIDEO;
video_codec_context-has_b_frames= 1;
video_codec_context-max_b_frames = 2;
video_codec_context-gop_size= 12;
video_codec_context-global_quality= FF_QP2LAMBDA * 1;
video_codec_context-rc_initial_buffer_occupancy= 10695476;
video_codec_context-scenechange_threshold = 10;
video_codec_context-color_primaries= AVCOL_PRI_BT709;
video_codec_context-color_trc= AVCOL_TRC_BT709;
video_codec_context-qmin= 1;
video_codec_context-flags |= CODEC_FLAG_GLOBAL_HEADER |
CODEC_FLAG_INTERLACED_DCT | CODEC_FLAG_INTERLACED_ME;
video_codec_context-bit_rate = 3000;
video_codec_context-rc_min_rate= 3000;
video_codec_context-rc_max_rate= 3000;
video_codec_context-rc_buffer_size= 10695476;
I also had specified me_method and me_range, but nothing changed.
Any idea what might be the problem?
Thanks guys,
Cheers
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH] avformat/adxdec: check avctx-channels for invalid values
On 26.02.2015 15:09, Luca Barbato wrote: On 26/02/15 12:19, Andreas Cadhalpun wrote: On 26.02.2015 04:15, Luca Barbato wrote: The decoder has this /* channels */ avctx-channels = buf[7]; if (avctx-channels = 0 || avctx-channels 2) return AVERROR_INVALIDDATA; So by the time you get there the channels are already validated. the extradata is validated on container and codec level so it should be fine. This validation just makes sure that the codec can't be opened. But then avformat_find_stream_info continues with reading a frame from the demuxer, leading to the segfault if avctx-channels is 0. do you have a sample for it? Yes. You can create one by setting the 8th byte of an adx file to 0. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movenc: Write 'colr' box correctly for MP4
On Thu, Feb 26, 2015 at 04:54:02PM +0100, Clément Bœsch wrote: On Thu, Feb 26, 2015 at 01:53:13PM +, Derek Buitenhuis wrote: On 2/26/2015 1:50 PM, Clément Bœsch wrote: If the option is set by default, you don't want to warn for no reason. It's not set by default. That patch never went in. Ah, my bad. I don't believe silently not writing it is a valid approach. Then again I think setting a default movflag like that instead of changing the option is also stupid. Well, breaking API on purpose when easily avoidable is kind of stupid too. You can also just deprecate the current flag and add yours. The point is to not make the option disappear because it will break callers. Changing the behaviour (enabling by default / making the old option void) is fine, breaking the API (removing the option) not so much. the option is in there since a month and was in no release so IMHO if people feel strongly about it then i guess simply replacing the option might be acceptable Strictly correct though it is to deprecate it and make it point to the new option though help text and or warning random idea: the new option could be a int with 3 states, on/force, off, auto where auto would write it only for supported formats like mov and maybe mp4 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movenc: Write 'colr' box correctly for MP4
On 2/26/2015 5:02 PM, Michael Niedermayer wrote: just of the top of my head, i can think of: AVOptions allows listing the available options, like for automatically building a list of available options in a GUI it allows changing the type int-int64, int-double it stores default value, min and max allows access to substructures, one can in some cases move a field to s substructure one could dump and load settings of a struct in a generic way not needing to update the code after fields get added Well, OK. Still need some reviews of the patch itself though ;). - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: Check linking against CoreGraphics or, ApplicationServices framework for avfoundation input device.
Am 08.02.15 um 15:19 schrieb Carl Eugen Hoyos: [...] Also attached is a patch that I believe is necessary for iOS audio capture, but it is mostly untested. (It allows device listing though.) Looks OK, please apply. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] bad arguments to init_put_bits
The init_put_bits() function (in libavcodec/put_bits.h) takes a buffer and a buffer size (in bytes). Several of the encoders are passing the buffer size in bits, by multiplying the buffer size by 8. This is incorrect. We saw this problem when encoding a ProRes (Anatoliy) file at size 4096x4096. Debugging showed that the buffer size was very large, and when multiplied by 8, it was interpreted as a negative number. This caused the init_put_bits() to zero out the buffer, leading to a crash. The attached patch fixes the argument to init_put_bits in all of the cases where the buffer size was multiplied by 8. You could use the patch or make the same change. Regards, Dyami fix_init_put_bits.patch.tar Description: Unix tar archive ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] bad arguments to init_put_bits
Hi On Thu, Feb 26, 2015 at 10:42:06AM -0800, Dyami Caliri wrote: The init_put_bits() function (in libavcodec/put_bits.h) takes a buffer and a buffer size (in bytes). Several of the encoders are passing the buffer size in bits, by multiplying the buffer size by 8. This is incorrect. We saw this problem when encoding a ProRes (Anatoliy) file at size 4096x4096. Debugging showed that the buffer size was very large, and when multiplied by 8, it was interpreted as a negative number. This caused the init_put_bits() to zero out the buffer, leading to a crash. The attached patch fixes the argument to init_put_bits in all of the cases where the buffer size was multiplied by 8. You could use the patch or make the same change. patch applied but how can the crash be reproduced? the code shouldnt really crash even without the patch [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 3 Rare item - Common item with rare defect or maybe just a lie Professional - 'Toy' made in china, not functional except as doorstop Experts will know - The seller hopes you are not an expert signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/bit: return early from write_packet if pkt-size is 0
L'octidi 8 ventôse, an CCXXIII, Andreas Cadhalpun a écrit : the bit format muxer currently segfaults, when it is passed a packet of size 0. This can be triggered e.g. with: ffmpeg -y -f lavfi -i sine=duration=0.1 -c:a flac -f bit /dev/null Attached patch fixes this. This looks wrong. The bit muxer seems to assume packets have a constant size, apparently 10 octets. Someone knowing the format should check, but I suppose this would be more correct: if (pkt-size != 10) return AVERROR(EINVAL); Also, it seems you should not be able to mux FLAC into this format, the write header callback does not validate enough. It looks like this muxer is a quick-and-dirty implementation, emphasis on the dirty. Last: how come ffmpeg/lavf tries to mux an empty packet? 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] bad arguments to init_put_bits
Do you want sample code that generates the crash? For the code shouldn't really crash even without the patch, are you saying that the code, as it's written, doesn't look it would crash? Or are you saying that we need to change the code to make sure it doesn't crash, even without the patch? Here is the short answer for how it happens: bit-shifting (or multiplying) the buffer_size argument to init_put_bits() can cause it to be interpreted as a negative number, which sets the buf_ptr to NULL, which leads to dereferencing null in later calls to put_bits(). Here is a longer explanation: prores_encode_frame() calculates a frame_size variable like this: int frame_size = FFALIGN(avctx-width, 16) * FFALIGN(avctx-height, 16)*16 + 500 + FF_MIN_BUFFER_SIZE; In encode_slice_plane, unsigned buf_size is passed in. This is related to the frame_size value from earlier. Then init_put_bits() is called with (buf_size 3). The argument for init_put_bits is a regular, signed int. So, for certain width+height, we end up with a buf_size that, when shifted left 3 times and converted to a signed int, becomes a negative value. In init_put_bits(), if buffer_size 0, the buffer_size is set to zero and the buffer is set to 0/NULL. Thereafter, any calls to put_bits will crash, because it accesses 'buf_ptr', which is NULL. On Thu, Feb 26, 2015 at 11:45 AM, Michael Niedermayer michae...@gmx.at wrote: Hi On Thu, Feb 26, 2015 at 10:42:06AM -0800, Dyami Caliri wrote: The init_put_bits() function (in libavcodec/put_bits.h) takes a buffer and a buffer size (in bytes). Several of the encoders are passing the buffer size in bits, by multiplying the buffer size by 8. This is incorrect. We saw this problem when encoding a ProRes (Anatoliy) file at size 4096x4096. Debugging showed that the buffer size was very large, and when multiplied by 8, it was interpreted as a negative number. This caused the init_put_bits() to zero out the buffer, leading to a crash. The attached patch fixes the argument to init_put_bits in all of the cases where the buffer size was multiplied by 8. You could use the patch or make the same change. patch applied but how can the crash be reproduced? the code shouldnt really crash even without the patch [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 3 Rare item - Common item with rare defect or maybe just a lie Professional - 'Toy' made in china, not functional except as doorstop Experts will know - The seller hopes you are not an expert ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [Patch] no_delay option for librtmp
This adds another option to a change authored by Brian Brice bbr...@gmail.com 2015-01-19 librtmp: Allow changing the socket send buffer size (Brian is aware of this change). Unlike a previous patch, this has no dependency on rtmpdump. Options to the ffmpeg commandline in support of now arguments in librtmp. rtmp_buffer_size - sets rtmp socket send buffer size in bytes. this is the same as the patch it replaces. rtmp_nodelay - on or off. defaults to on. allows users to control whether nagel is active. See this thread on Zeranoe forum: http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7t=657p=7823#p7823 I believe this addresses case 1604 on the ffmpeg tracker. Summary of the bug: Rtmp output to justin.tv fps continually drops, ... - note the memory problem mentioned had been fixed. This fix only applies if librtmp is enabled. https://trac.ffmpeg.org/ticket/1604 Defualt behavior leaves things unchanged. Users must employ options intentionally. My previous patch should be ignored. 0001-This-adds-another-option-to-a-change-authored-by-Bri.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movenc: Write 'colr' box correctly for MP4
On Thu, Feb 26, 2015 at 06:15:30PM +0100, Michael Niedermayer wrote: On Thu, Feb 26, 2015 at 04:54:02PM +0100, Clément Bœsch wrote: On Thu, Feb 26, 2015 at 01:53:13PM +, Derek Buitenhuis wrote: On 2/26/2015 1:50 PM, Clément Bœsch wrote: If the option is set by default, you don't want to warn for no reason. It's not set by default. That patch never went in. Ah, my bad. I don't believe silently not writing it is a valid approach. Then again I think setting a default movflag like that instead of changing the option is also stupid. Well, breaking API on purpose when easily avoidable is kind of stupid too. You can also just deprecate the current flag and add yours. The point is to not make the option disappear because it will break callers. Changing the behaviour (enabling by default / making the old option void) is fine, breaking the API (removing the option) not so much. the option is in there since a month and was in no release so IMHO if people feel strongly about it then i guess simply replacing the option might be acceptable Oh, I completely missed that. Then yeah, sure. Sorry for the noise. [...] -- Clément B. pgpfXU9AATc3g.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] ffmpeg: allow to set the thread message queue size.
Le septidi 7 ventôse, an CCXXIII, Michael Niedermayer a écrit : i think the case i tested had HAVE_W32THREADS set also theres HAVE_OS2THREADS I suspect my question was too vague. If I understand correctly, HAVE_THREADS = HAVE_PTHREADS || HAVE_W32THREADS || HAVE_OS2THREADS Am I right? My main question is: do we have supported case where we do not HAVE_THREADS at all? As a side note, I notice the current code for running demuxers in threads is protected by HAVE_PTHREADS instead of HAVE_THREADS initially because of this: # commit 47b812e9cec3e0b29799b71009585ea77133eef0 # Author: Anton Khirnov an...@khirnov.net # Date: 2012-06-11 15:34:12 +0200 # # avconv: support only native pthreads. # # Our w32pthreads wrapper has various issues and is only supposed to be # used in libavcodec. Does anyone know what issues this is about? I just ran a quick and dirty test and it seems to work with i686-w64-mingw32 cross-compiler and wine (I had to move windows.h after ffmpeg.h in ffmpeg_dxva.c for some reason). It would be nice if someone would test this more carefully. The basic reason I ask is that this kind of issue is that any application reading from a live stream and doing something else at the same time has similar kind of problems. We need some kind of really working non-blocking or input-driven API, and if we do not want to rewrite 90% of the demuxers, we will need threads. Regarding the patch itself, if you consider the series ok, you can pull this from my tree: a92193f lavd/alsa: set frame_size field. 508d6a2 ffmpeg: allow to set the thread message queue size. d92c6d8 ffmpeg: notify when the thread message queue blocks. Thanks. 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] avformat/bit: return early from write_packet if pkt-size is 0
L'octidi 8 ventôse, an CCXXIII, Nicolas George a écrit : Last: how come ffmpeg/lavf tries to mux an empty packet? It comes from that commit: commit 0957b274e312e985d69cb490bee2a7ff820acaa6 Author: Anton Khirnov an...@khirnov.net Date: 2014-04-29 15:06:45 +0200 lavc: add an option to enable side data-only packets during encoding Some encoders (e.g. flac) need to send side data when there is no more data to be output. This enables them to output a packet with no data in it, only side data. IMHO, the empty packet should not be reaching the demuxers that do not expect them, that would change the output. I suggest you check with Anton. 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] bad arguments to init_put_bits
On Thu, Feb 26, 2015 at 12:10:49PM -0800, Dyami Caliri wrote: Do you want sample code that generates the crash? For the code shouldn't really crash even without the patch, are you saying that the code, as it's written, doesn't look it would crash? Or are you saying that we need to change the code to make sure it doesn't crash, even without the patch? no, i thought you where talking about some code writing over the end of the array, if thats not so then its ok with just your patch thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/bit: return early from write_packet if pkt-size is 0
On 26.02.2015 20:48, Nicolas George wrote:
L'octidi 8 ventôse, an CCXXIII, Andreas Cadhalpun a écrit :
the bit format muxer currently segfaults, when it is passed a packet of size 0.
This can be triggered e.g. with:
ffmpeg -y -f lavfi -i sine=duration=0.1 -c:a flac -f bit /dev/null
Attached patch fixes this.
This looks wrong. The bit muxer seems to assume packets have a constant
size, apparently 10 octets. Someone knowing the format should check, but I
suppose this would be more correct:
if (pkt-size != 10)
return AVERROR(EINVAL);
You're right. New patch with this check attached.
Also, it seems you should not be able to mux FLAC into this format, the
write header callback does not validate enough. It looks like this muxer is
a quick-and-dirty implementation, emphasis on the dirty.
Indeed. I also attached a patch limiting the bit muxer to codec g729 with 1
channel, as this is apparently the only thing it supports.
Last: how come ffmpeg/lavf tries to mux an empty packet?
You already analyzed this.
Best regards,
Andreas
From c882243d66af01cca9efbcb4a750c7ea60bd610b Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun andreas.cadhal...@googlemail.com
Date: Thu, 26 Feb 2015 21:38:50 +0100
Subject: [PATCH 1/2] avformat/bit: check that pkt-size is 10 in write_packet
Ohter packet sizes are not supported by this muxer.
This avoids a null pointer dereference of pkt-data.
Signed-off-by: Andreas Cadhalpun andreas.cadhal...@googlemail.com
---
libavformat/bit.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/bit.c b/libavformat/bit.c
index 7b807b9..5d05da0 100644
--- a/libavformat/bit.c
+++ b/libavformat/bit.c
@@ -133,6 +133,9 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
GetBitContext gb;
int i;
+if (pkt-size != 10)
+return AVERROR(EINVAL);
+
avio_wl16(pb, SYNC_WORD);
avio_wl16(pb, 8 * 10);
--
2.1.4
From 369e4a57f9e52564f12f15fd31e1fdb0177499cd Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun andreas.cadhal...@googlemail.com
Date: Thu, 26 Feb 2015 21:42:02 +0100
Subject: [PATCH 2/2] avformat/bit: only accept the g729 codec and 1 channel
Other codecs/channel numbers are not supported by this muxer.
Signed-off-by: Andreas Cadhalpun andreas.cadhal...@googlemail.com
---
libavformat/bit.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavformat/bit.c b/libavformat/bit.c
index 5d05da0..138d2fe 100644
--- a/libavformat/bit.c
+++ b/libavformat/bit.c
@@ -119,8 +119,12 @@ static int write_header(AVFormatContext *s)
{
AVCodecContext *enc = s-streams[0]-codec;
-enc-codec_id = AV_CODEC_ID_G729;
-enc-channels = 1;
+if ((enc-codec_id != AV_CODEC_ID_G729) || enc-channels != 1) {
+av_log(s, AV_LOG_ERROR,
+ only codec g729 with 1 channel is supported by this format\n);
+return AVERROR(EINVAL);
+}
+
enc-bits_per_coded_sample = 16;
enc-block_align = (enc-bits_per_coded_sample * enc-channels) 3;
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Patch] no_delay option for librtmp
Use this instead. (sorry, corrected grammatical errors.) On Thu, Feb 26, 2015 at 1:22 PM, Cary Tetrick ctetri...@gmail.com wrote: This adds another option to a change authored by Brian Brice bbr...@gmail.com 2015-01-19 librtmp: Allow changing the socket send buffer size (Brian is aware of this change). Unlike a previous patch, this has no dependency on rtmpdump. Options to the ffmpeg commandline in support of now arguments in librtmp. rtmp_buffer_size - sets rtmp socket send buffer size in bytes. this is the same as the patch it replaces. rtmp_nodelay - on or off. defaults to on. allows users to control whether nagel is active. See this thread on Zeranoe forum: http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7t=657p=7823#p7823 I believe this addresses case 1604 on the ffmpeg tracker. Summary of the bug: Rtmp output to justin.tv fps continually drops, ... - note the memory problem mentioned had been fixed. This fix only applies if librtmp is enabled. https://trac.ffmpeg.org/ticket/1604 Defualt behavior leaves things unchanged. Users must employ options intentionally. My previous patch should be ignored. 0001-Topic-Option-to-control-no_delay-flag-in-librtmp.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add erosion dilation filter
On Wed, Feb 25, 2015 at 02:55:58PM +, Paul B Mahol wrote:
Signed-off-by: Paul B Mahol one...@gmail.com
---
doc/filters.texi | 34 ++
libavfilter/Makefile | 2 +
libavfilter/allfilters.c | 2 +
libavfilter/vf_neighbor.c | 289
++
4 files changed, 327 insertions(+)
create mode 100644 libavfilter/vf_neighbor.c
diff --git a/doc/filters.texi b/doc/filters.texi
index baef346..13ba797 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -3728,6 +3728,23 @@ FFmpeg was configured with @code{--enable-opencl}.
Default value is 0.
@end table
+@section dilation
+
+Apply dilation effect to the video.
+
+This filter replaces the pixel by the local(3x3) maximum.
+
+It accepts the following parameters:
+
+@table @option
+@item threshold
+Allows to limit the maximum change, default is 65535.
+
+@item coordinates
+Flag which specifies the pixel to refer to. Default is 255 ie. all eight
+pixels are used.
+@end table
+
@section drawbox
Draw a colored box on the input image.
@@ -4437,6 +4454,23 @@ value.
@end table
+@section erosion
+
+Apply erosion effect to the video.
+
+This filter replaces the pixel by the local(3x3) minimum.
+
+It accepts the following parameters:
+
+@table @option
+@item threshold
+Allows to limit the maximum change, default is 65535.
+
+@item coordinates
+Flag which specifies the pixel to refer to. Default is 255 ie. all eight
+pixels are used.
+@end table
+
[...]
+static int config_input(AVFilterLink *inlink)
+{
+EDContext *s = inlink-dst-priv;
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink-format);
+int ret;
+
+if ((ret = av_image_fill_linesizes(s-linesize, inlink-format,
inlink-w)) 0)
+return ret;
+
+s-planeheight[1] = s-planeheight[2] = FF_CEIL_RSHIFT(inlink-h,
desc-log2_chroma_h);
+s-planeheight[0] = s-planeheight[3] = inlink-h;
+
+s-nb_planes = av_pix_fmt_count_planes(inlink-format);
+s-buffer = av_malloc(3 * (s-linesize[0] + 32));
av_malloc_array() relevant?
+if (!s-buffer)
+return AVERROR(ENOMEM);
+
+return 0;
+}
+
+static inline void line_copy8(uint8_t *line, const uint8_t *srcp, int width,
int mergin)
+{
+memcpy(line, srcp, width);
+
+for (int i = mergin; i 0; i--) {
int should be declared out of the scope
+line[-i] = line[i];
+line[width - 1 + i] = line[width - 1 - i];
+}
+}
+
[...]
No other comment from me. May I ask if there was a special use case of
this or that's just because the effect were neat and simple to implement?
--
Clément B.
pgp55nEF6uOeE.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Port FFT domain filter.
I have updated the patch.
Can you please explain me which user options to include?
From b44034b68233cc5734924f64185f3c830a2e227d Mon Sep 17 00:00:00 2001
From: Arwa Arif arwaarif1...@gmail.com
Date: Tue, 24 Feb 2015 12:17:30 +0530
Subject: [PATCH] Port FFT domain filter.
---
libavfilter/Makefile |1 +
libavfilter/allfilters.c |1 +
libavfilter/vf_fftfilt.c | 169 ++
3 files changed, 171 insertions(+)
create mode 100644 libavfilter/vf_fftfilt.c
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 289c63b..b184f07 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -120,6 +120,7 @@ OBJS-$(CONFIG_EDGEDETECT_FILTER) += vf_edgedetect.o
OBJS-$(CONFIG_EQ_FILTER) += vf_eq.o
OBJS-$(CONFIG_EXTRACTPLANES_FILTER) += vf_extractplanes.o
OBJS-$(CONFIG_FADE_FILTER) += vf_fade.o
+OBJS-$(CONFIG_FFTFILT_FILTER)+= vf_fftfilt.o
OBJS-$(CONFIG_FIELD_FILTER) += vf_field.o
OBJS-$(CONFIG_FIELDMATCH_FILTER) += vf_fieldmatch.o
OBJS-$(CONFIG_FIELDORDER_FILTER) += vf_fieldorder.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 55de154..043ac56 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -136,6 +136,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(EQ, eq, vf);
REGISTER_FILTER(EXTRACTPLANES, extractplanes, vf);
REGISTER_FILTER(FADE, fade, vf);
+REGISTER_FILTER(FFTFILT,fftfilt,vf);
REGISTER_FILTER(FIELD, field, vf);
REGISTER_FILTER(FIELDMATCH, fieldmatch, vf);
REGISTER_FILTER(FIELDORDER, fieldorder, vf);
diff --git a/libavfilter/vf_fftfilt.c b/libavfilter/vf_fftfilt.c
new file mode 100644
index 000..0ce2e8b
--- /dev/null
+++ b/libavfilter/vf_fftfilt.c
@@ -0,0 +1,169 @@
+/*
+ * Copyright (c) 2015 Arwa Arif arwaarif1...@gmail.com
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU 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
+ * FFT domain filtering.
+ */
+
+#include libavfilter/internal.h
+#include libavutil/common.h
+#include libavutil/imgutils.h
+#include libavutil/opt.h
+#include libavutil/pixdesc.h
+#include libavcodec/avfft.h
+
+typedef struct {
+const AVClass *class;
+
+RDFTContext *rdft;
+int rdft_hbits;
+int rdft_vbits;
+FFTSample *rdft_hdata;
+FFTSample *rdft_vdata;
+
+} FFTFILTContext;
+
+static int filter_frame(AVFilterLink *inlink, AVFrame *in)
+{
+AVFilterContext *ctx = inlink-dst;
+AVFilterLink *outlink = inlink-dst-outputs[0];
+FFTFILTContext *fftfilt = ctx-priv;
+AVFrame *out;
+int i, j, rdft_hbits, rdft_vbits;
+size_t rdft_hlen, rdft_vlen, w, h;
+
+w = inlink-w;
+h = inlink-h;
+
+/* RDFT - Array initialization for Horizontal pass*/
+for (rdft_hbits = 1; 1 rdft_hbits 2 * w; rdft_hbits++);
+rdft_hlen = 1 rdft_hbits;
+fftfilt-rdft_hdata = av_malloc_array(h, rdft_hlen * sizeof(FFTSample));
+
+/* RDFT - Array initialization for Vertical pass*/
+for (rdft_vbits = 1; 1 rdft_vbits 2 * h; rdft_vbits++);
+rdft_vlen = 1 rdft_vbits;
+fftfilt-rdft_vdata = av_malloc_array(w, rdft_hlen * rdft_vlen * sizeof(FFTSample));
+
+out = ff_get_video_buffer(outlink, inlink-w, inlink-h);
+if (!out)
+return AVERROR(ENOMEM);
+
+av_frame_copy_props(out, in);
+
+/*Horizontal pass - RDFT*/
+fftfilt-rdft = av_rdft_init(rdft_hbits, DFT_R2C);
+for (i = 0; i h; i++)
+{
+memset(fftfilt-rdft_hdata + i * rdft_hlen, 0, rdft_hlen * sizeof(*fftfilt-rdft_hdata));
+for (j = 0; j w; j++)
+fftfilt-rdft_hdata[i * rdft_hlen + j] = *(in-data[0] + in-linesize[0] * i + j);
+}
+
+for (i = 0; i h; i++)
+av_rdft_calc(fftfilt-rdft, fftfilt-rdft_hdata + i * rdft_hlen);
+
+av_rdft_end(fftfilt-rdft);
+
+/*Vertical pass - RDFT*/
+fftfilt-rdft = av_rdft_init(rdft_vbits, DFT_R2C);
+for (i = 0; i rdft_hlen; i++)
+{
+memset(fftfilt-rdft_vdata + i * rdft_vlen, 0, rdft_vlen * sizeof(*fftfilt-rdft_vdata));
+for (j = 0; j h; j++)
+fftfilt-rdft_vdata[i * rdft_vlen + j] = fftfilt-rdft_hdata[j * rdft_hlen +
Re: [FFmpeg-devel] Adding Webvtt in hls muxer
On 02/25/2015 10:04 PM, Deron wrote:
On 2/21/15 8:05 AM, Deron wrote:
On 2/15/15 5:44 AM, Anshul wrote:
attached another cleaned patch.
-Anshul
Not sure if I should be posting here, privately, or do the user list
since it is an unaccepted patch... This patch applies cleanly to
ffmpeg git of that day, and with minor adjustment to current git, but
either crashes the same for me right away. Here is the back trace
from gdb:
Program received signal SIGSEGV, Segmentation fault.
__GI___libc_realloc (oldmem=0x70, bytes=8) at malloc.c:2977
2977malloc.c: No such file or directory.
(gdb) bt
#0 __GI___libc_realloc (oldmem=0x70, bytes=8) at malloc.c:2977
#1 0x77609b99 in avformat_new_stream (s=s@entry=0xe2dbc0,
c=c@entry=0x0) at libavformat/utils.c:3655
#2 0x775451c4 in hls_mux_init (s=0x6787c0) at
libavformat/hlsenc.c:194
#3 hls_write_header (s=0x6787c0) at libavformat/hlsenc.c:490
#4 0x775999ec in avformat_write_header (s=s@entry=0x6787c0,
options=0x6a9948) at libavformat/mux.c:406
#5 0x00424c00 in transcode_init () at ffmpeg.c:3096
#6 0x00407581 in transcode () at ffmpeg.c:3815
#7 main (argc=13, argv=0x7fffe5a8) at ffmpeg.c:4022
The command (I've tried all sorts of combinations. If I don't provide
a subtitle stream, it does not crash. Otherwise it does. Unpatched
can generate a webvtt from the subtitle stream without crashing.)
ffmpeg -loglevel debug -f lavfi -i movie=out.ts\[out0+subcc\] -f hls
-hls_segment_filename /var/www/html/stream/kota/v.low.%d.ts
-hls_subtitle_path /var/www/html/stream/kota/ -y
/var/www/html/stream/kota/v.low.m3u8
I did find the problem. The patch does not properly initialize
hls-vtt_oformat (etc) if you provide the -hls_segment_filename
parameter as I have done.
Deron
I have attached new patch with correctly initializing the webvtt, can
you please check this patch again.
-Anshul
From 176ee7227e3991925ced0ad593ae670d871a489d Mon Sep 17 00:00:00 2001
From: Anshul Maheshwari er.anshul.maheshw...@gmail.com
Date: Thu, 26 Feb 2015 16:53:17 +0530
Subject: [PATCH] Adding WebVtt implementation in hls
---
libavformat/hlsenc.c | 178 +++
1 file changed, 167 insertions(+), 11 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 29bf30e..35260a1 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -39,6 +39,7 @@
typedef struct HLSSegment {
char filename[1024];
+char sub_filename[1024];
double duration; /* in seconds */
int64_t pos;
int64_t size;
@@ -58,8 +59,10 @@ typedef struct HLSContext {
int64_t sequence;
int64_t start_sequence;
AVOutputFormat *oformat;
+AVOutputFormat *vtt_oformat;
AVFormatContext *avf;
+AVFormatContext *vtt_avf;
float time;// Set by a private option.
int max_nb_segments; // Set by a private option.
@@ -70,6 +73,7 @@ typedef struct HLSContext {
int allowcache;
int64_t recording_time;
int has_video;
+int has_subtitle;
int64_t start_pts;
int64_t end_pts;
double duration; // last segment duration computed so far, in seconds
@@ -82,11 +86,17 @@ typedef struct HLSContext {
HLSSegment *old_segments;
char *basename;
+char *vtt_basename;
+char *vtt_m3u8_name;
char *baseurl;
char *format_options_str;
+char *vtt_format_options_str;
+char *subtitle_filename;
AVDictionary *format_options;
+AVDictionary *vtt_format_options;
AVIOContext *pb;
+AVIOContext *sub_pb;
} HLSContext;
static int hls_delete_old_segments(HLSContext *hls) {
@@ -158,6 +168,7 @@ static int hls_mux_init(AVFormatContext *s)
{
HLSContext *hls = s-priv_data;
AVFormatContext *oc;
+AVFormatContext *vtt_oc;
int i, ret;
ret = avformat_alloc_output_context2(hls-avf, hls-oformat, NULL, NULL);
@@ -170,10 +181,25 @@ static int hls_mux_init(AVFormatContext *s)
oc-max_delay = s-max_delay;
av_dict_copy(oc-metadata, s-metadata, 0);
+
+if(hls-vtt_oformat) {
+ret = avformat_alloc_output_context2(hls-vtt_avf, hls-vtt_oformat, NULL, NULL);
+if (ret 0)
+return ret;
+vtt_oc = hls-vtt_avf;
+vtt_oc-oformat = hls-vtt_oformat;
+av_dict_copy(vtt_oc-metadata, s-metadata, 0);
+}
+
for (i = 0; i s-nb_streams; i++) {
AVStream *st;
-if (!(st = avformat_new_stream(oc, NULL)))
-return AVERROR(ENOMEM);
+if (s-streams[i]-codec-codec_type == AVMEDIA_TYPE_SUBTITLE hls-vtt_oformat) {
+if (!(st = avformat_new_stream(vtt_oc, NULL)))
+return AVERROR(ENOMEM);
+} else {
+if (!(st = avformat_new_stream(oc, NULL)))
+return AVERROR(ENOMEM);
+}
avcodec_copy_context(st-codec, s-streams[i]-codec);
st-sample_aspect_ratio = s-streams[i]-sample_aspect_ratio;
Re: [FFmpeg-devel] [libav-devel] [PATCH] avformat/adxdec: check avctx-channels for invalid values
On 26.02.2015 04:15, Luca Barbato wrote: The decoder has this /* channels */ avctx-channels = buf[7]; if (avctx-channels = 0 || avctx-channels 2) return AVERROR_INVALIDDATA; So by the time you get there the channels are already validated. the extradata is validated on container and codec level so it should be fine. This validation just makes sure that the codec can't be opened. But then avformat_find_stream_info continues with reading a frame from the demuxer, leading to the segfault if avctx-channels is 0. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Port FFT domain filter.
On Thu, Feb 26, 2015 at 01:41:08PM +0530, arwa arif wrote:
I have updated the patch.
Can you please explain me which user options to include?
yes
it could be similar to the vf_geq.c flter
so something like
-vf fftfilt=dc=128:lum='(1 / (1 + exp(-Y/10.0+H/100.0)))'
could result in the equivalent of this:
@@ -97,6 +98,13 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
av_rdft_end(fftfilt-rdft);
+for (i = 0; i rdft_hlen; i++)
+{
+for (j = 0; j rdft_vlen; j++)
+fftfilt-rdft_vdata[i * rdft_vlen + j] *= (1 / (1 +
exp(-j/10.0+h/100.0)));
+}
+fftfilt-rdft_vdata[0] += rdft_hlen * rdft_vlen * 128;
+
/*Vertical pass - IRDFT*/
fftfilt-rdft = av_rdft_init(rdft_vbits, IDFT_C2R);
further comments below
[...]
+/* RDFT - Array initialization for Horizontal pass*/
+for (rdft_hbits = 1; 1 rdft_hbits 2 * w; rdft_hbits++);
+rdft_hlen = 1 rdft_hbits;
+fftfilt-rdft_hdata = av_malloc_array(h, rdft_hlen * sizeof(FFTSample));
+
+/* RDFT - Array initialization for Vertical pass*/
+for (rdft_vbits = 1; 1 rdft_vbits 2 * h; rdft_vbits++);
without the 2 * the code will be faster
+rdft_vlen = 1 rdft_vbits;
+fftfilt-rdft_vdata = av_malloc_array(w, rdft_hlen * rdft_vlen *
sizeof(FFTSample));
ftfilt-rdft_vdata = av_malloc_array(rdft_hlen, rdft_vlen * sizeof(FFTSample));
that is without the w
also the av_malloc_array return values need to be checked, the functions
could fail if there is npt enough memory
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Silence warnings when compiling avfoundation
Am 24.02.15 um 11:32 schrieb Carl Eugen Hoyos: Thilo Borgmann thilo.borgmann at mail.de writes: You just misread me, I know what the first patch is for - which is what you just wrote. However, my question was about reason for the second #define patch. My comment was only about the second patch. Is the second patch ok? Ah yes my fault. Patch OK! -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_format issues when called outside frame decode.
On 26.02.2015, at 23:46, Hendrik Leppkes h.lepp...@gmail.com wrote:
On Thu, Feb 26, 2015 at 11:21 PM, Reimar Döffinger
reimar.doeffin...@gmx.de wrote:
When ff_thread_get_format is called from the main thread, e.g.
during codec init it will access the thread_ctx as a PerThreadContext
even though it is a FrameThreadContext.
Where is this a problem exactly? I don't see a single codec that calls
it during codec init.
The only codecs that actually call it are h264 and hevc, and thats in
slice header decoding, not codec init (and mpeg12, which doesn't do
frame threading)
HEVC seems to call it during extradata parsing as far as I can tell, though I
do not have a test-case.
In addition, when ff_thread_get_format is called during the context
update it would get confused because the state is not as expected.
Make it handle that case by adding a new state for this, signalling
that we are actually executing in the main thread and thus can
call get_format directly in all cases.
When would this ever happen? MT decoding works perfectly fine in a
number of applications as it is.
When would what happen? If you disable thread-safe callbacks then HEVC will
fail to decode anything with multithreading, so it's a fairly obvious issue.
Though not many using HEVC I guess.
Note that I think this might just be a bug, since it means if you run with n
threads then the HEVC decoder after each sps change will call get_format n
times with exactly the same arguments.
The context update should probably just copy the selected format instead of
ending up calling get_format due to reusing set_sps.
@@ -743,7 +754,10 @@ void ff_thread_flush(AVCodecContext *avctx)
int ff_thread_can_start_frame(AVCodecContext *avctx)
{
PerThreadContext *p = avctx-internal-thread_ctx;
-if ((avctx-active_thread_typeFF_THREAD_FRAME) p-state !=
STATE_SETTING_UP
+if (avctx-active_thread_typeFF_THREAD_FRAME)
+return 0;
+av_assert0(!p-main_thread);
+if (p-state != STATE_SETTING_UP
(avctx-codec-update_thread_context ||
!THREAD_SAFE_CALLBACKS(avctx))) {
return 0;
}
This hunk looks rather suspicious. Returning 0 unconditionally on
active_thread_type FF_THREAD_FRAME?
Yes, I flipped the condition there.
In general, I'm rather cautious with any changes to the threading
model, so these should be clearly warranted and explained properly.
My biggest issue is that we store two completely different structs in the same
variable, and all those threading functions just assume that they will always
be called only from the right places.
Otherwise they'd end up accessing things as the wrong struct.
I don't mind splitting the patch and/or fixing HEVC differently, but this
should be improved IMO.
Though just having both a main and a worker thread_ctx variable for example
might be a cleaner solution than what I have in this patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Live encoding into mxf...
On Thu, Feb 26, 2015 at 05:26:36PM +, Eng. Tweellt wrote:
Hello everyone,
I'm trying to encode video and audio directly from a capture board, 1 video
stream and 8 single channel audio streams into a MXF file encoding it in
Mpeg-2.
Everything is working fine except when I call av_write_trailer() at the end
(and before freeing CodecContext as stated in the documentation).
After using av_write_trailer, I end up with the whole video looking like
this http://i.imgur.com/M6HkcpR.jpg . It seems like the decoder is
misplacing the b-frames in the wrong position, but If i don't call this
function I can play the media file, with the image as it should be, in VLC
but the timestamp is completely wrong.
Looking at mediainfo I can see that my file doesn't have the file duration
(which later made sense when I looked inside the code.)
After a few hours with the file mxfenc.c found that if I comment the next
part inside the function mxf_write_footer(), the write trailer kinda
works,
(...)
if (mxf-edit_unit_byte_count s-oformat != ff_mxf_opatom_muxer) { //
no need to repeat index
if ((err = mxf_write_partition(s, 0, 0, footer_partition_key, 0))
0)
return err;
} /*else {
if ((err = mxf_write_partition(s, 0, 2, footer_partition_key, 0))
0)
return err;
mxf_write_klv_fill(s);
mxf_write_index_table_segment(s);
}*/
(...)
The kinda works part, its because I can play the file correctly in VLC
with the correct timestamps, and if I open it with Mediainfo everything
looks good, but If I try to open it with Sorenson Squeeze (for example), I
get a warning saying Squeeze does not support playing this file.
I carefully followed the documentation, samples, examples and I'm still
stuck :S.
I am using the ffmpeg 2.5.1 version and I also added a few changes that I
saw in the master, and nothing changed.
Additional info:
Target Output file format is a 1080i59.94, XDCam 30Mbit MXF op1a.
Regarding the 8 audio streams the codec options have the one provided by
avcodec_get_context_defaults3 plus this changes:
audio_codec_context-channels=1;
audio_codec_context-sample_rate = 48000;
audio_codec_context-bit_rate = 768000;
audio_codec_context-sample_fmt =AV_SAMPLE_FMT_S16;
audio_codec_context-flags= CODEC_FLAG_GLOBAL_HEADER;
audio_codec_context-time_base-num = 48000;
Regarding video I also do avcodec_get_context_defaults3 plus this:
video_codec_context- pix_fmt= AV_PIX_FMT_YUV422P;
video_codec_context-height = 1080;
video_codec_context-time_base-den = 3;
video_codec_context-time_base-num = 1001;
video_codec_context-field_order= AVFieldOrder.AV_FIELD_TB;
video_codec_context-width = 1920;
video_codec_context-codec_id= AV_CODEC_ID_MPEG2VIDEO;
video_codec_context-has_b_frames= 1;
video_codec_context-max_b_frames = 2;
video_codec_context-gop_size= 12;
video_codec_context-global_quality= FF_QP2LAMBDA * 1;
video_codec_context-rc_initial_buffer_occupancy= 10695476;
video_codec_context-scenechange_threshold = 10;
video_codec_context-color_primaries= AVCOL_PRI_BT709;
video_codec_context-color_trc= AVCOL_TRC_BT709;
video_codec_context-qmin= 1;
video_codec_context-flags |= CODEC_FLAG_GLOBAL_HEADER |
CODEC_FLAG_INTERLACED_DCT | CODEC_FLAG_INTERLACED_ME;
video_codec_context-bit_rate = 3000;
video_codec_context-rc_min_rate= 3000;
video_codec_context-rc_max_rate= 3000;
video_codec_context-rc_buffer_size= 10695476;
I also had specified me_method and me_range, but nothing changed.
Any idea what might be the problem?
can the problem be reproduced with command line FFmpeg ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
While the State exists there can be no freedom; when there is freedom there
will be no State. -- 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 1/2] ffmpeg: allow to set the thread message queue size.
On Thu, Feb 26, 2015 at 07:56:06PM +0100, Nicolas George wrote: Le septidi 7 ventôse, an CCXXIII, Michael Niedermayer a écrit : i think the case i tested had HAVE_W32THREADS set also theres HAVE_OS2THREADS I suspect my question was too vague. If I understand correctly, HAVE_THREADS = HAVE_PTHREADS || HAVE_W32THREADS || HAVE_OS2THREADS Am I right? i think so My main question is: do we have supported case where we do not HAVE_THREADS at all? yes but i doubt multiple live stream inputs ever worked properly in this case [...] The basic reason I ask is that this kind of issue is that any application reading from a live stream and doing something else at the same time has similar kind of problems. We need some kind of really working non-blocking or input-driven API, and if we do not want to rewrite 90% of the demuxers, we will need threads. Regarding the patch itself, if you consider the series ok, you can pull this from my tree: a92193f lavd/alsa: set frame_size field. 508d6a2 ffmpeg: allow to set the thread message queue size. d92c6d8 ffmpeg: notify when the thread message queue blocks. merged thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_format issues when called outside frame decode.
When ff_thread_get_format is called from the main thread, e.g.
during codec init it will access the thread_ctx as a PerThreadContext
even though it is a FrameThreadContext.
Catch this case and add asserts to protect against similar issues
in other places.
In addition, when ff_thread_get_format is called during the context
update it would get confused because the state is not as expected.
Make it handle that case by adding a new state for this, signalling
that we are actually executing in the main thread and thus can
call get_format directly in all cases.
These fix multithreaded decoding in MPlayer for example.
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
libavcodec/pthread_frame.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 5a4ab84..b0d3469 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -53,6 +53,7 @@
* Context used by codec threads and stored in their AVCodecInternal
thread_ctx.
*/
typedef struct PerThreadContext {
+int main_thread;
struct FrameThreadContext *parent;
pthread_t thread;
@@ -83,7 +84,8 @@ typedef struct PerThreadContext {
* Set when the codec calls get_format().
* State is returned to STATE_SETTING_UP
afterwards.
*/
-STATE_SETUP_FINISHED/// Set after the codec has called
ff_thread_finish_setup().
+STATE_SETUP_FINISHED, /// Set after the codec has called
ff_thread_finish_setup().
+STATE_UPDATE_CONTEXT, /// Main thread is updating its context
} state;
/**
@@ -105,6 +107,7 @@ typedef struct PerThreadContext {
* Context stored in the client AVCodecInternal thread_ctx.
*/
typedef struct FrameThreadContext {
+int main_thread;
PerThreadContext *threads; /// The contexts for each thread.
PerThreadContext *prev_thread; /// The last thread submit_packet() was
called on.
@@ -143,6 +146,7 @@ static attribute_align_arg void *frame_worker_thread(void
*arg)
AVCodecContext *avctx = p-avctx;
const AVCodec *codec = avctx-codec;
+av_assert0(!p-main_thread);
pthread_mutex_lock(p-mutex);
while (1) {
while (p-state == STATE_INPUT_READY !fctx-die)
@@ -330,6 +334,8 @@ static int submit_packet(PerThreadContext *p, AVPacket
*avpkt)
pthread_mutex_lock(p-mutex);
+p-state = STATE_UPDATE_CONTEXT;
+
release_delayed_buffers(p);
if (prev_thread) {
@@ -408,6 +414,7 @@ int ff_thread_decode_frame(AVCodecContext *avctx,
int finished = fctx-next_finished;
PerThreadContext *p;
int err;
+av_assert0(fctx-main_thread);
/*
* Submit a packet to the next decoding thread.
@@ -515,6 +522,7 @@ void ff_thread_finish_setup(AVCodecContext *avctx) {
if (!(avctx-active_thread_typeFF_THREAD_FRAME)) return;
+av_assert0(!p-main_thread);
if(p-state == STATE_SETUP_FINISHED){
av_log(avctx, AV_LOG_WARNING, Multiple ff_thread_finish_setup()
calls\n);
}
@@ -549,6 +557,7 @@ void ff_frame_thread_free(AVCodecContext *avctx, int
thread_count)
const AVCodec *codec = avctx-codec;
int i;
+av_assert0(fctx-main_thread);
park_frame_worker_threads(fctx, thread_count);
if (fctx-prev_thread fctx-prev_thread != fctx-threads)
@@ -634,6 +643,7 @@ int ff_frame_thread_init(AVCodecContext *avctx)
}
avctx-internal-thread_ctx = fctx =
av_mallocz(sizeof(FrameThreadContext));
+fctx-main_thread = 1;
fctx-threads = av_mallocz_array(thread_count, sizeof(PerThreadContext));
pthread_mutex_init(fctx-buffer_mutex, NULL);
@@ -718,6 +728,7 @@ void ff_thread_flush(AVCodecContext *avctx)
if (!fctx) return;
+av_assert0(fctx-main_thread);
park_frame_worker_threads(fctx, avctx-thread_count);
if (fctx-prev_thread) {
if (fctx-prev_thread != fctx-threads[0])
@@ -743,7 +754,10 @@ void ff_thread_flush(AVCodecContext *avctx)
int ff_thread_can_start_frame(AVCodecContext *avctx)
{
PerThreadContext *p = avctx-internal-thread_ctx;
-if ((avctx-active_thread_typeFF_THREAD_FRAME) p-state !=
STATE_SETTING_UP
+if (avctx-active_thread_typeFF_THREAD_FRAME)
+return 0;
+av_assert0(!p-main_thread);
+if (p-state != STATE_SETTING_UP
(avctx-codec-update_thread_context ||
!THREAD_SAFE_CALLBACKS(avctx))) {
return 0;
}
@@ -762,6 +776,7 @@ static int thread_get_buffer_internal(AVCodecContext
*avctx, ThreadFrame *f, int
if (!(avctx-active_thread_type FF_THREAD_FRAME))
return ff_get_buffer(avctx, f-f, flags);
+av_assert0(!p-main_thread);
if (p-state != STATE_SETTING_UP
(avctx-codec-update_thread_context ||
!THREAD_SAFE_CALLBACKS(avctx))) {
av_log(avctx, AV_LOG_ERROR, get_buffer() cannot be called after
Re: [FFmpeg-devel] [PATCH] avformat/bit: return early from write_packet if pkt-size is 0
On 26.02.2015 21:47, Nicolas George wrote: L'octidi 8 ventôse, an CCXXIII, Nicolas George a écrit : Last: how come ffmpeg/lavf tries to mux an empty packet? It comes from that commit: commit 0957b274e312e985d69cb490bee2a7ff820acaa6 Author: Anton Khirnov an...@khirnov.net Date: 2014-04-29 15:06:45 +0200 lavc: add an option to enable side data-only packets during encoding Some encoders (e.g. flac) need to send side data when there is no more data to be output. This enables them to output a packet with no data in it, only side data. IMHO, the empty packet should not be reaching the demuxers that do not expect them, that would change the output. I suggest you check with Anton. The other muxers handle the empty packet gracefully, so I don't see a problem. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/bit: return early from write_packet if pkt-size is 0
On Thu, Feb 26, 2015 at 10:11:37PM +0100, Andreas Cadhalpun wrote: On 26.02.2015 20:48, Nicolas George wrote: L'octidi 8 ventôse, an CCXXIII, Andreas Cadhalpun a écrit : the bit format muxer currently segfaults, when it is passed a packet of size 0. This can be triggered e.g. with: ffmpeg -y -f lavfi -i sine=duration=0.1 -c:a flac -f bit /dev/null Attached patch fixes this. This looks wrong. The bit muxer seems to assume packets have a constant size, apparently 10 octets. Someone knowing the format should check, but I suppose this would be more correct: if (pkt-size != 10) return AVERROR(EINVAL); You're right. New patch with this check attached. Also, it seems you should not be able to mux FLAC into this format, the write header callback does not validate enough. It looks like this muxer is a quick-and-dirty implementation, emphasis on the dirty. Indeed. I also attached a patch limiting the bit muxer to codec g729 with 1 channel, as this is apparently the only thing it supports. applied both patches thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_format issues when called outside frame decode.
On Thu, Feb 26, 2015 at 11:21 PM, Reimar Döffinger
reimar.doeffin...@gmx.de wrote:
When ff_thread_get_format is called from the main thread, e.g.
during codec init it will access the thread_ctx as a PerThreadContext
even though it is a FrameThreadContext.
Where is this a problem exactly? I don't see a single codec that calls
it during codec init.
The only codecs that actually call it are h264 and hevc, and thats in
slice header decoding, not codec init (and mpeg12, which doesn't do
frame threading)
In addition, when ff_thread_get_format is called during the context
update it would get confused because the state is not as expected.
Make it handle that case by adding a new state for this, signalling
that we are actually executing in the main thread and thus can
call get_format directly in all cases.
When would this ever happen? MT decoding works perfectly fine in a
number of applications as it is.
@@ -743,7 +754,10 @@ void ff_thread_flush(AVCodecContext *avctx)
int ff_thread_can_start_frame(AVCodecContext *avctx)
{
PerThreadContext *p = avctx-internal-thread_ctx;
-if ((avctx-active_thread_typeFF_THREAD_FRAME) p-state !=
STATE_SETTING_UP
+if (avctx-active_thread_typeFF_THREAD_FRAME)
+return 0;
+av_assert0(!p-main_thread);
+if (p-state != STATE_SETTING_UP
(avctx-codec-update_thread_context ||
!THREAD_SAFE_CALLBACKS(avctx))) {
return 0;
}
This hunk looks rather suspicious. Returning 0 unconditionally on
active_thread_type FF_THREAD_FRAME?
In general, I'm rather cautious with any changes to the threading
model, so these should be clearly warranted and explained properly.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Patch] no_delay option for librtmp
No, i just extended what Brian already had. Just an option to to control
the no delay. I put the changes inside you #if for networking config.
On Feb 26, 2015 7:42 PM, Michael Niedermayer michae...@gmx.at wrote:
On Thu, Feb 26, 2015 at 03:23:40PM -0600, Cary Tetrick wrote:
Use this instead. (sorry, corrected grammatical errors.)
On Thu, Feb 26, 2015 at 1:22 PM, Cary Tetrick ctetri...@gmail.com
wrote:
This adds another option to a change authored by Brian Brice
bbr...@gmail.com 2015-01-19
librtmp: Allow changing the socket send buffer size
(Brian is aware of this change).
Unlike a previous patch, this has no dependency on rtmpdump.
Options to the ffmpeg commandline in support of now arguments in
librtmp.
rtmp_buffer_size - sets rtmp socket send buffer size in bytes.
this is the same as the patch it replaces.
rtmp_nodelay - on or off. defaults to on.
allows users to control whether nagel is active.
See this thread on Zeranoe forum:
http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7t=657p=7823#p7823
I believe this addresses case 1604 on the ffmpeg tracker.
Summary of the bug: Rtmp output to justin.tv fps continually drops,
...
- note the memory problem mentioned had been fixed. This fix only
applies
if
librtmp is enabled.
https://trac.ffmpeg.org/ticket/1604
Defualt behavior leaves things unchanged. Users must employ options
intentionally.
My previous patch should be ignored.
librtmp.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
0957935410df54a8122e3cd62d771d87a39c4347
0001-Topic-Option-to-control-no_delay-flag-in-librtmp.patch
From fe8be0cdb6ed76a67283bb1000585af79b492d4d Mon Sep 17 00:00:00 2001
From: Cary Tetrick cary.tetr...@gmail.com
Date: Thu, 26 Feb 2015 15:18:47 -0600
Subject: [PATCH] Topic: Option to control no_delay flag in librtmp
This adds another option to a change authored by Brian Brice
bbr...@gmail.com 2015-01-19
librtmp: Allow changing the socket send buffer size
(Brian is aware of this change).
Unlike a previous patch, this has no dependency on rtmpdump.
Options to the ffmpeg commandline in support of now arguments in
librtmp.
rtmp_buffer_size - sets rtmp socket send buffer size in bytes.
this is the same as the patch it replaces.
rtmp_nodelay - on or off. defaults to on.
allows users to control whether nagel is active.
See this thread on Zeranoe forum:
http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7t=657p=7823#p7823
I believe this addresses case 1604 on the ffmpeg tracker.
Summary of the bug: Rtmp output to justin.tv fps continually drops,
...
- note the memory problem mentioned had been fixed. This fix only
applies if
librtmp is enabled.
https://trac.ffmpeg.org/ticket/1604
Defualt behavior leaves things unchanged. Users must employ options
intentionally.
---
libavformat/librtmp.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavformat/librtmp.c b/libavformat/librtmp.c
index bfa9a71..64ae59d 100644
--- a/libavformat/librtmp.c
+++ b/libavformat/librtmp.c
@@ -52,6 +52,7 @@ typedef struct LibRTMPContext {
int live;
char *temp_filename;
int buffer_size;
+int tcp_nodelay;
} LibRTMPContext;
static void rtmp_log(int level, const char *fmt, va_list args)
@@ -239,6 +240,11 @@ static int rtmp_open(URLContext *s, const char
*uri, int flags)
int tmp = ctx-buffer_size;
setsockopt(r-m_sb.sb_socket, SOL_SOCKET, SO_SNDBUF, tmp,
sizeof(tmp));
}
+
+if (flags AVIO_FLAG_WRITE) {
+int tmp = ctx-tcp_nodelay;
+setsockopt(r-m_sb.sb_socket, IPPROTO_TCP, TCP_NODELAY, tmp,
sizeof(tmp));
does this need any #includes, any checks in configure?
[...]
--
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
___
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] no_delay option for librtmp
On Thu, Feb 26, 2015 at 03:23:40PM -0600, Cary Tetrick wrote:
Use this instead. (sorry, corrected grammatical errors.)
On Thu, Feb 26, 2015 at 1:22 PM, Cary Tetrick ctetri...@gmail.com wrote:
This adds another option to a change authored by Brian Brice
bbr...@gmail.com 2015-01-19
librtmp: Allow changing the socket send buffer size
(Brian is aware of this change).
Unlike a previous patch, this has no dependency on rtmpdump.
Options to the ffmpeg commandline in support of now arguments in librtmp.
rtmp_buffer_size - sets rtmp socket send buffer size in bytes.
this is the same as the patch it replaces.
rtmp_nodelay - on or off. defaults to on.
allows users to control whether nagel is active.
See this thread on Zeranoe forum:
http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7t=657p=7823#p7823
I believe this addresses case 1604 on the ffmpeg tracker.
Summary of the bug: Rtmp output to justin.tv fps continually drops, ...
- note the memory problem mentioned had been fixed. This fix only applies
if
librtmp is enabled.
https://trac.ffmpeg.org/ticket/1604
Defualt behavior leaves things unchanged. Users must employ options
intentionally.
My previous patch should be ignored.
librtmp.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
0957935410df54a8122e3cd62d771d87a39c4347
0001-Topic-Option-to-control-no_delay-flag-in-librtmp.patch
From fe8be0cdb6ed76a67283bb1000585af79b492d4d Mon Sep 17 00:00:00 2001
From: Cary Tetrick cary.tetr...@gmail.com
Date: Thu, 26 Feb 2015 15:18:47 -0600
Subject: [PATCH] Topic: Option to control no_delay flag in librtmp
This adds another option to a change authored by Brian Brice
bbr...@gmail.com 2015-01-19
librtmp: Allow changing the socket send buffer size
(Brian is aware of this change).
Unlike a previous patch, this has no dependency on rtmpdump.
Options to the ffmpeg commandline in support of now arguments in librtmp.
rtmp_buffer_size - sets rtmp socket send buffer size in bytes.
this is the same as the patch it replaces.
rtmp_nodelay - on or off. defaults to on.
allows users to control whether nagel is active.
See this thread on Zeranoe forum:
http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7t=657p=7823#p7823
I believe this addresses case 1604 on the ffmpeg tracker.
Summary of the bug: Rtmp output to justin.tv fps continually drops, ...
- note the memory problem mentioned had been fixed. This fix only applies if
librtmp is enabled.
https://trac.ffmpeg.org/ticket/1604
Defualt behavior leaves things unchanged. Users must employ options
intentionally.
---
libavformat/librtmp.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavformat/librtmp.c b/libavformat/librtmp.c
index bfa9a71..64ae59d 100644
--- a/libavformat/librtmp.c
+++ b/libavformat/librtmp.c
@@ -52,6 +52,7 @@ typedef struct LibRTMPContext {
int live;
char *temp_filename;
int buffer_size;
+int tcp_nodelay;
} LibRTMPContext;
static void rtmp_log(int level, const char *fmt, va_list args)
@@ -239,6 +240,11 @@ static int rtmp_open(URLContext *s, const char *uri, int
flags)
int tmp = ctx-buffer_size;
setsockopt(r-m_sb.sb_socket, SOL_SOCKET, SO_SNDBUF, tmp,
sizeof(tmp));
}
+
+if (flags AVIO_FLAG_WRITE) {
+int tmp = ctx-tcp_nodelay;
+setsockopt(r-m_sb.sb_socket, IPPROTO_TCP, TCP_NODELAY, tmp,
sizeof(tmp));
does this need any #includes, any checks in configure?
[...]
--
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] no_delay option for librtmp
On Thu, Feb 26, 2015 at 08:00:49PM -0600, Cary Tetrick wrote:
No, i just extended what Brian already had. Just an option to to control
the no delay. I put the changes inside you #if for networking config.
you misunderstood my question
my question is what #includes it needs and if this is portable and
available on all platforms which support CONFIG_NETWORK?
there certainly is something missing as it does not build.
libavformat/librtmp.c: In function ‘rtmp_open’:
libavformat/librtmp.c:246:52: error: ‘TCP_NODELAY’ undeclared (first use in
this function)
libavformat/librtmp.c:246:52: note: each undeclared identifier is reported only
once for each function it appears in
make: *** [libavformat/librtmp.o] Error 1
[...]
+
+if (flags AVIO_FLAG_WRITE) {
+int tmp = ctx-tcp_nodelay;
+setsockopt(r-m_sb.sb_socket, IPPROTO_TCP, TCP_NODELAY, tmp,
sizeof(tmp));
does this need any #includes, any checks in configure?
[...]
--
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
___
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
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
