Re: [FFmpeg-devel] IRC meeting

2016-06-03 Thread Christophe Gisquet
Hi, sorry if I'm or was confusing, I'm best-effort here. 2016-06-03 21:13 GMT+02:00 Michael Niedermayer : > > FOUR.TWO) [...] > i want some assistent to help with dayly server admin duties > most root admins we have help and contribute but are often busy > raz recently

Re: [FFmpeg-devel] IRC meeting

2016-06-03 Thread Christophe Gisquet
Hi, here's I think a list of things left to do. I remember saste doing it on some occasions. Please comment on whether you think I have pointed an actual action to perform. Don't mind the details for now, it's just to get the train going. 2016-05-30 10:49 GMT+02:00 Michael Niedermayer

Re: [FFmpeg-devel] [PATCH] avcodec: add MagicYUV decoder

2016-06-01 Thread Christophe Gisquet
2016-05-30 17:50 GMT+02:00 Paul B Mahol : > On 5/30/16, Piotr Bandurski wrote: >> Hi, >> >>> patch attached. >> >> Is decoding of interlaced video supported? Because I get here invalid >> output. >> >> Also crash happens with this fuzzed file: >> >>

Re: [FFmpeg-devel] [PATCH] avcodec: add MagicYUV decoder

2016-05-31 Thread Christophe Gisquet
Hi, 2016-05-30 15:09 GMT+02:00 Paul B Mahol : Hi, 2016-05-30 15:09 GMT+02:00 Paul B Mahol : >> ffmpeg seems to have libavutil/qsort.h, but I don't even know how much >> effort is needed to use it here. > > Changed, doesn't help but maybe will for other archs.

Re: [FFmpeg-devel] [PATCH] avcodec: add MagicYUV decoder

2016-05-30 Thread Christophe Gisquet
Hi, 2016-05-29 21:51 GMT+02:00 Paul B Mahol : > +typedef struct Slice { > +uint32_t start; > +uint32_t size; > +} Slice; I'm not a security expert, but is there a reason for not using plain int there ? > +typedef struct MagicYUVContext { > +AVFrame*p; >

Re: [FFmpeg-devel] Remove Derek Buitenhuis from MAINTAINERS

2016-05-20 Thread Christophe Gisquet
Hi, 2016-05-20 1:55 GMT+02:00 Lukasz Marek : > Is Derek revoked to commit or what? Couldn't he just commit this patch and > leave? :P I was a problem for some people, but I see they still have > problems. Let people with problems go away with they problems. Sorry if

Re: [FFmpeg-devel] [Vote] Code of Conduct

2016-05-20 Thread Christophe Gisquet
Hi, 2016-05-18 20:40 GMT+02:00 Michael Niedermayer : > Please state clearly if you agree to the text or if not. > we can extend and tune it later and do another vote if there are more > suggestions I agree to having a CoC. This text is a first step, so I'm ok with it,

Re: [FFmpeg-devel] [PATCH] doc/developer.texi: Add a code of conduct

2016-05-20 Thread Christophe Gisquet
Hi, 2016-05-20 2:38 GMT+02:00 Timothy Gu : >> > Note how it has a list of specific violations, instead of vague things like >> > "Be excellent" that the FFmpeg one has. >> > Note how it has a huge section on disciplinary procedures. [...] > I have to agree with Kieran here.

Re: [FFmpeg-devel] [PATCH 01/10] avcodec/dca: remove Rice code length limit

2016-05-20 Thread Christophe Gisquet
2016-05-13 11:48 GMT+02:00 foo86 : > -unsigned int v = get_unary(gb, 1, 128); > +unsigned int v = get_unary(gb, 1, get_bits_left(gb)); Not that the patch is not ok, but I have a few uneducated questions: 1) Given the get_bits_long(gb, k) afterwards, won't that code

Re: [FFmpeg-devel] [PATCH 4/4] lossless audio dsp: unroll

2016-05-11 Thread Christophe Gisquet
2016-05-01 15:33 GMT+02:00 Christophe Gisquet <christophe.gisq...@gmail.com>: > The loops are guaranteed to be at least multiples of 8, so this > unrolling is safe but allows exploiting execution ports. > > For int32 version: 68 -> 58c. Ping? This was ok'ed by James irr

Re: [FFmpeg-devel] [PATCH] vc2enc_dwt: use 32 bit coefficients by default

2016-05-08 Thread Christophe Gisquet
2016-05-07 21:48 GMT+02:00 Rostislav Pehlivanov : > The costliest part of the encoder right now is encoding the coefficients > (~36%). Slightly less-costly is rate control (~31%), and after that is the > transform (~12%). There really isn't anything else, other than 3 copies

Re: [FFmpeg-devel] [PATCH] vc2enc_dwt: use 32 bit coefficients by default

2016-05-07 Thread Christophe Gisquet
2016-05-07 19:12 GMT+02:00 Rostislav Pehlivanov : > The problem is that with particularly complex images and especially at > high bit depths and 5-level transforms the coefficients would overflow I guess it also depends on the transform type, so that counts also for the last

Re: [FFmpeg-devel] [PATCH 1/2] vc2enc: prevent random data

2016-05-06 Thread Christophe Gisquet
Hi, 2016-05-06 2:19 GMT+02:00 Rostislav Pehlivanov : > I plan to merge the fate tests as well tomorrow or on Saturday when I'll > have time to quickly fix bugs which appear on platforms I haven't tested > the encoder on. Hopefully none, but you never know. Sure, makes sense.

