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
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 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 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 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
ping?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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
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 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 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
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 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
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 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
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 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.
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 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 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 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 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
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 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)
+{
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 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 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
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
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
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
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, 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 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 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 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 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 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
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 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
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 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
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 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
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
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 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
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 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:
[...]
> +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
---
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 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
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
>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
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
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 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 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
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 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
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 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 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 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
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 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
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
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 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
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 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
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 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
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 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 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 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/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
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
> 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
---
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
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.
>>
>>
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
___
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]
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!
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
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
___
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
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
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
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
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 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 +--
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
95 matches
Mail list logo
