Re: [FFmpeg-devel] [PATCH] avcodec/nuv: add FF_CODEC_CAP_INIT_CLEANUP
On Fri, Jan 11, 2019 at 01:05:38PM +, Derek Buitenhuis wrote: > On 11/01/2019 01:15, Michael Niedermayer wrote: > > Fixes: memleak > > Fixes: > > 12244/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_NUV_fuzzer-5099447273390080 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > --- > > libavcodec/nuv.c | 1 + > > 1 file changed, 1 insertion(+) > > OK. will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/hevc_parser: report detailed log when missing picture occurs
On Fri, Jan 11, 2019 at 04:07:33PM +0800, Linjie Fu wrote: > Report the detailed log with buf_size in parse_nal_units to provide > more information when picture could not be found. > > Match the behaviour in h264_parser. > > Signed-off-by: Linjie Fu > --- > libavcodec/hevc_parser.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Video codec design for very low-end decoder
Hi, On Thu, Jan 10, 2019 at 2:41 PM Carl Eugen Hoyos wrote: > 2019-01-07 18:37 GMT+01:00, Ronald S. Bultje : > > Hi, > > > > On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen wrote: > > > >> On Mon, 7 Jan 2019 12:02:58 -0500 > >> "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 has a reputation of being slow, so I didn't consider it. Benchmarks > >> show it as decoding slower than h264. > >> > > > > It is faster than h264 when comparing ffh264 vs. ffvp8: > > > > https://blogs.gnome.org/rbultje/files/2014/02/sintel_decspeed.png > > Are the relations identical without asm optimizations? > I believe so, yes. The theory behind it would be that lack of per-symbol probability adaptations in CABAC and bidirectional prediction were missing in VP8, both of which incur a significant runtime overhead. Then, if you start disabling tools (e.g. CABAC -> CAVLC) this difference would probably diminish quite quickly. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4] libswscale/ppc: VSX-optimize 9-16 bit yuv2planeX
On Fri, Jan 11, 2019 at 11:16:20AM +0200, Lauri Kasanen wrote: > On Fri, 11 Jan 2019 09:56:15 +0100 > Michael Niedermayer wrote: > > > > +#ifdef __GNUC__ > > > +// GCC does not support vmuluwm yet. Bug open. > > > > this should probably be tested by configure similar to how other > > compiler limitations are tested > > We can't really test for it, because there is no standard name for it. I > don't know what name the gcc devs will pick for it, it could be vec_mul, > vec_vmuluwm or something different. the code contains a #if and a #else case so i thought there was something else than the __GNUC__ case and gcc would follow that [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.
> > Signed-off-by: Nicolas George > > --- > > doc/developer.texi | 10 ++ > > 1 file changed, 10 insertions(+) > > Rather than repeat myself, I'll refer to my previous mails: > > * http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/238740.html > * http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/238743.html > > I utterly and absolutely think no good will come from such a policy. It's > divisive, exclusionary, inflamatory, witch-hunt-y, and privacy invading, > among other things. > > I'm speechless. Words cannot describe how terrible I think such a policy is > for current and future contributors, and I am of the opinion that adopting > such a policy would see any work sent to FFmpeg by anyone involved in a > company, which I may add, is a lot, utterly dry up. > > I've not much more to say on the matter, and I will not engage in flame > wars after. > > - Derek > > (P.S. Just how do you intend to enforce this? How do you prove/disprove > someone > has been paid in some form, directly, or indiectly? Do you just accuse them > on > the list?) > > (P.P.S. I am aware my opinions hold little clout here nowadays, so take my > response > as you will.) > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel My official contributions to ffmpeg are small and as such there isn't much value in my saying "I agree as well". By now I've got a much longer list of changes that I haven't submitted back as patches to ffmpeg than those where I did. This happened for various reasons none of which to blame ffmpeg for. Many others are doing the same. That leads to fragmentation of the code base of course. Fragmentation is not a bad thing per se - many changes are not suitable for general inclusion. But sometimes it can be even just small things keeping an individual developer from submitting patches back when he's got the option to go with his own "ffmpeg+custom" code base. That kind of fragmentation is bad of course, when the common code base could have benefited from a change. Establishing a "transparency requirement" as described, would set up an additional - for some even huge - impediment for contributing back their work. So, while my consent is surely irrelevant (per my own conviction), I really wonder if such a decision would be good for the project. softworkz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/lzw: Check for end of input
Fixes: Timeout
Fixes:
11873/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5093495044308992
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/lzw.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/lzw.c b/libavcodec/lzw.c
index b0b9a34358..e26e4829ee 100644
--- a/libavcodec/lzw.c
+++ b/libavcodec/lzw.c
@@ -71,6 +71,9 @@ static int lzw_get_code(struct LZWState * s)
{
int c;
+if (s->bbits < s->cursize && bytestream2_get_bytes_left(&s->gb) <= 0)
+return s->end_code;
+
if(s->mode == FF_LZW_GIF) {
while (s->bbits < s->cursize) {
if (!s->bs) {
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dxva2: d3d11va: don't try to get surface description for nullptr
2019-01-11 8:07 GMT+01:00, Anton Fedchin :
>>2019-01-05 11:44 GMT+01:00, Anton Fedchin :
>>> From: Anton Fedchin
>>>
>>> after 153b36f there is a possibility to crash when trying to get index of
>>> a surface which points to nirvana. it may occurs when a stream starts
>>> with
>>> non i-frame.
>>> ---
>>> libavcodec/dxva2.c | 10 ++
>>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
>>> index 32416112bf..dfae500444 100644
>>> --- a/libavcodec/dxva2.c
>>> +++ b/libavcodec/dxva2.c
>>> @@ -771,16 +771,18 @@ unsigned ff_dxva2_get_surface_index(const
>>> AVCodecContext *avctx,
>>> #if CONFIG_D3D11VA
>>> if (avctx->pix_fmt == AV_PIX_FMT_D3D11)
>>> return (intptr_t)frame->data[1];
>>> -if (avctx->pix_fmt == AV_PIX_FMT_D3D11VA_VLD) {
>>> +if (avctx->pix_fmt == AV_PIX_FMT_D3D11VA_VLD && surface) {
>>> D3D11_VIDEO_DECODER_OUTPUT_VIEW_DESC viewDesc;
>>>
>>> ID3D11VideoDecoderOutputView_GetDesc((ID3D11VideoDecoderOutputView*)
>>> surface, &viewDesc);
>>> return viewDesc.Texture2D.ArraySlice;
>>> }
>>> #endif
>>
>>> #if CONFIG_DXVA2
>>> -for (i = 0; i < DXVA_CONTEXT_COUNT(avctx, ctx); i++) {
>>> -if (avctx->pix_fmt == AV_PIX_FMT_DXVA2_VLD &&
>>> ctx->dxva2.surface[i]
>>> == surface)
>>> -return i;
>>> +if (avctx->pix_fmt == AV_PIX_FMT_DXVA2_VLD) {
>>> +for (i = 0; i < DXVA_CONTEXT_COUNT(avctx, ctx); i++) {
>>> +if (ctx->dxva2.surface[i] == surface)
>>> +return i;
>>> +}
>>
>>How is this change related?
>>
>>Carl Eugen
>
> Hi Carl,
>
> If previous condition is failed (i.e. pix_fmt is AV_PIX_FMT_D3D11VA_VLD and
> surface is null) it will iterate through all surfaces again with no sense.
> Yes, this is not related directly to the fix, but the fix changes method's
> behavior if surface is null and I found it necessary to change this block
> also
Please make it a separate patch.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Mark .rodata section as read only in COFF object file
Thanks Carl. Martin made a better fix when porting this to libav which uses .rdata as section name instead of .rodata with explicit read-only property. .rdata is read-only in COFF by default. I updated my patch accordingly, thanks Martin. Yes, this applies to 32-bit arm for Windows, the new patch includes this update. This also affects Windows x86/x64, but this has already been handled as below macro from FFmpeg\libavutil\x86\x86inc.asm. %macro SECTION_RODATA 0-1 16 %ifidn __OUTPUT_FORMAT__,aout SECTION .text %elifidn __OUTPUT_FORMAT__,coff SECTION .text %elifidn __OUTPUT_FORMAT__,win32 SECTION .rdata align=%1 %elif WIN64 SECTION .rdata align=%1 %else SECTION .rodata align=%1 %endif %endmacro -Original Message- From: ffmpeg-devel On Behalf Of Carl Eugen Hoyos Sent: Friday, January 11, 2019 5:07 AM To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH] Mark .rodata section as read only in COFF object file 2019-01-10 21:14 GMT+01:00, Tom Tan : > .rodata directive from GAS assembly produces .rodata as read/write for > COFF object file by default (object file format for Windows), but read > only for ELF. This change marks it as read only explicitly for COFF. > > The issue happens when building Chromium for Windows ARM64, with FFmpeg. Does this issue only apply to arm64 or also 32bit arm? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel 0001-Switch-.rodata-section-name-to-.rdata-for-COFF-objec.patch Description: 0001-Switch-.rodata-section-name-to-.rdata-for-COFF-objec.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.
On Fri, Jan 11, 2019 at 8:05 PM Nicolas George wrote: > > On the other hand, I have observed in the past patches that were of poor > quality and suspected they were the result of sponsorships. I would like > to know. Would you not? > Wanting to know and forcing everyone to tell you are two entirely different things. Its everyones right to keep their finances private. Would I be forced to disclose my hourly wages and then determine how long I worked on a patch, just because I did it during my day job? Thats not going to happen. 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. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.
Hi, On Fri, Jan 11, 2019 at 11:05 AM Nicolas George wrote: > > Kyle Swanson (12019-01-11): > > Lots of people get paid to work on OSS. It's not a conspiracy, that's > > just the way it is. If someone gets paid to write a patch that does > > something useful, great. They got paid, and FFmpeg is better. If > > someone gets paid to write a patch that's no good, we just don't merge > > it. I don't see any reason FFmpeg should be concerned who is getting > > paid and how much. > > I agree with that. Only you are suggesting a "conspiracy". Sorry, bad word choice. > > I am not suggesting we ban people from getting paid, I am not leading a > "witch hunt", I only advocate for transparency and honesty. > > Are you against transparency and honesty? > > On the other hand, I have observed in the past patches that were of poor > quality and suspected they were the result of sponsorships. I would like > to know. Would you not? If someone sends a bad patch, we have no obligation to merge it. > > Regards, > > -- > Nicolas George > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Thanks, Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.
Kyle Swanson (12019-01-11): > Lots of people get paid to work on OSS. It's not a conspiracy, that's > just the way it is. If someone gets paid to write a patch that does > something useful, great. They got paid, and FFmpeg is better. If > someone gets paid to write a patch that's no good, we just don't merge > it. I don't see any reason FFmpeg should be concerned who is getting > paid and how much. I agree with that. Only you are suggesting a "conspiracy". I am not suggesting we ban people from getting paid, I am not leading a "witch hunt", I only advocate for transparency and honesty. Are you against transparency and honesty? On the other hand, I have observed in the past patches that were of poor quality and suspected they were the result of sponsorships. I would like to know. Would you not? Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.
On Fri, Jan 11, 2019, at 9:21 AM, Nicolas George wrote: > > Signed-off-by: Nicolas George > --- > doc/developer.texi | 10 ++ > 1 file changed, 10 insertions(+) I am against this and completely agree with Derek and Kyle. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.
On Fri, 11 Jan 2019 at 18:38, Derek Buitenhuis wrote: > On 11/01/2019 18:21, Nicolas George wrote: > > Signed-off-by: Nicolas George > > --- > > doc/developer.texi | 10 ++ > > 1 file changed, 10 insertions(+) > > Rather than repeat myself, I'll refer to my previous mails: > > * http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/238740.html > * http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/238743.html > > I utterly and absolutely think no good will come from such a policy. It's > divisive, exclusionary, inflamatory, witch-hunt-y, and privacy invading, > among other things. > > I'm speechless. Words cannot describe how terrible I think such a policy is > for current and future contributors, and I am of the opinion that adopting > such a policy would see any work sent to FFmpeg by anyone involved in a > company, which I may add, is a lot, utterly dry up. > > I've not much more to say on the matter, and I will not engage in flame > wars after. > > - Derek > > (P.S. Just how do you intend to enforce this? How do you prove/disprove > someone > has been paid in some form, directly, or indiectly? Do you just accuse > them on > the list?) > > (P.P.S. I am aware my opinions hold little clout here nowadays, so take my > response > as you will.) > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I fully agree. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.
Hi,
On Fri, Jan 11, 2019 at 10:21 AM 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 burden cost efforts
> to the whole project; knowing that sponsorship has been given, to an
> individual or to the whole project, helps evaluating if the benefits
> match the costs.
>
> * Inclusion in FFmpeg implies implicit endorsement by the project;
> we owe to our users to disclose when this endorsement is not genuine;
> this is to relate to mandatory flagging of advertisement in mass media.
>
> * Systematic disclosure and transparency make a stronger position
> against accusations of bias or conflict of interest for difficult
> policy decisions.
>
> * Documenting bounties may give an incentive to new contributors
> who may not be aware of these opportunities.
>
> Signed-off-by: Nicolas George
> ---
> doc/developer.texi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 5c342c9106..1d77250083 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -420,6 +420,13 @@ your name after it.
> If at some point you no longer want to maintain some code, then please help
> in
> finding a new maintainer and also don't forget to update the
> @file{MAINTAINERS} file.
>
> +@subheading Disclose sponsors and other remunerations
> +If the patch is the result of sponsored work, expects a bounty or benefited
> +from any kind of specific remuneration or payment, include the identity of
> +the sponsors, the identity of the recipients (if it is not exactly the
> +author of the patch) and the amount (or an approximation if it is not
> +possible to define it exactly) in the commit message.
> +
> We think our rules are not too hard. If you have comments, contact us.
>
> @chapter Code of conduct
> @@ -664,6 +671,9 @@ are notoriously left unchecked, which is a serious
> problem.
> @item
> Test your code with valgrind and or Address Sanitizer to ensure it's free
> of leaks, out of array accesses, etc.
> +
> +@item
> +Did you disclose any sponsorship in the commit message?
> @end enumerate
>
> @chapter Patch review process
> --
> 2.20.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Lots of people get paid to work on OSS. It's not a conspiracy, that's
just the way it is. If someone gets paid to write a patch that does
something useful, great. They got paid, and FFmpeg is better. If
someone gets paid to write a patch that's no good, we just don't merge
it. I don't see any reason FFmpeg should be concerned who is getting
paid and how much.
Thanks,
Kyle
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dxva2: d3d11va: don't try to get surface description for nullptr
>2019-01-05 11:44 GMT+01:00, Anton Fedchin :
>> From: Anton Fedchin
>>
>> after 153b36f there is a possibility to crash when trying to get index of
>> a surface which points to nirvana. it may occurs when a stream starts with
>> non i-frame.
>> ---
>> libavcodec/dxva2.c | 10 ++
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
>> index 32416112bf..dfae500444 100644
>> --- a/libavcodec/dxva2.c
>> +++ b/libavcodec/dxva2.c
>> @@ -771,16 +771,18 @@ unsigned ff_dxva2_get_surface_index(const
>> AVCodecContext *avctx,
>> #if CONFIG_D3D11VA
>> if (avctx->pix_fmt == AV_PIX_FMT_D3D11)
>> return (intptr_t)frame->data[1];
>> -if (avctx->pix_fmt == AV_PIX_FMT_D3D11VA_VLD) {
>> +if (avctx->pix_fmt == AV_PIX_FMT_D3D11VA_VLD && surface) {
>> D3D11_VIDEO_DECODER_OUTPUT_VIEW_DESC viewDesc;
>>
>> ID3D11VideoDecoderOutputView_GetDesc((ID3D11VideoDecoderOutputView*)
>> surface, &viewDesc);
>> return viewDesc.Texture2D.ArraySlice;
>> }
>> #endif
>
>> #if CONFIG_DXVA2
>> -for (i = 0; i < DXVA_CONTEXT_COUNT(avctx, ctx); i++) {
>> -if (avctx->pix_fmt == AV_PIX_FMT_DXVA2_VLD && ctx->dxva2.surface[i]
>> == surface)
>> -return i;
>> +if (avctx->pix_fmt == AV_PIX_FMT_DXVA2_VLD) {
>> +for (i = 0; i < DXVA_CONTEXT_COUNT(avctx, ctx); i++) {
>> +if (ctx->dxva2.surface[i] == surface)
>> +return i;
>> +}
>
>How is this change related?
>
>Carl Eugen
Hi Carl,
If previous condition is failed (i.e. pix_fmt is AV_PIX_FMT_D3D11VA_VLD and
surface is null) it will iterate through all surfaces again with no sense.
Yes, this is not related directly to the fix, but the fix changes method's
behavior if surface is null and I found it necessary to change this block also
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.
On 11/01/2019 18:21, Nicolas George wrote: > Signed-off-by: Nicolas George > --- > doc/developer.texi | 10 ++ > 1 file changed, 10 insertions(+) Rather than repeat myself, I'll refer to my previous mails: * http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/238740.html * http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/238743.html I utterly and absolutely think no good will come from such a policy. It's divisive, exclusionary, inflamatory, witch-hunt-y, and privacy invading, among other things. I'm speechless. Words cannot describe how terrible I think such a policy is for current and future contributors, and I am of the opinion that adopting such a policy would see any work sent to FFmpeg by anyone involved in a company, which I may add, is a lot, utterly dry up. I've not much more to say on the matter, and I will not engage in flame wars after. - Derek (P.S. Just how do you intend to enforce this? How do you prove/disprove someone has been paid in some form, directly, or indiectly? Do you just accuse them on the list?) (P.P.S. I am aware my opinions hold little clout here nowadays, so take my response as you will.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.
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 burden cost efforts
to the whole project; knowing that sponsorship has been given, to an
individual or to the whole project, helps evaluating if the benefits
match the costs.
* Inclusion in FFmpeg implies implicit endorsement by the project;
we owe to our users to disclose when this endorsement is not genuine;
this is to relate to mandatory flagging of advertisement in mass media.
* Systematic disclosure and transparency make a stronger position
against accusations of bias or conflict of interest for difficult
policy decisions.
* Documenting bounties may give an incentive to new contributors
who may not be aware of these opportunities.
Signed-off-by: Nicolas George
---
doc/developer.texi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/doc/developer.texi b/doc/developer.texi
index 5c342c9106..1d77250083 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -420,6 +420,13 @@ your name after it.
If at some point you no longer want to maintain some code, then please help in
finding a new maintainer and also don't forget to update the
@file{MAINTAINERS} file.
+@subheading Disclose sponsors and other remunerations
+If the patch is the result of sponsored work, expects a bounty or benefited
+from any kind of specific remuneration or payment, include the identity of
+the sponsors, the identity of the recipients (if it is not exactly the
+author of the patch) and the amount (or an approximation if it is not
+possible to define it exactly) in the commit message.
+
We think our rules are not too hard. If you have comments, contact us.
@chapter Code of conduct
@@ -664,6 +671,9 @@ are notoriously left unchecked, which is a serious problem.
@item
Test your code with valgrind and or Address Sanitizer to ensure it's free
of leaks, out of array accesses, etc.
+
+@item
+Did you disclose any sponsorship in the commit message?
@end enumerate
@chapter Patch review process
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Transparency of sponsored works (was: avcodec: add photocd decoder)
On Fri, 11 Jan 2019, 15:31 Nicolas George Carl Eugen Hoyos (12019-01-11): > > I believe amount is never published (so far at least afair). > > I think it should. I wonder what other people think. > I don't see why this declaration is helpful or necessary in any way. Can you elaborate on why it is? Best, Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2 v2] avcodec/vc1: fix decoding of old WMV3 format
The position of the second MV predicitor candidate is slightly different
for the old WMV3 format indicated by RES_RTM_FLAG. This patch fixes
decoding of niceday.wmv on the samples server.
Fixes: #6641
Signed-off-by: Jerome Borsboom
---
libavcodec/vc1.c | 5 -
libavcodec/vc1_pred.c | 5 -
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vc1.c b/libavcodec/vc1.c
index 3581d87b57..e102b931d8 100644
--- a/libavcodec/vc1.c
+++ b/libavcodec/vc1.c
@@ -379,11 +379,6 @@ int ff_vc1_decode_sequence_header(AVCodecContext *avctx,
VC1Context *v, GetBitCo
} else {
v->res_rtm_flag = get_bits1(gb); //reserved
}
-if (!v->res_rtm_flag) {
-av_log(avctx, AV_LOG_ERROR,
- "Old WMV3 version detected, some frames may be decoded
incorrectly\n");
-//return -1;
-}
//TODO: figure out what they mean (always 0x402F)
if (!v->res_fasttx)
skip_bits(gb, 16);
diff --git a/libavcodec/vc1_pred.c b/libavcodec/vc1_pred.c
index 0b22d9916c..cff87907ec 100644
--- a/libavcodec/vc1_pred.c
+++ b/libavcodec/vc1_pred.c
@@ -275,7 +275,10 @@ void ff_vc1_pred_mv(VC1Context *v, int n, int dmv_x, int
dmv_y,
//in 4-MV mode different blocks have different B predictor position
switch (n) {
case 0:
-off = (s->mb_x > 0) ? -1 : 1;
+if (v->res_rtm_flag)
+off = s->mb_x ? -1 : 1;
+else
+off = s->mb_x ? -1 : 2 * s->mb_width - wrap - 1;
break;
case 1:
off = (s->mb_x == (s->mb_width - 1)) ? -1 : 1;
--
2.13.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add photocd decoder
Derek Buitenhuis (12019-01-11): > I'm sorry, but this just reeks of "your motives aren't pure enough for > us to trust you" partisanship, which is, frankly, disgusting. Maybe not enough people have been obnoxious to you during review for you to feel the problem. Or maybe you have thicker skin. > I suspect the replies will not reflect what you think they will, but > if it is the only way... so be it. That is possible. Let us see. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add photocd decoder
On 11/01/2019 16:23, Nicolas George wrote: > Derek Buitenhuis (12019-01-11): >> Irrelevant to whether a patch is acceptable or not to FFmpeg. > > In theory, it is, and it should be. > > In practice, I have several times suspected a sponsored work was the > reason behind cutting corners, poor design and future planning, bad > reception of review comments, etc. A mandatory disclosure would make > these bad behaviours obvious. I'm sorry, but this just reeks of "your motives aren't pure enough for us to trust you" partisanship, which is, frankly, disgusting. > I will produce a patch on the developer policy to start a real > discussion. I suspect the replies will not reflect what you think they will, but if it is the only way... so be it. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add photocd decoder
Derek Buitenhuis (12019-01-11): > Irrelevant to whether a patch is acceptable or not to FFmpeg. In theory, it is, and it should be. In practice, I have several times suspected a sponsored work was the reason behind cutting corners, poor design and future planning, bad reception of review comments, etc. A mandatory disclosure would make these bad behaviours obvious. I will produce a patch on the developer policy to start a real discussion. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Transparency of sponsored works (was: avcodec: add photocd decoder)
On Fri, 11 Jan 2019 at 15:31 Nicolas George wrote: > Carl Eugen Hoyos (12019-01-11): > > I believe amount is never published (so far at least afair). > > I think it should. I wonder what other people think. > Are you completely out of your mind? Regards, Kieran Kunhya ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add photocd decoder
On 11/01/2019 15:26, Nicolas George wrote: > Carl Eugen Hoyos (12019-01-11): >> The original unfinished demuxer was posted to the development >> mailing list: >> https://ffmpeg.org/pipermail/ffmpeg-devel/2010-January/086658.html > > Ah, good to know. Still, Paul made efforts to resurrect that patch, I > wonder if these efforts were sponsored, and in that case what the > sponsor thinks about them staying unfinished, or if they were not, and > in that case why expect payment for the final efforts. Irrelevant to whether a patch is acceptable or not to FFmpeg. > More generally, I think it would be a good practice that any submission > that is sponsored is clearly marked as such: identity of the sponsor, > amount, identity of the recipient(s). Why and to what end? Seems like a great way to witchhunt specific patches. Also, nobody has ANY business knowing what someone else is paid if they don't want to supply that info. None at all. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/tiff: Support some CMYK samples
On 11/01/2019 14:54, Carl Eugen Hoyos wrote: > Hi! > > Attached patch that fixes the sample from ticket #3459 cannot be > factorized with the code in mjpegdec (and psd), the representation is > different. Is there a good reason this is RGB0 instead of RGB24? Other than that, seems OK, if tested (is there a FATE sample we can add?) - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Transparency of sponsored works (was: avcodec: add photocd decoder)
Carl Eugen Hoyos (12019-01-11): > I believe amount is never published (so far at least afair). I think it should. I wonder what other people think. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add photocd decoder
2019-01-11 16:26 GMT+01:00, Nicolas George : > Carl Eugen Hoyos (12019-01-11): >> The original unfinished demuxer was posted to the development >> mailing list: >> https://ffmpeg.org/pipermail/ffmpeg-devel/2010-January/086658.html > > Ah, good to know. Still, Paul made efforts to resurrect that patch, I > wonder if these efforts were sponsored, and in that case what the > sponsor thinks about them staying unfinished, or if they were not, and > in that case why expect payment for the final efforts. > > More generally, I think it would be a good practice that any submission > that is sponsored is clearly marked as such: identity of the sponsor, > amount, identity of the recipient(s). I believe amount is never published (so far at least afair). Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add photocd decoder
Carl Eugen Hoyos (12019-01-11): > The original unfinished demuxer was posted to the development > mailing list: > https://ffmpeg.org/pipermail/ffmpeg-devel/2010-January/086658.html Ah, good to know. Still, Paul made efforts to resurrect that patch, I wonder if these efforts were sponsored, and in that case what the sponsor thinks about them staying unfinished, or if they were not, and in that case why expect payment for the final efforts. More generally, I think it would be a good practice that any submission that is sponsored is clearly marked as such: identity of the sponsor, amount, identity of the recipient(s). Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add photocd decoder
2019-01-11 16:20 GMT+01:00, Nicolas George : > Paul B Mahol (12019-01-11): >> No, pay me first. > > That actually explains a lot of things... > > But I wonder: were you not payed by somebody for this > unfinished demuxer? The original unfinished demuxer was posted to the development mailing list: https://ffmpeg.org/pipermail/ffmpeg-devel/2010-January/086658.html Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add photocd decoder
Paul B Mahol (12019-01-11): > No, pay me first. That actually explains a lot of things... But I wonder: were you not payed by somebody for this unfinished demuxer? -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/psd: Support CMYK images
On 11/01/2019 14:20, Carl Eugen Hoyos wrote: > Yes, but they can have different representations in FFmpeg. I suppose the "correct" fix is to put it in swscale, but noone is going to want to do that. > Is this patch ok? No strong opinion. I doubt anyone will want to patch swscale, so I suppose it is OK. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference
On 11/01/2019 13:28, Hendrik Leppkes wrote: > Because the computation accumulates more inaccuarcy then FLT_EPSILON > allows for. That value is really not of that great use. If you have > two accurate numbers and do one calculation, it may work, but if you > do a whole bunch of them, the error accumulates and eventually gets > bigger then FLT_EPSILON. > x86_32 floating point is for $reasons a tad bit less accurate then on > x86_64, for example, resulting in the test failing. We have some other > float tests that do (or used to) fail sporadically due to inaccuracy > problems, which sometimes where fixed by similar means - or > multiplifying FLT_EPSILON to make it bigger. OK. Two things: 1. That should be in the commit messages. 2. Would some multiple of FLT_EPSILON make more sense? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavc/tiff: Support some CMYK samples
Hi!
Attached patch that fixes the sample from ticket #3459 cannot be
factorized with the code in mjpegdec (and psd), the representation is
different.
Please comment, Carl Eugen
From c4f9f6248af4b277695b90bf3d2efdc8687d70d3 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Fri, 11 Jan 2019 15:44:17 +0100
Subject: [PATCH] lavc/tiff: Support CMYK images.
Fixes ticket #3459.
---
libavcodec/tiff.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 570b3cb..5a4271c 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -825,7 +825,7 @@ static int init_image(TiffContext *s, ThreadFrame *frame)
s->avctx->pix_fmt = s->le ? AV_PIX_FMT_YA16LE : AV_PIX_FMT_YA16BE;
break;
case 324:
-s->avctx->pix_fmt = AV_PIX_FMT_RGBA;
+s->avctx->pix_fmt = s->photometric == TIFF_PHOTOMETRIC_SEPARATED ? AV_PIX_FMT_RGB0 : AV_PIX_FMT_RGBA;
break;
case 483:
s->avctx->pix_fmt = s->le ? AV_PIX_FMT_RGB48LE : AV_PIX_FMT_RGB48BE;
@@ -1100,12 +1100,12 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame)
case TIFF_PHOTOMETRIC_BLACK_IS_ZERO:
case TIFF_PHOTOMETRIC_RGB:
case TIFF_PHOTOMETRIC_PALETTE:
+case TIFF_PHOTOMETRIC_SEPARATED:
case TIFF_PHOTOMETRIC_YCBCR:
case TIFF_PHOTOMETRIC_CFA:
s->photometric = value;
break;
case TIFF_PHOTOMETRIC_ALPHA_MASK:
-case TIFF_PHOTOMETRIC_SEPARATED:
case TIFF_PHOTOMETRIC_CIE_LAB:
case TIFF_PHOTOMETRIC_ICC_LAB:
case TIFF_PHOTOMETRIC_ITU_LAB:
@@ -1530,6 +1530,24 @@ again:
dst += stride;
}
}
+
+if (s->photometric == TIFF_PHOTOMETRIC_SEPARATED &&
+s->avctx->pix_fmt == AV_PIX_FMT_RGB0) {
+dst = p->data[plane];
+for (i = 0; i < s->height; i++) {
+for (j = 0; j < s->width; j++) {
+int k = 255 - dst[4 * j + 3];
+int r = (255 - dst[4 * j]) * k;
+int g = (255 - dst[4 * j + 1]) * k;
+int b = (255 - dst[4 * j + 2]) * k;
+dst[4 * j] = r * 257 >> 16;
+dst[4 * j + 1] = g * 257 >> 16;
+dst[4 * j + 2] = b * 257 >> 16;
+dst[4 * j + 3] = 255;
+}
+dst += p->linesize[plane];
+}
+}
}
if (s->planar && s->bppcount > 2) {
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/vc1: fix decoding of old WMV3 format
2019-01-11 15:36 GMT+01:00, Jerome Borsboom :
> The position of the B MV predicitor candidate is slightly different
> for the old WMV3 format that is indicated by RES_RTM_FLAG. This patch
> fixes the decoding artifacts in the niceday.wmv sample.
Cool!
Please mention / test ticket #6641, there are still (less) artefacts.
> Signed-off-by: Jerome Borsboom
> ---
> libavcodec/vc1.c | 5 -
> libavcodec/vc1_pred.c | 7 ++-
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/vc1.c b/libavcodec/vc1.c
> index 3581d87b57..e102b931d8 100644
> --- a/libavcodec/vc1.c
> +++ b/libavcodec/vc1.c
> @@ -379,11 +379,6 @@ int ff_vc1_decode_sequence_header(AVCodecContext
> *avctx, VC1Context *v, GetBitCo
> } else {
> v->res_rtm_flag = get_bits1(gb); //reserved
> }
> -if (!v->res_rtm_flag) {
> -av_log(avctx, AV_LOG_ERROR,
> - "Old WMV3 version detected, some frames may be decoded
> incorrectly\n");
> -//return -1;
> -}
> //TODO: figure out what they mean (always 0x402F)
> if (!v->res_fasttx)
> skip_bits(gb, 16);
> diff --git a/libavcodec/vc1_pred.c b/libavcodec/vc1_pred.c
> index 0b22d9916c..1ae1e33fbe 100644
> --- a/libavcodec/vc1_pred.c
> +++ b/libavcodec/vc1_pred.c
> @@ -275,7 +275,12 @@ void ff_vc1_pred_mv(VC1Context *v, int n, int dmv_x,
> int dmv_y,
> //in 4-MV mode different blocks have different B predictor position
> switch (n) {
> case 0:
> -off = (s->mb_x > 0) ? -1 : 1;
> +if (v->res_rtm_flag)
> +off = s->mb_x ? -1 : 1;
> +else {
Please add more (free) braces.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/vc1: fix decoding of old WMV3 format
The position of the B MV predicitor candidate is slightly different
for the old WMV3 format that is indicated by RES_RTM_FLAG. This patch
fixes the decoding artifacts in the niceday.wmv sample.
Signed-off-by: Jerome Borsboom
---
libavcodec/vc1.c | 5 -
libavcodec/vc1_pred.c | 7 ++-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vc1.c b/libavcodec/vc1.c
index 3581d87b57..e102b931d8 100644
--- a/libavcodec/vc1.c
+++ b/libavcodec/vc1.c
@@ -379,11 +379,6 @@ int ff_vc1_decode_sequence_header(AVCodecContext *avctx,
VC1Context *v, GetBitCo
} else {
v->res_rtm_flag = get_bits1(gb); //reserved
}
-if (!v->res_rtm_flag) {
-av_log(avctx, AV_LOG_ERROR,
- "Old WMV3 version detected, some frames may be decoded
incorrectly\n");
-//return -1;
-}
//TODO: figure out what they mean (always 0x402F)
if (!v->res_fasttx)
skip_bits(gb, 16);
diff --git a/libavcodec/vc1_pred.c b/libavcodec/vc1_pred.c
index 0b22d9916c..1ae1e33fbe 100644
--- a/libavcodec/vc1_pred.c
+++ b/libavcodec/vc1_pred.c
@@ -275,7 +275,12 @@ void ff_vc1_pred_mv(VC1Context *v, int n, int dmv_x, int
dmv_y,
//in 4-MV mode different blocks have different B predictor position
switch (n) {
case 0:
-off = (s->mb_x > 0) ? -1 : 1;
+if (v->res_rtm_flag)
+off = s->mb_x ? -1 : 1;
+else {
+off = s->mb_x ? -1 : 2 * s->mb_width - wrap - 1;
+b_valid = b_valid && (s->mb_x || s->mb_y > 1);
+}
break;
case 1:
off = (s->mb_x == (s->mb_width - 1)) ? -1 : 1;
--
2.13.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/vc1: shuffle calculation of MV predictor candidates
The B predictor for 4-MV macroblocks is only out of bounds when
the A predictor is also out of bounds.
Signed-off-by: Jerome Borsboom
---
This patch set fixes the decoding artifacts in the niceday.wmv file
on the samples server.
libavcodec/vc1_pred.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vc1_pred.c b/libavcodec/vc1_pred.c
index de736ec775..0b22d9916c 100644
--- a/libavcodec/vc1_pred.c
+++ b/libavcodec/vc1_pred.c
@@ -262,13 +262,15 @@ void ff_vc1_pred_mv(VC1Context *v, int n, int dmv_x, int
dmv_y,
return;
}
-C = s->current_picture.motion_val[dir][xy -1 + v->blocks_off];
-A = s->current_picture.motion_val[dir][xy - wrap + v->blocks_off];
+a_valid = !s->first_slice_line || (n == 2 || n == 3);
+b_valid = a_valid;
+c_valid = s->mb_x || (n == 1 || n == 3);
if (mv1) {
if (v->field_mode && mixedmv_pic)
off = (s->mb_x == (s->mb_width - 1)) ? -2 : 2;
else
off = (s->mb_x == (s->mb_width - 1)) ? -1 : 2;
+b_valid = b_valid && s->mb_width > 1;
} else {
//in 4-MV mode different blocks have different B predictor position
switch (n) {
@@ -285,11 +287,7 @@ void ff_vc1_pred_mv(VC1Context *v, int n, int dmv_x, int
dmv_y,
off = -1;
}
}
-B = s->current_picture.motion_val[dir][xy - wrap + off + v->blocks_off];
-a_valid = !s->first_slice_line || (n == 2 || n == 3);
-b_valid = a_valid && (s->mb_width > 1);
-c_valid = s->mb_x || (n == 1 || n == 3);
if (v->field_mode) {
a_valid = a_valid && !is_intra[xy - wrap];
b_valid = b_valid && !is_intra[xy - wrap + off];
@@ -297,6 +295,7 @@ void ff_vc1_pred_mv(VC1Context *v, int n, int dmv_x, int
dmv_y,
}
if (a_valid) {
+A = s->current_picture.motion_val[dir][xy - wrap + v->blocks_off];
a_f = v->mv_f[dir][xy - wrap + v->blocks_off];
num_oppfield += a_f;
num_samefield += 1 - a_f;
@@ -307,6 +306,7 @@ void ff_vc1_pred_mv(VC1Context *v, int n, int dmv_x, int
dmv_y,
a_f = 0;
}
if (b_valid) {
+B = s->current_picture.motion_val[dir][xy - wrap + off +
v->blocks_off];
b_f = v->mv_f[dir][xy - wrap + off + v->blocks_off];
num_oppfield += b_f;
num_samefield += 1 - b_f;
@@ -317,6 +317,7 @@ void ff_vc1_pred_mv(VC1Context *v, int n, int dmv_x, int
dmv_y,
b_f = 0;
}
if (c_valid) {
+C = s->current_picture.motion_val[dir][xy - 1 + v->blocks_off];
c_f = v->mv_f[dir][xy - 1 + v->blocks_off];
num_oppfield += c_f;
num_samefield += 1 - c_f;
--
2.13.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/psd: Support CMYK images
2019-01-11 14:05 GMT+01:00, Derek Buitenhuis : > On 11/01/2019 06:17, Peter Ross wrote: >> the same algorithm exists in libavcodec/mjpegdec.c, with alpha channel >> support. >> i guess it is trivial enough to be duplicated here. > > Is it worth deduplicating? Plenty of image formats have CMYK. Yes, but they can have different representations in FFmpeg. Is this patch ok? Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: set BRCParamMultiplier to aviod BRC overflow
Good catch.Yes,that is possible but possibility is smaller than bitrate since they are in Bytes. I got it too but finally ignored them to make things simple. Let me send an update version soon. Carl Eugen Hoyos 于 2019年1月11日周五 下午9:45写道： > 2019-01-11 14:25 GMT+01:00, Hendrik Leppkes : > > On Fri, Jan 11, 2019 at 1:18 PM Carl Eugen Hoyos > wrote: > >> > >> 2019-01-11 13:09 GMT+01:00, Zhong Li : > >> > +//libmfx BRC parameters are 16 bits thus maybe overflow, then > >> > BRCParamMultiplier is needed > >> > +target_bitrate_kbps = avctx->bit_rate / 1000; > >> > +max_bitrate_kbps = avctx->rc_max_rate / 1000; > >> > +brc_param_multiplier = (FFMAX(target_bitrate_kbps, > >> > max_bitrate_kbps) + 0x1) / 0x1; > >> > >> How will this behave if the user sets 100MBit? > > > > Its really quite simple math. It'll cause the multipler to become 2, > > effectively dividing all numbers by two, so instead of trying to pass > > 102400 kbps bitrate, it'll pass 51200 * 2 kbps bitrate, which fits > > into the 16-bit value. > > Seems like a useful solution. > > Is there no possibility that BufferSizeInKB or InitialDelayInKB overflow? > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: set BRCParamMultiplier to aviod BRC overflow
2019-01-11 14:25 GMT+01:00, Hendrik Leppkes : > On Fri, Jan 11, 2019 at 1:18 PM Carl Eugen Hoyos wrote: >> >> 2019-01-11 13:09 GMT+01:00, Zhong Li : >> > +//libmfx BRC parameters are 16 bits thus maybe overflow, then >> > BRCParamMultiplier is needed >> > +target_bitrate_kbps = avctx->bit_rate / 1000; >> > +max_bitrate_kbps = avctx->rc_max_rate / 1000; >> > +brc_param_multiplier = (FFMAX(target_bitrate_kbps, >> > max_bitrate_kbps) + 0x1) / 0x1; >> >> How will this behave if the user sets 100MBit? > > Its really quite simple math. It'll cause the multipler to become 2, > effectively dividing all numbers by two, so instead of trying to pass > 102400 kbps bitrate, it'll pass 51200 * 2 kbps bitrate, which fits > into the 16-bit value. Seems like a useful solution. Is there no possibility that BufferSizeInKB or InitialDelayInKB overflow? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference
On Fri, Jan 11, 2019 at 2:12 PM Derek Buitenhuis
wrote:
>
> On 10/01/2019 23:34, James Almer wrote:
> > -if (!float_near_abs_eps(cdst[i], odst[i], FLT_EPSILON)) {
> > +if (!float_near_abs_eps(cdst[i], odst[i], 6.2e-05)) {
>
> Can you elaborate a bit more on this? FLT_EPSILON is used correctly here
> as far as I can tell, and it is not clear why it fails on x86_32, and why
> we should choose an arbitrary unportable number instead (who knows if it
> explodes on weird systems).
>
Because the computation accumulates more inaccuarcy then FLT_EPSILON
allows for. That value is really not of that great use. If you have
two accurate numbers and do one calculation, it may work, but if you
do a whole bunch of them, the error accumulates and eventually gets
bigger then FLT_EPSILON.
x86_32 floating point is for $reasons a tad bit less accurate then on
x86_64, for example, resulting in the test failing. We have some other
float tests that do (or used to) fail sporadically due to inaccuracy
problems, which sometimes where fixed by similar means - or
multiplifying FLT_EPSILON to make it bigger.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: set BRCParamMultiplier to aviod BRC overflow
On Fri, Jan 11, 2019 at 1:18 PM Carl Eugen Hoyos wrote: > > 2019-01-11 13:09 GMT+01:00, Zhong Li : > > +//libmfx BRC parameters are 16 bits thus maybe overflow, then > > BRCParamMultiplier is needed > > +target_bitrate_kbps = avctx->bit_rate / 1000; > > +max_bitrate_kbps = avctx->rc_max_rate / 1000; > > +brc_param_multiplier = (FFMAX(target_bitrate_kbps, max_bitrate_kbps) + > > 0x1) / 0x1; > > How will this behave if the user sets 100MBit? > Its really quite simple math. It'll cause the multipler to become 2, effectively dividing all numbers by two, so instead of trying to pass 102400 kbps bitrate, it'll pass 51200 * 2 kbps bitrate, which fits into the 16-bit value. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc: Allow very high bitrates in AVCPBProperties after next version bump
On 11/01/2019 00:07, James Almer wrote: > Probalby correct. bitrate fields in AVCodecContext are all int64_t, and > AVCPBProperties fields are usually set to those. Only semi-related: Is it useful to properly clip the bitrate to INT_MAX/INT_MIN where we set it currently (behind deprecation guards, of course), since the behavior is implementation-defined, IIRC? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference
On 10/01/2019 23:34, James Almer wrote:
> -if (!float_near_abs_eps(cdst[i], odst[i], FLT_EPSILON)) {
> +if (!float_near_abs_eps(cdst[i], odst[i], 6.2e-05)) {
Can you elaborate a bit more on this? FLT_EPSILON is used correctly here
as far as I can tell, and it is not clear why it fails on x86_32, and why
we should choose an arbitrary unportable number instead (who knows if it
explodes on weird systems).
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/psd: Support CMYK images
On 11/01/2019 06:17, Peter Ross wrote: > the same algorithm exists in libavcodec/mjpegdec.c, with alpha channel > support. > i guess it is trivial enough to be duplicated here. Is it worth deduplicating? Plenty of image formats have CMYK. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Mark .rodata section as read only in COFF object file
2019-01-10 21:14 GMT+01:00, Tom Tan : > .rodata directive from GAS assembly produces .rodata as read/write for COFF > object file by default (object file format for Windows), but read only for > ELF. This change marks it as read only explicitly for COFF. > > The issue happens when building Chromium for Windows ARM64, with FFmpeg. Does this issue only apply to arm64 or also 32bit arm? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/nuv: add FF_CODEC_CAP_INIT_CLEANUP
On 11/01/2019 01:15, Michael Niedermayer wrote: > Fixes: memleak > Fixes: > 12244/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_NUV_fuzzer-5099447273390080 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > --- > libavcodec/nuv.c | 1 + > 1 file changed, 1 insertion(+) OK. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: add VDENC support for H264
2019-01-11 5:43 GMT+01:00, Li, Zhong :
>> Which libx264 option is / can be hidden?
> This one:
> #if X264_BUILD >= 144
> { "autovariance-biased", "Auto-variance AQ with bias to dark scenes", 0,
> AV_OPT_TYPE_CONST, {.i64 = X264_AQ_AUTOVARIANCE_BIASED}, INT_MIN, INT_MAX,
> VE, "aq_mode" },
> #endif
This seems a little different to me:
It is not an option but only a parameter and it needs a constant
from the header for compilation.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.
2019-01-11 11:18 GMT+01:00, Wang, Shaofei : >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of >> Carl Eugen Hoyos >> Sent: Friday, January 11, 2019 1:14 AM >> To: FFmpeg development discussions and patches >> Subject: Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode >> + >> N filter graphs and adaptive bitrate. >> >> My question is simply "why do you need this condition? If you disable >> threads, >> FFmpeg should still work fine, it simulates threads using one thread." >> >> Please do not top-post here, Carl Eugen > > Without this condition, it will fail the compile when !HAVE_THREAD. Ok. Your patch adds several warnings here, please avoid them. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: set BRCParamMultiplier to aviod BRC overflow
2019-01-11 13:09 GMT+01:00, Zhong Li : > +//libmfx BRC parameters are 16 bits thus maybe overflow, then > BRCParamMultiplier is needed > +target_bitrate_kbps = avctx->bit_rate / 1000; > +max_bitrate_kbps = avctx->rc_max_rate / 1000; > +brc_param_multiplier = (FFMAX(target_bitrate_kbps, max_bitrate_kbps) + > 0x1) / 0x1; How will this behave if the user sets 100MBit? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/qsvenc: Clip the bitrate, Intel limits it to 65535k
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Carl Eugen Hoyos > Sent: Friday, January 11, 2019 5:35 AM > To: FFmpeg development discussions and patches > > Subject: Re: [FFmpeg-devel] [PATCH]lavc/qsvenc: Clip the bitrate, Intel limits > it to 65535k > > 2019-01-10 22:32 GMT+01:00, Eoff, Ullysses A : > > We should use mfxInfoMFX::BRCParamMultiplier to handle high bitrate. > > Sadly, the rules here forbid an answer. > ;-) > > Carl Eugen I've sent another patch to fix this issue. Could you please help to review and comment? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/qsvenc: set BRCParamMultiplier to aviod BRC overflow
Fix ticket #7663
Signed-off-by: Zhong Li
---
libavcodec/qsvenc.c | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index e3b5a72..0e8229e 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -158,8 +158,8 @@ static void dump_video_param(AVCodecContext *avctx,
QSVEncContext *q,
#endif
) {
av_log(avctx, AV_LOG_VERBOSE,
- "BufferSizeInKB: %"PRIu16"; InitialDelayInKB: %"PRIu16";
TargetKbps: %"PRIu16"; MaxKbps: %"PRIu16"\n",
- info->BufferSizeInKB, info->InitialDelayInKB, info->TargetKbps,
info->MaxKbps);
+ "BufferSizeInKB: %"PRIu16"; InitialDelayInKB: %"PRIu16";
TargetKbps: %"PRIu16"; MaxKbps: %"PRIu16"; BRCParamMultiplier: %"PRIu16"\n",
+ info->BufferSizeInKB, info->InitialDelayInKB, info->TargetKbps,
info->MaxKbps, info->BRCParamMultiplier);
} else if (info->RateControlMethod == MFX_RATECONTROL_CQP) {
av_log(avctx, AV_LOG_VERBOSE, "QPI: %"PRIu16"; QPP: %"PRIu16"; QPB:
%"PRIu16"\n",
info->QPI, info->QPP, info->QPB);
@@ -167,8 +167,8 @@ static void dump_video_param(AVCodecContext *avctx,
QSVEncContext *q,
#if QSV_HAVE_AVBR
else if (info->RateControlMethod == MFX_RATECONTROL_AVBR) {
av_log(avctx, AV_LOG_VERBOSE,
- "TargetKbps: %"PRIu16"; Accuracy: %"PRIu16"; Convergence:
%"PRIu16"\n",
- info->TargetKbps, info->Accuracy, info->Convergence);
+ "TargetKbps: %"PRIu16"; Accuracy: %"PRIu16"; Convergence:
%"PRIu16"; BRCParamMultiplier: %"PRIu16"\n",
+ info->TargetKbps, info->Accuracy, info->Convergence,
info->BRCParamMultiplier);
}
#endif
#if QSV_HAVE_LA
@@ -178,8 +178,8 @@ static void dump_video_param(AVCodecContext *avctx,
QSVEncContext *q,
#endif
) {
av_log(avctx, AV_LOG_VERBOSE,
- "TargetKbps: %"PRIu16"; LookAheadDepth: %"PRIu16"\n",
- info->TargetKbps, co2->LookAheadDepth);
+ "TargetKbps: %"PRIu16"; LookAheadDepth: %"PRIu16";
BRCParamMultiplier: %"PRIu16"\n",
+ info->TargetKbps, co2->LookAheadDepth,
info->BRCParamMultiplier);
}
#endif
#if QSV_HAVE_ICQ
@@ -451,6 +451,7 @@ static int init_video_param(AVCodecContext *avctx,
QSVEncContext *q)
avctx->sw_pix_fmt : avctx->pix_fmt;
const AVPixFmtDescriptor *desc;
float quant;
+int target_bitrate_kbps, max_bitrate_kbps, brc_param_multiplier;
int ret;
mfxVersion ver;
@@ -552,16 +553,22 @@ static int init_video_param(AVCodecContext *avctx,
QSVEncContext *q)
if (ret < 0)
return ret;
+//libmfx BRC parameters are 16 bits thus maybe overflow, then
BRCParamMultiplier is needed
+target_bitrate_kbps = avctx->bit_rate / 1000;
+max_bitrate_kbps = avctx->rc_max_rate / 1000;
+brc_param_multiplier = (FFMAX(target_bitrate_kbps, max_bitrate_kbps) +
0x1) / 0x1;
+
switch (q->param.mfx.RateControlMethod) {
case MFX_RATECONTROL_CBR:
case MFX_RATECONTROL_VBR:
#if QSV_HAVE_VCM
case MFX_RATECONTROL_VCM:
#endif
-q->param.mfx.BufferSizeInKB = avctx->rc_buffer_size / 8000;
-q->param.mfx.InitialDelayInKB = avctx->rc_initial_buffer_occupancy /
1000;
-q->param.mfx.TargetKbps = avctx->bit_rate / 1000;
-q->param.mfx.MaxKbps = avctx->rc_max_rate / 1000;
+q->param.mfx.BufferSizeInKB = avctx->rc_buffer_size / 8000 /
brc_param_multiplier;
+q->param.mfx.InitialDelayInKB = avctx->rc_initial_buffer_occupancy /
1000 / brc_param_multiplier;
+q->param.mfx.TargetKbps = target_bitrate_kbps /
brc_param_multiplier;
+q->param.mfx.MaxKbps = max_bitrate_kbps /
brc_param_multiplier;
+q->param.mfx.BRCParamMultiplier = brc_param_multiplier;
break;
case MFX_RATECONTROL_CQP:
quant = avctx->global_quality / FF_QP2LAMBDA;
@@ -573,15 +580,17 @@ static int init_video_param(AVCodecContext *avctx,
QSVEncContext *q)
break;
#if QSV_HAVE_AVBR
case MFX_RATECONTROL_AVBR:
-q->param.mfx.TargetKbps = avctx->bit_rate / 1000;
+q->param.mfx.TargetKbps = target_bitrate_kbps / brc_param_multiplier;
q->param.mfx.Convergence = q->avbr_convergence;
q->param.mfx.Accuracy= q->avbr_accuracy;
+q->param.mfx.BRCParamMultiplier = brc_param_multiplier;
break;
#endif
#if QSV_HAVE_LA
case MFX_RATECONTROL_LA:
-q->param.mfx.TargetKbps = avctx->bit_rate / 1000;
+q->param.mfx.TargetKbps = target_bitrate_kbps / brc_param_multiplier;
q->extco2.LookAheadDepth = q->look_ahead_depth;
+q->param.mfx.BRCParamMultiplier = brc_param_multiplier;
break;
#if QSV_HAVE_ICQ
case MFX_RATECONTROL_LA_ICQ:
@@ -726,7 +735,7 @@ static int qsv_retrieve_enc_jpeg_params(AVCodecContext
*avctx, QSVEncContext *q)
Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > Carl Eugen Hoyos > Sent: Friday, January 11, 2019 1:14 AM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode + > N filter graphs and adaptive bitrate. > > My question is simply "why do you need this condition? If you disable threads, > FFmpeg should still work fine, it simulates threads using one thread." > > Please do not top-post here, Carl Eugen Without this condition, it will fail the compile when !HAVE_THREAD. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add photocd decoder
On 1/11/19, Carl Eugen Hoyos wrote: > 2018-12-22 21:32 GMT+01:00, Paul B Mahol : >> On 12/22/18, Steinar H. Gunderson wrote: >>> On Sat, Dec 22, 2018 at 09:18:11PM +0100, Paul B Mahol wrote: Unacceptable, I'm not adding another yuv420p variant. >>> >>> Well, if returning YCC as YCC is unacceptable, and converting YCC to RGB >>> is >>> unacceptable, I believe your only choices are: >>> >>> 1. Try to convert YCC to Y'CbCr ignoring the gamma curve, which will >>> return >>> images that look wrong and cannot be repaired by reasonable means. >>> 2. Return YCC mislabeled as something else, which will look even more >>> wrong. >>> 3. Don't include PhotoCD support in FFmpeg. >>> >> >> 4. Leave user to do conversion as he wish. > > Could you commit something with "-strict experimental"? No, pay me first. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4] libswscale/ppc: VSX-optimize 9-16 bit yuv2planeX
On Fri, 11 Jan 2019 09:56:15 +0100 Michael Niedermayer wrote: > > +#ifdef __GNUC__ > > +// GCC does not support vmuluwm yet. Bug open. > > this should probably be tested by configure similar to how other > compiler limitations are tested We can't really test for it, because there is no standard name for it. I don't know what name the gcc devs will pick for it, it could be vec_mul, vec_vmuluwm or something different. - Lauri ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4] libswscale/ppc: VSX-optimize 9-16 bit yuv2planeX
On Thu, Jan 10, 2019 at 11:55:34AM +0200, Lauri Kasanen wrote:
> ./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 vector multiplies, so POWER7 is locked out
> of the 16-bit function. This includes the vec_mulo/mule functions too,
> not just vmuluwm.
>
> yuv420p9le
> 12341 UNITS in planarX, 130976 runs, 96 skips
> 73752 UNITS in planarX, 131066 runs, 6 skips
> yuv420p9be
> 12364 UNITS in planarX, 131025 runs, 47 skips
> 73001 UNITS in planarX, 131055 runs, 17 skips
> yuv420p10le
> 12386 UNITS in planarX, 131042 runs, 30 skips
> 72735 UNITS in planarX, 131062 runs, 10 skips
> yuv420p10be
> 12337 UNITS in planarX, 131045 runs, 27 skips
> 72734 UNITS in planarX, 131057 runs, 15 skips
> yuv420p12le
> 12236 UNITS in planarX, 131058 runs, 14 skips
> 73029 UNITS in planarX, 131062 runs, 10 skips
> yuv420p12be
> 12218 UNITS in planarX, 130973 runs, 99 skips
> 72402 UNITS in planarX, 131069 runs, 3 skips
> yuv420p14le
> 12168 UNITS in planarX, 131067 runs, 5 skips
> 72480 UNITS in planarX, 131069 runs, 3 skips
> yuv420p14be
> 12358 UNITS in planarX, 130948 runs,124 skips
> 73772 UNITS in planarX, 131063 runs, 9 skips
> yuv420p16le
> 10439 UNITS in planarX, 130911 runs,161 skips
> 157923 UNITS in planarX, 131068 runs, 4 skips
> yuv420p16be
> 10463 UNITS in planarX, 130874 runs,198 skips
> 154405 UNITS in planarX, 131061 runs, 11 skips
>
> Signed-off-by: Lauri Kasanen
> ---
>
> v2: Separate macros so that yuv2plane1_16_vsx remains available for power7
> v3: Remove accidental tabs, switch to HAVE_POWER8 from configure + runtime
> check
> v4: #if HAVE_POWER8
>
> libswscale/ppc/swscale_ppc_template.c | 4 +-
> libswscale/ppc/swscale_vsx.c | 195
> +-
> 2 files changed, 193 insertions(+), 6 deletions(-)
[...]
> +static void yuv2planeX_16_vsx(const int16_t *filter, int filterSize,
> + const int32_t **src, uint16_t *dest, int dstW,
> + int big_endian, int output_bits)
> +{
> +const int dst_u = -(uintptr_t)dest & 7;
> +const int shift = 15;
> +const int bias = 0x8000;
> +const int add = (1 << (shift - 1)) - 0x4000;
> +const uint16_t swap = big_endian ? 8 : 0;
> +const vector uint32_t vadd = (vector uint32_t) {add, add, add, add};
> +const vector uint32_t vshift = (vector uint32_t) {shift, shift, shift,
> shift};
> +const vector uint16_t vswap = (vector uint16_t) {swap, swap, swap, swap,
> swap, swap, swap, swap};
> +const vector uint16_t vbias = (vector uint16_t) {bias, bias, bias, bias,
> bias, bias, bias, bias};
> +vector int32_t vfilter[MAX_FILTER_SIZE];
> +vector uint16_t v;
> +vector uint32_t vleft, vright, vtmp;
> +vector int32_t vin32l, vin32r;
> +int i, j;
> +
> +for (i = 0; i < filterSize; i++) {
> +vfilter[i] = (vector int32_t) {filter[i], filter[i], filter[i],
> filter[i]};
> +}
> +
> +yuv2planeX_16_u(filter, filterSize, src, dest, dst_u, big_endian,
> output_bits, 0);
> +
> +for (i = dst_u; i < dstW - 7; i += 8) {
> +vleft = vright = vadd;
> +
> +for (j = 0; j < filterSize; j++) {
> +vin32l = vec_vsx_ld(0, &src[j][i]);
> +vin32r = vec_vsx_ld(0, &src[j][i + 4]);
> +
> +#ifdef __GNUC__
> +// GCC does not support vmuluwm yet. Bug open.
this should probably be tested by configure similar to how other
compiler limitations are tested
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v1 2/2] lavc/libxavs2: use upper layer qp parameters first
Signed-off-by: hwrenx
---
libavcodec/libxavs2.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libxavs2.c b/libavcodec/libxavs2.c
index 2d29427..0ad9ca9 100644
--- a/libavcodec/libxavs2.c
+++ b/libavcodec/libxavs2.c
@@ -109,8 +109,9 @@ static av_cold int xavs2_init(AVCodecContext *avctx)
xavs2_opt_set2("RateControl", "%d", 1);
xavs2_opt_set2("TargetBitRate", "%"PRId64"", avctx->bit_rate);
xavs2_opt_set2("InitialQP", "%d", cae->initial_qp);
-xavs2_opt_set2("MaxQP", "%d", cae->max_qp);
-xavs2_opt_set2("MinQP", "%d", cae->min_qp);
+xavs2_opt_set2("MaxQP", "%d", avctx->qmax >= 0 ? avctx->qmax :
cae->max_qp);
+xavs2_opt_set2("MinQP", "%d", avctx->qmin >= 0 ? avctx->qmin :
cae->min_qp);
+
} else {
xavs2_opt_set2("InitialQP", "%d", cae->qp);
}
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v1 1/2] lavc/libxavs2: remove unused context parameter
Signed-off-by: hwrenx
---
libavcodec/libxavs2.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/libxavs2.c b/libavcodec/libxavs2.c
index 52c50a1..2d29427 100644
--- a/libavcodec/libxavs2.c
+++ b/libavcodec/libxavs2.c
@@ -46,7 +46,6 @@ typedef struct XAVS2EContext {
int min_qp;
int preset_level;
int log_level;
-int hierarchical_reference;
void *encoder;
char *xavs2_opts;
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/hevc_parser: report detailed log when missing picture occurs
Report the detailed log with buf_size in parse_nal_units to provide more information when picture could not be found. Match the behaviour in h264_parser. Signed-off-by: Linjie Fu --- libavcodec/hevc_parser.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c index f6df43a067..4b5ff60efc 100644 --- a/libavcodec/hevc_parser.c +++ b/libavcodec/hevc_parser.c @@ -239,7 +239,7 @@ static int parse_nal_units(AVCodecParserContext *s, const uint8_t *buf, } } /* didn't find a picture! */ -av_log(avctx, AV_LOG_ERROR, "missing picture in access unit\n"); +av_log(avctx, AV_LOG_ERROR, "missing picture in access unit with size %d\n", buf_size); return -1; } -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