[FFmpeg-devel] [PATCH 2/2] vc2: fate tests

2016-05-05 Thread Christophe Gisquet
--- tests/fate/vcodec.mak | 17 - tests/ref/vsynth/vsynth1-vc2-420p | 4 tests/ref/vsynth/vsynth1-vc2-420p10 | 4 tests/ref/vsynth/vsynth1-vc2-420p12 | 4 tests/ref/vsynth/vsynth1-vc2-422p | 4

[FFmpeg-devel] [PATCH 1/2] vc2enc: prevent random data

2016-05-05 Thread Christophe Gisquet
The slice prefix is 0 in the reference encoder and the decoder ignores it. Writing 0 there seems like the best temporary solution. The padding could have contained uninitialized data, but reference VC2 encoders put 0xFF there, hence the memset value. Overall this allows producing bistreams with

Re: [FFmpeg-devel] [PATCH 1/2] vc2enc: prevent random data

2016-05-04 Thread Christophe Gisquet
Hi, 2016-05-04 3:06 GMT+02:00 Rostislav Pehlivanov : > vc2hqencode is not the reference encoder, vc2-reference is. It's even worse > though. Sorry, I thought authoritative could mean "from the authors", so I didn't mean it as "the" reference/"the authority". Just a good

Re: [FFmpeg-devel] [PATCH 1/2] vc2enc: prevent random data

2016-05-03 Thread Christophe Gisquet
Le 3 mai 2016 22:15, "Rostislav Pehlivanov" <atomnu...@gmail.com> a écrit : > > On 3 May 2016 at 19:16, Christophe Gisquet <christophe.gisq...@gmail.com> > wrote: > > > > > > Btw, afaik, the padding is 0xFF, so expecting 0 in the buffer there &g

Re: [FFmpeg-devel] [PATCH 1/2] vc2enc: prevent random data

2016-05-03 Thread Christophe Gisquet
Hi, 2016-05-03 19:24 GMT+02:00 Hendrik Leppkes : >> +// The reference decoder ignores it, and its typical length is 0 >> +memset(put_bits_ptr(pb), 0, s->prefix_bytes); >> skip_put_bytes(pb, s->prefix_bytes); >> + > > I don't suppose we have a function to just

[FFmpeg-devel] [PATCH 0/2] Fix VC-2 encoder

2016-05-03 Thread Christophe Gisquet
are added. Suggestions for being even more concise in the target/rules are welcome. Christophe Gisquet (2): vc2enc: prevent random data vc2: fate tests libavcodec/vc2enc.c | 4 tests/fate/vcodec.mak | 17 - tests/ref/vsynth/vsynth1-vc2

[FFmpeg-devel] [PATCH 1/2] vc2enc: prevent random data

2016-05-03 Thread Christophe Gisquet
The slice prefix is 0 in the reference encoder and the decoder ignores it. Writing 0 there seems like the best temporary solution. The padding could have contained uninitialized data, but its standardized value is 0xFF, hence the memset value. Overall this allows producing bistreams with no

Re: [FFmpeg-devel] [PATCH 2/2] vc2: fate tests

2016-05-03 Thread Christophe Gisquet
2016-05-03 19:06 GMT+02:00 Christophe Gisquet <christophe.gisq...@gmail.com>: [SNIP] Incorrect padding used (0 instead of 0xFF), fixed in that patch series. -- Christophe From 22ff25711062fb1ca30da1674fd622fd6f81c8e3 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet <christ

Re: [FFmpeg-devel] [PATCH 1/2] vc2enc: prevent random data

2016-05-03 Thread Christophe Gisquet
2016-05-03 19:06 GMT+02:00 Christophe Gisquet <christophe.gisq...@gmail.com>: > +memset(pb->buf_ptr, 0, pad_c); Commit squashing fail, attached patch should fix that. This unfortunately requires updating the fate tests as I generated them from this squashing. -- Chr

[FFmpeg-devel] [PATCH 2/2] vc2: fate tests

2016-05-03 Thread Christophe Gisquet
--- tests/fate/vcodec.mak | 17 - tests/ref/vsynth/vsynth1-vc2-420p | 4 tests/ref/vsynth/vsynth1-vc2-420p10 | 4 tests/ref/vsynth/vsynth1-vc2-420p12 | 4 tests/ref/vsynth/vsynth1-vc2-422p | 4

Re: [FFmpeg-devel] [PATCH 1/4] fate: wma: add lossless 24bits test

2016-05-02 Thread Christophe Gisquet
Hi, 2016-05-02 16:02 GMT+02:00 Michael Niedermayer : >> +fate-lossless-wma24-rawtile: CMD = md5 -i >> $(TARGET_SAMPLES)/lossless-audio/g2_24bit.wma -f s24le > > where can i find that file ? > i assume i should upload it ? Sorry, I thought we had discussed it in this

Re: [FFmpeg-devel] [PATCH 2/4] wmalossless: allow calling madd_int16

2016-05-01 Thread Christophe Gisquet
2016-05-01 15:33 GMT+02:00 Christophe Gisquet <christophe.gisq...@gmail.com>: > This is done by actually handling the "prev_values" in the cascaded LMS data > as if it were int16_t, thus requiring switching at various locations the > computations. Patch update s

Re: [FFmpeg-devel] [PATCH 1/4] fate: wma: add lossless 24bits test

2016-05-01 Thread Christophe Gisquet
h raw pcm tiles then. -- Christophe From 584999fcce24585f989d2dc770e8c7c85aa19db7 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet <christophe.gisq...@gmail.com> Date: Mon, 18 Apr 2016 12:53:21 +0200 Subject: [PATCH 1/4] fate: wma: add lossless 24bits tests Should evaluate coefficients and raw pcm t

Re: [FFmpeg-devel] [PATCH 1/4] fate: wma: add lossless 24bits test

2016-05-01 Thread Christophe Gisquet
Hi, 2016-05-01 15:33 GMT+02:00 Christophe Gisquet <christophe.gisq...@gmail.com>: > +fate-lossless-wma24-2: CMD = md5 -i > $(TARGET_SAMPLES)/lossless-audio/Mega_Weird_Audio_Test_24bit.wma -f s24le The recent fixes actually changed the crc for that file. Is https://trac.ffmpeg.or

[FFmpeg-devel] [PATCH 2/4] wmalossless: allow calling madd_int16

2016-05-01 Thread Christophe Gisquet
This is done by actually handling the "prev_values" in the cascaded LMS data as if it were int16_t, thus requiring switching at various locations the computations. --- libavcodec/wmalosslessdec.c | 109 +++- 1 file changed, 58 insertions(+), 51 deletions(-)

[FFmpeg-devel] [PATCH 3/4] x86: lossless audio: SSE4 madd 32bits

2016-05-01 Thread Christophe Gisquet
The unique user so far is wmalossless 24bits. The few samples tested show an order of 8, so more unrolling or an avx2 version do not make sense. Timings: 68 -> 49 cycles --- libavcodec/x86/lossless_audiodsp.asm| 33 + libavcodec/x86/lossless_audiodsp_init.c |

[FFmpeg-devel] [PATCH 1/4] fate: wma: add lossless 24bits test

2016-05-01 Thread Christophe Gisquet
--- tests/fate/lossless-audio.mak | 5 - tests/ref/fate/lossless-wma24-1 | 1 + tests/ref/fate/lossless-wma24-2 | 1 + 3 files changed, 6 insertions(+), 1 deletion(-) create mode 100644 tests/ref/fate/lossless-wma24-1 create mode 100644 tests/ref/fate/lossless-wma24-2 diff --git

[FFmpeg-devel] [PATCH 4/4] lossless audio dsp: unroll

2016-05-01 Thread Christophe Gisquet
The loops are guaranteed to be at least multiples of 8, so this unrolling is safe but allows exploiting execution ports. For int32 version: 68 -> 58c. --- libavcodec/lossless_audiodsp.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git

[FFmpeg-devel] [PATCH 0/4] wmalossless: fix 16bits speed regression v3

2016-05-01 Thread Christophe Gisquet
Due to the changes to the cascaded LMS coefficients, most of the code needed a rewrite. In particular, the SSE4 madd32 code is no longer that similar to be shared inside a macro. Christophe Gisquet (4): fate: wma: add lossless 24bits test wmalossless: allow calling madd_int16 x86: lossless

[FFmpeg-devel] [PATCH 1/5] fate: wma: add lossless 24bits test

2016-04-30 Thread Christophe Gisquet
--- tests/fate/lossless-audio.mak | 5 - tests/ref/fate/lossless-wma24-1 | 1 + tests/ref/fate/lossless-wma24-2 | 1 + 3 files changed, 6 insertions(+), 1 deletion(-) create mode 100644 tests/ref/fate/lossless-wma24-1 create mode 100644 tests/ref/fate/lossless-wma24-2 diff --git

[FFmpeg-devel] [PATCH 2/5] wmalossless: allow calling madd_int16

2016-04-30 Thread Christophe Gisquet
This is done by actually handling the cascaded LMS data as if it were int16_t, thus requiring switching at various locations the computations. --- libavcodec/wmalosslessdec.c | 146 +--- 1 file changed, 84 insertions(+), 62 deletions(-) diff --git

[FFmpeg-devel] [PATCH 5/5] wmalossless: silence a sample request

2016-04-30 Thread Christophe Gisquet
16bits samples with CDLMS orders of 8 are currently unsupported, but have never been encountered before. However, 8 seems to be the most frequent, if not the only order used for 24bits. In that case, the dsp functions are fine with handling order that are multiples of 8, so silence the warning.

[FFmpeg-devel] [PATCH 3/5] x86: lossless audio: SSE4 madd 32bits

2016-04-30 Thread Christophe Gisquet
The unique user so far is wmalossless 24bits. The few samples tested show an order of 8, so more unrolling or an avx2 version do not make sense. Timings: 72 -> 49 cycles --- libavcodec/x86/lossless_audiodsp.asm| 31 +-- libavcodec/x86/lossless_audiodsp_init.c | 7

[FFmpeg-devel] [PATCH 4/5] lossless audio dsp: unroll

2016-04-30 Thread Christophe Gisquet
The loops are guaranteed to be at least multiples of 8, so this unrolling is safe but allows exploiting execution ports. For int32 version: 72 -> 57c. --- libavcodec/lossless_audiodsp.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git

[FFmpeg-devel] [PATCH 0/5] wmalossless: fix 16bits speed regression v2

2016-04-30 Thread Christophe Gisquet
Patch 2 is the squashing of several previous commits, as there were no opinion on their contents nor the way to go. The SSE4 one is the final version from its last thread. The last patch in this set is new, and silences a warning that's only meaningful for 16bits content. Christophe Gisquet (5

