Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Tobias Rapp
On 13.01.2019 15:07, Gyan wrote: On 13-01-2019 06:39 PM, Ronald S. Bultje wrote: Hi, On Sun, Jan 13, 2019 at 4:39 AM Gyan wrote: When someone submits a patch, it is implicit, unless stated otherwise, that it is of their own initiative (and their own work), and thus they are free to assign

[FFmpeg-devel] [PATCH] lavf/vaapi_deinterlace: return error if mode unsupported

2019-01-13 Thread Zhong Li
Signed-off-by: Fuwei Tang Signed-off-by: Zhong Li --- libavfilter/vf_deinterlace_vaapi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavfilter/vf_deinterlace_vaapi.c b/libavfilter/vf_deinterlace_vaapi.c index 97aee65..f67a1c8 100644 --- a/libavfilter/vf_deinterlace_vaapi.c +++

[FFmpeg-devel] [PATCH v2] lavc/qsvenc: set BRCParamMultiplier to aviod BRC overflow

2019-01-13 Thread Zhong Li
Fix ticket #7663 Reviewed-by Carl Eugen Hoyos Reviewed-by Hendrik Leppkes Signed-off-by: Zhong Li --- libavcodec/qsvenc.c | 41 +++-- 1 file changed, 27 insertions(+), 14 deletions(-) diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index

[FFmpeg-devel] [PATCH] lavc/vaapi_encode: add support for AVC Trellis

2019-01-13 Thread Linjie Fu
Add support for VAAPI AVC Trellis Quantization with limitation: - VA-API version >= (1, 0, 0) Use option "-trellis off/I/P/B" to disable or enable Trellis quantization for I/P/B frames. Signed-off-by: Linjie Fu --- libavcodec/vaapi_encode.c | 44 ++

Re: [FFmpeg-devel] [PATCH, v4] lavc/hevc_parser: cope with more leading_zero_8bits and update FATE

2019-01-13 Thread Fu, Linjie
> -Original Message- > From: Fu, Linjie > Sent: Friday, January 11, 2019 15:29 > To: ffmpeg-devel@ffmpeg.org > Cc: Fu, Linjie > Subject: [PATCH,v4] lavc/hevc_parser: cope with more leading_zero_8bits > and update FATE > > Given that leading_zero_8bits can be included many times at the

Re: [FFmpeg-devel] [PATCHv2] fate: add dst decoder test

2019-01-13 Thread Michael Niedermayer
On Sun, Dec 23, 2018 at 01:20:51PM +0100, Michael Niedermayer wrote: > On Sun, Dec 23, 2018 at 09:41:48AM +1100, Peter Ross wrote: > > the dst->dsd decoder is bit-exact, but uses ff_dsd2pcm_translate to > > output pcm. > > --- > > thanks for spotting this michael. totally forgotten about the

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Ronald S. Bultje
On Sun, Jan 13, 2019 at 9:38 AM Nicolas George wrote: > Derek Buitenhuis (12019-01-13): > > This is a policy change, not a techncal change. > > Policy changes need to be motivated too. > Wait, what? *You* are suggesting a policy change, not me/us. There is no burden of proof on me. You have to

Re: [FFmpeg-devel] [PATCH 4/6] avcodec/vp6: use ff_vp4_[hv]_loop_filter_12_c

2019-01-13 Thread Michael Niedermayer
On Mon, Jan 14, 2019 at 07:02:47AM +1100, Peter Ross wrote: > --- > libavcodec/vp56.c| 10 ++ > libavcodec/vp56.h| 1 + > libavcodec/vp56dsp.c | 19 --- > 3 files changed, 11 insertions(+), 19 deletions(-) > > diff --git a/libavcodec/vp56.c b/libavcodec/vp56.c >

[FFmpeg-devel] yadif frame doubling - incorrect closed captioning

2019-01-13 Thread Gabriel Blanchard
When frame doubling using yadif/bwdif closed captioning gets copied to the second frame - as a result the closed captioning text is garbage. I've attached a very simple patch that fixes this issue. Very similar to what vf_fps.c already does around line 253. -Gabe From

