On Thu, 04 Oct 2012 00:21:12 +0200, Luca Barbato wrote:
> On 10/03/2012 10:56 PM, Anton Khirnov wrote:
> > Right now it incorrectly assumes that the frames are sent in the proper
> > order, which worked with old ffmpeg and avconv versions by accident.
> > ---
> > libavfilter/vf_overlay.c | 207
On Wed, Oct 3, 2012 at 7:06 PM, Diego Biurrun wrote:
> ---
> libavutil/x86/cpu.c |5 +
> 1 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/libavutil/x86/cpu.c b/libavutil/x86/cpu.c
> index 9acc867..9cf68e4 100644
> --- a/libavutil/x86/cpu.c
> +++ b/libavutil/x86/cpu.c
> @@
On 10/04/2012 01:07 AM, Diego Biurrun wrote:
> ff_get_cpu_flags_x86() requires cpuid(), which is conditionally defined
> elsewhere in the file. Surrounding the function body with ifdefs allows
> building even when cpuid is not defined. An empty cpuflags mask is
> returned in this case.
> ---
>
From: "Ronald S. Bultje"
The variable is copied to subsequent threads at the same time, so this
may cause wrong ref_count[] values to be copied to subsequent threads.
This bug was found using TSAN.
Signed-off-by: Luca Barbato
---
Few cosmetic nits.
libavcodec/h264_cabac.c | 41 +
Diego Biurrun writes:
> On Thu, Oct 04, 2012 at 12:27:09AM +0100, Måns Rullgård wrote:
>> Diego Biurrun writes:
>> > --- a/libavutil/x86/cpu.c
>> > +++ b/libavutil/x86/cpu.c
>> > @@ -108,10 +108,7 @@ int ff_get_cpu_flags_x86(void)
>> >
>> > -cpuid(0, max_std_level, ebx, ecx, edx);
>> > -
On Thu, Oct 04, 2012 at 12:27:09AM +0100, Måns Rullgård wrote:
> Diego Biurrun writes:
> > --- a/libavutil/x86/cpu.c
> > +++ b/libavutil/x86/cpu.c
> > @@ -108,10 +108,7 @@ int ff_get_cpu_flags_x86(void)
> >
> > -cpuid(0, max_std_level, ebx, ecx, edx);
> > -vendor.i[0] = ebx;
> > -vendo
Diego Biurrun writes:
> +#define get_eflags(x) \
> +x = ff_cpu_cpuid_test();
> +
> +#define set_eflags(x) \
> +x = 0;
Instead of these weird definitions, please break out the existing cpuid
test into a function similar to the yasm one.
On Thu, Oct 04, 2012 at 01:07:00AM +0200, Diego Biurrun wrote:
>
> --- /dev/null
> +++ b/libavutil/x86/cpuid.asm
> @@ -0,0 +1,91 @@
> +;*
> +;* Copyright (C) 2005-2010 x264 project
> +;*
> +;* Authors: Loren Merritt
> +;*
Diego Biurrun writes:
> ---
> libavutil/x86/cpu.c |5 +
> 1 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/libavutil/x86/cpu.c b/libavutil/x86/cpu.c
> index 9acc867..9cf68e4 100644
> --- a/libavutil/x86/cpu.c
> +++ b/libavutil/x86/cpu.c
> @@ -108,10 +108,7 @@ int ff_get_
From: "Ronald S. Bultje"
The variable is copied to subsequent threads at the same time, so this
may cause wrong ref_count[] values to be copied to subsequent threads.
This bug was found using TSAN.
---
libavcodec/h264_cabac.c | 41 -
libavcodec/h264_cav
This allows detecting CPU features with builds that have neither
gcc inline assembly nor the right compiler intrinsics enabled.
---
libavutil/x86/Makefile |3 +-
libavutil/x86/cpu.c | 19 +-
libavutil/x86/cpu.h |4 ++
libavutil/x86/cpuid.asm | 91 ++
ff_get_cpu_flags_x86() requires cpuid(), which is conditionally defined
elsewhere in the file. Surrounding the function body with ifdefs allows
building even when cpuid is not defined. An empty cpuflags mask is
returned in this case.
---
This is an updated version of a patch previously sent.
Now
Now that there is CPU detection in YASM, there will always be one of
inline or external assembly enabled, which obviates the need to fall
back on CPU detection through compiler intrinsics.
---
configure |6 --
libavutil/x86/cpu.c | 38 +-
2 f
---
libavutil/x86/cpu.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/libavutil/x86/cpu.c b/libavutil/x86/cpu.c
index 9acc867..9cf68e4 100644
--- a/libavutil/x86/cpu.c
+++ b/libavutil/x86/cpu.c
@@ -108,10 +108,7 @@ int ff_get_cpu_flags_x86(void)
return 0; /*
From: "Ronald S. Bultje"
The variable is copied to subsequent threads at the same time, so this
may cause wrong ref_count[] values to be copied to subsequent threads.
---
libavcodec/h264_cabac.c | 41 -
libavcodec/h264_cavlc.c | 33 +---
From: "Ronald S. Bultje"
The variable is copied to subsequent threads at the same time, so this
may cause wrong ref_count[] values to be copied to subsequent threads.
---
libavcodec/h264_cabac.c | 41 -
libavcodec/h264_cavlc.c | 33 +---
On Thu, 4 Oct 2012, Luca Barbato wrote:
On 10/03/2012 11:37 PM, Martin Storsjö wrote:
This makes sure any buffered data is written to the segment, for
muxers that buffer up data internally (e.g. fragmented mp4).
---
libavformat/segment.c |1 +
1 file changed, 1 insertion(+)
Ok. I wonder
On Thu, 4 Oct 2012, Luca Barbato wrote:
On 10/03/2012 11:37 PM, Martin Storsjö wrote:
With this change, the segmenter muxer doesn't rely on anything
not available/supported to libavformat external users, making
the segmenter muxer do things just like a normal segmenter
application using libavfo
On 10/03/2012 10:56 PM, Anton Khirnov wrote:
> Right now it incorrectly assumes that the frames are sent in the proper
> order, which worked with old ffmpeg and avconv versions by accident.
> ---
> libavfilter/vf_overlay.c | 207
> +-
> 1 file changed,
On 10/03/2012 10:56 PM, Anton Khirnov wrote:
> Output frames correspond 1:1 to input frames on the main input.
> So use the main input timebase for output.
> ---
> libavfilter/vf_overlay.c | 25 -
> 1 file changed, 4 insertions(+), 21 deletions(-)
Ok.
__
On 10/03/2012 11:37 PM, Martin Storsjö wrote:
> This allows writing totally bare segments, without any header/trailer
> included anywhere.
> ---
> libavformat/segment.c | 52
> +
> 1 file changed, 48 insertions(+), 4 deletions(-)
>
Ok. Great pat
On 10/03/2012 11:37 PM, Martin Storsjö wrote:
> This makes sure any buffered data is written to the segment, for
> muxers that buffer up data internally (e.g. fragmented mp4).
> ---
> libavformat/segment.c |1 +
> 1 file changed, 1 insertion(+)
Ok. I wonder if is documented and/or we should m
On 10/03/2012 11:37 PM, Martin Storsjö wrote:
> This makes sure new inline headers are emitted when the next
> packet is written. This allows segmenting mpegts without calling
> write_header/write_trailer (nor freeing/reiniting the muxer)
> for each segment.
> ---
> libavformat/segment.c |3 ++
On 10/03/2012 11:37 PM, Martin Storsjö wrote:
> Some segmented formats (such as fragmented mp4) are "bare", as in,
> the segment files do not have the same headers/trailers as full normal
> files of that format have.
> ---
> libavformat/segment.c | 31 +++
> 1 file ch
On 10/03/2012 11:37 PM, Martin Storsjö wrote:
> This makes sure the muxers are set up in the way they expect
> with no data left around from the previous run (which could
> cause various issues including memory leaks, depending on the chaine
> muxer).
>
> This fixes memory leaks with the mpegts an
On 10/03/2012 11:37 PM, Martin Storsjö wrote:
> With this change, the segmenter muxer doesn't rely on anything
> not available/supported to libavformat external users, making
> the segmenter muxer do things just like a normal segmenter
> application using libavformat would do.
> ---
> libavformat/
On 10/03/2012 11:37 PM, Martin Storsjö wrote:
> Before, the chained muxer reused the AVStreams array from
> the outer muxer, which made it impossible to use the proper
> public functions (such as av_write_frame) when calling the
> chained muxer.
> ---
> libavformat/segment.c | 21 +++
On 10/03/2012 11:37 PM, Martin Storsjö wrote:
> ---
> libavformat/segment.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Ok.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On Wed, Oct 3, 2012 at 2:44 PM, Martin Storsjö wrote:
> From: Michael Niedermayer
>
> ---
> libavformat/h264dec.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/h264dec.c b/libavformat/h264dec.c
> index 8070086..3076b7c 100644
> --- a/libavformat/h264dec.
From: Michael Niedermayer
---
libavformat/h264dec.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/h264dec.c b/libavformat/h264dec.c
index 8070086..3076b7c 100644
--- a/libavformat/h264dec.c
+++ b/libavformat/h264dec.c
@@ -54,7 +54,7 @@ static int h264_probe(A
On Wed, 3 Oct 2012, Justin Ruggles wrote:
This will happen when the extradata is not a valid Speex header.
---
libavcodec/libspeexdec.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libspeexdec.c b/libavcodec/libspeexdec.c
index 760bfe2..0c93f05 10064
This allows writing totally bare segments, without any header/trailer
included anywhere.
---
libavformat/segment.c | 52 +
1 file changed, 48 insertions(+), 4 deletions(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index fb5a22e..1
This makes sure any buffered data is written to the segment, for
muxers that buffer up data internally (e.g. fragmented mp4).
---
libavformat/segment.c |1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index bdb5254..fb5a22e 100644
--- a/libavform
This makes sure new inline headers are emitted when the next
packet is written. This allows segmenting mpegts without calling
write_header/write_trailer (nor freeing/reiniting the muxer)
for each segment.
---
libavformat/segment.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/libavform
Some segmented formats (such as fragmented mp4) are "bare", as in,
the segment files do not have the same headers/trailers as full normal
files of that format have.
---
libavformat/segment.c | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/lib
This makes sure the muxers are set up in the way they expect
with no data left around from the previous run (which could
cause various issues including memory leaks, depending on the chaine
muxer).
This fixes memory leaks with the mpegts and flv muxers. It also
makes the usage of chained muxers co
With this change, the segmenter muxer doesn't rely on anything
not available/supported to libavformat external users, making
the segmenter muxer do things just like a normal segmenter
application using libavformat would do.
---
libavformat/segment.c | 30 +++---
1 file ch
Before, the chained muxer reused the AVStreams array from
the outer muxer, which made it impossible to use the proper
public functions (such as av_write_frame) when calling the
chained muxer.
---
libavformat/segment.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
---
libavformat/segment.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 0c644d4..e6dafe3 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -122,7 +122,7 @@ static int seg_write_header(AVFormatContext *s)
This will happen when the extradata is not a valid Speex header.
---
libavcodec/libspeexdec.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libspeexdec.c b/libavcodec/libspeexdec.c
index 760bfe2..0c93f05 100644
--- a/libavcodec/libspeexdec.c
+++ b/liba
Right now it incorrectly assumes that the frames are sent in the proper
order, which worked with old ffmpeg and avconv versions by accident.
---
libavfilter/vf_overlay.c | 207 +-
1 file changed, 115 insertions(+), 92 deletions(-)
diff --git a/libavfil
Output frames correspond 1:1 to input frames on the main input.
So use the main input timebase for output.
---
libavfilter/vf_overlay.c | 25 -
1 file changed, 4 insertions(+), 21 deletions(-)
diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
index 6dd9be4
On 10/03/2012 10:09 PM, Ronald S. Bultje wrote:
> From: "Ronald S. Bultje"
>
> This patch adds support for .dll shared library generation using MSVC's
> native build tools. To properly load non-function symbols from DLL files,
> we prefix them with __declspec(dllimport) on MSVC for shared library
From: Baptiste Coudurier
Setting the average bitrate to 0 in esds makes the produced files
not compatible with certain players.
Signed-off-by: Luca Barbato
---
libavformat/movenc.c | 21 -
tests/ref/fate/vsynth1-mpeg4 | 2 +-
tests/ref/fate/vsynth2-mpeg4 | 2 +-
t
On 10/03/2012 10:09 PM, Janne Grunau wrote:
> AVFrame.extended_data has to reset to the AVFrame.data of the current
> thread context after copying the frame contents.
> Fixes crashes with frame-threading after 2bc0de38584.
> ---
> libavcodec/mpegvideo.c | 5 +
> 1 file changed, 5 insertions(+)
On 10/03/2012 10:00 PM, Måns Rullgård wrote:
> Luca Barbato writes:
>
>> On 10/03/2012 08:46 PM, Mans Rullgard wrote:
>>> This works with gcc. Other compilers might need to have a flag
>>> mapping added.
>>
>> The other I know about (clang, path64) have some more exotic ways (clang
>> requires t
From: "Ronald S. Bultje"
This patch adds support for .dll shared library generation using MSVC's
native build tools. To properly load non-function symbols from DLL files,
we prefix them with __declspec(dllimport) on MSVC for shared library
builds when accessed from outside the .dll. For optimal p
AVFrame.extended_data has to reset to the AVFrame.data of the current
thread context after copying the frame contents.
Fixes crashes with frame-threading after 2bc0de38584.
---
libavcodec/mpegvideo.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegv
Luca Barbato writes:
> On 10/03/2012 08:46 PM, Mans Rullgard wrote:
>> This works with gcc. Other compilers might need to have a flag
>> mapping added.
>
> The other I know about (clang, path64) have some more exotic ways (clang
> requires to pass around --plugin theirplugin.so to everything cur
On 10/03/2012 08:46 PM, Mans Rullgard wrote:
> This works with gcc. Other compilers might need to have a flag
> mapping added.
The other I know about (clang, path64) have some more exotic ways (clang
requires to pass around --plugin theirplugin.so to everything currently)
lu
___
Luca Barbato writes:
> On 10/03/2012 08:46 PM, Mans Rullgard wrote:
>> -check_cflags -fno-tree-vectorize
>> +check_optflags -fno-tree-vectorize
>
> uhm?
That is necessary to disable the vectoriser during linking.
--
Måns Rullgård
m...@mansr.com
_
Luca Barbato writes:
> On 10/03/2012 08:46 PM, Mans Rullgard wrote:
>> This works with gcc. Other compilers might need to have a flag
>> mapping added.
>>
> which version you tested with lto? 4.7.2 can work?
Some 4.7 seemed to work. 4.8 failed to link.
--
Måns Rullgård
m...@mansr.com
__
On 10/03/2012 08:56 PM, Luca Barbato wrote:
> On 10/03/2012 08:46 PM, Mans Rullgard wrote:
>> -check_cflags -fno-tree-vectorize
>> +check_optflags -fno-tree-vectorize
>
> uhm?
Ignore, I misread =P
___
libav-devel mailing list
libav-devel@libav.
On 10/03/2012 08:46 PM, Mans Rullgard wrote:
> -check_cflags -fno-tree-vectorize
> +check_optflags -fno-tree-vectorize
uhm?
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 10/03/2012 08:46 PM, Mans Rullgard wrote:
> This works with gcc. Other compilers might need to have a flag
> mapping added.
>
which version you tested with lto? 4.7.2 can work?
lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.lib
This works with gcc. Other compilers might need to have a flag
mapping added.
Signed-off-by: Mans Rullgard
---
configure | 38 +++---
1 file changed, 27 insertions(+), 11 deletions(-)
diff --git a/configure b/configure
index 6d68424..12f9872 100755
--- a/configu
Diego Elio Pettenò writes:
> On 03/10/2012 10:05, Luca Barbato wrote:
>> looks a bit wasteful and, as you stated on irc, one value won't fit.
>
> Actually that's two values. 96000 won't fit either.
If you divide them by, say, 16 they all fit.
--
Måns Rullgård
m...@mansr.com
___
On 03/10/2012 10:05, Luca Barbato wrote:
> looks a bit wasteful and, as you stated on irc, one value won't fit.
Actually that's two values. 96000 won't fit either.
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
___
On 10/03/2012 06:48 PM, Christian Schmidt wrote:
> @@ -61,6 +61,9 @@ static int pcm_bluray_parse_header(AVCodecContext *avctx,
> static const uint8_t channels[16] = {
> 0, 1, 0, 2, 3, 3, 4, 4, 5, 6, 7, 8, 0, 0, 0, 0
> };
> +static const uint16_t sample_rates[16] = {
> +
Disregard the patch. 192000 needs uint32_t, and that makes the table too
large.
On 10/03/2012 06:48 PM, Christian Schmidt wrote:
> ---
> libavcodec/pcm-mpeg.c | 21 +++--
> 1 file changed, 7 insertions(+), 14 deletions(-)
___
libav-devel
---
libavcodec/pcm-mpeg.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/libavcodec/pcm-mpeg.c b/libavcodec/pcm-mpeg.c
index 4a38648..cb4af93 100644
--- a/libavcodec/pcm-mpeg.c
+++ b/libavcodec/pcm-mpeg.c
@@ -45,7 +45,7 @@
*/
/**
- * Parse the heade
On Wed, Oct 03, 2012 at 08:41:58AM -0700, Ronald S. Bultje wrote:
> On Wed, Oct 3, 2012 at 8:27 AM, Diego Biurrun wrote:
> > On Wed, Oct 03, 2012 at 07:37:29AM -0700, Ronald S. Bultje wrote:
> >> >> --- a/libavcodec/golomb.h
> >> >> +++ b/libavcodec/golomb.h
> >> >> @@ -33,13 +33,14 @@
> >> >>
> >
Hi,
On Wed, Oct 3, 2012 at 9:07 AM, Diego Biurrun wrote:
> On Wed, Oct 03, 2012 at 08:49:30AM -0700, Ronald S. Bultje wrote:
>> On Wed, Oct 3, 2012 at 8:43 AM, Diego Biurrun wrote:
>> > On Wed, Oct 03, 2012 at 08:31:43AM -0700, Ronald S. Bultje wrote:
>> >> On Wed, Oct 3, 2012 at 7:44 AM, Måns R
On Wed, Oct 03, 2012 at 08:49:30AM -0700, Ronald S. Bultje wrote:
> On Wed, Oct 3, 2012 at 8:43 AM, Diego Biurrun wrote:
> > On Wed, Oct 03, 2012 at 08:31:43AM -0700, Ronald S. Bultje wrote:
> >> On Wed, Oct 3, 2012 at 7:44 AM, Måns Rullgård wrote:
> >> > "Ronald S. Bultje" writes:
> >> >> These
Hi,
On Wed, Oct 3, 2012 at 8:43 AM, Diego Biurrun wrote:
> On Wed, Oct 03, 2012 at 08:31:43AM -0700, Ronald S. Bultje wrote:
>> On Wed, Oct 3, 2012 at 7:44 AM, Måns Rullgård wrote:
>> > "Ronald S. Bultje" writes:
>> >> These AVCODEC_SYMBOL things will be used in public headers, thus the
>> >> d
On Wed, Oct 03, 2012 at 08:31:43AM -0700, Ronald S. Bultje wrote:
> On Wed, Oct 3, 2012 at 7:44 AM, Måns Rullgård wrote:
> > "Ronald S. Bultje" writes:
> >> These AVCODEC_SYMBOL things will be used in public headers, thus the
> >> definition needs t exist in a public header. Since I need to use
>
Hi,
On Wed, Oct 3, 2012 at 8:27 AM, Diego Biurrun wrote:
> On Wed, Oct 03, 2012 at 07:37:29AM -0700, Ronald S. Bultje wrote:
>> >> --- a/libavcodec/golomb.h
>> >> +++ b/libavcodec/golomb.h
>> >> @@ -33,13 +33,14 @@
>> >>
>> >> -extern const uint8_t ff_golomb_vlc_len[512];
>> >> -extern const uint
"Ronald S. Bultje" writes:
> Hi,
>
> On Wed, Oct 3, 2012 at 7:44 AM, Måns Rullgård wrote:
>> "Ronald S. Bultje" writes:
>>> These AVCODEC_SYMBOL things will be used in public headers, thus the
>>> definition needs t exist in a public header. Since I need to use
>>> __declspec(dllimport) only fo
Hi,
On Wed, Oct 3, 2012 at 7:44 AM, Måns Rullgård wrote:
> "Ronald S. Bultje" writes:
>> These AVCODEC_SYMBOL things will be used in public headers, thus the
>> definition needs t exist in a public header. Since I need to use
>> __declspec(dllimport) only for .dll (shared) builds, not for .lib
>
On Wed, Oct 03, 2012 at 07:37:29AM -0700, Ronald S. Bultje wrote:
> On Wed, Oct 3, 2012 at 4:02 AM, Diego Biurrun wrote:
> > On Tue, Oct 02, 2012 at 05:48:26PM -0700, Ronald S. Bultje wrote:
> >> 2) a lot of ff_ symbols, and dsputil_init, are accessed from outside
> >> the library in which they ex
On 03/10/2012 10:44 AM, Måns Rullgård wrote:
>>> What's AV_HAVE_SHARED_LIBS? I'm not aware of it anywhere.
>>> What do you need avconfig.h for?
>>
>> These AVCODEC_SYMBOL things will be used in public headers, thus the
>> definition needs t exist in a public header. Since I need to use
>> __declsp
On 10/03/2012 04:37 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Wed, Oct 3, 2012 at 4:02 AM, Diego Biurrun wrote:
>> On Tue, Oct 02, 2012 at 05:48:26PM -0700, Ronald S. Bultje wrote:
>>> 2) a lot of ff_ symbols, and dsputil_init, are accessed from outside
>>> the library in which they exist. These a
"Ronald S. Bultje" writes:
> Hi,
>
> On Wed, Oct 3, 2012 at 4:02 AM, Diego Biurrun wrote:
>> On Tue, Oct 02, 2012 at 05:48:26PM -0700, Ronald S. Bultje wrote:
>>> 2) a lot of ff_ symbols, and dsputil_init, are accessed from outside
>>> the library in which they exist. These are bugs and should b
On 10/01/2012 04:02 PM, Martin Storsjö wrote:
> From: Dmitry Samonenko
>
> Speex detects non-speech periods and encodes them with just enough bits
> to reproduce the background noise, aka ``comfort noise generation''.
> ---
> libavcodec/libspeexenc.c |8
> 1 file changed, 8 insertio
Hi,
On Wed, Oct 3, 2012 at 4:02 AM, Diego Biurrun wrote:
> On Tue, Oct 02, 2012 at 05:48:26PM -0700, Ronald S. Bultje wrote:
>> 2) a lot of ff_ symbols, and dsputil_init, are accessed from outside
>> the library in which they exist. These are bugs and should be fixed (i.e.
>> renamed).
>
> You se
On 03/10/2012 07:21, Diego Biurrun wrote:
> avconv.c |2 +-
> avprobe.c |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
LGTM, and thanks for catching it.
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
_
---
avconv.c |2 +-
avprobe.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/avconv.c b/avconv.c
index 2e42065..9aaa4a8 100644
--- a/avconv.c
+++ b/avconv.c
@@ -143,7 +143,7 @@ static int decode_interrupt_cb(void *ctx)
const AVIOInterruptCB int_cb = { decode_inte
The whole set seems fine to me.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On Mon, Oct 01, 2012 at 11:22:37PM +0200, Diego Elio Pettenò wrote:
> --- a/avconv.c
> +++ b/avconv.c
> @@ -143,7 +143,7 @@ static int decode_interrupt_cb(void *ctx)
>
> -void exit_program(int ret)
> +static void exit_program()
> --- a/avprobe.c
> +++ b/avprobe.c
> @@ -59,10 +59,9 @@ static cons
---
libavcodec/libspeexdec.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/libavcodec/libspeexdec.c b/libavcodec/libspeexdec.c
index 1916fea..760bfe2 100644
--- a/libavcodec/libspeexdec.c
+++ b/libavcodec/libspeexdec.c
@@ -119,10 +119,12 @@ static int libspeex_d
---
libavcodec/libspeexdec.c | 14 ++
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/libavcodec/libspeexdec.c b/libavcodec/libspeexdec.c
index d118093..1916fea 100644
--- a/libavcodec/libspeexdec.c
+++ b/libavcodec/libspeexdec.c
@@ -32,7 +32,6 @@ typedef struct {
---
libavcodec/libspeexdec.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/libavcodec/libspeexdec.c b/libavcodec/libspeexdec.c
index 21c9d05..d118093 100644
--- a/libavcodec/libspeexdec.c
+++ b/libavcodec/libspeexdec.c
@@ -49,7 +49,6 @@ static av_cold int libspeex_d
---
libavcodec/libspeexdec.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/libavcodec/libspeexdec.c b/libavcodec/libspeexdec.c
index b9d9149..21c9d05 100644
--- a/libavcodec/libspeexdec.c
+++ b/libavcodec/libspeexdec.c
@@ -22,8 +22,10 @@
#include
#include
#incl
When initialized as stereo, libspeex can decode either mono or stereo packets
and will output stereo.
---
libavcodec/libspeexdec.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavcodec/libspeexdec.c b/libavcodec/libspeexdec.c
index 390d4de..b9d9149 100644
--- a
If there is no extradata and the sample rate given by the user is not valid,
decode as ultra-wideband.
---
libavcodec/libspeexdec.c | 37 +
1 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/libavcodec/libspeexdec.c b/libavcodec/libspeexdec.c
ind
On 10/03/2012 03:13 PM, Martin Storsjö wrote:
Seems ok to me.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On Wed, 3 Oct 2012, Måns Rullgård wrote:
Martin Storsjö writes:
On Wed, 3 Oct 2012, Måns Rullgård wrote:
Martin Storsjö writes:
From: Michael Niedermayer
This is not true.
It's a touched up version of a patch by him and I don't mind keeping
that authorship.
I call it a rewrite.
Martin Storsjö writes:
> On Wed, 3 Oct 2012, Måns Rullgård wrote:
>
>> Martin Storsjö writes:
>>
>>> From: Michael Niedermayer
>>
>> This is not true.
>
> It's a touched up version of a patch by him and I don't mind keeping
> that authorship.
I call it a rewrite.
--
Måns Rullgård
m...@mansr.
On Wed, 3 Oct 2012, Måns Rullgård wrote:
Martin Storsjö writes:
From: Michael Niedermayer
This is not true.
It's a touched up version of a patch by him and I don't mind keeping that
authorship.
// Martin___
libav-devel mailing list
libav-dev
Martin Storsjö writes:
> From: Michael Niedermayer
This is not true.
> ---
> libavutil/xtea.c | 32 +---
> 1 file changed, 21 insertions(+), 11 deletions(-)
>
> diff --git a/libavutil/xtea.c b/libavutil/xtea.c
> index 7c3a14c..11ae266 100644
> --- a/libavutil/xte
From: Michael Niedermayer
Based on test code by: Giorgio Vazzana
---
libavutil/xtea.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/libavutil/xtea.c b/libavutil/xtea.c
index cf63670..f3357ce 100644
--- a/libavutil/xtea.c
+++ b/libavutil/xtea.c
@@ -160,14
From: Michael Niedermayer
---
libavutil/xtea.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/libavutil/xtea.c b/libavutil/xtea.c
index 11ae266..cf63670 100644
--- a/libavutil/xtea.c
+++ b/libavutil/xtea.c
@@ -36,7 +36,7 @@ void av_xtea_init(AVXTEA *ct
From: Michael Niedermayer
---
libavutil/xtea.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/libavutil/xtea.c b/libavutil/xtea.c
index 7c3a14c..11ae266 100644
--- a/libavutil/xtea.c
+++ b/libavutil/xtea.c
@@ -139,6 +139,25 @@ static cons
On Wed, 5 Sep 2012, Diego Biurrun wrote:
---
configure | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/configure b/configure
index f870b14..9398415 100755
--- a/configure
+++ b/configure
@@ -1101,6 +1101,12 @@ ARCH_EXT_LIST="
vis
"
+HAVE_LIST_CMDLINE='
+
On Tue, 2 Oct 2012, Martin Storsjö wrote:
On Tue, 2 Oct 2012, Martin Storsjö wrote:
---
libavutil/blowfish.c |4
1 file changed, 4 insertions(+)
diff --git a/libavutil/blowfish.c b/libavutil/blowfish.c
index 7a571a8..1258e09 100644
--- a/libavutil/blowfish.c
+++ b/libavutil/blowfish.c
On Tue, Oct 02, 2012 at 11:26:53PM +0200, Luca Barbato wrote:
> I had a look at doxygen and I managed to get a first change, it needs
> some cleanup but we got it there =P
>
> http://i.imgur.com/Ap7T0.png
> http://i.imgur.com/i2wTz.png
> http://i.imgur.com/ncimi.png
> http://i.imgur.com/Qxs91.png
On Tue, Oct 02, 2012 at 05:48:26PM -0700, Ronald S. Bultje wrote:
> 2) a lot of ff_ symbols, and dsputil_init, are accessed from outside
> the library in which they exist. These are bugs and should be fixed (i.e.
> renamed).
You seem to be working on the wrong tree.
> --- a/configure
> +++ b/conf
Anton Khirnov writes:
> On Tue, 2 Oct 2012 22:32:41 -0700, "Ronald S. Bultje"
> wrote:
>> Hi,
>>
>> On Tue, Oct 2, 2012 at 7:07 PM, Luca Barbato wrote:
>> > On 10/03/2012 03:47 AM, Diego Elio Pettenò wrote:
>> >> On 02/10/2012 18:40, Luca Barbato wrote:
>> >>>
>> >>> The patch was rejected si
On Tue, 2 Oct 2012 22:32:41 -0700, "Ronald S. Bultje"
wrote:
> Hi,
>
> On Tue, Oct 2, 2012 at 7:07 PM, Luca Barbato wrote:
> > On 10/03/2012 03:47 AM, Diego Elio Pettenò wrote:
> >> On 02/10/2012 18:40, Luca Barbato wrote:
> >>>
> >>> The patch was rejected since it was _really_ invasive and a
On 10/3/12 7:32 AM, Ronald S. Bultje wrote:
Hi,
On Tue, Oct 2, 2012 at 7:07 PM, Luca Barbato wrote:
On 10/03/2012 03:47 AM, Diego Elio Pettenò wrote:
On 02/10/2012 18:40, Luca Barbato wrote:
The patch was rejected since it was _really_ invasive and after lots of
back and forth we ended up w
100 matches
Mail list logo
