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..bb221
It looks like #include 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
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 port
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" wrote:
> On Thu, Feb 26, 2015 at 03:23:40PM -0600, Cary Tetrick wrote:
> > Use this instead. (sorry, correc
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 wrote:
>
> > This adds another option to a change authored by Brian Brice <
> > bbr...@gmail.com> 2015-01-19
> > "librtmp
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
On 26.02.2015, at 23:46, Hendrik Leppkes wrote:
> On Thu, Feb 26, 2015 at 11:21 PM, Reimar Döffinger
> 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.
>
>
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 =
On Thu, Feb 26, 2015 at 11:21 PM, Reimar Döffinger
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
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
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 c
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
Date: 2014-04-29 15:06:45 +0200
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
On Wed, Feb 25, 2015 at 02:55:58PM +, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi | 34 ++
> libavfilter/Makefile | 2 +
> libavfilter/allfilters.c | 2 +
> libavfilter/vf_neighbor.c | 289
> ++
Use this instead. (sorry, corrected grammatical errors.)
On Thu, Feb 26, 2015 at 1:22 PM, Cary Tetrick 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 chang
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 pat
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
Date: 2014-04-29 15:06:45 +0200
lavc: add an option to enable side data-only
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 chan
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
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.
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
Hi,
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.
Best regards,
Andreas
>From 6990ac1deb197613bfaffca1d721e94042c68b04 Mon Sep 17 00:0
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 a
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 ma
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 d
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. De
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 b
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 th
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 mail
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
> ---
> libavformat/movenc.c | 29 +++--
> 1 file changed, 23 insertions(+), 6 dele
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 t
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
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, mi
Am 09.02.15 um 21:55 schrieb Carl Eugen Hoyos:
> Thilo Borgmann 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?
>>>
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-dev
James Cowgill cowgill.org.uk> writes:
> ARCH_EXT_LIST_MIPS="
> mipsfpu
> -mips32r2
This breaks some compilation scripts, consider
leaving a dummy options.
In any case, add a line to the Changelog.
Thank you, Carl Eugen
___
ffmpeg-devel mai
Carl Eugen Hoyos ag.or.at> writes:
> -s->bpp = av_get_bits_per_pixel(pixdesc) >> 3;
> +s->bpp = pixdesc->flags & AV_PIX_FMT_FLAG_PLANAR ?
> + 1 :
> + av_get_bits_per_pixel(pixdesc) >> 3;
This was merged by Michael.
Thank you for the reviews, Carl Eugen
_
Carl Eugen Hoyos ag.or.at> writes:
> -if (pkt->size < 5 || AV_RB32(pkt->data) != 0x001) {
> +if (pkt->size < 5 || AV_RB32(pkt->data) != 0x001
> && AV_RB24(pkt->data) != 0x01) {
This was merged by Michael, it also fixed ticket #2220.
Thank you, Carl Eugen
__
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: Jame
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 com
Carl Eugen Hoyos 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
Carl Eugen Hoyos ag.or.at> writes:
> -If both duration and nb_frames are specified,
> duration is used. Default is 0.
> +If both duration and nb_frames are specified,
> duration is used. Default is 0
> +(nb_frames is used by default).
I will push this change if nobody objects.
Carl Eugen
___
On 2/26/2015 4:16 PM, Clément Bœsch wrote:
>>
>> No ABI constraints.
>>
That's really only better for adding options, which you could do anyway
with a struct (add them to the end of the struct, and require use of
mystruct_alloc()).
- Derek
___
ffmpeg-d
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-dev
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 l
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
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 t
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.
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 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 w
On Thu, Feb 26, 2015 at 4:54 PM, 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 i
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 i
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 be
On Wed, Feb 25, 2015 at 10:31:09PM -0800, Chris Kennedy wrote:
> I forgot the copy of the original buffer, oddly if I copy it then causes
> things to crash at the end when the codec is freed, only for certain .avi
> mpeg4 and in the mpeg4 codec where it frees some data there. I am digging
> in to
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 syst
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 ge
On Thu, Feb 26, 2015 at 01:42:47PM +, James Cowgill wrote:
> The float_copy and fmul_and_reverse functions are refactored out from the
> multiple copies in this file.
>
> Signed-off-by: James Cowgill
> ---
> libavcodec/mips/aacdec_mips.c | 612
> --
>
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
> ---
> libavcodec/mips/sbrdsp_mips.c | 34 --
> 1 file changed, 34 delet
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
> ---
> libavcodec/mips/aacpsdsp_mips.c | 6 +++---
> 1 file changed, 3 insertio
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
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BA
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
> ---
> libavcodec
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(-)
> >>09f8c8250ce5ec1bdad79a1bf280028c9d3
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 ac
On Sun, Feb 22, 2015 at 7:26 AM, Clément Bœsch 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
> >
> [...]
>
Hi!
I believe attached patch fixes ticket #3268 in some cases.
Please comment, Carl Eugen
diff --git a/libavformat/http.c b/libavformat/http.c
index 55dcb6e..b617800 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -312,9 +312,16 @@ static int http_open(URLContext *h, const char *uri,
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 impleme
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
---
libavcodec/mips/acelp_filters_mips.c | 2 +-
1 file changed
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
cha
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
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
> ---
> libavformat/movenc.c | 29 +++--
> 1 file changed, 23 insertions(+), 6 dele
The float_copy and fmul_and_reverse functions are refactored out from the
multiple copies in this file.
Signed-off-by: James Cowgill
---
libavcodec/mips/aacdec_mips.c | 612 --
1 file changed, 111 insertions(+), 501 deletions(-)
diff --git a/libavcodec/mi
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 av
This is obviously needed for 64-bit support.
Signed-off-by: James Cowgill
---
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/m
This also restricts it to MOV and MP4, since it is only
defined for those formats.
Signed-off-by: Derek Buitenhuis
---
libavformat/movenc.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 210f78e
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
unrol
The optimized C version of this code actually runs faster than this
version, so remove it.
Signed-off-by: James Cowgill
---
libavcodec/mips/sbrdsp_mips.c | 34 --
1 file changed, 34 deletions(-)
diff --git a/libavcodec/mips/sbrdsp_mips.c b/libavcodec/mips/sbrdsp_
Remove some assembly that the compiler can easily handle optimally on its own.
GCC produces almost identical assembly.
Signed-off-by: James Cowgill
---
libavcodec/mips/fft_mips.c | 26 ++
1 file changed, 2 insertions(+), 24 deletions(-)
diff --git a/libavcodec/mips/fft_m
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
---
libavcodec/mips/aacpsdsp_mips.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mips/aacpsdsp_mips.c b/libavco
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
---
libavcodec/mips/aacdec_mips.h | 49
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
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 regist
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
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
---
libavcodec/mips/mathops.h | 26 --
1 file changed, 26 deletions
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
> p
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
> >
> > This makes the sorting of the colors along an axis (r, g or b)
> > predictible, and thus testable under FATE. The performance is no
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);
> >
>
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
Fr
On Thu, Feb 26, 2015 at 01:27:34AM +0100, Andreas Cadhalpun wrote:
> On 26.02.2015 00:24, Michael Niedermayer wrote:
> >On Wed, Feb 25, 2015 at 11:48:33PM +0100, Andreas Cadhalpun wrote:
> >>Hi,
> >>
> >>if avctx->channels is 0 in adx_read_packet, size gets set to 0,
> >>av_get_packet sets pkt->dat
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
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 equ
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 validate
Am 24.02.15 um 11:32 schrieb Carl Eugen Hoyos:
> Thilo Borgmann 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 pat
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
Date: Tue, 24 Feb 2015 12:17:30 +0530
Subject: [PATCH] Port FFT domain filter.
---
libavfilter/Makefile |1 +
libavfi
92 matches
Mail list logo