Re: [FFmpeg-devel] [PATCH 0/6] wmalossless: fix 16bits speed regression

2016-04-30 Thread Christophe Gisquet
2016-04-29 10:50 GMT+02:00 Paul B Mahol : > Should be OK if it doesn't break anything. I'll resend the current state of this patchset for easier testing & applying. Michael ran this under valgrind with nothing popping up, and fate passes. I think the remaining thing is: is the

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mpegts: Skip over broken 0x80 headers

2016-04-29 Thread Christophe Gisquet
Hi, 2016-04-27 23:58 GMT+02:00 Carl Eugen Hoyos : > Mark Thompson jkqxz.net> writes: > >> Unless someone can show what created this file and that >> it might make more, I suggest that the hack workaround >> should be removed. > > Is there a valid file affected by the applied

Re: [FFmpeg-devel] [PATCH 5/6] x86: lossless audio: SSE4 madd 32bits

2016-04-20 Thread Christophe Gisquet
Hi, 2016-04-20 2:01 GMT+02:00 Ronald S. Bultje : > This is typically only an issue if the data came from stack. On win64 as > well as unix64, the 4th argument never comes from stack but is a direct > register argument instead. So no benefit except consistency. I don't mind

Re: [FFmpeg-devel] [PATCH 5/6] x86: lossless audio: SSE4 madd 32bits

2016-04-18 Thread Christophe Gisquet
istophe From a0d4a96c032d73bc0e34fec320497aefafba3c28 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet <christophe.gisq...@gmail.com> Date: Mon, 18 Apr 2016 13:20:07 +0200 Subject: [PATCH 5/7] x86: lossless audio: SSE4 madd 32bits The unique user so far is wmalossless 24bits. The few samples tested show an o

Re: [FFmpeg-devel] [PATCH 1/6] fate: wma: add lossless 24bits test

2016-04-18 Thread Christophe Gisquet
2016-04-18 22:22 GMT+02:00 Christophe Gisquet <christophe.gisq...@gmail.com>: > 2016-04-18 19:11 GMT+02:00 James Almer <jamr...@gmail.com>: >> No way to create one using existing 24bit audio currently available in fate >> or any redistributable 24 audio out ther

Re: [FFmpeg-devel] [PATCH 1/6] fate: wma: add lossless 24bits test

2016-04-18 Thread Christophe Gisquet
Hi, 2016-04-18 19:11 GMT+02:00 James Almer : > No way to create one using existing 24bit audio currently available in fate > or any redistributable 24 audio out there? > There are some dts-ma and truehd multichannel samples that are not sine waves. You're right. Just did that,

Re: [FFmpeg-devel] [PATCH 2/6] wmalossless: allow calling madd_int16

2016-04-18 Thread Christophe Gisquet
Hi, 2016-04-18 20:09 GMT+02:00 Michael Niedermayer <mich...@niedermayer.cc>: > On Mon, Apr 18, 2016 at 03:07:27PM +0200, Christophe Gisquet wrote: >> This is done by actually handling the cascaded LMS data as if it >> were int16_t, thus requiring switching at various location

Re: [FFmpeg-devel] [PATCH 6/6] lossless audio dsp: unroll

2016-04-18 Thread Christophe Gisquet
2016-04-18 19:15 GMT+02:00 James Almer <jamr...@gmail.com>: > On 4/18/2016 10:07 AM, Christophe Gisquet wrote: >> The loops are guaranteed to be at least multiples of 8, so this >> unrolling is safe but allows exploiting execution ports. >> >> For int32 vers

Re: [FFmpeg-devel] [PATCH 1/6] fate: wma: add lossless 24bits test

2016-04-18 Thread Christophe Gisquet
2016-04-18 18:39 GMT+02:00 Paul B Mahol : > Better to have real 24bit content. Yeah, my point, but I'm not sure we'll get one redistribuable in fate, eg by pinging people from the various tickets. And when would we decide this is better than nothing? -- Christophe

Re: [FFmpeg-devel] [PATCH 1/6] fate: wma: add lossless 24bits test

2016-04-18 Thread Christophe Gisquet
2016-04-18 15:07 GMT+02:00 Christophe Gisquet <christophe.gisq...@gmail.com>: > +fate-lossless-wma24: CMD = md5 -i > $(TARGET_SAMPLES)/lossless-audio/luckynight-partial-24.wma -f s24le -frames > 209 Btw, this is the regular luckynight whose samples have been shifted into 24 bit

[FFmpeg-devel] [PATCH 6/6] lossless audio dsp: unroll

2016-04-18 Thread Christophe Gisquet
The loops are guaranteed to be at least multiples of 8, so this unrolling is safe but allows exploiting execution ports. For int32 version: 72 -> 57c. --- libavcodec/lossless_audiodsp.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git

[FFmpeg-devel] [PATCH 4/6] wmalossless: template code to remove inloop if

2016-04-18 Thread Christophe Gisquet
Code size increase is minimal. --- libavcodec/wmalosslessdec.c | 140 ++-- 1 file changed, 57 insertions(+), 83 deletions(-) diff --git a/libavcodec/wmalosslessdec.c b/libavcodec/wmalosslessdec.c index 77017ff..27510d4 100644 ---

[FFmpeg-devel] [PATCH 1/6] fate: wma: add lossless 24bits test

