On Mon, Jul 16, 2012 at 03:28:03PM +0100, Måns Rullgård wrote:
Diego Biurrun di...@biurrun.de writes:
On Mon, Jul 16, 2012 at 02:17:06PM +0100, Mans Rullgard wrote:
--- a/libavcodec/arm/Makefile
+++ b/libavcodec/arm/Makefile
@@ -14,6 +14,7 @@ OBJS-$(CONFIG_FLAC_DECODER)+=
Diego Biurrun di...@biurrun.de writes:
On Mon, Jul 16, 2012 at 03:28:03PM +0100, Måns Rullgård wrote:
Diego Biurrun di...@biurrun.de writes:
On Mon, Jul 16, 2012 at 02:17:06PM +0100, Mans Rullgard wrote:
--- a/libavcodec/arm/Makefile
+++ b/libavcodec/arm/Makefile
@@ -14,6 +14,7 @@
---
Changelog| 1 +
configure| 2 ++
doc/general.texi | 2 +-
doc/protocols.texi | 7 +++
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/rtmp.h | 1 +
libavformat/rtmpproto.c | 23 +++
---
Changelog| 1 +
configure| 1 +
doc/general.texi | 1 +
doc/protocols.texi | 8
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/rtmphttp.c | 32
libavformat/rtmpproto.c
On Tue, 17 Jul 2012, Samuel Pitoiset wrote:
---
Changelog| 1 +
configure| 2 ++
doc/general.texi | 2 +-
doc/protocols.texi | 7 +++
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/rtmp.h | 1 +
25% faster on penryn (even though I didn't predict that by counting uops).
25% faster on sandybridge.
No change on bulldozer.
But even though I successfully predicted that this is an improvement, I don't
understand its performance.
6x load, 12x punpckldq, 6x store, 4x scalar:
Should take 12
On Tue, 17 Jul 2012, Samuel Pitoiset wrote:
diff --git a/libavformat/rtmphttp.c b/libavformat/rtmphttp.c
index febe4b3..8ac9b40 100644
--- a/libavformat/rtmphttp.c
+++ b/libavformat/rtmphttp.c
@@ -30,8 +30,10 @@
#include libavutil/time.h
#include internal.h
#include http.h
+#include rtmp.h
URLProtocol ff_ffrtmphttp_protocol = {
.name = ffrtmphttp,
.url_open = rtmp_http_open,
@@ -248,4 +271,5 @@ URLProtocol ff_ffrtmphttp_protocol = {
.url_close = rtmp_http_close,
.priv_data_size = sizeof(RTMP_HTTPContext),
.flags =
This adds two protocols, but one of them is an internal implementation
detail just used as an abstraction layer/generalization in the code. The
RTMPE protocol implementation uses rtmpenc:// as an alternative to the
tcp:// protocol. This allows moving most of the lower level logic out
from the
configure| 11 ++
doc/general.texi | 2 +-
doc/protocols.texi | 9 ++
libavformat/Makefile | 2 +
libavformat/allformats.c | 2 +
libavformat/rtmpdh.c | 291
libavformat/rtmpdh.h | 105
On Tue, Jul 17, 2012 at 12:52:30AM +0200, Luca Barbato wrote:
From: Michael Bradshaw mbrads...@sorensonmedia.com
Signed-off-by: Luca Barbato lu_z...@gentoo.org
---
Changelog |1 +
configure |3 +-
doc/general.texi|2 +-
On 07/17/2012 07:02 AM, Loren Merritt wrote:
25% faster on penryn (even though I didn't predict that by counting uops).
25% faster on sandybridge.
No change on bulldozer.
But even though I successfully predicted that this is an improvement, I don't
understand its performance.
6x load, 12x
---
libavresample/x86/audio_convert.asm| 63
libavresample/x86/audio_convert_init.c |9 +
2 files changed, 72 insertions(+), 0 deletions(-)
diff --git a/libavresample/x86/audio_convert.asm
b/libavresample/x86/audio_convert.asm
index
OK
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
OK
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
OK
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
LGTM
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
ok
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
LGTM
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
OK
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
LGTM
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
---
libavcodec/tscc2.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavcodec/tscc2.c b/libavcodec/tscc2.c
index 972dc43..91f79e2 100644
--- a/libavcodec/tscc2.c
+++ b/libavcodec/tscc2.c
@@ -91,7 +91,7 @@ static av_cold int init_vlcs(TSCC2Context *c)
#define
Reversing the lpc coefficient order simplifies indexing in
the filter.
Signed-off-by: Mans Rullgard m...@mansr.com
---
libavcodec/flacdec.c | 2 +-
libavcodec/flacdsp.c | 27 +--
2 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/libavcodec/flacdec.c
On Mon, 16 Jul 2012, Samuel Pitoiset wrote:
This adds two protocols, but one of them is an internal implementation
detail just used as an abstraction layer/generalization in the code. The
RTMPE protocol implementation uses rtmpenc:// as an alternative to the
This should be updated with the
It turns out that the reference decoder subtracts 128 from DC during block
decode but adds it back during reordering block with zigzag pattern.
Transforming block with incorrect DC caused heavy visual artifacts for
many quantisers.
---
libavcodec/tscc2.c |4 ++--
1 files changed, 2
On 07/17/2012 11:58 AM, Mans Rullgard wrote:
Reversing the lpc coefficient order simplifies indexing in
the filter.
Signed-off-by: Mans Rullgard m...@mansr.com
---
libavcodec/flacdec.c | 2 +-
libavcodec/flacdsp.c | 27 +--
2 files changed, 14 insertions(+), 15
On 07/17/2012 06:19 PM, Kostya Shishkov wrote:
It turns out that the reference decoder subtracts 128 from DC during block
decode but adds it back during reordering block with zigzag pattern.
Transforming block with incorrect DC caused heavy visual artifacts for
many quantisers.
---
On 07/17/2012 05:35 PM, Kostya Shishkov wrote:
---
libavcodec/tscc2.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavcodec/tscc2.c b/libavcodec/tscc2.c
index 972dc43..91f79e2 100644
--- a/libavcodec/tscc2.c
+++ b/libavcodec/tscc2.c
@@ -91,7 +91,7 @@ static
---
Somehow I missed this during review - of course the prudent choice is
not to assume compatibility until it has been confirmed. In general
compatibility between copyleft-style licenses is tricky...
configure |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/configure
---
configure | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/configure b/configure
index 7cf2b7b..d6fede1 100755
--- a/configure
+++ b/configure
@@ -2846,9 +2846,9 @@ if enabled network; then
if check_header arpa/inet.h ; then
check_func
+
+// Send Window Acknowledgement Size (wireshark)
wireshark?
Both wireshark and the specification document I used as reference call this
Send Widndow Acknowledgement Size instead of Set Client BW which is what I
would expect if I look at the code while watching wireshark. May be the
On 07/17/2012 08:26 PM, Jordi Ortiz wrote:
+
+// Send Window Acknowledgement Size (wireshark)
wireshark?
Both wireshark and the specification document I used as reference call this
Send Widndow Acknowledgement Size instead of Set Client BW which is what I
would expect if I look at
Diego Biurrun di...@biurrun.de writes:
---
configure | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
LGTM
--
Måns Rullgård
m...@mansr.com
___
libav-devel mailing list
libav-devel@libav.org
From: Michael Bradshaw mbrads...@sorensonmedia.com
Based on FFmpeg version from
commit 3275981207e30e140cffaea334ac390f1a04266a
---
Update for the decoder side, my own review will follow as well.
libavcodec/libopenjpegdec.c | 330 +++
1 files changed,
On 07/17/2012 02:13 PM, Diego Biurrun wrote:
---
Somehow I missed this during review - of course the prudent choice is
not to assume compatibility until it has been confirmed. In general
compatibility between copyleft-style licenses is tricky...
configure |1 +
1 files changed, 1
On Tue, Jul 17, 2012 at 10:24:01AM +0100, Måns Rullgård wrote:
Diego Biurrun di...@biurrun.de writes:
On Mon, Jul 16, 2012 at 03:28:03PM +0100, Måns Rullgård wrote:
Diego Biurrun di...@biurrun.de writes:
On Mon, Jul 16, 2012 at 02:17:06PM +0100, Mans Rullgard wrote:
---
This moves all VP3-specific function pointers from dsputil to a
new vp3dsp context. There is no reason to ever use the VP3 IDCT
where an MPEG2 IDCT is expected or vice versa.
Signed-off-by: Mans Rullgard m...@mansr.com
---
Now with some av_cold I forgot the first time.
---
On Wed, Jul 18, 2012 at 01:25:08AM +0100, Mans Rullgard wrote:
This moves all VP3-specific function pointers from dsputil to a
new vp3dsp context. There is no reason to ever use the VP3 IDCT
where an MPEG2 IDCT is expected or vice versa.
OK
Diego
On 07/17/2012 08:13 PM, Diego Biurrun wrote:
---
Somehow I missed this during review - of course the prudent choice is
not to assume compatibility until it has been confirmed. In general
compatibility between copyleft-style licenses is tricky...
We discussed that before the commit, the short
On Wed, Jul 18, 2012 at 02:43:13AM +0200, Luca Barbato wrote :
On 07/17/2012 08:13 PM, Diego Biurrun wrote:
---
Somehow I missed this during review - of course the prudent choice is
not to assume compatibility until it has been confirmed. In general
compatibility between copyleft-style
40 matches
Mail list logo
