On Wed, Oct 7, 2015 at 5:39 PM, Derek Buitenhuis
wrote:
> This becomes unuseful in the following commit.
>
> This reverts commit 092d1977cc7146f20c8db2155e7d648afb300de7.
>
> Signed-off-by: Derek Buitenhuis
> ---
> libavcodec/Makefile | 4 +-
> libavcodec/cabac.c | 74 +
On Wed, Oct 7, 2015 at 5:39 PM, Derek Buitenhuis
wrote:
> From: Anton Khirnov
>
> There's not much reason to generate such a small table at runtime.
>
> Signed-off-by: Derek Buitenhuis
> ---
> libavcodec/cabac.c | 207
> ++-
> libavcodec/cabac.
On Wed, Oct 7, 2015 at 6:29 PM, Hendrik Leppkes wrote:
> On Wed, Oct 7, 2015 at 6:23 PM, Matt Oliver wrote:
>> On 6 October 2015 at 21:36, Hendrik Leppkes wrote:
>>
>>> The emulation uses native InitOnce* APIs on Windows Vista+, and a
>>> lock-free/allocation-free approach using atomics and spin
從我的 iPhone 傳送壓縮啊啊轉
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Sat, Oct 10, 2015 at 03:18:38AM +0200, Michael Niedermayer wrote:
[...]
> > +
> > +if ((ret = avpriv_jni_exception_get_summary(env, exception, &message,
> > log_ctx)) < 0) {
> > +return ret;
> > +}
> > +
> > +(*env)->DeleteLocalRef(env, exception);
> > +
> > +av_log(log_
Le decadi 30 fructidor, an CCXXIII, Michael Niedermayer a écrit :
> ffmpeg | branch: master | Michael Niedermayer | Wed
> Sep 16 01:39:18 2015 +0200| [3496a20bb92570aaa82849f0d5409f2e29fe2d2b] |
> committer: Michael Niedermayer
>
> avformat/flvdec: Change packet loop to return EAGAIN instead of
> Could you please fix it?
>
> Thanks
>
> Best regards
curl
https://github.com/BtbN/FFmpeg/commit/29294c283a656cf809461cbae21d612b5a0f2159.patch
| git apply
That works for me, the patch is not in git format-patch format, so git
am can't apply it.
I also attached the two patches in format-patch
av_fifo_generic_write() does not return any error code.
---
libavformat/async.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/libavformat/async.c b/libavformat/async.c
index a01673d..9172f5d 100644
--- a/libavformat/async.c
+++ b/libavformat/asyn
---
libavformat/async.c | 41 +
tests/ref/fate/async | 2 ++
2 files changed, 43 insertions(+)
diff --git a/libavformat/async.c b/libavformat/async.c
index 9172f5d..a8c8f54 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -387,6 +387,9 @@ sta
On Fri, Oct 09, 2015 at 11:53:44PM +0200, Christophe Gisquet wrote:
> ---
> libavcodec/arm/dct-test.c | 10 --
> libavcodec/dct-test.c | 41 +++--
> libavcodec/ppc/dct-test.c | 10 --
> libavcodec/x86/dct-test.c | 9 +++--
> 4 files chan
On Fri, Oct 09, 2015 at 11:53:45PM +0200, Christophe Gisquet wrote:
> ---
> libavcodec/x86/dct-test.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
with this patch
libavcodec/dct-test -i 0 10
end in "Error: 1." after testing SIMPLE10-C
libavcodec/dct-test 0 10
tests IJG-
Michael Niedermayer niedermayer.cc> writes:
> ill make 2.8.1 soon from release/2.8
I backported a few regression fixes into 2.8.
The following tickets look like regressions
wrt 2.7:
https://trac.ffmpeg.org/ticket/4881
https://trac.ffmpeg.org/ticket/4899
https://trac.ffmpeg.org/ticket/4903
Car
On 2015-10-10 00:43, Ganesh Ajjanagadde wrote:
> During a build, a lot of *.o-hash files are created - had not noticed
> this as they are usually dumped in tmpfs on Linux. However, they
> sometimes are present during a long build in the project directory, making it
> annoying to commit while the pr
On Fri, Oct 09, 2015 at 11:53:40PM +0200, Christophe Gisquet wrote:
> Modeled from the prores version. Clips to [0;1023] and is bitexact.
> Bitexactness requires to add an offset in a different place compared
> to prores or C, and makes the function approximately 2% slower.
>
> For 16 frames of a
On 2015-10-09 14:46, Nicolas George wrote:
> Le quartidi 4 vendémiaire, an CCXXIV, James Darnley a écrit :
>> I can. You should find it attached to this email. I cleaned it up and
>> put two test cases of data into the file. You will need Lua and the
>> Lua-iconv module. If your package manager
On Sat, Oct 10, 2015 at 11:37:04AM +0200, Nicolas George wrote:
> Le decadi 30 fructidor, an CCXXIII, Michael Niedermayer a écrit :
> > ffmpeg | branch: master | Michael Niedermayer |
> > Wed Sep 16 01:39:18 2015 +0200| [3496a20bb92570aaa82849f0d5409f2e29fe2d2b]
> > | committer: Michael Niederma
On Sat, Oct 10, 2015 at 7:40 AM, James Darnley wrote:
> On 2015-10-10 00:43, Ganesh Ajjanagadde wrote:
>> During a build, a lot of *.o-hash files are created - had not noticed
>> this as they are usually dumped in tmpfs on Linux. However, they
>> sometimes are present during a long build in the pr
Signed-off-by: Ganesh Ajjanagadde
---
doc/build_system.txt | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/build_system.txt b/doc/build_system.txt
index 1efe6b5..a9bd4eb 100644
--- a/doc/build_system.txt
+++ b/doc/build_system.txt
@@ -9,7 +9,7 @@ V
Signed-off-by: Ganesh Ajjanagadde
---
doc/developer.texi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc/developer.texi b/doc/developer.texi
index 31952d8..3fe4447 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -124,10 +124,10 @@ the @samp{inline} keywor
Hi
On Sat, Oct 10, 2015 at 09:43:55AM +0200, Luca Barbato wrote:
> ffmpeg | branch: master | Luca Barbato | Mon Oct 5
> 20:49:55 2015 +0200| [8b830ee9a26d47b138f12a82085cdb372f407f1e] | committer:
> Luca Barbato
>
> avconv: Do not try to configure filter outputs without streams
>
> Prevent a
Similar to 33fefdb44.
Fix trac ticket #4921.
Signed-off-by: Nicolas George
---
libavformat/tee.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/tee.c b/libavformat/tee.c
index c619eae..a86952b 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -403,6 +403,8 @@ static in
This uses the av_warn_unused_result attribute liberally to catch some forms of
improper
usage of functions defined in avfilter/formats.h.
Signed-off-by: Ganesh Ajjanagadde
---
libavfilter/formats.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavfilter/formats.h b/libavfilter/
On Sat, Oct 10, 2015 at 9:19 AM, Nicolas George wrote:
> Similar to 33fefdb44.
> Fix trac ticket #4921.
>
> Signed-off-by: Nicolas George
> ---
> libavformat/tee.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/tee.c b/libavformat/tee.c
> index c619eae..a86952b 100644
> -
On Sat, Oct 10, 2015 at 9:18 AM, Michael Niedermayer
wrote:
> Hi
>
> On Sat, Oct 10, 2015 at 09:43:55AM +0200, Luca Barbato wrote:
>> ffmpeg | branch: master | Luca Barbato | Mon Oct 5
>> 20:49:55 2015 +0200| [8b830ee9a26d47b138f12a82085cdb372f407f1e] | committer:
>> Luca Barbato
>>
>> avconv:
Hi all,
Once again, apologies for sending patch as an attachment, gmail smtp
sendmail is still broken.
The patch uses Nicolas's ideas to achieve a substantial improvement in
readability.
Regards,
Ganesh
From 64f45a7938c8e34dbbd77110fea3f19a78e77c78 Mon Sep 17 00:00:00 2001
From: Ganesh Ajjanagad
On Fri, Oct 09, 2015 at 03:59:04PM -0400, Ganesh Ajjanagadde wrote:
> This should fix the undefined behavior reported in:
> https://trac.ffmpeg.org/ticket/4727.
>
> I can reproduce this at runtime: simply stick in an abort call in
> asym_quant to check if c < 0 and run FATE. I don't know ac3 so I
During a build, a lot of *.o.-hash files are created - had not noticed
this as they are usually dumped in tmpfs on Linux. However, they
sometimes are present during a long build in the project directory, making it
annoying to commit while the project is being built.
These have been observed with C
On Sat, Oct 10, 2015 at 09:34:21AM -0400, Ganesh Ajjanagadde wrote:
[...]
> diff --git a/libavfilter/vsrc_life.c b/libavfilter/vsrc_life.c
> index 314746d..0e31ef7 100644
> --- a/libavfilter/vsrc_life.c
> +++ b/libavfilter/vsrc_life.c
> @@ -417,6 +417,7 @@ static int query_formats(AVFilterContext *
On Sat, Oct 10, 2015 at 9:10 AM, Ganesh Ajjanagadde wrote:
> On Sat, Oct 10, 2015 at 7:40 AM, James Darnley
> wrote:
>> On 2015-10-10 00:43, Ganesh Ajjanagadde wrote:
>>> During a build, a lot of *.o-hash files are created - had not noticed
>>> this as they are usually dumped in tmpfs on Linux.
On Sat, Oct 10, 2015 at 9:40 AM, Clément Bœsch wrote:
> On Sat, Oct 10, 2015 at 09:34:21AM -0400, Ganesh Ajjanagadde wrote:
> [...]
>> diff --git a/libavfilter/vsrc_life.c b/libavfilter/vsrc_life.c
>> index 314746d..0e31ef7 100644
>> --- a/libavfilter/vsrc_life.c
>> +++ b/libavfilter/vsrc_life.c
>
Le nonidi 19 vendémiaire, an CCXXIV, Clement Boesch a écrit :
> You could change that last function to return AVERROR(ENOMEM) in case a
> parameter is NULL, but that's weird semantic.
Since it is an internal function, it is not really a problem, and it makes
for nice simplifications.
Regards,
--
On date Thursday 2015-10-08 11:14:40 -0400, Ganesh Ajjanagadde encoded:
> On Thu, Oct 8, 2015 at 10:29 AM, Stefano Sabatini wrote:
> > On date Thursday 2015-10-08 09:01:04 -0400, Ganesh Ajjanagadde encoded:
> >> Signed-off-by: Ganesh Ajjanagadde
> >> ---
> >> doc/build_system.txt | 20 ++
On Sat, Oct 10, 2015 at 9:50 AM, Stefano Sabatini wrote:
> On date Thursday 2015-10-08 11:14:40 -0400, Ganesh Ajjanagadde encoded:
>> On Thu, Oct 8, 2015 at 10:29 AM, Stefano Sabatini wrote:
>> > On date Thursday 2015-10-08 09:01:04 -0400, Ganesh Ajjanagadde encoded:
>> >> Signed-off-by: Ganesh A
On date Thursday 2015-10-08 16:11:49 -0400, Ganesh Ajjanagadde encoded:
> On Thu, Oct 8, 2015 at 10:05 AM, Moritz Barsnick wrote:
> > On Thu, Oct 08, 2015 at 09:01:38 -0400, Ganesh Ajjanagadde wrote:
> >> For variables and functions visible outside of file scope, but only used
> >> -internally by
On date Saturday 2015-10-10 09:13:47 -0400, Ganesh Ajjanagadde encoded:
> Signed-off-by: Ganesh Ajjanagadde
> ---
> doc/build_system.txt | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
Already applied.
--
FFmpeg = F**king Fiendish Most Prodigious EnGraver
On date Saturday 2015-10-10 09:14:02 -0400, Ganesh Ajjanagadde encoded:
> Signed-off-by: Ganesh Ajjanagadde
> ---
> doc/developer.texi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Already applied.
--
FFmpeg = Fancy and Freak Muttering Pacific Excellent Gymnast
_
Dear All,
using tee pseudo muxer I faced an issue.
During applying bit stream filters, when the main packet data buffer is
changed, filter_packet function uses a temporary new packet (new_pkt) to
store that buffer, frees the original packet (*pkt), and replace it with
the new packet.
Howeve
Le nonidi 19 vendémiaire, an CCXXIV, Bodecs Bela a écrit :
> using tee pseudo muxer I faced an issue.
Sorry for the duplicated work, I already submitted an identical patch:
http://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/180686.html
Regards,
--
Nicolas George
signature.asc
Descripti
On Thu, Oct 8, 2015 at 8:37 AM, Michael Niedermayer
wrote:
> Hi
>
> ill make 2.8.1 soon from release/2.8
> if you want something backported push it to release/2.8 soon!
> (or ask me to pull from your git tree, or if its trivial without
> conflicts then the commit hash to cherry pick is fine too)
2015.10.10. 16:11 keltezéssel, Bodecs Bela írta:
Dear All,
using tee pseudo muxer I faced an issue.
During applying bit stream filters, when the main packet data buffer
is changed, filter_packet function uses a temporary new packet
(new_pkt) to store that buffer, frees the original packet (
Hi — are there still outstanding issues with the patch, or is it good to go?
Thanks,
- Alex
On October 9, 2015 at 8:57:22 AM, Alex Agranovsky (a...@sighthound.com) wrote:
Thanks for your comments. I’m attaching the amended patch, hopefully it
addresses all of them. Please let me know if somethin
On Sat, Oct 3, 2015 at 4:43 PM, Ganesh Ajjanagadde wrote:
> ping
Please note that I am pasting the patch here as a reference, it may be
mangled by gmail:
Removes unnecessary isatty(), fixes Ticket2964
Signed-off-by: Ganesh Ajjanagadde
---
ffmpeg.c | 8 +---
1 file changed, 1 insertion(+),
On Sat, Oct 10, 2015 at 7:20 AM Ganesh Ajjanagadde wrote:
> On Thu, Oct 8, 2015 at 8:37 AM, Michael Niedermayer
> wrote:
> > Hi
> >
> > ill make 2.8.1 soon from release/2.8
> > if you want something backported push it to release/2.8 soon!
> > (or ask me to pull from your git tree, or if its triv
2015.10.10. 16:14 keltezéssel, Nicolas George írta:
Le nonidi 19 vendémiaire, an CCXXIV, Bodecs Bela a écrit :
using tee pseudo muxer I faced an issue.
Sorry for the duplicated work, I already submitted an identical patch:
http://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/180686.html
Re
Signed-off-by: Paul B Mahol
---
libavcodec/sipr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/sipr.c b/libavcodec/sipr.c
index 4602a42..595097a 100644
--- a/libavcodec/sipr.c
+++ b/libavcodec/sipr.c
@@ -537,7 +537,7 @@ static int sipr_decode_frame(AVCodecContext
Hi,
2015-10-10 13:20 GMT+02:00 Michael Niedermayer :
> On Fri, Oct 09, 2015 at 11:53:45PM +0200, Christophe Gisquet wrote:
>> ---
>> libavcodec/x86/dct-test.c | 13 -
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> with this patch
> libavcodec/dct-test -i 0 10
> end in "Error:
2015-10-10 13:12 GMT+02:00 Michael Niedermayer :
> this breaks testing the (i)dcts with other bits than 8 bits
>
> example:
> libavcodec/dct-test 0 9
> libavcodec/dct-test -i 0 9
OK, I misunderstood the intent of how to test with the bitdepth.
> also it seems some of the "8bit" (i)dcts work fine
On Tue, Oct 6, 2015 at 9:59 PM, Ronald S. Bultje wrote:
> +cglobal vp9_idct_idct_4x4_add_12, 4, 4, 6, dst, stride, block, eob
[...]
> +movdm0, coefd
> +punpcklwd m0, m0
> +pshufd m0, m0, q
pshuflw + punpcklqdq is faster on some older CPUs, su
During a build, a lot of *.o.-hash files are created - had not noticed
this as they are usually dumped in tmpfs on Linux. However, they
sometimes are present during a long build in the project directory, making it
annoying to commit while the project is being built.
These have been observed with C
On Sat, Oct 10, 2015 at 9:39 AM, Ganesh Ajjanagadde
wrote:
> During a build, a lot of *.o.-hash files are created - had not noticed
> this as they are usually dumped in tmpfs on Linux. However, they
> sometimes are present during a long build in the project directory, making it
> annoying to commi
On Sat, Oct 10, 2015 at 06:22:38PM +0200, Christophe Gisquet wrote:
> 2015-10-10 13:12 GMT+02:00 Michael Niedermayer :
> > this breaks testing the (i)dcts with other bits than 8 bits
> >
> > example:
> > libavcodec/dct-test 0 9
> > libavcodec/dct-test -i 0 9
>
> OK, I misunderstood the intent of
Proper names should be capitalized in all user facing API as far as
possible. The option names themselves have not been changed since:
1. We consistently keep option names in lower case.
2. Changing them would break existing scripts.
3. I suspect that we want to be similar to Sox and its relevant o
Proper names should be capitalized in all user facing API as far as
possible. The option names themselves have not been changed since:
1. We consistently keep option names in lower case.
2. Changing them would break existing scripts.
The converse is also true: improper names should not be capitali
On Sat, Oct 10, 2015 at 4:36 AM, Ronald S. Bultje wrote:
> @@ -674,6 +715,24 @@ cglobal vp9_idct_idct_8x8_add_10, 4, 6 + ARCH_X86_64,
> 10, \
[...]
> +shl skipd, 1
> +lea blockq, [blockq+skipq*(mmsize>>1)]
add skipd, skipd
Nit: mmsize/2 is more readable than mmsi
On Sat, 10 Oct 2015 15:19:43 +0200
Nicolas George wrote:
> Similar to 33fefdb44.
> Fix trac ticket #4921.
>
> Signed-off-by: Nicolas George
> ---
> libavformat/tee.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/tee.c b/libavformat/tee.c
> index c619eae..a86952b 10064
L'octidi 18 vendémiaire, an CCXXIV, Alex Agranovsky a écrit :
> Thanks for your comments. I’m attaching the amended patch, hopefully it
> addresses all of them. Please let me know if something else is out of
> order.
Thanks, I was about to apply, after fixing myself very minor details
(trailing sp
On Sat, Oct 10, 2015 at 06:14:13PM +0200, Christophe Gisquet wrote:
> Hi,
>
> 2015-10-10 13:20 GMT+02:00 Michael Niedermayer :
> > On Fri, Oct 09, 2015 at 11:53:45PM +0200, Christophe Gisquet wrote:
> >> ---
> >> libavcodec/x86/dct-test.c | 13 -
> >> 1 file changed, 12 insertions(+),
Le nonidi 19 vendémiaire, an CCXXIV, wm4 a écrit :
> This looks suspicious. Like some code above this does unclean tricks
> with keeping side-data somehow referenced, instead of using proper
> methods like creating a new AVPacket reference.
It is the same code than in ffmpeg.c, but I must admit I
On Fri, Oct 09, 2015 at 07:00:44PM +0200, Nicolas George wrote:
> L'octidi 18 vendémiaire, an CCXXIV, Jean-Baptiste Kempf a écrit :
> > > +HEADERS-$(CONFIG_JNI) += jni.h
> > You are going to install a jni.h header?
>
> I am not very fond of having java-related stuff in FFmpeg, bu
Le septidi 17 vendémiaire, an CCXXIV, Rodger Combs a écrit :
> ---
> libavformat/tee.c | 43 ++-
> 1 file changed, 2 insertions(+), 41 deletions(-)
LGTM, thanks for taking care of it.
Did you read this patch:
http://ffmpeg.org/pipermail/ffmpeg-devel/2015-
L'octidi 18 vendémiaire, an CCXXIV, Bodecs Bela a écrit :
> I have altered the code to work correctly in situations with multiple
> streams. I have also tested it with your command.
Thanks, it looks almost good for apply.
Your other patches were made with git format-patch, so that is ok; do not
Partially fixes Ticket 4727.
-duration is not a safe expression, since duration can be INT_MIN.
One might ask how it can become INT_MIN.
Although it is true that line 2574 is no longer reached with INT_MIN due
to commit 053e80f6eaf8d87521fe58ea96886b6ee0bbe59d (which fixed another
integer overflow
On Sat, Oct 10, 2015 at 12:54:33PM -0400, Ganesh Ajjanagadde wrote:
> Proper names should be capitalized in all user facing API as far as
> possible. The option names themselves have not been changed since:
> 1. We consistently keep option names in lower case.
> 2. Changing them would break existin
On Sat, Oct 10, 2015 at 05:51:09PM +0800, Zhang Rui wrote:
> ---
> libavformat/async.c | 41 +
> tests/ref/fate/async | 2 ++
> 2 files changed, 43 insertions(+)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040
On Sat, Oct 10, 2015 at 05:51:08PM +0800, Zhang Rui wrote:
> av_fifo_generic_write() does not return any error code.
> ---
> libavformat/async.c | 28 ++--
> 1 file changed, 22 insertions(+), 6 deletions(-)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B
On Sat, Oct 10, 2015 at 12:36:27PM -0400, Ganesh Ajjanagadde wrote:
> During a build, a lot of *.o.-hash files are created - had not noticed
> this as they are usually dumped in tmpfs on Linux. However, they
> sometimes are present during a long build in the project directory, making it
> annoying
On Sat, Oct 10, 2015 at 05:31:55PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/sipr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
LGTM
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you think the mosad wa
On Sat, Oct 10, 2015 at 12:48:08PM -0400, Ganesh Ajjanagadde wrote:
> Proper names should be capitalized in all user facing API as far as
> possible. The option names themselves have not been changed since:
> 1. We consistently keep option names in lower case.
> 2. Changing them would break existin
On Sat, Oct 10, 2015 at 10:59 AM, Timothy Gu wrote:
> On Sat, Oct 10, 2015 at 7:20 AM Ganesh Ajjanagadde wrote:
>
>> On Thu, Oct 8, 2015 at 8:37 AM, Michael Niedermayer
>> wrote:
>> > Hi
>> >
>> > ill make 2.8.1 soon from release/2.8
>> > if you want something backported push it to release/2.8 s
2015.10.10. 19:33 keltezéssel, Nicolas George írta:
L'octidi 18 vendémiaire, an CCXXIV, Bodecs Bela a écrit :
I have altered the code to work correctly in situations with multiple
streams. I have also tested it with your command.
Thanks, it looks almost good for apply.
Your other patches were
On October 10, 2015 at 1:10:25 PM, Nicolas George (geo...@nsup.org) wrote:
Thanks, I was about to apply, after fixing myself very minor details
(trailing spaces, >80 chars lines in the doc and H:M:S -> HH:MM::SS), but I
noticed that your patch is missing the "Signed-Off" tag; we have not been
ve
This uses Stein's binary GCD algorithm:
https://en.wikipedia.org/wiki/Binary_GCD_algorithm
to get a reported 1.7-2.1x speedup over Euclidean GCD on standard architectures.
Have not benchmarked, so I can't comment.
Note that there may be some room for optimization of the bit operations.
Quick note
On Sat, Oct 10, 2015 at 11:06 PM, Ganesh Ajjanagadde
wrote:
> This uses Stein's binary GCD algorithm:
> https://en.wikipedia.org/wiki/Binary_GCD_algorithm
> to get a reported 1.7-2.1x speedup over Euclidean GCD on standard
> architectures.
> Have not benchmarked, so I can't comment
Before you su
On Sat, Oct 10, 2015 at 5:32 PM, Henrik Gramner wrote:
> On Sat, Oct 10, 2015 at 11:06 PM, Ganesh Ajjanagadde
> wrote:
>> This uses Stein's binary GCD algorithm:
>> https://en.wikipedia.org/wiki/Binary_GCD_algorithm
>> to get a reported 1.7-2.1x speedup over Euclidean GCD on standard
>> architec
On Sat, Oct 10, 2015 at 5:45 PM, Ganesh Ajjanagadde wrote:
> On Sat, Oct 10, 2015 at 5:32 PM, Henrik Gramner wrote:
>> On Sat, Oct 10, 2015 at 11:06 PM, Ganesh Ajjanagadde
>> wrote:
>>> This uses Stein's binary GCD algorithm:
>>> https://en.wikipedia.org/wiki/Binary_GCD_algorithm
>>> to get a re
On 2015-10-10 23:06, Ganesh Ajjanagadde wrote:
> ...
Is the greatest common denominator (yes, I had to look that up) actually
used anywhere that is slow and needs to be fast?
All the uses of 'av_gcd' found by grep appear be dealing with timing. I
see framerate, timebase, scale. I do see uses in
On Sat, Oct 10, 2015 at 6:10 PM, James Darnley wrote:
> On 2015-10-10 23:06, Ganesh Ajjanagadde wrote:
>> ...
>
> Is the greatest common denominator (yes, I had to look that up) actually
> used anywhere that is slow and needs to be fast?
>
> All the uses of 'av_gcd' found by grep appear be dealing
On Sun, Oct 11, 2015 at 12:10:39AM +0200, James Darnley wrote:
> On 2015-10-10 23:06, Ganesh Ajjanagadde wrote:
> > ...
>
> Is the greatest common denominator (yes, I had to look that up) actually
> used anywhere that is slow and needs to be fast?
>
> All the uses of 'av_gcd' found by grep appear
Hi,
On Sat, Oct 10, 2015 at 6:07 PM, Ganesh Ajjanagadde
wrote:
> On Sat, Oct 10, 2015 at 5:45 PM, Ganesh Ajjanagadde
> wrote:
> > On Sat, Oct 10, 2015 at 5:32 PM, Henrik Gramner
> wrote:
> >> On Sat, Oct 10, 2015 at 11:06 PM, Ganesh Ajjanagadde
> >> wrote:
> >>> This uses Stein's binary GCD a
On Sat, Oct 10, 2015 at 11:32:06PM +0200, Henrik Gramner wrote:
> On Sat, Oct 10, 2015 at 11:06 PM, Ganesh Ajjanagadde
> wrote:
> > This uses Stein's binary GCD algorithm:
> > https://en.wikipedia.org/wiki/Binary_GCD_algorithm
> > to get a reported 1.7-2.1x speedup over Euclidean GCD on standard
On Sat, Oct 10, 2015 at 11:32:06PM +0200, Henrik Gramner wrote:
> On Sat, Oct 10, 2015 at 11:06 PM, Ganesh Ajjanagadde
> wrote:
> > This uses Stein's binary GCD algorithm:
> > https://en.wikipedia.org/wiki/Binary_GCD_algorithm
> > to get a reported 1.7-2.1x speedup over Euclidean GCD on standard
Signed-off-by: James Almer
---
libavfilter/x86/vf_w3fdif.asm | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavfilter/x86/vf_w3fdif.asm b/libavfilter/x86/vf_w3fdif.asm
index 988b847..f02319b 100644
--- a/libavfilter/x86/vf_w3fdif.asm
+++ b/libavfilter/x86/vf_w3fdif.
Signed-off-by: James Almer
---
libavfilter/x86/vf_w3fdif.asm | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/libavfilter/x86/vf_w3fdif.asm b/libavfilter/x86/vf_w3fdif.asm
index f02319b..f2001a4 100644
--- a/libavfilter/x86/vf_w3fdif.asm
+++ b/libavfilter/x86/v
On Sat, Oct 10, 2015 at 7:14 PM, Michael Niedermayer
wrote:
> On Sat, Oct 10, 2015 at 11:32:06PM +0200, Henrik Gramner wrote:
>> On Sat, Oct 10, 2015 at 11:06 PM, Ganesh Ajjanagadde
>> wrote:
>> > This uses Stein's binary GCD algorithm:
>> > https://en.wikipedia.org/wiki/Binary_GCD_algorithm
>> >
On Sun, Oct 11, 2015 at 01:14:27AM +0200, Michael Niedermayer wrote:
> On Sat, Oct 10, 2015 at 11:32:06PM +0200, Henrik Gramner wrote:
> > On Sat, Oct 10, 2015 at 11:06 PM, Ganesh Ajjanagadde
> > wrote:
> > > This uses Stein's binary GCD algorithm:
> > > https://en.wikipedia.org/wiki/Binary_GCD_al
On Sat, Oct 10, 2015 at 07:45:17PM -0400, Ganesh Ajjanagadde wrote:
> On Sat, Oct 10, 2015 at 7:14 PM, Michael Niedermayer
> wrote:
> > On Sat, Oct 10, 2015 at 11:32:06PM +0200, Henrik Gramner wrote:
> >> On Sat, Oct 10, 2015 at 11:06 PM, Ganesh Ajjanagadde
> >> wrote:
> >> > This uses Stein's bi
On Sun, Oct 11, 2015 at 02:13:59AM +0200, Michael Niedermayer wrote:
> On Sat, Oct 10, 2015 at 07:45:17PM -0400, Ganesh Ajjanagadde wrote:
> > On Sat, Oct 10, 2015 at 7:14 PM, Michael Niedermayer
> > wrote:
> > > On Sat, Oct 10, 2015 at 11:32:06PM +0200, Henrik Gramner wrote:
> > >> On Sat, Oct 10
On Sat, Oct 10, 2015 at 8:13 PM, Michael Niedermayer
wrote:
> On Sat, Oct 10, 2015 at 07:45:17PM -0400, Ganesh Ajjanagadde wrote:
>> On Sat, Oct 10, 2015 at 7:14 PM, Michael Niedermayer
>> wrote:
>> > On Sat, Oct 10, 2015 at 11:32:06PM +0200, Henrik Gramner wrote:
>> >> On Sat, Oct 10, 2015 at 11
---
libavcodec/x86/vp9itxfm.asm | 84 +-
libavcodec/x86/vp9itxfm_16bpp.asm | 95 ---
2 files changed, 91 insertions(+), 88 deletions(-)
diff --git a/libavcodec/x86/vp9itxfm.asm b/libavcodec/x86/vp9itxfm.asm
index a3e0f86..6
On Sat, Oct 10, 2015 at 8:22 PM, Michael Niedermayer
wrote:
> On Sun, Oct 11, 2015 at 02:13:59AM +0200, Michael Niedermayer wrote:
>> On Sat, Oct 10, 2015 at 07:45:17PM -0400, Ganesh Ajjanagadde wrote:
>> > On Sat, Oct 10, 2015 at 7:14 PM, Michael Niedermayer
>> > wrote:
>> > > On Sat, Oct 10, 20
On Sat, Oct 10, 2015 at 8:34 PM, Ganesh Ajjanagadde wrote:
> On Sat, Oct 10, 2015 at 8:22 PM, Michael Niedermayer
> wrote:
>> On Sun, Oct 11, 2015 at 02:13:59AM +0200, Michael Niedermayer wrote:
>>> On Sat, Oct 10, 2015 at 07:45:17PM -0400, Ganesh Ajjanagadde wrote:
>>> > On Sat, Oct 10, 2015 at
On Sat, Oct 10, 2015 at 8:37 PM, Ganesh Ajjanagadde wrote:
> On Sat, Oct 10, 2015 at 8:34 PM, Ganesh Ajjanagadde wrote:
>> On Sat, Oct 10, 2015 at 8:22 PM, Michael Niedermayer
>> wrote:
>>> On Sun, Oct 11, 2015 at 02:13:59AM +0200, Michael Niedermayer wrote:
On Sat, Oct 10, 2015 at 07:45:17
This uses Stein's binary GCD algorithm:
https://en.wikipedia.org/wiki/Binary_GCD_algorithm
to get a roughly 4x speedup over Euclidean GCD on standard architectures
with a compiler intrinsic for ctzll, and a roughly 2x speedup otherwise.
At the moment, the compiler intrinsic is used on GCC and Clang
On Mon, Oct 05, 2015 at 05:08:56AM +0200, Michael Niedermayer wrote:
> On Sun, Oct 04, 2015 at 10:39:26PM -0400, Ganesh Ajjanagadde wrote:
> > On Sun, Oct 4, 2015 at 10:16 PM, Michael Niedermayer
> > wrote:
> > > On Sun, Oct 04, 2015 at 09:21:55PM -0400, Ganesh Ajjanagadde wrote:
> > >> Fixes CID
Based on code by Yuri Dario, http://svn.netlabs.org/repos/ports/pthread/trunk
Signed-off-by: Dave Yeo
---
compat/os2threads.h | 45 +
1 file changed, 45 insertions(+)
diff --git a/compat/os2threads.h b/compat/os2threads.h
index 5b6ca55..7f2c925 100644
Hi all,
Turns out that the De-Bruijn method can be used to speed up av_ctz as
well. But before going about it, I was curious as to why such an
interface is actually public. It makes absolutely zero sense to me:
usage is limited exactly to one location, namely libavcodec/flacenc.c.
Was this an acci
On 10/10/2015 11:44 PM, Ganesh Ajjanagadde wrote:
> Hi all,
>
> Turns out that the De-Bruijn method can be used to speed up av_ctz as
> well. But before going about it, I was curious as to why such an
> interface is actually public. It makes absolutely zero sense to me:
> usage is limited exactly
On Sat, Oct 10, 2015 at 09:58:47PM -0400, Ganesh Ajjanagadde wrote:
> This uses Stein's binary GCD algorithm:
> https://en.wikipedia.org/wiki/Binary_GCD_algorithm
> to get a roughly 4x speedup over Euclidean GCD on standard architectures
> with a compiler intrinsic for ctzll, and a roughly 2x speed
---
libavcodec/samidec.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/libavcodec/samidec.c b/libavcodec/samidec.c
index 95f35ab..8dd2749 100644
--- a/libavcodec/samidec.c
+++ b/libavcodec/samidec.c
@@ -46,6 +46,7 @@ static int sami_paragraph_to_ass(AVCo
hex_to_data should probably move to lavu before this is merged.
This is probably a good case for sub_charenc to run _after_ the decoder.
I could see an argument that this should go in the demuxer instead. Thoughts?
---
libavcodec/samidec.c | 78 +++
100 matches
Mail list logo