2016-04-18 Thread Christophe Gisquet
--- tests/fate/lossless-audio.mak | 4 +++- tests/ref/fate/lossless-wma24 | 1 + 2 files changed, 4 insertions(+), 1 deletion(-) create mode 100644 tests/ref/fate/lossless-wma24 diff --git a/tests/fate/lossless-audio.mak b/tests/fate/lossless-audio.mak index 58641ab..ccc4d00 100644 ---

[FFmpeg-devel] [PATCH 2/6] wmalossless: allow calling madd_int16

2016-04-18 Thread Christophe Gisquet
This is done by actually handling the cascaded LMS data as if it were int16_t, thus requiring switching at various locations the computations. --- libavcodec/wmalosslessdec.c | 61 + 1 file changed, 61 insertions(+) diff --git

[FFmpeg-devel] [PATCH 5/6] x86: lossless audio: SSE4 madd 32bits

2016-04-18 Thread Christophe Gisquet
The unique user so far is wmalossless 24bits. The few samples tested show an order of 8, so more unrolling or an avx2 version do not make sense. Timings: 72 -> 49 cycles --- libavcodec/x86/lossless_audiodsp.asm| 38 + libavcodec/x86/lossless_audiodsp_init.c |

[FFmpeg-devel] [PATCH 3/6] wmalossless pro: move lms_update

2016-04-18 Thread Christophe Gisquet
Cosmetics before macroing it and another function. --- libavcodec/wmalosslessdec.c | 94 ++--- 1 file changed, 47 insertions(+), 47 deletions(-) diff --git a/libavcodec/wmalosslessdec.c b/libavcodec/wmalosslessdec.c index 3885dc1..77017ff 100644 ---

[FFmpeg-devel] [PATCH 0/6] wmalossless: fix 16bits speed regression

2016-04-18 Thread Christophe Gisquet
I think only the 2 first patches are needed, but I prefer the code from the 3rd+4th patches. Overall, it's still not the nicest code, and valgrind-proofing the patchset is needed (not possible atm for me). The SSE4 implementation is not worthwhile in my opinion. Christophe Gisquet (6): fate

Re: [FFmpeg-devel] [PATCH] avcodec/wmalosslessdec: real 24bit support

2016-04-13 Thread Christophe Gisquet
Hi, 2016-04-12 22:53 GMT+02:00 Paul B Mahol : > -LLAudDSPContext dsp; ///< accelerated And later: > +static int scalarproduct_and_madd_int(int *v1, const int *v2, > + const int *v3, > +

Re: [FFmpeg-devel] [PATCH 1/3] configure: Force mingw's ld to keep the reloc section

