On Wed, Jul 18, 2012 at 04:44:24PM -0400, Justin Ruggles wrote:
On 07/18/2012 01:23 PM, Kostya Shishkov wrote:
+memset(p-frame.data[0], 0, FRAME_LEN * 2);
[...]
+memcpy(p-frame.data[0], p-audio + LPC_ORDER, FRAME_LEN * 2);
Maybe use av_get_bytes_per_sample() instead of
---
I'm extremely sorry I forgot to do it while committing main patch.
---
libavcodec/version.h |2 +-
libavformat/version.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/version.h b/libavcodec/version.h
index a3fbb74..98d6690 100644
---
On Sun, 22 Jul 2012 08:08:42 +0200, Kostya Shishkov kostya.shish...@gmail.com
wrote:
---
I'm extremely sorry I forgot to do it while committing main patch.
Extremely? Ok then, I forgive you.
You can commit this if you promise not to do it again.
--
Anton Khirnov
On Sun, Jul 22, 2012 at 08:26:20AM +0200, Anton Khirnov wrote:
On Sun, 22 Jul 2012 08:08:42 +0200, Kostya Shishkov
kostya.shish...@gmail.com wrote:
---
I'm extremely sorry I forgot to do it while committing main patch.
Extremely? Ok then, I forgive you.
You can commit this if you
---
libavformat/utils.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 99fbb2f..8a473e9 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2383,9 +2383,9 @@ int avformat_find_stream_info(AVFormatContext *ic,
Useful in cases where a significant analyzeduration is
still needed, while minimizing buffering before output.
Useful for eg, processing low-latency streams where all
media types won't necessarily come in if the analysis
phase is brief.
---
libavformat/avformat.h |5 +
On Sun, 22 Jul 2012 00:42:16 -0700, Josh Allmann joshua.allm...@gmail.com
wrote:
Useful in cases where a significant analyzeduration is
still needed, while minimizing buffering before output.
Useful for eg, processing low-latency streams where all
media types won't necessarily come in if
Nellymoser is float, so use tiny_psnr comparison instead of md5.
---
tests/fate/filter.mak |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/fate/filter.mak b/tests/fate/filter.mak
index d547d3b..41916c9 100644
--- a/tests/fate/filter.mak
+++
It internally decodes as float and then converts to s16 by a call to
float_to_int16(). The caller can do this just as well by using lavr.
---
libavcodec/nellymoserdec.c | 31 ---
1 file changed, 4 insertions(+), 27 deletions(-)
diff --git
Anton Khirnov an...@khirnov.net writes:
Nellymoser is float, so use tiny_psnr comparison instead of md5.
^
Say oneoff instead.
---
tests/fate/filter.mak |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/fate/filter.mak
On Sun, Jul 22, 2012 at 01:50:03AM +0100, Mans Rullgard wrote:
This adds a full identification probe of CC, AS, LD and HOSTCC,
and sets up correct flags and dependency tracking for each.
This is shaping up to be a big step forward. But it's very tricky
code with a lot of subtle name mangling,
---
These are baseline suggestions for things that everybody should have.
Further ideas for things to add more than welcome.
doc/git-howto.texi | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/doc/git-howto.texi b/doc/git-howto.texi
index
On Fri, May 04, 2012 at 02:38:48PM +0200, Jean-Baptiste Kempf wrote:
Hello fellow-geeks and friends,
Like last year, I plan to organize a small technical conference, at the
end of the summer, in Paris, for us to gather, discuss and/or code.
Like last year, this is a technical conference,
Diego Biurrun di...@biurrun.de writes:
On Sun, Jul 22, 2012 at 01:50:03AM +0100, Mans Rullgard wrote:
This adds a full identification probe of CC, AS, LD and HOSTCC,
and sets up correct flags and dependency tracking for each.
This is shaping up to be a big step forward. But it's very tricky
This adds a full identification probe of CC, AS, LD and HOSTCC,
and sets up correct flags and dependency tracking for each.
Signed-off-by: Mans Rullgard m...@mansr.com
---
Updated per Diego's comments.
Fixed some corner cases when DEPCC != CC.
---
Makefile | 9 +-
configure | 296
Hi,
On Sat, Jul 21, 2012 at 5:03 PM, Ronald S. Bultje rsbul...@gmail.com wrote:
From: Ronald S. Bultje rsbul...@gmail.com
This allows compiling this code using compilers that do not understand
gcc-style inline assembly.
---
libavfilter/x86/gradfun.c |6 ++
libavfilter/x86/yadif.c
On 07/22/2012 05:30 AM, Anton Khirnov wrote:
It internally decodes as float and then converts to s16 by a call to
float_to_int16(). The caller can do this just as well by using lavr.
---
libavcodec/nellymoserdec.c | 31 ---
1 file changed, 4 insertions(+), 27
Hi,
On Sat, Jul 21, 2012 at 5:19 PM, Måns Rullgård m...@mansr.com wrote:
Ronald S. Bultje rsbul...@gmail.com writes:
From: Ronald S. Bultje rsbul...@gmail.com
This removes some code duplication between the 3 different versions,
and aligns brackets in such a way that it is now possible to
Ronald S. Bultje rsbul...@gmail.com writes:
This manner of splitting things is incredibly weird-looking. Instead of
trying to unify these rather different fragments, turning the second
half of the loop into a macro and writing out separate loops, each
calling the macro for the common part,
Hi,
On Sun, Jul 22, 2012 at 8:17 AM, Måns Rullgård m...@mansr.com wrote:
Ronald S. Bultje rsbul...@gmail.com writes:
This manner of splitting things is incredibly weird-looking. Instead of
trying to unify these rather different fragments, turning the second
half of the loop into a macro and
Useful in cases where a significant analyzeduration is
still needed, while minimizing buffering before output.
An example is processing low-latency streams where all
media types won't necessarily come in if the analysis
phase is brief.
---
libavformat/avformat.h |1 +
---
libavformat/utils.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 37a9d10..f485f06 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2383,9 +2383,9 @@ int avformat_find_stream_info(AVFormatContext *ic,
---
A couple of the functions have such bad indentation they're nearly unreadable.
libavcodec/ppc/fmtconvert_altivec.c | 126 ++-
1 files changed, 64 insertions(+), 62 deletions(-)
diff --git a/libavcodec/ppc/fmtconvert_altivec.c
On 22/07/2012 3:00 PM, Justin Ruggles wrote:
---
A couple of the functions have such bad indentation they're nearly unreadable.
libavcodec/ppc/fmtconvert_altivec.c | 126
++-
1 files changed, 64 insertions(+), 62 deletions(-)
Looks OK, but it's still
From: Ronald S. Bultje rsbul...@gmail.com
This completes the conversion of h264dsp to yasm; note that h264 also
uses some dsputil functions, most notably qpel. Performance-wise, the
yasm-version is ~10 cycles faster (182-172) on x86-64, and ~8 cycles
faster (201-193) on x86-32.
---
From: Ronald S. Bultje rsbul...@gmail.com
This completes the conversion of h264dsp to yasm; note that h264 also
uses some dsputil functions, most notably qpel. Performance-wise, the
yasm-version is ~10 cycles faster (182-172) on x86-64, and ~8 cycles
faster (201-193) on x86-32.
---
From: Ronald S. Bultje rsbul...@gmail.com
The function called in this block is under HAVE_INLINE_ASM itself also.
---
libswscale/swscale.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 7ae5af3..5cfa7f2 100644
---
On 07/22/2012 03:34 PM, Derek Buitenhuis wrote:
On 22/07/2012 3:00 PM, Justin Ruggles wrote:
---
A couple of the functions have such bad indentation they're nearly
unreadable.
libavcodec/ppc/fmtconvert_altivec.c | 126
++-
1 files changed, 64
From: Ronald S. Bultje rsbul...@gmail.com
---
libswscale/utils.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index d8fee58..a6b5a18 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -576,7 +576,7 @@ fail:
Justin Ruggles justin.rugg...@gmail.com writes:
On 07/22/2012 03:34 PM, Derek Buitenhuis wrote:
On 22/07/2012 3:00 PM, Justin Ruggles wrote:
---
A couple of the functions have such bad indentation they're nearly
unreadable.
libavcodec/ppc/fmtconvert_altivec.c | 126
From: Ronald S. Bultje rsbul...@gmail.com
This allows compiling with compilers that don't support gcc-style
inline assembly.
---
libavcodec/x86/dsputil_mmx.c | 69 --
libavcodec/x86/h264_qpel_mmx.c |4 ++-
libavcodec/x86/idct_mmx.c|4
From: Ronald S. Bultje rsbul...@gmail.com
Mixing yasm and inline asm is a bad idea, since if either yasm or inline
asm is not supported by your toolchain, all of the asm stops working.
Thus, better to use either one or the other alone.
---
libavcodec/x86/vp3dsp.asm | 120
From: Ronald S. Bultje rsbul...@gmail.com
This allows compiling with compilers that don't support gcc-style
inline assembly.
---
libavcodec/dct-test.c|2 +-
libavcodec/x86/dsputil_mmx.c | 69 --
libavcodec/x86/h264_qpel_mmx.c |4 ++-
On Sun, Jul 22, 2012 at 02:01:28PM -0700, Ronald S. Bultje wrote:
From: Ronald S. Bultje rsbul...@gmail.com
---
libswscale/utils.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
You are not adding a scaler, merely placing an existing one under ifdef.
So the log message
From: Ronald S. Bultje rsbul...@gmail.com
This allows compiling with compilers that don't support gcc-style
inline assembly.
---
libavcodec/dct-test.c|2 +-
libavcodec/x86/dsputil_mmx.c | 69 --
libavcodec/x86/h264_qpel_mmx.c |4 ++-
Hello,
I am a Handbrake user and I appologize if this message is being sent to the
wrong area.
I was wanting to ask if the addition of the Grass Valley Canopus HQX codec for
decode use in Handbrake is a possibility for Libav?
This is a 10-bit 4:2:2 cross platform codec that my NLE, Grass
Hi everyone!
I using this command bellow for converting file
./avconv -i inputFile -vcodec libx264 -trellis 2 -crf 23 -tune psnr -vf
crop='trunc(iw/2)*2:trunc(ih/2)*2' -y outputFile
But, I don't want to using this command, I want to make a function like
convert(char *inputFile, char *outputFile).
---
libavformat/rtp.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavformat/rtp.c b/libavformat/rtp.c
index 6516779..dab8216 100644
--- a/libavformat/rtp.c
+++ b/libavformat/rtp.c
@@ -110,9 +110,10 @@ int ff_rtp_get_payload_type(AVFormatContext *fmt,
From: Adriano Pallavicino adriano.pallavic...@gmail.com
---
libavformat/rtp.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavformat/rtp.c b/libavformat/rtp.c
index 6516779..dab8216 100644
--- a/libavformat/rtp.c
+++ b/libavformat/rtp.c
@@ -110,9 +110,10 @@ int
On Sun, Jul 22, 2012 at 11:37 PM, Diego Biurrun di...@biurrun.de wrote:
On Fri, May 04, 2012 at 02:38:48PM +0200, Jean-Baptiste Kempf wrote:
Hello fellow-geeks and friends,
Like last year, I plan to organize a small technical conference, at the
end of the summer, in Paris, for us to gather,
Tim Susan Polster polstermi...@yahoo.com writes:
Hello,
I am a Handbrake user and I appologize if this message is being sent
to the wrong area.
I was wanting to ask if the addition of the Grass Valley Canopus HQX
codec for decode use in Handbrake is a possibility for Libav?
This is a
From: Ronald S. Bultje rsbul...@gmail.com
---
libswscale/utils.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index d8fee58..a6b5a18 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -576,7 +576,7 @@ fail:
On 22/07/2012 6:17 PM, Måns Rullgård wrote:
Are there any specifications for this codec available?
All of Canopus' stuff are binary only. Last time I looked,
the codecs were in several-mbyte-large, so RE might be a PITA.
- Derek
___
libav-devel
On 22/07/2012 6:14 PM, Ronald S. Bultje wrote:
From: Ronald S. Bultje rsbul...@gmail.com
This allows compiling with compilers that don't support gcc-style
inline assembly.
---
I think this looks OK, assuming:
1) You've tested every yasm/inline asm enable/disable combination
2) Everybody
---
libswscale/output.c | 15 ---
libswscale/ppc/swscale_altivec.c |3 ++-
libswscale/ppc/yuv2rgb_altivec.c | 11 +++
libswscale/rgb2rgb.c |3 ++-
libswscale/sparc/yuv2rgb_vis.c |3 ++-
libswscale/utils.c |4 +++-
On Sun, Jul 22, 2012 at 03:23:21PM -0700, Ronald S. Bultje wrote:
From: Ronald S. Bultje rsbul...@gmail.com
---
libswscale/utils.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
OK
Diego
___
libav-devel mailing list
On 21/07/2012 4:36 PM, Diego Biurrun wrote:
The files do not contain only MMX code.
---
libswscale/x86/Makefile |4 ++--
libswscale/x86/{swscale_mmx.c = swscale.c} |0
libswscale/x86/{yuv2rgb_mmx.c = yuv2rgb.c} |0
3 files changed, 2 insertions(+), 2
Hi,
On Sun, Jul 22, 2012 at 3:30 PM, Diego Biurrun di...@biurrun.de wrote:
---
libswscale/output.c | 15 ---
libswscale/ppc/swscale_altivec.c |3 ++-
libswscale/ppc/yuv2rgb_altivec.c | 11 +++
libswscale/rgb2rgb.c |3 ++-
On 22/07/2012 4:56 PM, Ronald S. Bultje wrote:
From: Ronald S. Bultje rsbul...@gmail.com
The function called in this block is under HAVE_INLINE_ASM itself also.
---
libswscale/swscale.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Seems OK, as long as I didn't miss some
On 22/07/2012 6:58 PM, Kieran Kunhya wrote:
_mmx seems to usually signify inline asm, no? Shouldn't we still use some
sort of suffix to indicate this? Perhaps I am mistaken.
It signifies inline asm only by nature of the fact that the mmx at the
time was written using inline asm.
Perhaps it
On Sun, Jul 22, 2012 at 11:56 PM, Derek Buitenhuis
derek.buitenh...@gmail.com wrote:
On 21/07/2012 4:36 PM, Diego Biurrun wrote:
The files do not contain only MMX code.
---
libswscale/x86/Makefile |4 ++--
libswscale/x86/{swscale_mmx.c = swscale.c} |0
This allows non-standard replacements for the -c compiler flag.
Some compilers use other flags or no flag at all in place of
the usual one.
Signed-off-by: Mans Rullgard m...@mansr.com
---
Makefile | 2 +-
configure | 13 ++---
2 files changed, 11 insertions(+), 4 deletions(-)
diff
These patches go on top of the already posted configure
patches and prepare the build system for supporting even
stranger compiler command line syntaxes.
Mans Rullgard (2):
build: support non-standard replacements for -E flag
build: support non-standard replacements for -c flag
Makefile |
This allows using non-standard flags for running the C preprocessor.
The -o flag must be included in this setting due to strange syntax
required by some compilers.
Set the correct flags for tms470.
Signed-off-by: Mans Rullgard m...@mansr.com
---
configure | 12 ++--
1 file changed, 10
On 22/07/2012 7:16 PM, Mans Rullgard wrote:
This allows non-standard replacements for the -c compiler flag.
Some compilers use other flags or no flag at all in place of
the usual one.
Signed-off-by: Mans Rullgard m...@mansr.com
---
Makefile | 2 +-
configure | 13 ++---
2
On Sun, Jul 22, 2012 at 06:56:37PM -0400, Derek Buitenhuis wrote:
On 21/07/2012 4:36 PM, Diego Biurrun wrote:
The files do not contain only MMX code.
---
libswscale/x86/Makefile |4 ++--
libswscale/x86/{swscale_mmx.c = swscale.c} |0
On 22/07/2012 7:16 PM, Mans Rullgard wrote:
This allows using non-standard flags for running the C preprocessor.
The -o flag must be included in this setting due to strange syntax
required by some compilers.
Set the correct flags for tms470.
Signed-off-by: Mans Rullgard m...@mansr.com
On 22/07/2012 7:31 PM, Diego Biurrun wrote:
_mmx seems to usually signify inline asm, no? Shouldn't we still use some
sort of suffix to indicate this? Perhaps I am mistaken.
All the code below x86/ is either inline asm or yasm, plus a bit of init
code. The yasm stuff ends in .asm, the init
Derek Buitenhuis derek.buitenh...@gmail.com writes:
On 22/07/2012 7:16 PM, Mans Rullgard wrote:
This allows non-standard replacements for the -c compiler flag.
Some compilers use other flags or no flag at all in place of
the usual one.
Signed-off-by: Mans Rullgard m...@mansr.com
---
Derek Buitenhuis derek.buitenh...@gmail.com writes:
On 22/07/2012 7:16 PM, Mans Rullgard wrote:
This allows using non-standard flags for running the C preprocessor.
The -o flag must be included in this setting due to strange syntax
required by some compilers.
Set the correct flags for
On 22/07/2012 7:39 PM, Måns Rullgård wrote:
+cc_e(){
+eval printf '%s\\n' $CC_E
+}
I'm probably ignorant here, but why is this needed?
Why is what needed?
cc_e(). Something preventing using $CC_E directly (I'm sure there is).
- Derek
___
On Sun, Jul 22, 2012 at 07:35:53PM -0400, Derek Buitenhuis wrote:
On 22/07/2012 7:31 PM, Diego Biurrun wrote:
_mmx seems to usually signify inline asm, no? Shouldn't we still use some
sort of suffix to indicate this? Perhaps I am mistaken.
All the code below x86/ is either inline asm or
On Sat, Jul 21, 2012 at 05:03:12PM -0700, Ronald S. Bultje wrote:
From: Ronald S. Bultje rsbul...@gmail.com
This allows compiling this code using compilers that do not understand
gcc-style inline assembly.
---
libavfilter/x86/gradfun.c |6 ++
libavfilter/x86/yadif.c |6
Derek Buitenhuis derek.buitenh...@gmail.com writes:
On 22/07/2012 7:39 PM, Måns Rullgård wrote:
+cc_e(){
+eval printf '%s\\n' $CC_E
+}
I'm probably ignorant here, but why is this needed?
Why is what needed?
cc_e(). Something preventing using $CC_E directly (I'm sure there is).
On 22/07/2012 7:54 PM, Måns Rullgård wrote:
Same reason as cc_o. For both of these variables, the value will
contain $@ which make expands to the target being built. In the shell,
$@ expands to all arguments of the script/function. Passing the
filename as argument to a function and, within
On Mon, Jul 23, 2012 at 12:16:41AM +0100, Mans Rullgard wrote:
This allows using non-standard flags for running the C preprocessor.
The -o flag must be included in this setting due to strange syntax
required by some compilers.
--- a/configure
+++ b/configure
@@ -621,6 +621,10 @@ cc_o(){
Diego Biurrun di...@biurrun.de writes:
On Mon, Jul 23, 2012 at 12:16:41AM +0100, Mans Rullgard wrote:
This allows using non-standard flags for running the C preprocessor.
The -o flag must be included in this setting due to strange syntax
required by some compilers.
--- a/configure
+++
On Mon, Jul 23, 2012 at 01:16:07AM +0100, Måns Rullgård wrote:
Diego Biurrun di...@biurrun.de writes:
On Mon, Jul 23, 2012 at 12:16:41AM +0100, Mans Rullgard wrote:
This allows using non-standard flags for running the C preprocessor.
The -o flag must be included in this setting due to
Diego Biurrun di...@biurrun.de writes:
On Mon, Jul 23, 2012 at 01:16:07AM +0100, Måns Rullgård wrote:
Diego Biurrun di...@biurrun.de writes:
On Mon, Jul 23, 2012 at 12:16:41AM +0100, Mans Rullgard wrote:
This allows using non-standard flags for running the C preprocessor.
The -o flag
Just some backports for files I watch or maintain.
Carl Eugen Hoyos (1):
Do not fail when decoding invalid v410 files with odd width.
Clément Bœsch (1):
wav: init st to NULL to avoid a false-positive warning.
Hendrik Leppkes (1):
wavpack: set bits_per_raw_sample for S32 samples to
From: Hendrik Leppkes h.lepp...@gmail.com
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/wavpack.c |1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
index 022a4ce..920e0b5 100644
--- a/libavcodec/wavpack.c
+++
From: Clément Bœsch ubi...@gmail.com
If st is NULL, it means no 'fmt ' tag is found, but 'data' tag (which
needs a previous 'fmt ' tag to be parsed correctly and st initialized)
check will make sure st is never dereferenced in that case.
---
libavformat/wav.c |2 +-
1 file changed, 1
From: Reimar Döffinger reimar.doeffin...@gmx.de
Set picture type before calling get_buffer.
This allows the DR application to make better decisions.
It also fixes a resource leak in case of missing reference frames
since it would call get_buffer but never release_buffer.
Also use FFSWAP to ensure
From: Carl Eugen Hoyos ceho...@ag.or.at
---
libavcodec/v410dec.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavcodec/v410dec.c b/libavcodec/v410dec.c
index a6f236b..2484d8e 100644
--- a/libavcodec/v410dec.c
+++ b/libavcodec/v410dec.c
@@ -28,10 +28,8 @@ static
Benjamin Larsson benjamin@... writes:
OK
PING
Thanks to Anton, the sample is in FATE now.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 22/07/2012 10:22 PM, Mashiat Sarker Shakkhar wrote:
OK
PING
Thanks to Anton, the sample is in FATE now.
Ran through FATE locally and pushed. It's been on the fate-suite
servers for ~2 days now, so it should be synched everywhere.
- Derek
___
Hi,
On Sun, Jul 22, 2012 at 5:35 PM, Måns Rullgård m...@mansr.com wrote:
Diego Biurrun di...@biurrun.de writes:
On Mon, Jul 23, 2012 at 01:16:07AM +0100, Måns Rullgård wrote:
Diego Biurrun di...@biurrun.de writes:
On Mon, Jul 23, 2012 at 12:16:41AM +0100, Mans Rullgard wrote:
This allows
From: Ronald S. Bultje rsbul...@gmail.com
Write out the NAL decoding loops in full so that they are easier to
parse for a preprocessor without it having to be aware of macros or
other such things in C code.
This also makes the code more readable.
---
libavcodec/h264.c | 42
On 07/22/2012 10:22 PM, Derek Buitenhuis wrote:
From: Hendrik Leppkes h.lepp...@gmail.com
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/wavpack.c |1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
index
On 07/22/2012 10:22 PM, Derek Buitenhuis wrote:
From: Clément Bœsch ubi...@gmail.com
If st is NULL, it means no 'fmt ' tag is found, but 'data' tag (which
needs a previous 'fmt ' tag to be parsed correctly and st initialized)
check will make sure st is never dereferenced in that case.
---
On 23/07/2012 12:05 AM, Justin Ruggles wrote:
Ok if you include the warning message in the commit log.
Amended locally.
- Derek
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On Sun, Jul 22, 2012 at 10:22:30PM -0400, Derek Buitenhuis wrote:
From: Carl Eugen Hoyos ceho...@ag.or.at
---
libavcodec/v410dec.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavcodec/v410dec.c b/libavcodec/v410dec.c
index a6f236b..2484d8e 100644
---
On Sun, Jul 22, 2012 at 10:22:29PM -0400, Derek Buitenhuis wrote:
From: Reimar Döffinger reimar.doeffin...@gmx.de
Set picture type before calling get_buffer.
This allows the DR application to make better decisions.
It also fixes a resource leak in case of missing reference frames
since it
On 23/07/2012 12:37 AM, Kostya Shishkov wrote:
Ahem, why?
I think the reasoning was something along the lines of:
We should try our very bestest to decode broken files.
- Derek
___
libav-devel mailing list
libav-devel@libav.org
84 matches
Mail list logo
