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

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, v4] lavc/hevc_parser: cope with more leading_zero_8bits and update FATE

> -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] [PATCH] doc/developer: require transparency about sponshorships.

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,

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

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

> 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

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

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.

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.

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.

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.

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.

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.

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] doc/developer: require transparency about sponshorships.

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.

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] avcodec/tests/rangecoder: initialize array to avoid valgrind warning

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 2/3] avcodec/gdv: Optimize and factorize scaling loops

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] doc/developer: require transparency about sponshorships.

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.

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] checkasm/af_afir: relax the max allowed absolute difference

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

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] Video codec design for very low-end decoder

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

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

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] matroskadec: Adjust content light side data check

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

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

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

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] doc/developer: require transparency about sponshorships.

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.

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.

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.

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.

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.

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.

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.

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] Video codec design for very low-end decoder

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:

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

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

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

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.

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] checkasm/af_afir: relax the max allowed absolute difference

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.

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.

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] doc/developer: require transparency about sponshorships.

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.

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.

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] [PATCH] doc/developer: require transparency about sponshorships.

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] matroskadec: Adjust content light side data check

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] doc/developer: require transparency about sponshorships.

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] checkasm/af_afir: relax the max allowed absolute difference

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

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

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

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

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

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

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 >

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

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] checkasm/af_afir: relax the max allowed absolute difference

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

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

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

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 1/4] vp3: ref_frame/ref_frames are only required when HAVE_THREADS=1

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

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

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 6/6] fate: update vp6 regression test data

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

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

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 1/4] vp3: ref_frame/ref_frames are only required when HAVE_THREADS=1

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

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

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

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

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

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

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

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

--- 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 5/6] avcodec/vp6: select idct based (loosely) on number of coefficients decoded

--- 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 1/6] avcodec/vp3dsp: add 12 pixel loop filter functions

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

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

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] matroskadec: Adjust content light side data check

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 0/6] improved VP6 decoding

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 ___

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

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

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

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] lavf/vaapi_deinterlace: return error if mode unsupported

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

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

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