2016-03-20 Thread Christophe Gisquet
Hi, 2016-03-19 19:08 GMT+01:00 Ismail Donmez <ism...@i10z.com>: >> 2016-03-11 8:57 GMT+01:00 Christophe Gisquet <christophe.gisq...@gmail.com>: >>>> It should either be reverted or made dependent on >>>> --enable/disable-debug (I would favor the first, h

Re: [FFmpeg-devel] [PATCH 1/3] configure: Force mingw's ld to keep the reloc section

2016-03-19 Thread Christophe Gisquet
ophe From 87e4f2a42bdb5f733d104ffba7cf70f786b72a03 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet <christophe.gisq...@gmail.com> Date: Sat, 19 Mar 2016 14:45:23 +0100 Subject: [PATCH] mingw64: configure: disable pie with debug enabled This breaks use of gdb. --- configure | 8 ++-- 1 file changed, 6 insertions(

Re: [FFmpeg-devel] [PATCH 1/3] configure: Force mingw's ld to keep the reloc section

2016-03-19 Thread Christophe Gisquet
Hi, 2016-03-11 8:57 GMT+01:00 Christophe Gisquet <christophe.gisq...@gmail.com>: >> It should either be reverted or made dependent on >> --enable/disable-debug (I would favor the first, honestly, since its a >> rather ugly hack in itself). > > At the very least,

Re: [FFmpeg-devel] [PATCH 1/3] configure: Force mingw's ld to keep the reloc section

2016-03-11 Thread Christophe Gisquet
Hi, 2016-03-10 19:57 GMT+01:00 Hendrik Leppkes : > This patch (the relocations part) broke debugging mingw-w64 ffmpeg > builds with gdb, you can't set breakpoints anymore when its applied. That issue prevented me to do anything interesting for ffmpeg since then, thinking it

Re: [FFmpeg-devel] [PATCH] x86/dcadec: add ff_lfe_fir1_float_{sse3, avx}

2016-02-22 Thread Christophe Gisquet
Hi, > +.inner_loop: Given this precludes reusing m5, then I don't have anything more to comment, and seems ok. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] x86/dcadec: add ff_lfe_fir1_float_{sse3, avx}

2016-02-22 Thread Christophe Gisquet
Hi, 2016-02-22 22:43 GMT+01:00 James Almer : > +.loop: > +%if cpuflag(avx) > +cvtdq2ps m4, [lfeq] > +shufpsm5, m4, m4, q0123 > +%elif cpuflag(sse2) > +movu m4, [lfeq] > +cvtdq2ps m4, m4 > +pshufdm5, m4, q0123 > +%endif > + > +.inner_loop: >

Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (v2)

2016-02-14 Thread Christophe Gisquet
Hi, 2016-02-14 0:43 GMT+01:00 Michael Niedermayer : > i can test and commit the code, it seems everyone who wanted to > comment did comment Yes, nothing really worth postponing the patchset from my side, except maybe cleaner splitting of the bypass stuff, as agreed by the

Re: [FFmpeg-devel] [PATCH] x86/vc1dsp: Port vc1_*_hor_16b_shift2 to NASM format

2016-02-14 Thread Christophe Gisquet
Hi, 2016-02-14 6:49 GMT+01:00 Timothy Gu : > %if HAVE_MMX_INLINE Isn't that macro meant for C code (and in config.asm without much of a purpose)? I suspect it is not useful, but I haven't dug into that. > +; XXX some of these macros are not used right now, but they will

Re: [FFmpeg-devel] [PATCH] libavformat/dnxhddec added support for raw 444 and dnxhr formats

2016-02-08 Thread Christophe Gisquet
Hi, 2016-02-08 8:15 GMT+01:00 Christophe Gisquet <christophe.gisq...@gmail.com>: > At this point, I'd say the encoder would better use that prefix. > That's what the attached patch does (rebased but not tested). You may > consider building on top of it for that purpose. Which I h

Re: [FFmpeg-devel] [PATCH] libavformat/dnxhddec added support for raw 444 and dnxhr formats

2016-02-08 Thread Christophe Gisquet
Hi, 2016-02-09 6:27 GMT+01:00 Mark Reid : [...] > I'm guessing its okay to > include "libavcodec/dnxhddata.h" in something thats in libavformat > then? movenc.c uses those prefixes too. Argh, nice catch, you can't use the the content of ff_dnxhd_headers there, which is the

Re: [FFmpeg-devel] [PATCH] libavformat/dnxhddec added support for raw 444 and dnxhr formats

2016-02-07 Thread Christophe Gisquet
Hi, 2016-02-08 2:31 GMT+01:00 Mark Reid : > +static int dnxhd_is_prefix(uint64_t prefix) > +{ > + if (prefix == DNXHD_HEADER_PREFIX|| > + prefix == DNXHD_HEADER_PREFIX444 || > + prefix == DNXHD_HEADER_PREFIXHR1 || > + prefix == DNXHD_HEADER_PREFIXHR2) > +

Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (v2)

2016-02-02 Thread Christophe Gisquet
Hi, as a motus operandi for this review, I have no time for a proper one, or at least not fitting with John's timeframe. I'll try to close as many pending discussions, and would prefer if someone else completed the review/validation/commit. 2016-01-22 19:33 GMT+01:00 John Cox

Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)

2016-01-22 Thread Christophe Gisquet
Hi, 2016-01-20 15:27 GMT+01:00 John Cox : > The by22 code gained me an overall factor of two in the abs level decode > - the gains do depend a lot on the quantity of residual - you gain a lot > more on I-frames than you do otherwise as they tend to have much longer >

Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)

2016-01-22 Thread Christophe Gisquet
Hi, 2016-01-22 14:29 GMT+01:00 John Cox : >>This is a big slowdown on Win64 and UHD-bluray like sequences, but >>that can be switched off in that case. > > I'm a bit surprised that it generated a big slowdown - some cache must > be running just on the edge, but yes if you

Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (v2)

2016-01-22 Thread Christophe Gisquet
Hi, 2016-01-21 11:45 GMT+01:00 John Cox : > Hi > > v2 of my hevc residual patch I'll review the bit not related to significant coeffs first, because I think it is the most performance-sensitive. Also there are bits that could be moved to other patches, at least some are

Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)

2016-01-20 Thread Christophe Gisquet
Hi, 2016-01-19 13:46 GMT+01:00 John Cox : > I've just done a fair bit of work on hevc_cabac decode for the Rasberry > Pi2 and I think that the patch is generally applicable. Patch is > attached but you may prefer to take it from git: This work is certainly impressive, and

Re: [FFmpeg-devel] [PATCH] swscale/yuv2rgb: Increase YUV2RGB table headroom

2016-01-14 Thread Christophe Gisquet
Hi, 2016-01-14 9:41 GMT+01:00 Michael Niedermayer : > there are 2 seperate tables, the headroom in them also differs > curently, also the exact relation between input values and headroom > needed in the 2nd table depends on the yuv-rgb coefficients > > i can replace the

Re: [FFmpeg-devel] [PATCH] swscale/yuv2rgb: Increase YUV2RGB table headroom

2016-01-13 Thread Christophe Gisquet
> -#define YUVRGB_TABLE_HEADROOM 256 > +#define YUVRGB_TABLE_HEADROOM 512 [...] > -const int yoffs = fullRange ? 384 : 326; > +const int yoffs = fullRange ? 896 : 838; I think it's time to use that macro everywhere it is actually used without showing up. Best regards, Christophe

Re: [FFmpeg-devel] [PATCH 1/3] x86/float_dsp: remove len check from ff_butterflies_float_sse

2016-01-08 Thread Christophe Gisquet
2016-01-08 17:41 GMT+01:00 Christophe Gisquet <christophe.gisq...@gmail.com>: > On a side note, do you intend to do an avx version? Just did that, need a tail processing, and no gain on a(n) Haswell over a 7 minute sample. The code for reference, over your set of patches. -- Christop

Re: [FFmpeg-devel] [PATCH 1/3] x86/float_dsp: remove len check from ff_butterflies_float_sse

2016-01-08 Thread Christophe Gisquet
Hi, 2016-01-08 20:16 GMT+01:00 James Almer : > Then honestly i don't think it's worth it. Maybe if we could change the > alignment to 32 bytes and making len multiple of 8 or 16, but not sure > how feasible is that. There could be a more specialized version, but of doubtful