[FFmpeg-devel] [PATCH]lavf/mov: Do not fail hard for more mov atoms

2019-01-13 Thread Carl Eugen Hoyos
Hi! Attached patch fixes ticket #7679. Please comment, Carl Eugen From ea6afa36d5ceb6e027176f051e7886f0648e3ac2 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Sun, 13 Jan 2019 23:07:06 +0100 Subject: [PATCH] lavf/mov: Do not fail hard for more invalid atoms. This is what several other

Re: [FFmpeg-devel] [PATCH 5/6] avcodec/vp6: select idct based (loosely) on number of coefficients decoded

2019-01-13 Thread Carl Eugen Hoyos
2019-01-13 21:03 GMT+01:00, Peter Ross : > --- > libavcodec/vp5.c | 1 + > libavcodec/vp56.c | 30 -- > libavcodec/vp56.h | 2 ++ > libavcodec/vp6.c | 14 ++ > 4 files changed, 41 insertions(+), 6 deletions(-) Please add a sentence about the reason for

Re: [FFmpeg-devel] [PATCH 0/6] improved VP6 decoding

2019-01-13 Thread Carl Eugen Hoyos
2019-01-13 21:00 GMT+01:00, Peter Ross : > These patches make FFmpeg match the output of the VP6 reference > decoder. Collectively they fix But none of the commit messages mention the ticket;-( Carl Eugen ___

Re: [FFmpeg-devel] [PATCH] matroskadec: Adjust content light side data check

2019-01-13 Thread Michael Niedermayer
On Sun, Jan 13, 2019 at 12:17:24PM -0500, Vittorio Giovara wrote: > While in practice both fields are always initialized, this mimics > what other tools like ffms2, and x265 do more closely. > > This work has been sponsored by Tyrell Corporation, for a compensation > of dozen of cents of US

Re: [FFmpeg-devel] [PATCH 4/6] avcodec/vp6: use ff_vp4_[hv]_loop_filter_12_c

2019-01-13 Thread Carl Eugen Hoyos
2019-01-13 21:02 GMT+01:00, Peter Ross : > --- > libavcodec/vp56.c| 10 ++ > libavcodec/vp56.h| 1 + > libavcodec/vp56dsp.c | 19 --- > 3 files changed, 11 insertions(+), 19 deletions(-) > > diff --git a/libavcodec/vp56.c b/libavcodec/vp56.c > index

Re: [FFmpeg-devel] [PATCH 6/6] fate: update vp6 regression test data

2019-01-13 Thread Carl Eugen Hoyos
2019-01-13 21:03 GMT+01:00, Peter Ross : > --- > tests/ref/fate/vp60| 202 +-- > tests/ref/fate/vp61| 238 +++ > tests/ref/fate/vp6a| 172 - > tests/ref/fate/vp6a-skip_alpha | 172 - >

[FFmpeg-devel] [PATCH 6/6] fate: update vp6 regression test data

2019-01-13 Thread Peter Ross
--- tests/ref/fate/vp60| 202 +-- tests/ref/fate/vp61| 238 +++ tests/ref/fate/vp6a| 172 - tests/ref/fate/vp6a-skip_alpha | 172 - tests/ref/fate/vp6f| 342

[FFmpeg-devel] [PATCH 4/6] avcodec/vp6: use ff_vp4_[hv]_loop_filter_12_c

2019-01-13 Thread Peter Ross
--- libavcodec/vp56.c| 10 ++ libavcodec/vp56.h| 1 + libavcodec/vp56dsp.c | 19 --- 3 files changed, 11 insertions(+), 19 deletions(-) diff --git a/libavcodec/vp56.c b/libavcodec/vp56.c index 27b4b8b944..c5c5a9fb65 100644 --- a/libavcodec/vp56.c +++

[FFmpeg-devel] [PATCH 5/6] avcodec/vp6: select idct based (loosely) on number of coefficients decoded

2019-01-13 Thread Peter Ross
--- libavcodec/vp5.c | 1 + libavcodec/vp56.c | 30 -- libavcodec/vp56.h | 2 ++ libavcodec/vp6.c | 14 ++ 4 files changed, 41 insertions(+), 6 deletions(-) diff --git a/libavcodec/vp5.c b/libavcodec/vp5.c index cb08cec33f..49988b8b76 100644 ---

[FFmpeg-devel] [PATCH 3/6] avcodec/vp6: use rounded shift for chroma motion vector calculation

2019-01-13 Thread Peter Ross
--- libavcodec/vp56.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/libavcodec/vp56.c b/libavcodec/vp56.c index b69fe6c176..27b4b8b944 100644 --- a/libavcodec/vp56.c +++ b/libavcodec/vp56.c @@ -196,12 +196,8 @@ static void vp56_decode_4mv(VP56Context *s, int row, int

[FFmpeg-devel] [PATCH 2/6] avcodec/vp3dsp: add 10 coefficient version of the vp3 idct

2019-01-13 Thread Peter Ross
--- libavcodec/vp3dsp.c | 152 libavcodec/vp3dsp.h | 3 + 2 files changed, 155 insertions(+) diff --git a/libavcodec/vp3dsp.c b/libavcodec/vp3dsp.c index f049953356..8204188aa8 100644 --- a/libavcodec/vp3dsp.c +++ b/libavcodec/vp3dsp.c @@ -195,6

[FFmpeg-devel] [PATCH 1/6] avcodec/vp3dsp: add 12 pixel loop filter functions

2019-01-13 Thread Peter Ross
--- This is a reposting of my earlier 12-pixel loop filter for VP4. libavcodec/vp3dsp.c | 28 libavcodec/vp3dsp.h | 5 + 2 files changed, 25 insertions(+), 8 deletions(-) diff --git a/libavcodec/vp3dsp.c b/libavcodec/vp3dsp.c index 4e08ee0b8f..f049953356

[FFmpeg-devel] [PATCH 0/6] improved VP6 decoding

2019-01-13 Thread Peter Ross
These patches make FFmpeg match the output of the VP6 reference decoder. Collectively they fix Bugs fixed: * Chroma motion vector calculation was sometimes off by 1. * Loop filter differences. The VP6 loop filter is the same as the VP4 one. * IDCT drift.

Re: [FFmpeg-devel] [PATCH 1/4] vp3: ref_frame/ref_frames are only required when HAVE_THREADS=1

2019-01-13 Thread Carl Eugen Hoyos
2019-01-06 8:42 GMT+01:00, Peter Ross : > squelch another warning > --- > libavcodec/vp3.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c > index 9df2fda49d..a5d8c2ed0b 100644 > --- a/libavcodec/vp3.c > +++ b/libavcodec/vp3.c > @@

Re: [FFmpeg-devel] [PATCH 1/4] vp3: ref_frame/ref_frames are only required when HAVE_THREADS=1

2019-01-13 Thread Peter Ross
On Sun, Jan 06, 2019 at 06:42:50PM +1100, Peter Ross wrote: > squelch another warning > --- > libavcodec/vp3.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) If no one objects, I will apply this warnings-fix patch in a day or so. -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40

Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference

2019-01-13 Thread Derek Buitenhuis
On 13/01/2019 18:24, James Almer wrote: > I thought i had amended the patch, but guess not... > > I can revert and reapply with the amended commit message if you want, > but it will kinda litter the tree for not a lot of gain. Then again, the > tree is already a mess with all the merges. Not

Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference

2019-01-13 Thread James Almer
On 1/13/2019 3:18 PM, Derek Buitenhuis wrote: > On 13/01/2019 18:01, James Almer wrote: >> Pushes as is then. Thanks. > > Er. > > You didn't add the actual description of the problem/fix > to the commit message. I thought i had amended the patch, but guess not... I can revert and reapply with

[FFmpeg-devel] [PATCH] avfilter: add colorhold filter

2019-01-13 Thread Paul B Mahol
Signed-off-by: Paul B Mahol --- doc/filters.texi | 14 ++ libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/vf_colorkey.c | 93 ++- 4 files changed, 108 insertions(+), 1 deletion(-) diff --git a/doc/filters.texi

Re: [FFmpeg-devel] [PATCH] avfilter: add colorhold filter

2019-01-13 Thread Paul B Mahol
On 1/13/19, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > doc/filters.texi | 14 ++ > libavfilter/Makefile | 1 + > libavfilter/allfilters.c | 1 + > libavfilter/vf_colorkey.c | 93 ++- > 4 files changed, 108 insertions(+), 1

Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference

2019-01-13 Thread Derek Buitenhuis
On 13/01/2019 18:01, James Almer wrote: > Pushes as is then. Thanks. Er. You didn't add the actual description of the problem/fix to the commit message. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference

2019-01-13 Thread James Almer
On 1/13/2019 12:55 PM, Derek Buitenhuis wrote: > On 13/01/2019 15:45, James Almer wrote: >> If there is, i don't know it. >> >> Float based fate tests have been fine tuned before when different >> architectures proved a certain stddev value was not lax enough, so this >> one could be increased if

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Nicolas George
James Almer (12019-01-13): > A temporal ban for first time offenders and such could maybe work. But > then we're back to the CoC discussion that went nowhere. And look who blocked this... > And again, you think requesting the disclosure of the incentive behind > the patch will make a difference

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/gdv: Optimize and factorize scaling loops

2019-01-13 Thread Michael Niedermayer
On Sat, Jan 12, 2019 at 04:49:40PM +0100, Carl Eugen Hoyos wrote: > 2019-01-12 16:46 GMT+01:00, Michael Niedermayer : > > On Sat, Jan 12, 2019 at 04:07:42PM +0100, Carl Eugen Hoyos wrote: > >> 2019-01-04 20:22 GMT+01:00, Michael Niedermayer : > >> > >> > +static void scaledown(uint8_t *dst, const

Re: [FFmpeg-devel] [PATCH] avcodec/tests/rangecoder: initialize array to avoid valgrind warning

2019-01-13 Thread Michael Niedermayer
On Sun, Jan 13, 2019 at 04:21:14PM +0800, Steven Liu wrote: > > > > On Jan 12, 2019, at 22:49, Michael Niedermayer > > wrote: > > > > On Fri, Jan 04, 2019 at 02:46:29AM +0100, Michael Niedermayer wrote: > >> Found-by: jamrial > >> Signed-off-by: Michael Niedermayer > >> --- > >>

Re: [FFmpeg-devel] [PATCH] avcodec: fix some docstrings

2019-01-13 Thread Michael Niedermayer
On Sun, Jan 13, 2019 at 12:15:55AM +0100, Nicolas Granger wrote: > Hello, > > This fixes an erroneous reference and missing links in the API documentation. > > Best regards, > > Nicolas Granger > > --- > libavcodec/avcodec.h | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > >

Re: [FFmpeg-devel] [PATCH] matroskadec: Adjust content light side data check

2019-01-13 Thread Paul B Mahol
On 1/13/19, Vittorio Giovara wrote: > While in practice both fields are always initialized, this mimics > what other tools like ffms2, and x265 do more closely. > > This work has been sponsored by Tyrell Corporation, for a compensation > of dozen of cents of US dollars. > --- >

Re: [FFmpeg-devel] [PATCH] matroskadec: Adjust content light side data check

2019-01-13 Thread Carl Eugen Hoyos
2019-01-13 18:17 GMT+01:00, Vittorio Giovara : > While in practice both fields are always initialized, this mimics > what other tools like ffms2, and x265 do more closely. > This work has been sponsored by Tyrell Corporation, for a compensation > of dozen of cents of US dollars. Please remove

Re: [FFmpeg-devel] [PATCH] matroskadec: Adjust content light side data check

2019-01-13 Thread James Almer
On 1/13/2019 2:17 PM, Vittorio Giovara wrote: > While in practice both fields are always initialized, this mimics > what other tools like ffms2, and x265 do more closely. > > This work has been sponsored by Tyrell Corporation, for a compensation > of dozen of cents of US dollars. > --- >

[FFmpeg-devel] [PATCH] matroskadec: Adjust content light side data check

2019-01-13 Thread Vittorio Giovara
While in practice both fields are always initialized, this mimics what other tools like ffms2, and x265 do more closely. This work has been sponsored by Tyrell Corporation, for a compensation of dozen of cents of US dollars. --- libavformat/matroskadec.c | 7 ++- 1 file changed, 6

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Nicolas George
Michael Niedermayer (12019-01-13): > You should add yourself to > https://ffmpeg.org/consulting.html > > I have no doubt code you would write for money would be of high quality. > And more paid developers equal more contributions which is a good thing. I thank you for your praise, but I will

Re: [FFmpeg-devel] Video codec design for very low-end decoder

2019-01-13 Thread Paul B Mahol
On 1/13/19, Lauri Kasanen wrote: > On Mon, 7 Jan 2019 12:37:01 -0500 > "Ronald S. Bultje" wrote: > >> On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen wrote: >> > "Ronald S. Bultje" wrote: >> > >> > > Have you considered vp8? It may sound weird but this is basically what >> > > vp8 was great at:

[FFmpeg-devel] [PATCH v2] api-h264-slice-test: fix arguments and help

2019-01-13 Thread Rafaël Carré
This patch also changes the call to api-h264-slice-test. v1 was done during a working day but was not requested by the direction. v2 was done on sunday. I think it's fair to say I was not paid for this, and to reassure you, both times I put a minimum amount of effort. >From

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread James Almer
On 1/13/2019 1:29 PM, Nicolas George wrote: > James Almer (12019-01-13): >> (1) is not an issue, > > It is an issue because it makes the rest possible. After all, people > whose main motivation is code quality would want their code reviewed. > >> (2) and (3) are the issue,

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Michael Niedermayer
On Fri, Jan 11, 2019 at 07:21:07PM +0100, Nicolas George wrote: > Rationale: > > * This requirement should offset a little the incentive to neglect > design, code quality and politeness during the review process when > done for money. > > * The review process itself and future maintenance

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Nicolas George
James Almer (12019-01-13): > (1) is not an issue, It is an issue because it makes the rest possible. After all, people whose main motivation is code quality would want their code reviewed. > (2) and (3) are the issue, and depending on the > developer's reaction at reviews

Re: [FFmpeg-devel] Video codec design for very low-end decoder

2019-01-13 Thread Lauri Kasanen
On Mon, 7 Jan 2019 12:37:01 -0500 "Ronald S. Bultje" wrote: > On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen wrote: > > "Ronald S. Bultje" wrote: > > > > > Have you considered vp8? It may sound weird but this is basically what > > > vp8 was great at: being really simple to decode. > > > > VP8

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread James Almer
On 1/13/2019 12:57 PM, Nicolas George wrote: > James Almer (12019-01-13): >> And kill the project by reducing development speed to crawl? Unreviewed > > That is indeed the problem. > >> and unchallenged patches by long time devs with commit rights can and >> will still be pushed after enough

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Kieran O Leary
On Sun, 13 Jan 2019, 15:57 Nicolas George James Almer (12019-01-13): > > And kill the project by reducing development speed to crawl? Unreviewed > > That is indeed the problem. > > > and unchallenged patches by long time devs with commit rights can and > > will still be pushed after enough time

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Nicolas George
James Almer (12019-01-13): > And kill the project by reducing development speed to crawl? Unreviewed That is indeed the problem. > and unchallenged patches by long time devs with commit rights can and > will still be pushed after enough time and ping attempts have been made. > Expecting anything

Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference

2019-01-13 Thread Derek Buitenhuis
On 13/01/2019 15:45, James Almer wrote: > If there is, i don't know it. > > Float based fate tests have been fine tuned before when different > architectures proved a certain stddev value was not lax enough, so this > one could be increased if needed as well, but if you prefer i can use a > big

Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference

2019-01-13 Thread James Almer
On 1/13/2019 11:32 AM, Derek Buitenhuis wrote: > On 13/01/2019 02:44, James Almer wrote: >> Michael suggested 1000*FLT_EPSILON but IMO that's too big and may hide >> errors in future implementations. >> The value i used is the smallest value i found that didn't fail after >> several runs. 6.1e-05

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread James Almer
On 1/13/2019 12:24 PM, Nicolas George wrote: > James Almer (12019-01-13): >> How is that related to sponsored work? If a patch was ignored, then the >> extra line in the commit message would have been ignored as much as the >> actual code. > > Without sponsoring, most reasons for developing code

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Nicolas George
James Almer (12019-01-13): > How is that related to sponsored work? If a patch was ignored, then the > extra line in the commit message would have been ignored as much as the > actual code. Without sponsoring, most reasons for developing code are positively correlated with code quality. Not

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread James Almer
On 1/13/2019 12:06 PM, Nicolas George wrote: > James Almer (12019-01-13): >> If no one challenges, then either no one looked at it, or everyone that >> looked at it was fine with it. Where is the issue then? > > If nobody looked, how can we know there is no obvious security issue? How is that

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Nicolas George
Derek Buitenhuis (12019-01-13): > On 13/01/2019 14:52, Nicolas George wrote: > > Therefore, I ask reasons: if you do not want to disclose your > > sponsorships, please explain why? > > https://en.wikipedia.org/wiki/Nothing_to_hide_argument Exactly: the "nothing to hide" argument has good

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Nicolas George
James Almer (12019-01-13): > If no one challenges, then either no one looked at it, or everyone that > looked at it was fine with it. Where is the issue then? If nobody looked, how can we know there is no obvious security issue? > You're looking for a solution for a problem that doesn't exist.

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Nicolas George
Hendrik Leppkes (12019-01-13): > You can't ask for arguments then dismiss the ones you are given based > on your opinions. I dismiss an opinion based on an opinion. Proof of the fact: > I consider my finances and employment my own business, and will never ^^ > disclose it on *public*

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread James Almer
On 1/13/2019 11:06 AM, Nicolas George wrote: > James Almer (12019-01-13): >> Be the change you want in the world and post your day job income here >> for all to see. Otherwise drop this absurd obsession of yours and let >> people have a peaceful weekend. > > Of course: > > All that I have

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Derek Buitenhuis
On 13/01/2019 14:52, Nicolas George wrote: > Therefore, I ask reasons: if you do not want to disclose your > sponsorships, please explain why? https://en.wikipedia.org/wiki/Nothing_to_hide_argument - Derek ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Hendrik Leppkes
On Sun, Jan 13, 2019 at 2:40 PM Nicolas George wrote: > > James Almer (12019-01-13): > > I seem to remember the famous votes count voices, if one were to be called. > > You should check again, the rules state that mails without arguments do > not count. > > > Nicolas, no one is in favor of this

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Nicolas George
Derek Buitenhuis (12019-01-13): > No, I don't think that, and I think it's offensive to the people who you > accuse of that. I do not accuse them of that, but I find the lack of reasons highly suspicious. Most times somebody wants something but does not give a reason, it happens that the reason

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Derek Buitenhuis
On 13/01/2019 14:38, Nicolas George wrote: > Any unmotivated objection can be interpreted as "I push bad code for a > quick buck and do not intend to stop", do you not think? No, I don't think that, and I think it's offensive to the people who you accuse of that. - Derek

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Nicolas George
Derek Buitenhuis (12019-01-13): > This is a policy change, not a techncal change. Policy changes need to be motivated too. Any unmotivated objection can be interpreted as "I push bad code for a quick buck and do not intend to stop", do you not think? Regards, -- Nicolas George

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Derek Buitenhuis
On 13/01/2019 13:18, Nicolas George wrote: > I seem to remember that arguments count, not voices. I have given > several arguments in the commit message, almost none of them were > addressed and the dissenting arguments were feeble at best. This is a policy change, not a techncal change. - Derek

Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference

2019-01-13 Thread Derek Buitenhuis
On 13/01/2019 02:44, James Almer wrote: > Michael suggested 1000*FLT_EPSILON but IMO that's too big and may hide > errors in future implementations. > The value i used is the smallest value i found that didn't fail after > several runs. 6.1e-05 for example fails. I figured that's how it was

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Gyan
On 13-01-2019 06:39 PM, Ronald S. Bultje wrote: Hi, On Sun, Jan 13, 2019 at 4:39 AM Gyan wrote: When someone submits a patch, it is implicit, unless stated otherwise, that it is of their own initiative (and their own work), and thus they are free to assign copyright. When work is performed

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Nicolas George
James Almer (12019-01-13): > Be the change you want in the world and post your day job income here > for all to see. Otherwise drop this absurd obsession of yours and let > people have a peaceful weekend. Of course: All that I have received related to my work on FFmpeg is: - coverage of my

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread James Almer
On 1/13/2019 10:40 AM, Nicolas George wrote: > James Almer (12019-01-13): >> I seem to remember the famous votes count voices, if one were to be called. > > You should check again, the rules state that mails without arguments do > not count. > >> Nicolas, no one is in favor of this thing. It's

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Nicolas George
James Almer (12019-01-13): > I seem to remember the famous votes count voices, if one were to be called. You should check again, the rules state that mails without arguments do not count. > Nicolas, no one is in favor of this thing. It's an invasion of privacy I do not consider this specific

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread James Almer
On 1/13/2019 10:18 AM, Nicolas George wrote: > Ronald S. Bultje (12019-01-13): >> But we don't do copyright assignment. > > There have been efforts of relicensing in the past.² > >> Anyway, like several others, I'm against this proposal. > > I seem to remember that arguments count, not voices.

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Paul B Mahol
On 1/13/19, Nicolas George wrote: > Ronald S. Bultje (12019-01-13): >> But we don't do copyright assignment. > > There have been efforts of relicensing in the past.² > >> Anyway, like several others, I'm against this proposal. > > I seem to remember that arguments count, not voices. I have given

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Nicolas George
Ronald S. Bultje (12019-01-13): > But we don't do copyright assignment. There have been efforts of relicensing in the past.² > Anyway, like several others, I'm against this proposal. I seem to remember that arguments count, not voices. I have given several arguments in the commit message,

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Ronald S. Bultje
Hi, On Sun, Jan 13, 2019 at 4:39 AM Gyan wrote: > When someone submits a patch, it is implicit, unless stated otherwise, > that it is of their own initiative (and their own work), and thus they > are free to assign copyright. When work is performed for hire, the > copyright may belong to the

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Nicolas George
Gyan (12019-01-13): > One angle that I haven't seen brought up is legal encumbrance. > > When someone submits a patch, it is implicit, unless stated otherwise, that > it is of their own initiative (and their own work), and thus they are free > to assign copyright. When work is performed for hire,

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

2019-01-13 Thread Gyan
On 12-01-2019 12:51 AM, Hendrik Leppkes wrote: To take a line from your post: Are you against privacy? Patches should generally be considered on their own merit. Any such information will only bias any discussions and result in more conflict. One angle that I haven't seen brought up is

[FFmpeg-devel] [PATCH v6] libswscale/ppc: VSX-optimize 9-16 bit yuv2planeX

2019-01-13 Thread Lauri Kasanen
./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt yuv420p16be \ -s 1920x1728 -f null -vframes 100 -v error -nostats - 9-14 bit funcs get about 6x speedup, 16-bit gets about 15x. Fate passes, each format tested with an image to video conversion. Only POWER8 includes 32-bit

Re: [FFmpeg-devel] [PATCH] avcodec/tests/rangecoder: initialize array to avoid valgrind warning

2019-01-13 Thread Steven Liu
> On Jan 12, 2019, at 22:49, Michael Niedermayer wrote: > > On Fri, Jan 04, 2019 at 02:46:29AM +0100, Michael Niedermayer wrote: >> Found-by: jamrial >> Signed-off-by: Michael Niedermayer >> --- >> libavcodec/tests/rangecoder.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > i