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 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 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 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/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
---
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
