On Mon, Jul 23, 2012 at 12:47:06AM -0400, Derek Buitenhuis wrote:
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.
Then that message should be reworded, maybe change
On Mon, Jul 23, 2012 at 12:47:06AM -0400, Derek Buitenhuis wrote:
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.
Do such files exist?
Diego
On Mon, Jul 23, 2012 at 01:35:06AM +0100, Måns Rullgård 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 using
On Mon, Jul 23, 2012 at 10:17:02AM +0200, Diego Biurrun wrote:
On Mon, Jul 23, 2012 at 12:47:06AM -0400, Derek Buitenhuis wrote:
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
On Sun, Jul 22, 2012 at 08:46:10PM -0700, Ronald S. Bultje wrote:
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
Ronald S. Bultje rsbul...@gmail.com writes:
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
On Sun, Jul 22, 2012 at 02:04:10AM +0200, Luca Barbato wrote:
On 07/22/2012 12:17 AM, Diego Biurrun wrote:
All other GPLed internal components that are not glue code for external
libraries are not special-cased either.
---
configure | 12
1 files changed, 4
Diego Biurrun di...@biurrun.de writes:
On Sun, Jul 22, 2012 at 02:04:10AM +0200, Luca Barbato wrote:
On 07/22/2012 12:17 AM, Diego Biurrun wrote:
All other GPLed internal components that are not glue code for external
libraries are not special-cased either.
---
configure | 12
On Mon, Jul 23, 2012 at 10:45:46AM +0100, Måns Rullgård wrote:
Diego Biurrun di...@biurrun.de writes:
On Sun, Jul 22, 2012 at 02:04:10AM +0200, Luca Barbato wrote:
On 07/22/2012 12:17 AM, Diego Biurrun wrote:
All other GPLed internal components that are not glue code for external
On 07/23/2012 06:47 AM, Derek Buitenhuis wrote:
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.
Mind adding support for explode mode?
We have people that would
On 07/22/2012 03:11 PM, Diego Biurrun wrote:
---
These are baseline suggestions for things that everybody should have.
Further ideas for things to add more than welcome.
Looks good.
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
___
On Tue, 17 Jul 2012, Adriano Pallavicino wrote:
---
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
From: Adriano Pallavicino adrianopallavic...@gmail.com
If using a different sample rate or number of channels, use a dynamic
payload type instead, where the parameters are passed in the SDP.
G722 is a special case where the normal rules don't apply.
---
libavformat/rtp.c | 14 +++---
On Fri, 20 Jul 2012, Samuel Pitoiset wrote:
---
Changelog| 1 +
configure| 1 +
doc/general.texi | 2 +-
doc/protocols.texi | 8
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/rtmpcrypt.c | 33
The rtmpts protocol uses https implicitly, via the ffrtmphttp
protocol, but the ffrtmphttp protocol is also useable for plain
rtmpt without https, so the dependency needs to be added here instead.
---
configure |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure
On 7/23/2012 8:39 AM, Derek Buitenhuis wrote:
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.
Thanks a
On Thu, 19 Jul 2012, Samuel Pitoiset wrote:
diff --git a/libavformat/rtmpdh.c b/libavformat/rtmpdh.c
new file mode 100644
index 000..8ddc5fc
--- /dev/null
+++ b/libavformat/rtmpdh.c
@@ -0,0 +1,329 @@
+/*
+ * RTMP Diffie-Hellmann utilities
+ * Copyright (c) 2012 Samuel Pitoiset
+ *
+ * This
Hi,
On Mon, Jul 23, 2012 at 2:05 AM, Diego Biurrun di...@biurrun.de wrote:
On Sun, Jul 22, 2012 at 08:46:10PM -0700, Ronald S. Bultje wrote:
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
Hi,
On Sun, Jul 22, 2012 at 2:38 PM, Ronald S. Bultje rsbul...@gmail.com wrote:
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
Hi,
On Sun, Jul 22, 2012 at 1:16 PM, Ronald S. Bultje rsbul...@gmail.com wrote:
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
On Mon, Jul 23, 2012 at 07:11:49AM -0700, Ronald S. Bultje wrote:
Hi,
On Mon, Jul 23, 2012 at 2:05 AM, Diego Biurrun di...@biurrun.de wrote:
On Sun, Jul 22, 2012 at 08:46:10PM -0700, Ronald S. Bultje wrote:
From: Ronald S. Bultje rsbul...@gmail.com
Write out the NAL decoding loops in
Hi,
On Mon, Jul 23, 2012 at 7:14 AM, Kostya Shishkov
kostya.shish...@gmail.com wrote:
On Mon, Jul 23, 2012 at 07:11:49AM -0700, Ronald S. Bultje wrote:
Hi,
On Mon, Jul 23, 2012 at 2:05 AM, Diego Biurrun di...@biurrun.de wrote:
On Sun, Jul 22, 2012 at 08:46:10PM -0700, Ronald S. Bultje
Kostya Shishkov kostya.shish...@gmail.com writes:
On Mon, Jul 23, 2012 at 07:11:49AM -0700, Ronald S. Bultje wrote:
Hi,
On Mon, Jul 23, 2012 at 2:05 AM, Diego Biurrun di...@biurrun.de wrote:
On Sun, Jul 22, 2012 at 08:46:10PM -0700, Ronald S. Bultje wrote:
From: Ronald S. Bultje
On Mon, Jul 23, 2012 at 07:16:53AM -0700, Ronald S. Bultje wrote:
Hi,
On Mon, Jul 23, 2012 at 7:14 AM, Kostya Shishkov
kostya.shish...@gmail.com wrote:
On Mon, Jul 23, 2012 at 07:11:49AM -0700, Ronald S. Bultje wrote:
Hi,
On Mon, Jul 23, 2012 at 2:05 AM, Diego Biurrun di...@biurrun.de
---
libavcodec/libfdk-aacenc.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c
index f2c3fbd..8c819a3 100644
--- a/libavcodec/libfdk-aacenc.c
+++ b/libavcodec/libfdk-aacenc.c
@@ -33,6 +33,8 @@ typedef
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.
Signed-off-by: Luca Barbato lu_z...@gentoo.org
On Mon, Jul 23, 2012 at 09:27:03AM -0500, Kieran Kunhya wrote:
---
libavcodec/libfdk-aacenc.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
LGTM though formatting probably could be better
___
libav-devel mailing list
On Mon, 23 Jul 2012, Kieran Kunhya wrote:
---
libavcodec/libfdk-aacenc.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c
index f2c3fbd..8c819a3 100644
--- a/libavcodec/libfdk-aacenc.c
+++
On 7/23/12 3:41 PM, Martin Storsjö wrote:
The rtmpts protocol uses https implicitly, via the ffrtmphttp
protocol, but the ffrtmphttp protocol is also useable for plain
rtmpt without https, so the dependency needs to be added here instead.
---
configure |2 +-
1 file changed, 1
Hi,
On Mon, Jul 23, 2012 at 7:29 AM, Luca Barbato lu_z...@gentoo.org wrote:
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
On 7/23/12 2:39 PM, Martin Storsjö wrote:
From: Adriano Pallavicino adrianopallavic...@gmail.com
If using a different sample rate or number of channels, use a dynamic
payload type instead, where the parameters are passed in the SDP.
G722 is a special case where the normal rules don't apply.
On 23/07/2012 10:12 AM, Ronald S. Bultje wrote:
Ping.
From what I can tell, it looks OK, so long as you've
tested each possibility + FATE.
Someone better acquainted with (Y)ASM should look, though.
- Derek
___
libav-devel mailing list
On Fri, 20 Jul 2012, Samuel Pitoiset wrote:
These messages are Adobe-specific historical artifacts that some RTMP
servers do not support. It is safer to ignore their failure. This fixes
publishing streams to crtmpserver and it fixes Bugzilla bug #309.
---
libavformat/rtmpproto.c | 30
On 7/23/12 4:54 PM, Martin Storsjö wrote:
I'm not too familiar off-hand with this section of code right now, but I
think it might be reasonable like this. I guess Luca knows it better.
Luca, is this one ok?
I'd rather have message response tracking implemented fully, but can be
done later.
On Wed, 4 Jul 2012, Jordi Ortiz wrote:
---
libavformat/rtmppkt.c | 38 ++
libavformat/rtmppkt.h | 37 +
2 files changed, 75 insertions(+)
diff --git a/libavformat/rtmppkt.c b/libavformat/rtmppkt.c
index 4ce238d..3251b71
On 3/24/12 2:50 AM, Luca Barbato wrote:
On 23/03/12 15:46, Martin Storsjö wrote:
On Fri, 23 Mar 2012, Luca Barbato wrote:
---
libavformat/avformat.h |1 +
libavformat/options.c |1 +
libavformat/utils.c| 13 -
3 files changed, 10 insertions(+), 5 deletions(-)
diff
Try and decode broken files, but still fail if explode
mode is enabled.
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavcodec/v410dec.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/v410dec.c b/libavcodec/v410dec.c
index
On 23/07/2012 6:40 AM, Luca Barbato wrote:
Mind adding support for explode mode?
We have people that would rather know their files are broken.
Done sent.
- Derek
___
libav-devel mailing list
libav-devel@libav.org
On Wed, 4 Jul 2012, Jordi Ortiz wrote:
This code allows receiving a stream from a client with the PUBLISH command.
---
libavformat/rtmpproto.c | 470 ---
1 file changed, 449 insertions(+), 21 deletions(-)
diff --git a/libavformat/rtmpproto.c
On Mon, Jul 23, 2012 at 11:13:16AM -0400, Derek Buitenhuis wrote:
Try and decode broken files, but still fail if explode
mode is enabled.
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavcodec/v410dec.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
On 23/07/2012 11:30 AM, Kostya Shishkov wrote:
I'd add , continuing anyway in the second case but patch LGTM without that
change too.
Done.
- Derek
___
libav-devel mailing list
libav-devel@libav.org
On 7/21/12 10:13 PM, Diego Biurrun wrote:
From: Ronald S. Bultje rsbul...@gmail.com
Fixes compilation for compilers that do not support gcc inline Assembly.
Signed-off-by: Diego Biurrun di...@biurrun.de
---
This is Ronald's set of three patches squashed into one.
The patches are very short and
Some of the rtmp* dependencies are in shambles.
libavformat/rtmpproto.c unconditionally uses all the symbols from
libavformat/rtmpcrypt.c, but does not depend on it.
I suspect all of the rtmp hackers have the dependencies for ffrtmpcrypt
protocol installed and thus never noticed, but at least one
On 7/21/12 10:24 PM, Diego Biurrun wrote:
On Sat, Jul 21, 2012 at 09:20:59PM +0100, Måns Rullgård wrote:
Diego Biurrun di...@biurrun.de writes:
On Sat, Jul 21, 2012 at 10:13:11PM +0200, Diego Biurrun wrote:
Fixes compilation for compilers that do not support gcc inline Assembly.
---
This is
On Mon, Jul 23, 2012 at 5:36 PM, Diego Biurrun di...@biurrun.de wrote:
Some of the rtmp* dependencies are in shambles.
libavformat/rtmpproto.c unconditionally uses all the symbols from
libavformat/rtmpcrypt.c, but does not depend on it.
I suspect all of the rtmp hackers have the dependencies
On 7/20/12 3:33 PM, Luca Barbato wrote:
From: Michael Bradshaw mbrads...@sorensonmedia.com
Based on FFmpeg version from
commit 3275981207e30e140cffaea334ac390f1a04266a
---
libavcodec/libopenjpegdec.c | 297 +++
1 files changed, 246 insertions(+), 51
---
configure|1 -
doc/general.texi |1 -
doc/protocols.texi |4 --
libavformat/Makefile |1 -
libavformat/allformats.c |1 -
libavformat/gopher.c | 125 --
6 files changed, 0 insertions(+), 133
On Mon, 23 Jul 2012, Diego Biurrun wrote:
Some of the rtmp* dependencies are in shambles.
libavformat/rtmpproto.c unconditionally uses all the symbols from
libavformat/rtmpcrypt.c, but does not depend on it.
I suspect all of the rtmp hackers have the dependencies for ffrtmpcrypt
protocol
On 23/07/2012 11:47 AM, Diego Biurrun wrote:
---
configure|1 -
doc/general.texi |1 -
doc/protocols.texi |4 --
libavformat/Makefile |1 -
libavformat/allformats.c |1 -
libavformat/gopher.c | 125
Diego Biurrun di...@biurrun.de writes:
---
configure|1 -
doc/general.texi |1 -
doc/protocols.texi |4 --
libavformat/Makefile |1 -
libavformat/allformats.c |1 -
libavformat/gopher.c | 125
On Mon, 23 Jul 2012, Derek Buitenhuis wrote:
On 23/07/2012 11:47 AM, Diego Biurrun wrote:
---
configure|1 -
doc/general.texi |1 -
doc/protocols.texi |4 --
libavformat/Makefile |1 -
libavformat/allformats.c |1 -
libavformat/gopher.c
---
libavcodec/libfdk-aacenc.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c
index f2c3fbd..4d7aa7b 100644
--- a/libavcodec/libfdk-aacenc.c
+++ b/libavcodec/libfdk-aacenc.c
@@ -33,6 +33,8 @@ typedef
On Mon, 23 Jul 2012, Kieran Kunhya wrote:
---
libavcodec/libfdk-aacenc.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c
index f2c3fbd..4d7aa7b 100644
--- a/libavcodec/libfdk-aacenc.c
+++
On 23 March 2012 12:40, Luca Barbato lu_z...@gentoo.org wrote:
---
libavformat/avformat.h |1 +
libavformat/options.c |1 +
libavformat/utils.c| 13 -
3 files changed, 10 insertions(+), 5 deletions(-)
The commit message probably should mention this affects only
On Mon, Jul 23, 2012 at 9:20 AM, Kieran Kunhya kier...@ob-encoder.com wrote:
---
libavcodec/libfdk-aacenc.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c
index f2c3fbd..4d7aa7b 100644
---
On 7/23/12 6:53 PM, Josh Allmann wrote:
On 23 March 2012 12:40, Luca Barbato lu_z...@gentoo.org wrote:
---
libavformat/avformat.h |1 +
libavformat/options.c |1 +
libavformat/utils.c| 13 -
3 files changed, 10 insertions(+), 5 deletions(-)
The commit message
On 7/23/12 5:13 PM, Derek Buitenhuis wrote:
Try and decode broken files, but still fail if explode
mode is enabled.
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavcodec/v410dec.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
Looks good, thank you.
On Mon, Jul 23, 2012 at 06:47:51PM +0300, Martin Storsjö wrote:
On Mon, 23 Jul 2012, Diego Biurrun wrote:
Some of the rtmp* dependencies are in shambles.
libavformat/rtmpproto.c unconditionally uses all the symbols from
libavformat/rtmpcrypt.c, but does not depend on it.
I suspect all of
If you remove this then you can drop the ra14.4 encoder also. It has the
same usability factor. I am opposed to removing things unless it becomes
a maintenance burden.
MvH
Benjamin Larsson
___
libav-devel mailing list
libav-devel@libav.org
On Mon, Jul 23, 2012 at 12:16:42AM +0100, 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.
LGTM
Diego
___
libav-devel mailing list
The ffrtmpcrypt protocol depends on external libraries, which are
also required to compile the header file.
---
libavformat/Makefile |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/libavformat/Makefile b/libavformat/Makefile
index d8fe448..dbf1057 100644
---
On Mon, 23 Jul 2012, Diego Biurrun wrote:
The ffrtmpcrypt protocol depends on external libraries, which are
also required to compile the header file.
---
libavformat/Makefile |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/libavformat/Makefile b/libavformat/Makefile
On Mon, Jul 23, 2012 at 04:54:57PM +0100, Måns Rullgård wrote:
Diego Biurrun di...@biurrun.de writes:
---
configure|1 -
doc/general.texi |1 -
doc/protocols.texi |4 --
libavformat/Makefile |1 -
libavformat/allformats.c |1 -
On Mon, Jul 23, 2012 at 11:45:33PM +0200, Benjamin Larsson wrote:
If you remove this then you can drop the ra14.4 encoder also. It has
the same usability factor. I am opposed to removing things unless it
becomes a maintenance burden.
You cannot compare one with the other. libavcodec is the
On Sun, Jul 22, 2012 at 1:16 PM, Ronald S. Bultje rsbul...@gmail.com wrote:
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
I don't see a point in removing it as long as it's not a big maintenance
burden.
Especially not since it's been added so recently.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
I messed up while adding Kostya's sugegsted log text change.
Here's the fix.
Carl Eugen Hoyos (1):
Fix typo in v410 decoder.
libavcodec/v410dec.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
1.7.10.4
___
libav-devel mailing
From: Carl Eugen Hoyos ceho...@ag.or.at
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavcodec/v410dec.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/v410dec.c b/libavcodec/v410dec.c
index d7660ee..93545ab 100644
---
Diego Biurrun di...@biurrun.de writes:
On Mon, Jul 23, 2012 at 04:54:57PM +0100, Måns Rullgård wrote:
Diego Biurrun di...@biurrun.de writes:
---
configure|1 -
doc/general.texi |1 -
doc/protocols.texi |4 --
libavformat/Makefile |1
On 07/24/2012 12:17 AM, Diego Biurrun wrote:
On Mon, Jul 23, 2012 at 11:45:33PM +0200, Benjamin Larsson wrote:
There are Gopher implementations in other places.
The same is true for http. Anyway you have some points and I don't
really care that much I just wanted to state that I am against
From: Yang Wang yang.y.w...@intel.com
In ff_put_pixels_clamped_mmx(), there are two assembly code blocks.
In the first block (in the unrolled loop), the instructions
movq 8%3, %%mm1 \n\t, and so forth, have problems.
From above instruction, it is clear what the programmer wants: a load from
p +
On Mon, Jul 23, 2012 at 07:09:06PM -0400, Derek Buitenhuis wrote:
From: Yang Wang yang.y.w...@intel.com
This error was fixed in the second block of the assembly code, but not in
the unrolled loop.
How to reproduce:
This error is exposed when we build the ffmpeg using Intel C++
On Mon, Jul 23, 2012 at 11:52:17PM +0100, Måns Rullgård wrote:
Diego Biurrun di...@biurrun.de writes:
On Mon, Jul 23, 2012 at 04:54:57PM +0100, Måns Rullgård wrote:
Diego Biurrun di...@biurrun.de writes:
---
configure|1 -
doc/general.texi |1 -
On 7/24/12 12:52 AM, Måns Rullgård wrote:
And snow.c doesn't?
Apparently I'm the one wanting to preserve it, if we manage to get dirac
inside we might drop snow.
I'd rather drop it once it is completely surpassed by dirac though =/
lu
___
On 7/24/12 12:45 AM, Derek Buitenhuis wrote:
From: Carl Eugen Hoyos ceho...@ag.or.at
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavcodec/v410dec.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/v410dec.c b/libavcodec/v410dec.c
Ahem, it seems to be the brown paperbag season again...
So, I slipped up and accidentally pushed some ongoing work I had on
my master branch to origin/master, namely the following commits:
0abed1d13fdc0fb04873a7763e7a765ba621d66a
aacps: Drop some function argument const qualifiers to silence
On 23/07/2012 7:32 PM, Diego Biurrun wrote:
Please don't undo the prettyprinting I applied to that file.
I don't see a way to keep it pretty short of re-indenting the
whole block, which should be a 2nd commit.
- Derek
___
libav-devel mailing list
From: Daniel Kang daniel.d.k...@gmail.com
The only CPUs that have 3dnow and don't have mmxext are 12 years old.
---
libavcodec/x86/dsputil_mmx.c |9 -
libavcodec/x86/h264_qpel_mmx.c |4
2 files changed, 0 insertions(+), 13 deletions(-)
diff --git
Il 23/07/2012 17:03, Diego Biurrun ha scritto:
I'm not entirely sure if I should have
expected that or not.
You should. That's why it's best to work on a branch and only add to
master when you intend to push it.
Since your master tracks origin/master both ways, a git push to origin
_will_
Most people know the codec as AAC and not Advanced Audio Coding.
---
libavcodec/aacdec.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index 4be5255..76d4120 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -2846,7
On Mon, Jul 23, 2012 at 08:13:20PM -0400, Derek Buitenhuis wrote:
On 23/07/2012 7:32 PM, Diego Biurrun wrote:
Please don't undo the prettyprinting I applied to that file.
I don't see a way to keep it pretty short of re-indenting the
whole block, which should be a 2nd commit.
Have a look at
On Mon, Jul 23, 2012 at 05:12:23PM -0700, Daniel Kang wrote:
From: Daniel Kang daniel.d.k...@gmail.com
The only CPUs that have 3dnow and don't have mmxext are 12 years old.
---
libavcodec/x86/dsputil_mmx.c |9 -
libavcodec/x86/h264_qpel_mmx.c |4
2 files changed, 0
From: Yang Wang yang.y.w...@intel.com
In ff_put_pixels_clamped_mmx(), there are two assembly code blocks.
In the first block (in the unrolled loop), the instructions
movq 8%3, %%mm1 \n\t, and so forth, have problems.
From above instruction, it is clear what the programmer wants: a load from
p +
On Mon, Jul 23, 2012 at 05:15:15PM -0700, Diego Elio Pettenò wrote:
Il 23/07/2012 17:03, Diego Biurrun ha scritto:
I'm not entirely sure if I should have
expected that or not.
You should. That's why it's best to work on a branch and only add to
master when you intend to push it.
On Mon, Jul 23, 2012 at 5:21 PM, Diego Biurrun di...@biurrun.de wrote:
On Mon, Jul 23, 2012 at 05:12:23PM -0700, Daniel Kang wrote:
From: Daniel Kang daniel.d.k...@gmail.com
The only CPUs that have 3dnow and don't have mmxext are 12 years old.
---
libavcodec/x86/dsputil_mmx.c |9
On 23/07/2012 8:15 PM, Diego Biurrun wrote:
Most people know the codec as AAC and not Advanced Audio Coding.
---
libavcodec/aacdec.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
OK. But, should we not change e.g. MP3?
It is currently: MPEG audio layer 2/3
- Derek
Derek Buitenhuis derek.buitenh...@gmail.com writes:
On 23/07/2012 8:15 PM, Diego Biurrun wrote:
Most people know the codec as AAC and not Advanced Audio Coding.
---
libavcodec/aacdec.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
OK. But, should we not change e.g. MP3?
MP3
On 23/07/2012 8:30 PM, Derek Buitenhuis wrote:
How to reproduce:
This error is exposed when we build the ffmpeg using Intel C++ Compiler,
IPO+PGO optimization. Crashed when decoding an MJPEG video.
Forgot to remove the first occurrence. Woops. Amended locally,
pending further review.
On 23/07/2012 8:48 PM, Måns Rullgård wrote:
OK. But, should we not change e.g. MP3?
MP3 is not an official designation whatsoever.
I was going by the rationale of this patch.
Most people will recognize 'MP3'.
Merely a musing.
- Derek
___
On Mon, 2012-07-23 at 20:43 -0400, Derek Buitenhuis wrote:
On 23/07/2012 8:15 PM, Diego Biurrun wrote:
Most people know the codec as AAC and not Advanced Audio Coding.
---
libavcodec/aacdec.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
OK. But, should we not change
On 23/07/2012 8:54 PM, Uoti Urpala wrote:
No, the MP3 decoder is already MP3 (MPEG audio layer 3), matching what
I suggested changing AAC to. The name you quoted above is from the
libavformat _demuxer_. Thus this makes the audio codecs more consistent,
but there is already an inconsistency
On Tue, 2012-07-24 at 01:48 +0100, Måns Rullgård wrote:
Derek Buitenhuis derek.buitenh...@gmail.com writes:
On 23/07/2012 8:15 PM, Diego Biurrun wrote:
Most people know the codec as AAC and not Advanced Audio Coding.
---
libavcodec/aacdec.c |2 +-
1 files changed, 1
On Mon, Jul 23, 2012 at 08:56:55PM -0400, Derek Buitenhuis wrote:
On 23/07/2012 8:54 PM, Uoti Urpala wrote:
No, the MP3 decoder is already MP3 (MPEG audio layer 3), matching what
I suggested changing AAC to. The name you quoted above is from the
libavformat _demuxer_. Thus this makes the
On Tue, Jul 24, 2012 at 02:03:00AM +0200, Diego Biurrun wrote:
I took the Git server offline in roundabout a minute, so hopefully
nothing should have picked up the stray commits. The repo is fixed
now and HEAD is pointing to the commit that it should point to.
Mail notifications for the
Hi,
On Mon, Jul 23, 2012 at 5:37 PM, Daniel Kang daniel.d.k...@gmail.com wrote:
On Mon, Jul 23, 2012 at 5:21 PM, Diego Biurrun di...@biurrun.de wrote:
On Mon, Jul 23, 2012 at 05:12:23PM -0700, Daniel Kang wrote:
From: Daniel Kang daniel.d.k...@gmail.com
The only CPUs that have 3dnow and
Hi,
On Mon, Jul 23, 2012 at 7:45 PM, Ronald S. Bultje rsbul...@gmail.com wrote:
Hi,
On Mon, Jul 23, 2012 at 5:37 PM, Daniel Kang daniel.d.k...@gmail.com wrote:
On Mon, Jul 23, 2012 at 5:21 PM, Diego Biurrun di...@biurrun.de wrote:
On Mon, Jul 23, 2012 at 05:12:23PM -0700, Daniel Kang wrote:
On Mon, Jul 23, 2012 at 06:45:17PM -0400, Derek Buitenhuis wrote:
From: Carl Eugen Hoyos ceho...@ag.or.at
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavcodec/v410dec.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/v410dec.c
97 matches
Mail list logo
