Nicolas George nsup.org> writes:
> This is a waste of computing power and will result to 0,
> making it always dropped.
> Use maximum difference values instead.
Please commit.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ff
On Fri, Jan 01, 2016 at 04:40:06PM -0800, Aman Gupta wrote:
> From: Aman Gupta
>
> CC data is fed to in small chunks (usually 60 bytes at a time)
> and is parsed fully by the eia608 decoder. There is no reason to copy it
> into a secondary buffer first.
> ---
> libavcodec/ccaption_dec.c | 22 +--
Hi!
Attached patch fixes ticket #4792 for me, please comment.
Carl Eugen
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index e96bfb6..1ef3ecb 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -824,7 +824,7 @@ static int func_pts(AVFilterContext *ctx, A
On Wed, Dec 30, 2015 at 08:34:55PM -0800, Ganesh Ajjanagadde wrote:
> This gets rid of some branches to speed up table generation slightly
> (impact higher on mulaw than alaw). Tables are identical to before,
> tested with FATE.
>
> Sample benchmark (Haswell, GNU/Linux+gcc):
> old:
> 313494 decic
Le quartidi 14 nivôse, an CCXXIV, Carl Eugen Hoyos a écrit :
> Please commit.
Last news were you saying that this patch did not fix anything. Is there an
update?
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-de
Nicolas George nsup.org> writes:
> Le quartidi 14 nivôse, an CCXXIV, Carl Eugen Hoyos a écrit :
> > Please commit.
>
> Last news were you saying that this patch did not fix
> anything. Is there an update?
I am not convinced your patch fixes every issue but it
definitely improves the current c
On Sat, Jan 02, 2016 at 07:43:03PM +0100, Andreas Cadhalpun wrote:
> On 02.01.2016 19:14, Michael Niedermayer wrote:
> > On Sat, Jan 02, 2016 at 04:51:17PM +0100, Andreas Cadhalpun wrote:
> >> This fixes segmentation faults caused by passing a packet_ptr of NULL to
> >> memcpy.
> >>
> >> Signed-off
Le quartidi 14 nivôse, an CCXXIV, Carl Eugen Hoyos a écrit :
> I am not convinced your patch fixes every issue but it
> definitely improves the current code.
Ok, pushed.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
Hi!
Is there still something important missing?
Carl Eugen
diff --git a/libavcodec/dcadec.c b/libavcodec/dcadec.c
index 6b8d02d..4f8cf54 100644
--- a/libavcodec/dcadec.c
+++ b/libavcodec/dcadec.c
@@ -2038,7 +2038,7 @@ static av_cold int dca_decode_end(AVCodecContext *avctx)
static const AVOpti
On Sun, Jan 3, 2016 at 3:58 PM, Carl Eugen Hoyos wrote:
> Hi!
>
> Is there still something important missing?
>
Its still equally broken as it was when it was once commited - bugs
have not been fixed since then.
___
ffmpeg-devel mailing list
ffmpeg-deve
Hi!
Attached patch fixes ticket #4990 for me, I tested the following
command line:
$ ffmpeg -loglevel debug -i bugged.avi -vf fieldmatch,decimate -f null -
The first frames show the following debug output:
before:
[Parsed_decimate_0 @ 0x329e160] 1/5 frame drop:
[Parsed_decimate_0 @ 0x329e160]
Hendrik Leppkes gmail.com> writes:
> > Is there still something important missing?
>
> Its still equally broken as it was when it was
> once commited - bugs have not been fixed since
> then.
Could you elaborate on (some of) the bugs, I
was unable to find a report?
Thank you, Carl Eugen
___
On Sun, Jan 3, 2016 at 6:13 AM, Michael Niedermayer
wrote:
> On Wed, Dec 30, 2015 at 08:34:55PM -0800, Ganesh Ajjanagadde wrote:
>> This gets rid of some branches to speed up table generation slightly
>> (impact higher on mulaw than alaw). Tables are identical to before,
>> tested with FATE.
>>
>>
---
libavcodec/ccaption_dec.c | 43 +++
1 file changed, 7 insertions(+), 36 deletions(-)
diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index 9f67caa..1fdf7ed 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcodec/ccaption_dec.c
@@ -101
> It is still "speed critical" enough for people to retain
> CONFIG_HARDCODED_TABLES. My goal here is simple: I want to get cycle
> count down enough so that hardcoded tables can be removed here.
How are you going to guarantee this across all arches?
Whilst by all means feel free to work on what y
Hi,
On Sun, Jan 3, 2016 at 11:21 AM, Ganesh Ajjanagadde
wrote:
> It is still "speed critical" enough for people to retain
> CONFIG_HARDCODED_TABLES. My goal here is simple: I want to get cycle
> count down enough so that hardcoded tables can be removed here.
Can you explain why? Does CONFIG_HA
On 1/3/2016 5:33 PM, Clément Bœsch wrote:
> +return (0x6996966996696996ULL >> (x & 63) ^ (x>>7) ^ (x>>6)) & 1;
I mean, I see how it works, but it's incredibly non-obvious without the
patch context (table removal).
- Derek
___
ffmpeg-devel mailing li
On 1/3/2016 1:00 PM, Carl Eugen Hoyos wrote:
> Attached patch fixes ticket #4792 for me, please comment.
Looks OK.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 1/3/16, Carl Eugen Hoyos wrote:
> Hendrik Leppkes gmail.com> writes:
>
>> > Is there still something important missing?
>>
>> Its still equally broken as it was when it was
>> once commited - bugs have not been fixed since
>> then.
>
> Could you elaborate on (some of) the bugs, I
> was unable
On Sun, Jan 03, 2016 at 05:43:26PM +, Derek Buitenhuis wrote:
> On 1/3/2016 5:33 PM, Clément Bœsch wrote:
> > +return (0x6996966996696996ULL >> (x & 63) ^ (x>>7) ^ (x>>6)) & 1;
>
> I mean, I see how it works, but it's incredibly non-obvious without the
> patch context (table removal).
>
On Sun, Jan 3, 2016 at 9:43 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Jan 3, 2016 at 11:21 AM, Ganesh Ajjanagadde
> wrote:
>
>> It is still "speed critical" enough for people to retain
>> CONFIG_HARDCODED_TABLES. My goal here is simple: I want to get cycle
>> count down enough so that hardcod
On Sun, Jan 3, 2016 at 9:35 AM, Kieran Kunhya wrote:
>> It is still "speed critical" enough for people to retain
>> CONFIG_HARDCODED_TABLES. My goal here is simple: I want to get cycle
>> count down enough so that hardcoded tables can be removed here.
>
> How are you going to guarantee this across
From: Michael Niedermayer
This fixes a regression of the sample from Ticket 2371
Signed-off-by: Michael Niedermayer
---
libavcodec/h264.h |1 +
libavcodec/h264_refs.c | 11 +--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h264.h b/libavcodec/h26
On Sun, Jan 03, 2016 at 06:53:34PM +0100, Clément Bœsch wrote:
> On Sun, Jan 03, 2016 at 05:43:26PM +, Derek Buitenhuis wrote:
> > On 1/3/2016 5:33 PM, Clément Bœsch wrote:
> > > +return (0x6996966996696996ULL >> (x & 63) ^ (x>>7) ^ (x>>6)) & 1;
> >
> > I mean, I see how it works, but it's
On Sat, Jan 02, 2016 at 06:20:53PM +0100, Hendrik Leppkes wrote:
> On Sat, Dec 19, 2015 at 10:35 AM, Michael Niedermayer
> wrote:
> > On Thu, Dec 17, 2015 at 02:46:40PM +0100, Hendrik Leppkes wrote:
> >> On Thu, Dec 17, 2015 at 2:06 PM, Michael Niedermayer
> >> wrote:
> >> > From: Michael Nieder
On Sun, Jan 3, 2016 at 6:49 PM, foo86 wrote:
> This is initial version of libdcadec DCA decoder port I hacked together over
> the last week. This patch is of RFC/inquiry type and not meant for immediate
> inclusion.
>
> Any comments about the code are appreciated, as well as suggestions concerning
Clément Bœsch pkh.me> writes:
> -if (!parity_table[cc_data_pair[2]]) {
> +if (!get_parity(cc_data_pair[2]))
I this slower or faster than before the patch?
Replacing it with popcount seems ok either way
imo.
Carl Eugen
___
ffmpeg-deve
On 3 January 2016 at 18:17, Carl Eugen Hoyos wrote:
> Clément Bœsch pkh.me> writes:
>
>> -if (!parity_table[cc_data_pair[2]]) {
>> +if (!get_parity(cc_data_pair[2]))
I doubt this is speed critical.
Kieran
___
ffmpeg-devel mailing list
f
On 1/3/2016 2:49 PM, foo86 wrote:
> This is initial version of libdcadec DCA decoder port I hacked together over
> the last week. This patch is of RFC/inquiry type and not meant for immediate
> inclusion.
>
> Any comments about the code are appreciated, as well as suggestions concerning
> how shou
It serves absolutely no purpose other than to confuse potentional
Android developers about how to use hardware acceleration properly
on the the platform. Both stagefright itself, and MediaCodec, have
avcodec backends already, and this is the correct way to use it.
MediaCodec as a proper JNI API.
F
On 1/3/2016 6:05 PM, Clément Bœsch wrote:
> Now that I think a bit about, I could just do return av_popcount(x) & 1...
Sounds like a plan.
- derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 03.01.2016 02:03, Michael Niedermayer wrote:
> On Sun, Jan 03, 2016 at 01:35:39AM +0100, Andreas Cadhalpun wrote:
>> --- a/libavcodec/get_bits.h
>> +++ b/libavcodec/get_bits.h
>> @@ -269,6 +269,14 @@ static inline unsigned int get_bits(GetBitContext *s,
>> int n)
>> return tmp;
>> }
>>
On Sun, 3 Jan 2016 13:37:18 -0500
Derek Buitenhuis wrote:
> It serves absolutely no purpose other than to confuse potentional
> Android developers about how to use hardware acceleration properly
> on the the platform. Both stagefright itself, and MediaCodec, have
> avcodec backends already, and
On 1/3/2016 3:11 PM, Carl Eugen Hoyos wrote:
> With the patch, the frame with the lowest diff is actually dropped
> instead of the first frame that indicates a scene change without
> the patch (iiuc).
Is this for all scene changes or just frame 0? If for all scene changes, ignore
the lower comme
On Sun, 3 Jan 2016 20:49:10 +0300
foo86 wrote:
> This is initial version of libdcadec DCA decoder port I hacked together over
> the last week. This patch is of RFC/inquiry type and not meant for immediate
> inclusion.
>
> Any comments about the code are appreciated, as well as suggestions concer
Yes, considering the security vulnerabilities in stagefright, the reported
underuse, confusion and the fact that the Android framework already
provides a proper native API to do hardware and software (though plugins)
decoding, I see no reason why this should not be dropped from Git master
and the n
On 1/3/2016 6:47 PM, Rostislav Pehlivanov wrote:
> I see no reason why this should not be dropped from Git master
> and the next stable release.
I was unsure if this should be dropped in a minor or major bump, actually.
- Derek
___
ffmpeg-devel mailing
On 03.01.2016 02:41, Michael Niedermayer wrote:
> On Sun, Jan 03, 2016 at 01:36:13AM +0100, Andreas Cadhalpun wrote:
>> get_bits is documented to only support reading 1-25 bits.
>> get_bitsz was added for this purpose.
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavcodec/vorbisdec.c | 4 ++
On Sun, 3 Jan 2016 13:37:18 -0500
Derek Buitenhuis wrote:
> It serves absolutely no purpose other than to confuse potentional
> Android developers about how to use hardware acceleration properly
> on the the platform. Both stagefright itself, and MediaCodec, have
> avcodec backends already, and
On 1/3/2016 3:44 PM, wm4 wrote:
> On Sun, 3 Jan 2016 20:49:10 +0300
> foo86 wrote:
>
>> This is initial version of libdcadec DCA decoder port I hacked together over
>> the last week. This patch is of RFC/inquiry type and not meant for immediate
>> inclusion.
>>
>> Any comments about the code are
On 1/3/2016 6:37 PM, Derek Buitenhuis wrote:
> Both stagefright itself, and MediaCodec, have
> avcodec backends already, and this is the correct way to use it.
This bit is wrong. The correct way is to use MediaCodecs API,
since stagefright is not a public API, I have been informed.
I think Martin
>IMO this should replace the current dca decoder. Based on what i saw from
libdcadec
>yours is cleaner, more feature complete, you're a knowledgeable
maintainer, and
>since the current developer for ffdca over at libav is porting code from
yours to
>get bitexact xll working the code duplication wou
Derek Buitenhuis gmail.com> writes:
>
> On 1/3/2016 3:11 PM, Carl Eugen Hoyos wrote:
> > With the patch, the frame with the lowest diff is actually dropped
> > instead of the first frame that indicates a scene change without
> > the patch (iiuc).
>
> Is this for all scene changes or just fram
On 1/3/2016 7:04 PM, Carl Eugen Hoyos wrote:
> "dm->scthresh+1" is equivalent to INT_MAX afaict and
> makes the given sample fail with our decimate filter.
I think it should be OK, then.
Perhaps Clement can comment if not.
- Derek
___
ffmpeg-devel mai
---
libavcodec/g729dec.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/libavcodec/g729dec.c b/libavcodec/g729dec.c
index 99053ad..7265883 100644
--- a/libavcodec/g729dec.c
+++ b/libavcodec/g729dec.c
@@ -181,14 +181,6 @@ static inline uint16_t g729_prng(uint16_t valu
---
configure | 2 ++
libavutil/x86/intmath.h | 9 +
2 files changed, 11 insertions(+)
diff --git a/configure b/configure
index 6710f85..610be92 100755
--- a/configure
+++ b/configure
@@ -1738,6 +1738,7 @@ BUILTIN_LIST="
machine_rw_barrier
MemoryBarrier
mm_emp
---
libavcodec/ccaption_dec.c | 38 ++
1 file changed, 2 insertions(+), 36 deletions(-)
diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index 9f67caa..c39fefd 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcodec/ccaption_dec.c
@@ -101,40 +
On Sun, Jan 03, 2016 at 08:21:00PM +0100, Clément Bœsch wrote:
[...]
> +static av_always_inline av_const int ff_parity(uint32_t v)
> +{
> +#if HAVE_PARITY
> +return __builtin_parity(v);
> +#else
> +return av_popcount(v) & 1;
doing a popcount being overkill, this could be replaced with
(0x6
On Sun, Jan 03, 2016 at 03:58:04PM +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> Is there still something important missing?
the code below or a change to bits_long
also there are segfaults
try with a fuzzer
diff --git a/libavcodec/dca_xll.c b/libavcodec/dca_xll.c
index 98fd4c8..60efa16 100644
--- a/
On Sun, Jan 03, 2016 at 08:21:00PM +0100, Clément Bœsch wrote:
> ---
> configure | 2 ++
> libavutil/x86/intmath.h | 9 +
> 2 files changed, 11 insertions(+)
>
> diff --git a/configure b/configure
> index 6710f85..610be92 100755
> --- a/configure
> +++ b/configure
> @@ -1738
On 02.01.2016 18:56, Rostislav Pehlivanov wrote:
> --- /dev/null
> +++ b/libavcodec/daala_entropy.h
> @@ -0,0 +1,464 @@
[...]
> +/* Expectation value is in Q16 */
> +static inline int daalaent_decode_generic(DaalaEntropy *e, DaalaCDF *c, int
> *ex,
> + int
James Almer gmail.com> writes:
> But by all means lets not have another prores
> or asf/wmv demuxer situation.
The asf situation can be fixed anytime, nobody
is working on the broken demuxer...
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel
On Sun, Jan 03, 2016 at 07:41:49PM +0100, Andreas Cadhalpun wrote:
> On 03.01.2016 02:03, Michael Niedermayer wrote:
> > On Sun, Jan 03, 2016 at 01:35:39AM +0100, Andreas Cadhalpun wrote:
> >> --- a/libavcodec/get_bits.h
> >> +++ b/libavcodec/get_bits.h
> >> @@ -269,6 +269,14 @@ static inline unsig
On Sun, Jan 03, 2016 at 07:14:28PM +0100, Hendrik Leppkes wrote:
> Having two dca decoders with varying degrees of features is no
> advantages, and considering the native decoder lacks a long list of
> features and fails decoding a bunch of XLL streams, the aim should be
> to replace.
> I'm not awa
Signed-off-by: Paul B Mahol
---
libavfilter/avf_showspectrum.c | 357 -
1 file changed, 285 insertions(+), 72 deletions(-)
diff --git a/libavfilter/avf_showspectrum.c b/libavfilter/avf_showspectrum.c
index d9fae7f..a40d189 100644
--- a/libavfilter/avf_show
On 03.01.2016 15:52, Michael Niedermayer wrote:
> On Sat, Jan 02, 2016 at 07:43:03PM +0100, Andreas Cadhalpun wrote:
>> ffmdec.c |9 ++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>> 1600298d54df3b7c7c74d4437521405b38342c60
>> 0001-ffmdec-reset-packet_end-in-case-of-failure.pat
On 03.01.2016 20:39, Michael Niedermayer wrote:
> On Sun, Jan 03, 2016 at 07:41:49PM +0100, Andreas Cadhalpun wrote:
>> get_bits.h |8
>> mpegaudiodec_template.c |7 ---
>> 2 files changed, 8 insertions(+), 7 deletions(-)
>> 0d68f088494147aaab5cdd3b3e42fed473b6bc4
On Sun, 3 Jan 2016 20:21:00 +0100
Clément Bœsch wrote:
> ---
> configure | 2 ++
> libavutil/x86/intmath.h | 9 +
> 2 files changed, 11 insertions(+)
>
> diff --git a/configure b/configure
> index 6710f85..610be92 100755
> --- a/configure
> +++ b/configure
> @@ -1738,6 +1
This is a WIP patch for the RAM playlist format:
http://service.real.com/help/library/guides/realone/IntroGuide/HTML/htmfiles/ramfile.htm,
http://service.real.com/help/library/guides/realone/IntroGuide/HTML/htmfiles/ramsum.htm.
The implementation is currently essentially a kitchen sink dump of
con
On 1/3/2016 4:22 PM, Clément Bœsch wrote:
> On Sun, Jan 03, 2016 at 08:21:00PM +0100, Clément Bœsch wrote:
> [...]
>> +static av_always_inline av_const int ff_parity(uint32_t v)
>> +{
>> +#if HAVE_PARITY
>> +return __builtin_parity(v);
>> +#else
>> +return av_popcount(v) & 1;
>
> doing a p
On 1/3/2016 5:33 PM, wm4 wrote:
> On Sun, 3 Jan 2016 20:21:00 +0100
> Clément Bœsch wrote:
>
>> ---
>> configure | 2 ++
>> libavutil/x86/intmath.h | 9 +
>> 2 files changed, 11 insertions(+)
>>
>> diff --git a/configure b/configure
>> index 6710f85..610be92 100755
>> ---
On Sun, Jan 3, 2016 at 9:42 PM, Ganesh Ajjanagadde
wrote:
> This is a WIP patch for the RAM playlist format:
> http://service.real.com/help/library/guides/realone/IntroGuide/HTML/htmfiles/ramfile.htm,
> http://service.real.com/help/library/guides/realone/IntroGuide/HTML/htmfiles/ramsum.htm.
>
> Th
On Sun, 3 Jan 2016 21:59:21 +0100
Hendrik Leppkes wrote:
> On Sun, Jan 3, 2016 at 9:42 PM, Ganesh Ajjanagadde
> wrote:
> > This is a WIP patch for the RAM playlist format:
> > http://service.real.com/help/library/guides/realone/IntroGuide/HTML/htmfiles/ramfile.htm,
> > http://service.real.com/he
On Sun, Jan 3, 2016 at 1:05 PM, wm4 wrote:
> On Sun, 3 Jan 2016 21:59:21 +0100
> Hendrik Leppkes wrote:
>
>> On Sun, Jan 3, 2016 at 9:42 PM, Ganesh Ajjanagadde
>> wrote:
>> > This is a WIP patch for the RAM playlist format:
>> > http://service.real.com/help/library/guides/realone/IntroGuide/HTML
On Sun, 3 Jan 2016, Derek Buitenhuis wrote:
It serves absolutely no purpose other than to confuse potentional
Android developers about how to use hardware acceleration properly
on the the platform. Both stagefright itself, and MediaCodec, have
avcodec backends already, and this is the correct wa
On Sun, Jan 3, 2016 at 12:59 PM, Hendrik Leppkes wrote:
> On Sun, Jan 3, 2016 at 9:42 PM, Ganesh Ajjanagadde
> wrote:
>> This is a WIP patch for the RAM playlist format:
>> http://service.real.com/help/library/guides/realone/IntroGuide/HTML/htmfiles/ramfile.htm,
>> http://service.real.com/help/li
On Sun, Jan 3, 2016 at 9:35 AM, Kieran Kunhya wrote:
>> It is still "speed critical" enough for people to retain
>> CONFIG_HARDCODED_TABLES. My goal here is simple: I want to get cycle
>> count down enough so that hardcoded tables can be removed here.
>
> How are you going to guarantee this across
Ganesh Ajjanagadde mit.edu> writes:
> No one has told me what is interesting
Did you look at tickets #4441 or #4085?
(Careful about the license for the second one.)
But you can only decide for yourself what you
find interesting...
Carl Eugen
___
ffm
Carl Eugen Hoyos ag.or.at> writes:
> Ganesh Ajjanagadde mit.edu> writes:
>
> > No one has told me what is interesting
>
> Did you look at tickets #4441 or #4085?
Or ticket #4829 or a j2k issue?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel
On Sun, Jan 03, 2016 at 05:56:41PM -0300, James Almer wrote:
[...]
> >> +static av_always_inline av_const int ff_parity(uint32_t v)
> >> +{
> >> +#if HAVE_PARITY
> >> +return __builtin_parity(v);
> >> +#else
> >> +return av_popcount(v) & 1;
> >> +#endif
> >
> > Do compilers really generate
On Sun, Jan 03, 2016 at 05:54:34PM -0300, James Almer wrote:
> On 1/3/2016 4:22 PM, Clément Bœsch wrote:
> > On Sun, Jan 03, 2016 at 08:21:00PM +0100, Clément Bœsch wrote:
> > [...]
> >> +static av_always_inline av_const int ff_parity(uint32_t v)
> >> +{
> >> +#if HAVE_PARITY
> >> +return __bui
On Sun, Jan 03, 2016 at 07:50:39PM +0100, Andreas Cadhalpun wrote:
> On 03.01.2016 02:41, Michael Niedermayer wrote:
> > On Sun, Jan 03, 2016 at 01:36:13AM +0100, Andreas Cadhalpun wrote:
> >> get_bits is documented to only support reading 1-25 bits.
> >> get_bitsz was added for this purpose.
> >>
On 1/3/2016 6:33 PM, Clément Bœsch wrote:
> On Sun, Jan 03, 2016 at 05:54:34PM -0300, James Almer wrote:
>> On 1/3/2016 4:22 PM, Clément Bœsch wrote:
>>> On Sun, Jan 03, 2016 at 08:21:00PM +0100, Clément Bœsch wrote:
>>> [...]
+static av_always_inline av_const int ff_parity(uint32_t v)
+{
Derek Buitenhuis gmail.com> writes:
> On 1/3/2016 1:00 PM, Carl Eugen Hoyos wrote:
> > Attached patch fixes ticket #4792 for me, please comment.
>
> Looks OK.
Thank you, patch applied.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Sun, Jan 03, 2016 at 08:21:02PM +0100, Clément Bœsch wrote:
> ---
> libavcodec/g729dec.c | 10 +-
> 1 file changed, 1 insertion(+), 9 deletions(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have often repented speaking, but never of h
On Sun, Jan 03, 2016 at 08:21:01PM +0100, Clément Bœsch wrote:
> ---
> libavcodec/ccaption_dec.c | 38 ++
> 1 file changed, 2 insertions(+), 36 deletions(-)
should be ok
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Aw
On 1/3/16, Ganesh Ajjanagadde wrote:
> On Sun, Jan 3, 2016 at 12:59 PM, Hendrik Leppkes
> wrote:
>> On Sun, Jan 3, 2016 at 9:42 PM, Ganesh Ajjanagadde
>> wrote:
>>> This is a WIP patch for the RAM playlist format:
>>> http://service.real.com/help/library/guides/realone/IntroGuide/HTML/htmfiles/r
On 03.01.2016 22:50, Michael Niedermayer wrote:
> On Sun, Jan 03, 2016 at 07:50:39PM +0100, Andreas Cadhalpun wrote:
>> vorbisdec.c |5 +
>> 1 file changed, 5 insertions(+)
>> ba151dadb72b6c74e1139decf4b32c8676ddc58e
>> 0001-vorbisdec-reject-rangebits-0.patch
>> From d740a59b6e099c90504d
On 03.01.2016 22:50, Michael Niedermayer wrote:
> On Sun, Jan 03, 2016 at 07:50:39PM +0100, Andreas Cadhalpun wrote:
>> vorbisdec.c |5 +
>> 1 file changed, 5 insertions(+)
>> d8862de6632822fd066a585953e5966fd941ad93
>> 0002-vorbisdec-reject-channel-mapping-with-less-than-two-.patch
>> F
On Fri, Jan 01, 2016 at 08:07:39AM -0800, Ganesh Ajjanagadde wrote:
> Hi all,
>
> Motivated by a remark by Ronald:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186200.html,
> this is a request for comment on disabling compile time tablegen for
> cbrt if the total cycle count < 20.
Hi,
In general looks good, although it might look a bit weird for someone
as usually libraries have initialization functions called like that.
That said, this is what
https://gnupg.org/documentation/manuals/gcrypt/Initializing-the-library.html
recommends.
My only comment would be that we might wa
On Sun, Jan 3, 2016 at 7:03 PM, Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> This fixes a regression of the sample from Ticket 2371
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/h264.h |1 +
> libavcodec/h264_refs.c | 11 +--
> 2 files changed, 10 in
On Mon, Jan 04, 2016 at 12:07:15AM +0100, Michael Niedermayer wrote:
> On Fri, Jan 01, 2016 at 08:07:39AM -0800, Ganesh Ajjanagadde wrote:
> > Hi all,
> >
> > Motivated by a remark by Ronald:
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186200.html,
> > this is a request for comment
On Mon, Jan 04, 2016 at 12:21:40AM +0100, Michael Niedermayer wrote:
> On Mon, Jan 04, 2016 at 12:07:15AM +0100, Michael Niedermayer wrote:
> > On Fri, Jan 01, 2016 at 08:07:39AM -0800, Ganesh Ajjanagadde wrote:
> > > Hi all,
> > >
> > > Motivated by a remark by Ronald:
> > > https://ffmpeg.org/pi
Decodes YUV422P10 samples in AVI and MOV (Gopro Studio)
Older files with more subbands, skips, Bayer not supported
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 1 +
libavcodec/cfhd.c | 567
On Sun, Jan 03, 2016 at 11:44:02PM +0100, Andreas Cadhalpun wrote:
> On 03.01.2016 22:50, Michael Niedermayer wrote:
> > On Sun, Jan 03, 2016 at 07:50:39PM +0100, Andreas Cadhalpun wrote:
> >> vorbisdec.c |5 +
> >> 1 file changed, 5 insertions(+)
> >> ba151dadb72b6c74e1139decf4b32c8676ddc
On Mon, Jan 04, 2016 at 12:14:44AM +0100, Hendrik Leppkes wrote:
> On Sun, Jan 3, 2016 at 7:03 PM, Michael Niedermayer wrote:
> > From: Michael Niedermayer
> >
> > This fixes a regression of the sample from Ticket 2371
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/h264.h
On 3 January 2016 at 23:13, Jan Ekstrom wrote:
> Hi,
>
> In general looks good, although it might look a bit weird for someone
> as usually libraries have initialization functions called like that.
> That said, this is what
>
> https://gnupg.org/documentation/manuals/gcrypt/Initializing-the-libra
On Wed, Dec 30, 2015 at 08:34:55PM -0800, Ganesh Ajjanagadde wrote:
> This gets rid of some branches to speed up table generation slightly
> (impact higher on mulaw than alaw). Tables are identical to before,
> tested with FATE.
>
> Sample benchmark (Haswell, GNU/Linux+gcc):
> old:
> 313494 decic
ping?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Mon, Jan 04, 2016 at 04:04:02AM +0100, Michael Niedermayer wrote:
> On Wed, Dec 30, 2015 at 08:34:55PM -0800, Ganesh Ajjanagadde wrote:
> > This gets rid of some branches to speed up table generation slightly
> > (impact higher on mulaw than alaw). Tables are identical to before,
> > tested with
On Sun, Jan 3, 2016 at 7:32 PM, Michael Niedermayer
wrote:
> On Mon, Jan 04, 2016 at 04:04:02AM +0100, Michael Niedermayer wrote:
>> On Wed, Dec 30, 2015 at 08:34:55PM -0800, Ganesh Ajjanagadde wrote:
>> > This gets rid of some branches to speed up table generation slightly
>> > (impact higher on
On Sun, Jan 3, 2016 at 3:07 PM, Michael Niedermayer
wrote:
> On Fri, Jan 01, 2016 at 08:07:39AM -0800, Ganesh Ajjanagadde wrote:
>> Hi all,
>>
>> Motivated by a remark by Ronald:
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186200.html,
>> this is a request for comment on disabling co
On Sun, Jan 3, 2016 at 2:29 PM, Paul B Mahol wrote:
> On 1/3/16, Ganesh Ajjanagadde wrote:
>> On Sun, Jan 3, 2016 at 12:59 PM, Hendrik Leppkes
>> wrote:
>>> On Sun, Jan 3, 2016 at 9:42 PM, Ganesh Ajjanagadde
>>> wrote:
This is a WIP patch for the RAM playlist format:
http://service.re
On Sun, Jan 3, 2016 at 1:30 PM, Carl Eugen Hoyos wrote:
> Carl Eugen Hoyos ag.or.at> writes:
>
>> Ganesh Ajjanagadde mit.edu> writes:
>>
>> > No one has told me what is interesting
>>
>> Did you look at tickets #4441 or #4085?
>
> Or ticket #4829 or a j2k issue?
Thanks a lot for taking the time
95 matches
Mail list logo