Re: [FFmpeg-devel] [PATCH 1/3] x86/float_dsp: remove len check from ff_butterflies_float_sse

2016-01-08 Thread Christophe Gisquet
Hi, 2016-01-08 16:22 GMT+01:00 James Almer : > -test lenq, lenq > -jz .end > shl lenq, 2 > add src0q, lenq > add src1q, lenq > @@ -377,5 +375,4 @@ cglobal butterflies_float, 3,3,3, src0, src1, len > mova[src0q + lenq], m0

Re: [FFmpeg-devel] [PATCH 2/3] x86/float_dsp: zero extend len from ff_butterflies_float_sse implicitly

2016-01-08 Thread Christophe Gisquet
Hi, 2016-01-08 16:22 GMT+01:00 James Almer : > INIT_XMM sse > cglobal butterflies_float, 3,3,3, src0, src1, len > -%if ARCH_X86_64 > -movsxdlenq, lend > -%endif > -shl lenq, 2 > +shl lend, 2 All the more ok since, afaik, only WIN64 actually

Re: [FFmpeg-devel] [PATCH 3/3] x86/float_dsp: zero extend offset from ff_scalarproduct_float_sse

2016-01-08 Thread Christophe Gisquet
Hi, 2016-01-08 16:22 GMT+01:00 James Almer : > +shl offsetd, 2 > +add v1q, offsetq > +add v2q, offsetq > neg offsetq > -shl offsetq, 2 > -sub v1q, offsetq > -sub v2q, offsetq Lucky that we never had any crash then.

