On 15 July 2011 23:48, Diego Biurrun wrote:
> Somebody please doublecheck that I was not overeager with the unused
> functions in those *celp*.c files, possibly they were intended to
> fulfill some sort of purpose at some future point in time.
Have you spoken to Vladimir Voroshilov about this? Ma
mingw-w64 64-bit gcc complains on every file:
warning: -fPIC ignored for target (all code is position independent)
so filter out -fPIC for 64-bit MinGW targets
-- Daniel Verkamp
0001-mingw-w64-Silence-worthless-fPIC-warning.patch
Description: Binary data
___
On Mon, Jul 18, 2011 at 10:49:42PM +0100, Mans Rullgard wrote:
> ---
> The idct selection in dsputil needs more work, but this is enough to
> test it out with the 10-bit DNxHD patch.
>
> The accuracy of this is very slightly worse than the 8-bit version.
> ---
> libavcodec/dsputil.c
On Mon, Jul 18, 2011 at 05:50:49PM -0700, Alex Converse wrote:
> ---
> libavcodec/dsputil.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libavcodec/dsputil.c b/libavcodec/dsputil.c
> index f24985c..bb201ea 100644
> --- a/libavcodec/dsputil.c
> +++ b/libavcodec/ds
On Mon, Jul 18, 2011 at 05:50:50PM -0700, Alex Converse wrote:
> ---
> libavcodec/dsputil.c |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/libavcodec/dsputil.c b/libavcodec/dsputil.c
> index bb201ea..0a30e28 100644
> --- a/libavcodec/dsputil.c
> +++ b/libavcodec/dsp
On Sat, 2011-07-16 at 23:35 +0100, Mans Rullgard wrote:
> int ff_check_alignment(void){
> static int did_fail=0;
> -DECLARE_ALIGNED(16, int, aligned);
> +LOCAL_ALIGNED_16(int, aligned);
>
> if((intptr_t)&aligned & 15){
The test below doesn't work with LOCAL_ALIGNED. If "aligne
---
libavcodec/dsputil.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/libavcodec/dsputil.c b/libavcodec/dsputil.c
index bb201ea..0a30e28 100644
--- a/libavcodec/dsputil.c
+++ b/libavcodec/dsputil.c
@@ -3280,4 +3280,3 @@ av_cold void dsputil_init(DSPContext* c, AVCodecCo
---
libavcodec/dsputil.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavcodec/dsputil.c b/libavcodec/dsputil.c
index f24985c..bb201ea 100644
--- a/libavcodec/dsputil.c
+++ b/libavcodec/dsputil.c
@@ -185,7 +185,7 @@ static int pix_norm1_c(uint8_t * pix, int line_size
Joseph Artsimovich writes:
> On 18/07/2011 15:45, Måns Rullgård wrote:
>> Maxim writes:
>>
>>> Am 18.07.2011 16:09, schrieb Måns Rullgård:
[...]
> An integer implementation is surely much faster than floating-point
> one but it's still insufficient for realtime applications
>>>
---
The idct selection in dsputil needs more work, but this is enough to
test it out with the 10-bit DNxHD patch.
The accuracy of this is very slightly worse than the 8-bit version.
---
libavcodec/dsputil.c | 14 +-
libavcodec/simple_idct.c | 338 +
On Mon, Jul 18, 2011 at 06:46:17PM +0100, Mans Rullgard wrote:
> Signed-off-by: Mans Rullgard
> ---
> libavcodec/simple_idct.c | 24 ++--
> 1 files changed, 6 insertions(+), 18 deletions(-)
looks ok
___
libav-devel mailing list
li
On Mon, Jul 18, 2011 at 06:46:16PM +0100, Mans Rullgard wrote:
> DCTELEM can never be changed to anything else, too much code
> depends on it.
>
> Signed-off-by: Mans Rullgard
> ---
> libavcodec/simple_idct.c | 45 +++--
> 1 files changed, 15 insertions(
---
libavcodec/h263dec.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index 6eea8de..feeca74 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -638,7 +638,7 @@ retry:
s->mb_x=0;
s->mb_y=0;
-dec
Hi,
On Sun, Jul 17, 2011 at 4:43 AM, Diego Biurrun wrote:
> @@ -3457,52 +3389,6 @@ static int decode_slice(struct AVCodecContext *avctx,
> void *arg){
> }
> }
> }
> -
> -#if 0
> - for(;s->mb_y < s->mb_height; s->mb_y++){
> - for(;s->mb_x < s->mb_width; s->mb_x++
Am 18.07.2011 18:11, schrieb Måns Rullgård:
> "Ronald S. Bultje" writes:
>
>
>> Hi,
>>
>> On Mon, Jul 18, 2011 at 8:33 AM, Joseph Artsimovich
>> wrote:
>>
>>> On 18/07/2011 16:29, Kostya wrote:
>>>
On Mon, Jul 18, 2011 at 04:20:14PM +0100, Joseph Artsimovich wrote:
DCTELEM can never be changed to anything else, too much code
depends on it.
Signed-off-by: Mans Rullgard
---
libavcodec/simple_idct.c | 45 +++--
1 files changed, 15 insertions(+), 30 deletions(-)
diff --git a/libavcodec/simple_idct.c b/libavcodec/simpl
Signed-off-by: Mans Rullgard
---
libavcodec/simple_idct.c | 24 ++--
1 files changed, 6 insertions(+), 18 deletions(-)
diff --git a/libavcodec/simple_idct.c b/libavcodec/simple_idct.c
index c82f092..0ffbfca 100644
--- a/libavcodec/simple_idct.c
+++ b/libavcodec/simple_idct.
On Sun, Jul 17, 2011 at 07:57:55PM +0100, Mans Rullgard wrote:
> Signed-off-by: Mans Rullgard
> ---
> tests/Makefile |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
OK
Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lis
On Sun, Jul 17, 2011 at 02:50:44PM -0700, Ronald S. Bultje wrote:
>
> On Sun, Jul 17, 2011 at 4:43 AM, Diego Biurrun wrote:
> > --- a/libavformat/rtspdec.c
> > +++ b/libavformat/rtspdec.c
> > @@ -383,12 +383,6 @@ static int rtsp_read_close(AVFormatContext *s)
> > {
> > RTSPState *rt = s->pri
"Ronald S. Bultje" writes:
> Hi,
>
> On Mon, Jul 18, 2011 at 8:33 AM, Joseph Artsimovich
> wrote:
>> On 18/07/2011 16:29, Kostya wrote:
>>> On Mon, Jul 18, 2011 at 04:20:14PM +0100, Joseph Artsimovich wrote:
On 18/07/2011 16:01, Kostya wrote:
> On Mon, Jul 18, 2011 at 03:56:42PM +0100,
Hi,
On Mon, Jul 18, 2011 at 8:59 AM, Diego Biurrun wrote:
> On Mon, Jul 18, 2011 at 08:52:58AM -0700, Ronald S. Bultje wrote:
>> On Mon, Jul 18, 2011 at 2:52 AM, Diego Biurrun wrote:
>> > -#if 0
>> > - s += sq[pix[0]];
>> > - s += sq[pix[1]];
>> > - s += sq[pix[2
Hi,
On Mon, Jul 18, 2011 at 8:33 AM, Joseph Artsimovich wrote:
> On 18/07/2011 16:29, Kostya wrote:
>> On Mon, Jul 18, 2011 at 04:20:14PM +0100, Joseph Artsimovich wrote:
>>> On 18/07/2011 16:01, Kostya wrote:
On Mon, Jul 18, 2011 at 03:56:42PM +0100, Joseph Artsimovich wrote:
> On 18/07
Hi,
On Mon, Jul 18, 2011 at 5:03 AM, Kostya wrote:
> On Mon, Jul 18, 2011 at 12:53:46PM +0100, Joseph Artsimovich wrote:
>> On 18/07/2011 12:06, Kostya wrote:
>> >On Mon, Jul 18, 2011 at 11:54:31AM +0100, Joseph Artsimovich wrote:
>> >>Here is the latest version of my patch set, made against toda
On Mon, Jul 18, 2011 at 08:52:58AM -0700, Ronald S. Bultje wrote:
>
> On Mon, Jul 18, 2011 at 2:52 AM, Diego Biurrun wrote:
> > -#if 0
> > - s += sq[pix[0]];
> > - s += sq[pix[1]];
> > - s += sq[pix[2]];
> > - s += sq[pix[3]];
> > - s += sq[p
Hi,
On Mon, Jul 18, 2011 at 2:52 AM, Diego Biurrun wrote:
> -#if 0
> - s += sq[pix[0]];
> - s += sq[pix[1]];
> - s += sq[pix[2]];
> - s += sq[pix[3]];
> - s += sq[pix[4]];
> - s += sq[pix[5]];
> - s += sq[pix[6]];
> -
On 18/07/2011 16:29, Kostya wrote:
On Mon, Jul 18, 2011 at 04:20:14PM +0100, Joseph Artsimovich wrote:
On 18/07/2011 16:01, Kostya wrote:
On Mon, Jul 18, 2011 at 03:56:42PM +0100, Joseph Artsimovich wrote:
On 18/07/2011 15:45, Måns Rullgård wrote:
Maximwrites:
Am 18.07.2011 16:09, schri
On Mon, Jul 18, 2011 at 04:20:14PM +0100, Joseph Artsimovich wrote:
> On 18/07/2011 16:01, Kostya wrote:
> >On Mon, Jul 18, 2011 at 03:56:42PM +0100, Joseph Artsimovich wrote:
> >>On 18/07/2011 15:45, Måns Rullgård wrote:
> >>>Maxim writes:
> >>>
> Am 18.07.2011 16:09, schrieb Måns Rullgård:
On 18/07/2011 16:01, Kostya wrote:
On Mon, Jul 18, 2011 at 03:56:42PM +0100, Joseph Artsimovich wrote:
On 18/07/2011 15:45, Måns Rullgård wrote:
Maxim writes:
Am 18.07.2011 16:09, schrieb Måns Rullgård:
[...]
An integer implementation is surely much faster than floating-point
one but it'
On Mon, Jul 18, 2011 at 03:56:42PM +0100, Joseph Artsimovich wrote:
> On 18/07/2011 15:45, Måns Rullgård wrote:
> >Maxim writes:
> >
> >>Am 18.07.2011 16:09, schrieb Måns Rullgård:
> >>>[...]
> >>>
> An integer implementation is surely much faster than floating-point
> one but it's still i
On 18/07/2011 15:45, Måns Rullgård wrote:
Maxim writes:
Am 18.07.2011 16:09, schrieb Måns Rullgård:
[...]
An integer implementation is surely much faster than floating-point
one but it's still insufficient for realtime applications
The point?
You'll be able to obtain reasonable performa
Maxim writes:
> Am 18.07.2011 16:09, schrieb Måns Rullgård:
>> [...]
>>
>>> An integer implementation is surely much faster than floating-point
>>> one but it's still insufficient for realtime applications
>>>
>> The point?
>>
>
> You'll be able to obtain reasonable performance benefit
Am 18.07.2011 16:09, schrieb Måns Rullgård:
> [...]
>
>> An integer implementation is surely much faster than floating-point
>> one but it's still insufficient for realtime applications
>>
> The point?
>
You'll be able to obtain reasonable performance benefits only by using
SIMD-optimiz
Ronald,
> You can't remove it, that's an ABI break. What's better is to add a
> warning if it's set and tell users that it does nothing.
>
> It's already deprecated and under a version check, so it'll be removed
> on the next ABI bump.
>
> Ronald
Ok, I thought that might be the case. I'll just le
Maxim writes:
> Am 18.07.2011 14:10, schrieb Måns Rullgård:
>> [...]
>> Why are you using the incredibly slow floating-point dct anyway? It
>> can't be that hard to extend one of the integer ones to 10-bit. It
>> shouldn't take more than updating the coefficients and some shift
>> values.
>>
On Mon, Jul 18, 2011 at 03:45:30PM +0200, Maxim wrote:
>
> I was able to update the existing Altivec code (ppc/idct_altivec.c) to
> support 10bit and would submit a patch if someone cares. Unfortunately I
> don't have any solution for x86 etc.
There's never a reason not to submit such a patch - g
On Mon, Jul 18, 2011 at 11:54:31AM +0100, Joseph Artsimovich wrote:
> Here is the latest version of my patch set, made against today's Git.
>
> --- a/libavcodec/dnxhddec.c
> +++ b/libavcodec/dnxhddec.c
> @@ -43,20 +47,33 @@ typedef struct {
>
> +static void dnxhd_8bit_idct_put(DNXHDContext* ctx,
On Mon, 18 Jul 2011 12:42:42 +0200, Diego Biurrun wrote:
> On Sun, Jul 17, 2011 at 06:46:34PM +0200, Stefano Sabatini wrote:
> >
> > --- a/cmdutils.h
> > +++ b/cmdutils.h
> > @@ -150,6 +150,12 @@ void parse_options(int argc, char **argv, const
> > OptionDef *options,
> >
> > /**
> > * Filt
Am 18.07.2011 14:10, schrieb Måns Rullgård:
> [...]
> Why are you using the incredibly slow floating-point dct anyway? It
> can't be that hard to extend one of the integer ones to 10-bit. It
> shouldn't take more than updating the coefficients and some shift
> values.
>
Unfortunately such a t
On Mon, 18 Jul 2011 12:47:25 +0200, Diego Biurrun wrote:
> On Sun, Jul 17, 2011 at 06:47:54PM +0200, Stefano Sabatini wrote:
> >
> > --- a/cmdutils.h
> > +++ b/cmdutils.h
> > @@ -159,8 +159,16 @@ void parse_options(int argc, char **argv, const
> > OptionDef *options,
> >
> > +/**
> > + * Setu
Joseph Artsimovich writes:
> Here is the latest version of my patch set, made against today's Git.
>
> I think I addressed all raised issues, except I decided not to mess
> with dsputil.c, at least until we actually have some
> assembly-accelerated routines for 10-bit DNxHD.
It would be much cle
On Mon, Jul 18, 2011 at 12:53:46PM +0100, Joseph Artsimovich wrote:
> On 18/07/2011 12:06, Kostya wrote:
> >On Mon, Jul 18, 2011 at 11:54:31AM +0100, Joseph Artsimovich wrote:
> >>Here is the latest version of my patch set, made against today's Git.
> >>
> >>I think I addressed all raised issues, e
On 18/07/2011 12:06, Kostya wrote:
On Mon, Jul 18, 2011 at 11:54:31AM +0100, Joseph Artsimovich wrote:
Here is the latest version of my patch set, made against today's Git.
I think I addressed all raised issues, except I decided not to mess
with dsputil.c, at least until we actually have some
a
---
libavcodec/x86/h264_intrapred.asm |5 +-
libavcodec/x86/h264_intrapred_10bit.asm | 968 +++
libavcodec/x86/h264_intrapred_init.c| 23 +-
3 files changed, 365 insertions(+), 631 deletions(-)
diff --git a/libavcodec/x86/h264_intrapred.asm
b/libavcod
On Mon, Jul 18, 2011 at 11:54:31AM +0100, Joseph Artsimovich wrote:
> Here is the latest version of my patch set, made against today's Git.
>
> I think I addressed all raised issues, except I decided not to mess
> with dsputil.c, at least until we actually have some
> assembly-accelerated routines
On Mon, Jul 18, 2011 at 11:46:50AM +0100, Mans Rullgard wrote:
> ---
> Instead of increasing MAX_LP_HALF_ORDER, another constant could be
> used, but I thought that might get confusing.
> ---
> libavcodec/lsp.c |4 ++--
> libavcodec/lsp.h |2 +-
> 2 files changed, 3 insertions(+), 3 deleti
On Sun, Jul 17, 2011 at 06:47:54PM +0200, Stefano Sabatini wrote:
>
> --- a/cmdutils.h
> +++ b/cmdutils.h
> @@ -159,8 +159,16 @@ void parse_options(int argc, char **argv, const
> OptionDef *options,
>
> +/**
> + * Setup AVCodecContext options for avformat_find_stream_info().
> + *
> + * Create
---
Instead of increasing MAX_LP_HALF_ORDER, another constant could be
used, but I thought that might get confusing.
---
libavcodec/lsp.c |4 ++--
libavcodec/lsp.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/lsp.c b/libavcodec/lsp.c
index 26b3584..1b4af
On Sun, Jul 17, 2011 at 06:46:34PM +0200, Stefano Sabatini wrote:
>
> --- a/cmdutils.h
> +++ b/cmdutils.h
> @@ -150,6 +150,12 @@ void parse_options(int argc, char **argv, const
> OptionDef *options,
>
> /**
> * Filter out options for given codec.
the/a given codec
> + *
> + * Create a new
On Sun, 17 Jul 2011, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Jul 17, 2011 at 4:43 AM, Diego Biurrun wrote:
> > diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> > index 848ff31..6d1bef5 100644
> > --- a/libavformat/rtsp.c
> > +++ b/libavformat/rtsp.c
> > @@ -1114,17 +1114,9 @@ int ff_rtsp
Diego Biurrun writes:
> From: Stefano Sabatini
>
> The latter works with version 2.2+ and older versions, the former does not.
It's a bit unclear which versions what breaks with.
> Signed-off-by: Diego Biurrun
> ---
> libavfilter/vf_libopencv.c |2 +-
> 1 files changed, 1 insertions(+),
From: Stefano Sabatini
The latter works with version 2.2+ and older versions, the former does not.
Signed-off-by: Diego Biurrun
---
libavfilter/vf_libopencv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavfilter/vf_libopencv.c b/libavfilter/vf_libopencv.c
index
"Ronald S. Bultje" writes:
>if(s->out_format != FMT_H264 || s->codec_id == CODEC_ID_SVQ3){
> + if (s->last_picture_ptr->owner2 == s)
>free_frame_buffer(s, s->last_picture_ptr);
Please reindent that free_frame_buffer() line in the same commit.
Splitting such things is
52 matches
Mail list logo
