On 2012-11-25 23:10:26 +, Måns Rullgård wrote:
Janne Grunau janne-li...@jannau.net writes:
Although sample count and delta are in ISO 14496-12 specified as
unsigned files exists were interpreting it as signed integer makes
more sense (see mp4-negative-stts-problem.mp4).
Can someone
On 2012-11-26 02:31:10 +0100, Luca Barbato wrote:
On 11/26/2012 12:03 AM, Janne Grunau wrote:
Although sample count and delta are in ISO 14496-12 specified as
unsigned files exists were interpreting it as signed integer makes
more sense (see mp4-negative-stts-problem.mp4).
Fixes an assert
On 2012-11-26 10:46:27 +0100, Janne Grunau wrote:
On 2012-11-25 23:10:26 +, Måns Rullgård wrote:
Janne Grunau janne-li...@jannau.net writes:
Although sample count and delta are in ISO 14496-12 specified as
unsigned files exists were interpreting it as signed integer makes
more
---
libavcodec/h264.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index fea607e..eca4636 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -3820,7 +3820,7 @@ again:
case NAL_IDR_SLICE:
if
Fixes infinitive or long taking loop in frame num gap code in
the fuzzed sample bipbop234.ts_s223302.
CC: libav-sta...@libav.org
---
libavcodec/h264_ps.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 810f69f..dc6b676 100644
---
Fixes segfault in the fuzzed sample bipbop234.ts_s226407.
CC: libav-sta...@libav.org
---
libavcodec/h264.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index eca4636..730e34a 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
This does not seem to have an effect currently. Fate-h264 passes with
THREADS=1..16 and both threading types as before. It fixes however a
segfault during error resillience with my adaptive-frame-mt patchset.
A picture in use during error resillience gets realloced in another
thread in the fuzzed
On 11/26/2012 01:06 PM, Janne Grunau wrote:
This does not seem to have an effect currently. Fate-h264 passes with
THREADS=1..16 and both threading types as before. It fixes however a
segfault during error resillience with my adaptive-frame-mt patchset.
A picture in use during error resillience
On Mon, Nov 26, 2012 at 01:06:17PM +0100, Janne Grunau wrote:
---
libavcodec/h264.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index fea607e..eca4636 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -3820,7 +3820,7
On Mon, Nov 26, 2012 at 01:06:18PM +0100, Janne Grunau wrote:
Fixes infinitive or long taking loop in frame num gap code in
the fuzzed sample bipbop234.ts_s223302.
CC: libav-sta...@libav.org
---
libavcodec/h264_ps.c | 9 +
1 file changed, 9 insertions(+)
diff --git
On 11/26/2012 01:06 PM, Janne Grunau wrote:
Fixes segfault in the fuzzed sample bipbop234.ts_s226407.
CC: libav-sta...@libav.org
---
libavcodec/h264.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
Ok I guess.
___
libav-devel
On 2012-11-26 13:22:51 +0100, Kostya Shishkov wrote:
On Mon, Nov 26, 2012 at 01:06:18PM +0100, Janne Grunau wrote:
Fixes infinitive or long taking loop in frame num gap code in
the fuzzed sample bipbop234.ts_s223302.
CC: libav-sta...@libav.org
---
libavcodec/h264_ps.c | 9 +
From: Michael Niedermayer michae...@gmx.at
This fixes segfault caused by 3d3cf6745e2a5dc9c377244454c3186d75b177fa
when SingleChannelElement.ret was renamed to SingleChannelElement.ret_buf.
Signed-off-by: Justin Ruggles justin.rugg...@gmail.com
---
libavcodec/aacenc.c | 10 +-
1 files
On 2012-11-26 07:01:20 -0800, Ronald S. Bultje wrote:
Hi,
On Mon, Nov 26, 2012 at 4:06 AM, Janne Grunau janne-li...@jannau.net wrote:
Fixes segfault in the fuzzed sample bipbop234.ts_s226407.
CC: libav-sta...@libav.org
---
libavcodec/h264.c | 7 ++-
1 file changed, 6
On 2012-11-26 10:37:34 -0500, Justin Ruggles wrote:
From: Michael Niedermayer michae...@gmx.at
This fixes segfault caused by 3d3cf6745e2a5dc9c377244454c3186d75b177fa
when SingleChannelElement.ret was renamed to SingleChannelElement.ret_buf.
Signed-off-by: Justin Ruggles
On Mon, Nov 26, 2012 at 12:06 PM, Janne Grunau janne-li...@jannau.net wrote:
Fixes infinitive or long taking loop in frame num gap code in
the fuzzed sample bipbop234.ts_s223302.
I think you mean infinite.
___
libav-devel mailing list
On Mon, Nov 26, 2012 at 7:54 AM, Janne Grunau janne-li...@jannau.net wrote:
On 2012-11-26 07:01:20 -0800, Ronald S. Bultje wrote:
Hi,
On Mon, Nov 26, 2012 at 4:06 AM, Janne Grunau janne-li...@jannau.net wrote:
Fixes segfault in the fuzzed sample bipbop234.ts_s226407.
CC:
On 11/17/2012 10:33 AM, Justin Ruggles wrote:
These patches depend on Mans' ac3dec planar decoding patch set, which he
seems reluctant to push due to the inline asm changes. This removes the
inline asm and replaces it with a simplified version of the x86
downmixing asm from libavresample.
On Sat, Nov 17, 2012 at 10:33:28AM -0500, Justin Ruggles wrote:
---
libavcodec/ac3dsp.c | 48
1 files changed, 24 insertions(+), 24 deletions(-)
OK
Diego
___
libav-devel mailing list
On 11/07/2012 05:29 PM, Justin Ruggles wrote:
Include x86-optimized versions for SSE2 and AVX.
---
libavutil/float_dsp.c |9
libavutil/float_dsp.h | 15 +
libavutil/x86/float_dsp.asm| 45
On Sunday, November 25, 2012, Måns Rullgård m...@mansr.com wrote:
Sean McGovern gsean...@gmail.com writes:
Greedy compiler option parsing in Solaris Studio make this option
do bad things to the resulting shared library.
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
libavutil/eval.c| 27 ---
tests/ref/fate/eval |6 ++
2 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/libavutil/eval.c b/libavutil/eval.c
index 7a28dbe..9e9f43a 100644
--- a/libavutil/eval.c
+++ b/libavutil/eval.c
@@ -81,7 +81,11 @@ double
Hi folks,
I talked about this briefly on IRC earlier this weekend, but in the course
of attempting to implement library symbol versioning I have run into this
problem.
For example, the macro for ff_log2 in libavutil/intmath.h still uses
ff_log2_tab if you aren't on GCC. suncc doesn't appear to
On 2012-11-25 12:42:37 -0500, Justin Ruggles wrote:
---
libavformat/riff.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/libavformat/riff.c b/libavformat/riff.c
index 7313092..190504c 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -734,6
On 2012-11-26 01:04:27 +0100, Diego Biurrun wrote:
---
Now featuring explicit avutil dependencies for all libraries.
configure | 47 +--
1 files changed, 21 insertions(+), 26 deletions(-)
diff --git a/configure b/configure
index
Sean McGovern gsean...@gmail.com writes:
Hi folks,
I talked about this briefly on IRC earlier this weekend, but in the course
of attempting to implement library symbol versioning I have run into this
problem.
For example, the macro for ff_log2 in libavutil/intmath.h still uses
ff_log2_tab
Avoids a 2G memory allocation and parsing of random data in
mov_read_dref(). The fuzzed sample sample.mp4_s224424 triggers this.
---
libavformat/mov.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index a80bf5b..83d8dd7 100644
---
On 11/26/12 10:22 PM, Janne Grunau wrote:
Avoids a 2G memory allocation and parsing of random data in
mov_read_dref(). The fuzzed sample sample.mp4_s224424 triggers this.
---
libavformat/mov.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Seems ok.
On 2012-11-26 22:25:03 +0100, Luca Barbato wrote:
On 11/26/12 10:22 PM, Janne Grunau wrote:
Avoids a 2G memory allocation and parsing of random data in
mov_read_dref(). The fuzzed sample sample.mp4_s224424 triggers this.
---
libavformat/mov.c | 4 +++-
1 file changed, 3 insertions(+),
On 2012-11-26 22:37:38 +0100, Janne Grunau wrote:
On 2012-11-26 22:25:03 +0100, Luca Barbato wrote:
On 11/26/12 10:22 PM, Janne Grunau wrote:
Avoids a 2G memory allocation and parsing of random data in
mov_read_dref(). The fuzzed sample sample.mp4_s224424 triggers this.
---
Hi,
overall, ok.
2012/11/7 Justin Ruggles justin.rugg...@gmail.com:
+mova [dstq+lenq+mmsize], m2
+sub lenq, 2*mmsize
So you scan in reverse order. Is that because you are used to do it
that way, or because it is an actual improvement?
--
Christophe
On 11/26/2012 05:47 PM, Christophe Gisquet wrote:
Hi,
overall, ok.
2012/11/7 Justin Ruggles justin.rugg...@gmail.com:
+mova [dstq+lenq+mmsize], m2
+sub lenq, 2*mmsize
So you scan in reverse order. Is that because you are used to do it
that way, or because it is an
It will always be the number of samples in the input buffer, so just use that
directly instead of passing it as a separate parameter.
---
libavresample/audio_convert.c |3 ++-
libavresample/audio_convert.h |7 +--
libavresample/utils.c |9 -
3 files changed, 11
---
libavresample/resample.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavresample/resample.h b/libavresample/resample.h
index b42fdbb..c16186e 100644
--- a/libavresample/resample.h
+++ b/libavresample/resample.h
@@ -62,7 +62,7 @@ void
Since the resampler handles buffering of unconsumed samples internally, the
caller does not need this information.
---
libavresample/resample.c |9 -
libavresample/resample.h |4 +---
libavresample/utils.c|3 +--
3 files changed, 6 insertions(+), 10 deletions(-)
diff
From: Michael Niedermayer michae...@gmx.at
Fixes curruption of metadata in the INFO chunk.
Signed-off-by: Michael Niedermayer michae...@gmx.at
Signed-off-by: Justin Ruggles justin.rugg...@gmail.com
---
libavformat/wavenc.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff
Hi,
On Mon, Nov 26, 2012 at 4:11 PM, Justin Ruggles
justin.rugg...@gmail.com wrote:
From: Michael Niedermayer michae...@gmx.at
Fixes curruption of metadata in the INFO chunk.
Signed-off-by: Michael Niedermayer michae...@gmx.at
Signed-off-by: Justin Ruggles justin.rugg...@gmail.com
---
Only the low 18 bits are used for channel assignments. The high bit is a
special-case flag bit used to indicate that any channel layout is
supported.
From Microsoft document, Multiple Channel Audio Data and WAVE Files:
When using WAVEFORMATEXTENSIBLE, channel locations beyond this
predefined set
On 26/11/2012 20:10, Justin Ruggles wrote:
Only the low 18 bits are used for channel assignments. The high bit is a
special-case flag bit used to indicate that any channel layout is
supported.
LGTM
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Original commit, 7b24f9b, says it was added because it is used in libnut.
---
libavformat/nut.c |1 +
libavformat/riff.c |1 -
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavformat/nut.c b/libavformat/nut.c
index 65fadbf..196e04e 100644
--- a/libavformat/nut.c
+++
2012/11/27 Justin Ruggles justin.rugg...@gmail.com:
It's 1 sub vs. 2 add and 1 neg. But it's before the loop, so the
difference is too small to really matter. I can change it if you prefer.
Don't bother, that was only genuine curiosity.
Some older optimized memcpy (AMD one iirc) used to do
41 matches
Mail list logo