Re: [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.

2016-01-07 Thread Christophe Gisquet
Hi, 2016-01-07 12:48 GMT+01:00 foo86 : > bench dca pcm_f32le > bench dca2 pcm_f32le > bench libdcadec pcm_s32le OK, that was mostly out of curiosity, as "dca2" has benefits surpassing such issues anyway. And the improvement is 10% for where it matters (raspberry).

Re: [FFmpeg-devel] [PATCH 2/2] swscale: add P010 input support

2016-01-07 Thread Christophe Gisquet
Hi, 2016-01-07 12:11 GMT+01:00 Hendrik Leppkes : > +static void p010LEToY_c(uint8_t *dst, const uint8_t *src, const uint8_t > *unused1, > +const uint8_t *unused2, int width, uint32_t *unused) > +{ > +int i; > +for (i = 0; i < width; i++) { > +

Re: [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.

2016-01-06 Thread Christophe Gisquet
Hi, 2016-01-06 18:32 GMT+01:00 foo86 : > dca dca2libdcadec > System 1: 0:11.90 0:11.16 0:19.73 > System 2: 0:57.00 0:55.23 1:21.33 > System 3: 7:41.31 7:00.84 13:16.70 Just to be sure, because I won't check myself: is

Re: [FFmpeg-devel] [PATCH 1/3] x86/hevc_sao: simplify sao_band_filter 10/12bit

2015-12-20 Thread Christophe Gisquet
Hi, 2015-12-16 4:24 GMT+01:00 James Almer : > On 12/10/2015 8:02 PM, James Almer wrote: >> Signed-off-by: James Almer >> --- >> libavcodec/x86/hevc_sao_10bit.asm | 142 >> +++--- >> 1 file changed, 57 insertions(+), 85

Re: [FFmpeg-devel] [PATCH 1/3] x86/hevc_sao: simplify sao_band_filter 10/12bit

2015-12-16 Thread Christophe Gisquet
Hi, 2015-12-16 4:24 GMT+01:00 James Almer : > Ping for patchset. I'll probably have a look on Sunday. But I don't expect my review to be very worthwhile, so several people can probably do a better and faster one. -- Christophe ___

Re: [FFmpeg-devel] [PATCH] vc1dsp: Port ff_vc1_put_ver_16b_shift2_mmx to yasm

2015-10-21 Thread Christophe Gisquet
Hi, 2015-10-18 2:47 GMT+02:00 Timothy Gu : > This function is only used within other inline asm functions, hence the > HAVE_MMX_INLINE guard. Per recent discussions, we should not worry about > the performance of inline asm-only builds. On a quick glance, looks good. >

[FFmpeg-devel] [PATCH] dnxhd: interleave AC levels and flags

2015-10-14 Thread Christophe Gisquet
This allows more efficient access to the array as the level and flags are contiguous. Around 4% faster coefficient decoding. --- Not the cleanest, and may complicate adding new profiles. But DNxHR just got added, so it should be ok for some years. --- libavcodec/dnxhddata.c | 492

[FFmpeg-devel] [PATCH] fate: use PROGSSUF

2015-10-14 Thread Christophe Gisquet
May require exporting in the shell var PROGSUF when invoking a shell script. --- tests/Makefile | 14 +- tests/fate-run.sh| 38 +++--- tests/fate/ffprobe.mak | 2 +- tests/fate/filter-video.mak | 4 ++--

Re: [FFmpeg-devel] request for feedback on video codec idea

2015-10-14 Thread Christophe Gisquet
2015-10-14 20:08 GMT+02:00 Roger Pack : > I have become aware of some "fast" compression tools like LZO, LZ4, > density, etc. It seems like they all basically compress "the first > 64KB then the next 64KB" or something like that [1]. It's generally the size of a window or

Re: [FFmpeg-devel] [PATCH 5/9] x86: simple_idct10_template: fix overflow in pass

2015-10-13 Thread Christophe Gisquet
Hi, 2015-10-13 2:26 GMT+02:00 Michael Niedermayer <mich...@niedermayer.cc>: > On Mon, Oct 12, 2015 at 07:37:46PM +0200, Christophe Gisquet wrote: >> When the input of a pass has 15 or 16 bits of precision (in particular >> the column pass), the addition of a bias to W4

Re: [FFmpeg-devel] [PATCH 2/9] fate: add 10bits YUV4:2:2 test

2015-10-13 Thread Christophe Gisquet
Hi, 2015-10-13 4:04 GMT+02:00 Michael Niedermayer : > wasnt that easy, there was another difference, between 32 and 64bit > it may be float rounding in the scaler but its not dnxhd i worked > around it by adjusting the scaler parameters. I'm not completely sure now, but I

Re: [FFmpeg-devel] [PATCH 2/9] fate: add 10bits YUV4:2:2 test

2015-10-13 Thread Christophe Gisquet
Hi, 2015-10-13 0:00 GMT+02:00 Michael Niedermayer : >> I'm so bad at this codec stuff. > > no, you are not, this stuff is rather convoluted and the mpegvideo > *dct stuff is not well documented. Sorry for the outburst, it was really frustrating to get caught in whatever

Re: [FFmpeg-devel] [PATCH 5/9] x86: simple_idct10_template: fix overflow in pass

2015-10-13 Thread Christophe Gisquet
Hi, 2015-10-13 13:10 GMT+02:00 Michael Niedermayer : > hmm, iam a bit concerned that adding the rounder (which effectively is > 0.5) causes a overflow, that would if iam not mistaken imlpy that > things are very close to overflowing already without it It's true, but the

Re: [FFmpeg-devel] [PATCH 2/9] fate: add 10bits YUV4:2:2 test

2015-10-13 Thread Christophe Gisquet
2015-10-13 9:06 GMT+02:00 Christophe Gisquet <christophe.gisq...@gmail.com>: >I think I didn't run into those failures under Win64. Confirmed, as well as under Win32 (also gcc 5.2.0) and gcc x86_64 4.9.2 under a linux environment. -- C

Re: [FFmpeg-devel] [PATCH 5/9] x86: simple_idct10_template: fix overflow in pass

2015-10-13 Thread Christophe Gisquet
2015-10-13 15:43 GMT+02:00 Michael Niedermayer <mich...@niedermayer.cc>: > On Tue, Oct 13, 2015 at 01:33:07PM +0200, Christophe Gisquet wrote: >> Hi, >> >> 2015-10-13 13:10 GMT+02:00 Michael Niedermayer <mich...@niedermayer.cc>: >> > hmm, iam a bi

[FFmpeg-devel] [PATCH 1/3] x86: simple_idct10_template: use const

2015-10-13 Thread Christophe Gisquet
This avoid going through constants.c while still sharing them with proresdsp.asm --- libavcodec/x86/constants.c| 28 libavcodec/x86/constants.h| 16 libavcodec/x86/proresdsp.asm | 13 +

Re: [FFmpeg-devel] [PATCH 2/9] fate: add 10bits YUV4:2:2 test

2015-10-13 Thread Christophe Gisquet
Hi, 2015-10-13 21:41 GMT+02:00 James Almer : > This test is failing on pretty much every fate client. Valgrind seems to > complain about uninitialized values. > http://fate.ffmpeg.org/report.cgi?time=20151013040721=x86_64-archlinux-gcc-valgrindundef Can someone test the

Re: [FFmpeg-devel] [PATCH 1/9] dnxhdenc: fix scan used for bitstream generation

2015-10-12 Thread Christophe Gisquet
Hi, 2015-10-12 0:09 GMT+02:00 Michael Niedermayer : > this seems to cause artifacts on the red/cyan edge in > ./ffmpeg -f lavfi -i testsrc=s=1920x1080 -vframes 1 -pix_fmt yuv422p -vcodec > dnxhd -flags +ildct -vb 185M test.mov ok, ff_convert_matrix permutes the table, so

[FFmpeg-devel] [PATCH 9/9] x86: dct-test: add more idcts

2015-10-12 Thread Christophe Gisquet
In particular for 10 and 12 bits. --- libavcodec/dct-test.c | 2 ++ libavcodec/x86/dct-test.c | 10 ++ 2 files changed, 12 insertions(+) diff --git a/libavcodec/dct-test.c b/libavcodec/dct-test.c index 56e1a62..72fe353 100644 --- a/libavcodec/dct-test.c +++ b/libavcodec/dct-test.c

[FFmpeg-devel] [PATCH 5/9] x86: simple_idct10_template: fix overflow in pass

2015-10-12 Thread Christophe Gisquet
When the input of a pass has 15 or 16 bits of precision (in particular the column pass), the addition of a bias to W4 may lead to overflows in the input to pmaddwd. This requires postponing the adding of the bias to after the first butterfly. To do so, the fact that m15, unused although zeroed,

[FFmpeg-devel] [PATCH 4/9] simple_idct10: improve precision

2015-10-12 Thread Christophe Gisquet
omse goes from 0.03060703 (which fails for dct-test) to 0.01663750. This also actually improve the error of decoding the sample generated by fate-vsynth3-dnxhd1080i-10bit using simple_idct10 to FAANI, which goes (when resampled to yuv422p) from: stddev:0.06 PSNR: 72.28 MAXDIFF:1 to

  1   2   3   4   5   6   >