date:20200723

Re: [FFmpeg-devel] [PATCH] avfilter: add radial and circular blur video filter

2020-07-23 Thread Paul B Mahol

On 7/19/20, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi |  46 
>  libavfilter/Makefile |   2 +
>  libavfilter/allfilters.c |   2 +
>  libavfilter/vf_rblur.c   | 558 +++
>  4 files changed, 608 insertions(+)
>  create mode 100644 libavfilter/vf_rblur.c
>

Ping.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Support HDR10+ metadata for HEVC

2020-07-23 Thread zhilizhao



> On Jul 17, 2020, at 5:47 AM, Steinar H. Gunderson 
>  wrote:
> 
> On Thu, Jul 16, 2020 at 06:34:31PM -0300, James Almer wrote:
>>> static AVMutex codec_mutex = AV_MUTEX_INITIALIZER;
>>> +static const uint8_t usa_country_code = 0xB5;
>>> +static const uint16_t smpte_provider_code = 0x003C;
>>> +static const uint16_t smpte2094_40_provider_oriented_code = 0x0001;
>>> +static const uint16_t smpte2094_40_application_identifier = 0x04;
>>> +static const int64_t luminance_den = 1;
>>> +static const int32_t peak_luminance_den = 15;
>>> +static const int64_t rgb_den = 10;
>>> +static const int32_t fraction_pixel_den = 1000;
>>> +static const int32_t knee_point_den = 4095;
>>> +static const int32_t bezier_anchor_den = 1023;
>>> +static const int32_t saturation_weight_den = 8;
>> Same, no global state.
> 
> It's not state if it can't be changed.

If there is any chance to reuse these variables, I prefer current style than
use a literal with comments next to it.

> 
> /* Steinar */
> -- 
> Homepage: https://www.sesse.net/
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Support HDR10+ metadata for HEVC

2020-07-23 Thread Timo Rothenpieler


On 23/07/2020 10:13, zhilizhao wrote:




On Jul 17, 2020, at 5:47 AM, Steinar H. Gunderson  
wrote:

On Thu, Jul 16, 2020 at 06:34:31PM -0300, James Almer wrote:

static AVMutex codec_mutex = AV_MUTEX_INITIALIZER;
+static const uint8_t usa_country_code = 0xB5;
+static const uint16_t smpte_provider_code = 0x003C;
+static const uint16_t smpte2094_40_provider_oriented_code = 0x0001;
+static const uint16_t smpte2094_40_application_identifier = 0x04;
+static const int64_t luminance_den = 1;
+static const int32_t peak_luminance_den = 15;
+static const int64_t rgb_den = 10;
+static const int32_t fraction_pixel_den = 1000;
+static const int32_t knee_point_den = 4095;
+static const int32_t bezier_anchor_den = 1023;
+static const int32_t saturation_weight_den = 8;

Same, no global state.


It's not state if it can't be changed.


If there is any chance to reuse these variables, I prefer current style than
use a literal with comments next to it.


I guess ffmpeg more commonly uses #defines for constants like this, but 
it's still valid and not global state.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 7/7] avfilter: add afwtdn filter

2020-07-23 Thread Valentin Schweitzer


On 12/06/2020 00:58, Nicolas George wrote:

Paul B Mahol (12020-06-12):

FFmpeg is not math encyclopedia.

You did not type these numbers, you took them from somewhere. Include it
in the source code, where it belongs.


I am not familiar with the entirety of this commit, but this
seems to concern wavelet coefficients. I think linking a source
for these coefficients that leads to further documentation instead
of including this in the source code is a good idea.

For anyone looking for such a source, http://wavelets.pybytes.com/wavelet/sym2/
offers a list of (rounded) coefficients (the specific link is for Symlets 2).
Paul seems to have a source for either a more accurate list or the formulas to
calculate these values. Linking this in the source might be really helpful for
quick debugging or adapting the code later.

I hope this comment was helpful in any way,

-Valentin

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 7/7] avfilter: add afwtdn filter

2020-07-23 Thread Paul B Mahol

On 7/23/20, Valentin Schweitzer  wrote:
> On 12/06/2020 00:58, Nicolas George wrote:
>> Paul B Mahol (12020-06-12):
>>> FFmpeg is not math encyclopedia.
>> You did not type these numbers, you took them from somewhere. Include it
>> in the source code, where it belongs.
>
> I am not familiar with the entirety of this commit, but this
> seems to concern wavelet coefficients. I think linking a source
> for these coefficients that leads to further documentation instead
> of including this in the source code is a good idea.
>
> For anyone looking for such a source,
> http://wavelets.pybytes.com/wavelet/sym2/
> offers a list of (rounded) coefficients (the specific link is for Symlets
> 2).
> Paul seems to have a source for either a more accurate list or the formulas
> to
> calculate these values. Linking this in the source might be really helpful
> for
> quick debugging or adapting the code later.
>
> I hope this comment was helpful in any way,

LOL, very very funny. Site have javascript copy to copy coefficients,
and yes for almost all wavelets
I used that site as source.

>
> -Valentin
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 14/14] [inline assembly] add mmx clobbers to cavsdsp

2020-07-23 Thread FRÉDÉRIC RECOULES

Hi, 

I just realized that I have been unsubscribed from the mailing list (is there a 
inactivity timeout?).
Thus, I do not know if there was some news about the review of the submitted 
patches. 
Yet, I could well imagine that some conflicts have appeared since the 
submission in May, so if it is the case, let me know it and I will try to 
update them. 

For memory, the patches try to harmonize the interface of inline assembly 
chunks because for some of them, the compiler miss information (like clobbers) 
such that it could take advantage of it to produce wrong code. The patches help 
to avoid unexpected behaviours which may depend on the compiler or the 
optimization level. 

I am looking forward to hearing from you, 

Regards, 
Frédéric Recoules 

- Mail original - 
De: "FRÉDÉRIC RECOULES"  
À: "ffmpeg-devel"  
Cc: "michael" , "frederic recoules" 
 
Envoyé: Lundi 4 Mai 2020 21:52:44 
Objet: Re: [FFmpeg-devel] [PATCH 14/14] [inline assembly] add mmx clobbers to 
cavsdsp 

Hi Michael, 

I would like an update on the review process. 

The patches add missing clobbers (mmx, xmm and memory) to some assembly chunks. 
Note that looking at the commit history, some other chunks have already been 
patched in such a way by the past. 
Moreover, as far as I know, the patches from 1 to 14 passed the fate tests, 
both on my computer and on patchwork. 
Let me know if you have any remark on them. 

By the way, I have a deadline that comes and I would really appreciate to see 
the patches applied by wednesday night. Do you think it would be possible? 


Regards, 
Frédéric 


De: "frederic recoules"  
À: "ffmpeg-devel"  
Cc: "frederic recoules"  
Envoyé: Dimanche 26 Avril 2020 21:44:24 
Objet: [FFmpeg-devel] [PATCH 14/14] [inline assembly] add mmx clobbers to 
cavsdsp 

From: Frédéric Recoules  

--- 
libavcodec/x86/cavsdsp.c | 9 ++--- 
1 file changed, 6 insertions(+), 3 deletions(-) 

diff --git a/libavcodec/x86/cavsdsp.c b/libavcodec/x86/cavsdsp.c 
index becb3a4808..b1b2c7b069 100644 
--- a/libavcodec/x86/cavsdsp.c 
+++ b/libavcodec/x86/cavsdsp.c 
@@ -166,7 +166,8 @@ static void cavs_idct8_add_sse2(uint8_t *dst, int16_t 
*block, ptrdiff_t stride) 
: "+a"(src), "+c"(dst)\ 
: "S"((x86_reg)srcStride), "r"((x86_reg)dstStride)\ 
NAMED_CONSTRAINTS_ADD(ADD,MUL1,MUL2)\ 
- : "memory"\ 
+ : "memory" MMX_CLOBBERS(, "mm0", "mm1", "mm2", "mm3",\ 
+ "mm4", "mm5", "mm6", "mm7") \ 
);\ 
if(h==16){\ 
__asm__ volatile(\ 
@@ -182,7 +183,8 @@ static void cavs_idct8_add_sse2(uint8_t *dst, int16_t 
*block, ptrdiff_t stride) 
: "+a"(src), "+c"(dst)\ 
: "S"((x86_reg)srcStride), "r"((x86_reg)dstStride)\ 
NAMED_CONSTRAINTS_ADD(ADD,MUL1,MUL2)\ 
- : "memory"\ 
+ : "memory" MMX_CLOBBERS(, "mm0", "mm1", "mm2", "mm3",\ 
+ "mm4", "mm5", "mm6", "mm7") \ 
);\ 
}\ 
src += 4-(h+5)*srcStride;\ 
@@ -235,7 +237,8 @@ static void OPNAME ## cavs_qpel8_h_ ## MMX(uint8_t *dst, 
const uint8_t *src, ptr 
: "+a"(src), "+c"(dst), "+m"(h)\ 
: "d"((x86_reg)srcStride), "S"((x86_reg)dstStride)\ 
NAMED_CONSTRAINTS_ADD(ff_pw_4,ff_pw_5)\ 
- : "memory"\ 
+ : "memory" MMX_CLOBBERS(, "mm0", "mm1", "mm2", "mm3",\ 
+ "mm4", "mm5", "mm6", "mm7")\ 
);\ 
}\ 
\ 
-- 
2.17.1 

___ 
ffmpeg-devel mailing list 
ffmpeg-devel@ffmpeg.org 
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel 

To unsubscribe, visit link above, or email 
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". 
___ 
ffmpeg-devel mailing list 
ffmpeg-devel@ffmpeg.org 
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel 

To unsubscribe, visit link above, or email 
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 7/7] avfilter: add afwtdn filter

2020-07-23 Thread Valentin Schweitzer


On 23/07/2020 14:55, Paul B Mahol wrote:


Site have javascript copy to copy coefficients,
and yes for almost all wavelets


You're right, I missed that


I used that site as source.


You could link it above the variable declaration, I
think this might be useful for anyone looking for a
source on that topic, or for anyone trying to contribute
to this part of the code.

Also, my prior e-mail may not have been plaintext,
apologies for that.

-Valentin

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v6 0/6] MIPS MSA & MMI Runtime detection support

2020-07-23 Thread Michael Niedermayer

On Tue, Jul 21, 2020 at 03:40:25PM +0800, Shiyou Yin wrote:
> >-Original Message-
> >From: ffmpeg-devel-boun...@ffmpeg.org 
> >[mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> >Jiaxun Yang
> >Sent: Saturday, July 18, 2020 11:36 PM
> >To: ffmpeg-devel@ffmpeg.org
> >Cc: Jiaxun Yang
> >Subject: [FFmpeg-devel] [PATCH v6 0/6] MIPS MSA & MMI Runtime detection 
> >support
> >
> >This series adds MIPS MSA & MMI runtime detection support
> >
> >Please review.
> >
> >Thanks!
> >
> >v2:
> >  - Add CPUCFG support.
> >  - Add "-mloongson-ext" to MMIFLAGS for Loongson-3 as well. (Loongson2F 
> > don't need this flag)
> >
> >v3:
> >  - Address reveiew suggestions from Shiyou Yin and Weixi Gu.
> >
> >v4:
> >  - Disable DSP for generic CPU
> >
> >v5:
> >  - Clean ups
> >  - Address some GCC build warnings
> >
> >v6:
> >  - Address more Shiyou's comments
> >
> >Jiaxun Yang (6):
> >  ffbuild: Refine MIPS handling
> >  libavutils: Add parse_r helper for MIPS
> >  libavutil: Detect MMI and MSA flags for MIPS
> >  libavcodec: Enable runtime detection for MIPS MMI & MSA
> >  libavcodec: MIPS: MMI: Fix type mismatches
> >  libavcodec: MIPS: MMI: Move sp out of the clobber list
> >
> > configure   | 172 ++--
> > ffbuild/common.mak  |  10 +-
> > libavcodec/mips/Makefile|   3 +-
> > libavcodec/mips/blockdsp_init_mips.c|  40 +-
> > libavcodec/mips/cabac.h |   2 +-
> > libavcodec/mips/h263dsp_init_mips.c |  18 +-
> > libavcodec/mips/h264chroma_init_mips.c  |  55 +-
> > libavcodec/mips/h264dsp_init_mips.c | 225 +++--
> > libavcodec/mips/h264dsp_mips.h  |  18 +-
> > libavcodec/mips/h264dsp_mmi.c   |  56 +-
> > libavcodec/mips/h264pred_init_mips.c| 207 ++--
> > libavcodec/mips/h264qpel_init_mips.c| 412 
> > libavcodec/mips/hevcdsp_init_mips.c | 992 ++--
> > libavcodec/mips/hevcpred_init_mips.c|  40 +-
> > libavcodec/mips/hpeldsp_init_mips.c | 180 ++--
> > libavcodec/mips/idctdsp_init_mips.c |  74 +-
> > libavcodec/mips/me_cmp_init_mips.c  |  50 +-
> > libavcodec/mips/mpegvideo_init_mips.c   |  48 +-
> > libavcodec/mips/mpegvideoencdsp_init_mips.c |  21 +-
> > libavcodec/mips/pixblockdsp_init_mips.c |  63 +-
> > libavcodec/mips/qpeldsp_init_mips.c | 270 +++---
> > libavcodec/mips/vc1dsp_init_mips.c  | 186 ++--
> > libavcodec/mips/videodsp_init.c |  10 +-
> > libavcodec/mips/vp3dsp_init_mips.c  |  44 +-
> > libavcodec/mips/vp8dsp_init_mips.c  | 240 +++--
> > libavcodec/mips/vp9dsp_init_mips.c  |  16 +-
> > libavcodec/mips/wmv2dsp_init_mips.c |  18 +-
> > libavcodec/mips/wmv2dsp_mips.h  |   4 +-
> > libavcodec/mips/wmv2dsp_mmi.c   |   4 +-
> > libavcodec/mips/xvid_idct_mmi.c |   4 +-
> > libavcodec/mips/xvididct_init_mips.c|  31 +-
> > libavcodec/mips/xvididct_mips.h |   4 +-
> > libavutil/cpu.c |  10 +
> > libavutil/cpu.h |   3 +
> > libavutil/cpu_internal.h|   2 +
> > libavutil/mips/Makefile |   2 +-
> > libavutil/mips/asmdefs.h|  42 +
> > libavutil/mips/cpu.c| 134 +++
> > libavutil/mips/cpu.h|  28 +
> > libavutil/tests/cpu.c   |   3 +
> > tests/checkasm/checkasm.c   |   3 +
> > 41 files changed, 1919 insertions(+), 1825 deletions(-)
> > create mode 100644 libavutil/mips/cpu.c
> > create mode 100644 libavutil/mips/cpu.h
> >
> >--
> >2.27.0
> 
> LGTM

will apply


thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3 1/3] libavcodec/jpeg2000dec: Fix codeblock decode check

2020-07-23 Thread Michael Niedermayer

On Tue, Jul 21, 2020 at 11:37:13PM +0530, gautamr...@gmail.com wrote:
> From: Gautam Ramakrishnan 
> 
> The codeblock decoder checks whether the mqc decoder
> has decoded the right number of bytes. However, this
> check does not account for the fact that the mqc encoder's
> flush routine adds 2 bytes of data which does not have to be
> read by the decoder. The check is modified to account for
> this. This patch solves issue #4827
> ---
>  libavcodec/jpeg2000dec.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> index f5ad8402fb..5e9e97eb6a 100644
> --- a/libavcodec/jpeg2000dec.c
> +++ b/libavcodec/jpeg2000dec.c
> @@ -1753,9 +1753,9 @@ static int decode_cblk(Jpeg2000DecoderContext *s, 
> Jpeg2000CodingStyle *codsty,
>  pass_cnt ++;
>  }
>  
> -if (cblk->data + cblk->length - 2*(term_cnt < cblk->nb_terminations) != 
> t1->mqc.bp) {
> +if (cblk->data + cblk->length - 2 > t1->mqc.bp) {
>  av_log(s->avctx, AV_LOG_WARNING, "End mismatch 
> %"PTRDIFF_SPECIFIER"\n",

This changes a equals check to a larger than check, so it removes checking
in one direction. The commit message doesnt explain this sufficiently i think

thx

[...]
-- 
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
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3 2/3] libavcodec/jpeg2000dec: Add check when done with main header markers

2020-07-23 Thread Michael Niedermayer

On Tue, Jul 21, 2020 at 11:37:14PM +0530, gautamr...@gmail.com wrote:
> From: Gautam Ramakrishnan 
> 
> This patch sets a flag when the processing of the
> main header is complete.
> ---
>  libavcodec/jpeg2000dec.c | 4 
>  1 file changed, 4 insertions(+)

will apply

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Elect your leaders based on what they did after the last election, not
based on what they say before an election.



signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3 2/3] libavcodec/jpeg2000dec: Add check when done with main header markers

2020-07-23 Thread Paul B Mahol

On 7/23/20, Michael Niedermayer  wrote:
> On Tue, Jul 21, 2020 at 11:37:14PM +0530, gautamr...@gmail.com wrote:
>> From: Gautam Ramakrishnan 
>>
>> This patch sets a flag when the processing of the
>> main header is complete.
>> ---
>>  libavcodec/jpeg2000dec.c | 4 
>>  1 file changed, 4 insertions(+)
>
> will apply
>
> thx
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Elect your leaders based on what they did after the last election, not
> based on what they say before an election.

Well said. But ffmpeg always picks/have same leaders.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter: add radial and circular blur video filter

2020-07-23 Thread Michael Niedermayer

On Sun, Jul 19, 2020 at 09:45:44PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi |  46 
>  libavfilter/Makefile |   2 +
>  libavfilter/allfilters.c |   2 +
>  libavfilter/vf_rblur.c   | 558 +++
>  4 files changed, 608 insertions(+)
>  create mode 100644 libavfilter/vf_rblur.c
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index a2c31ff610..62705db984 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -7231,6 +7231,29 @@ Set planes to filter. Default value is to filter all
>  planes except alpha plane.
>  @end table
>  
> +@section cblur
> +Apply a circular blur filter.
> +
> +The filter accepts the following options:
> +
> +@table @option
> +@item centerx, centery
> +Set central point position of circular blur. Default is @code{0.5}.
> +
> +@item amount
> +Set amount of circular blur. Default is @code{0.03}.
> +
> +@item planes
> +Set which planes to filter. By default all planes are filtered.
> +@end table
> +
> +@subsection Commands
> +This filter supports same @ref{commands} as options.
> +The command accepts the same syntax of the corresponding option.
> +
> +If the specified expression is not valid, it is kept at its current
> +value.
> +
>  @section chromahold
>  Remove all color information for all colors except for certain one.
>  
> @@ -15768,6 +15791,29 @@ less than @code{0}, the filter will try to use a 
> good random seed on a
>  best effort basis.
>  @end table
>  
> +@section rblur
> +Apply a radial blur filter.
> +
> +The filter accepts the following options:
> +
> +@table @option
> +@item centerx, centery
> +Set central point position of radial blur. Default is @code{0.5}.
> +
> +@item amount
> +Set amount of radial blur. Default is @code{0.03}.
> +
> +@item planes
> +Set which planes to filter. By default all planes are filtered.
> +@end table
> +
> +@subsection Commands
> +This filter supports same @ref{commands} as options.
> +The command accepts the same syntax of the corresponding option.
> +
> +If the specified expression is not valid, it is kept at its current
> +value.
> +
>  @section readeia608
>  
>  Read closed captioning (EIA-608) information from the top lines of a video 
> frame.

Please add an example that produces high quality output.
Iam asking so the filter can be tested in relation to the concerns that
have been raised in previous reviews

Thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Nations do behave wisely once they have exhausted all other alternatives. 
-- Abba Eban


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v6 0/6] MIPS MSA & MMI Runtime detection support

2020-07-23 Thread Michael Niedermayer

On Thu, Jul 23, 2020 at 04:18:32PM +0200, Michael Niedermayer wrote:
> On Tue, Jul 21, 2020 at 03:40:25PM +0800, Shiyou Yin wrote:
> > >-Original Message-
> > >From: ffmpeg-devel-boun...@ffmpeg.org 
> > >[mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > >Jiaxun Yang
> > >Sent: Saturday, July 18, 2020 11:36 PM
> > >To: ffmpeg-devel@ffmpeg.org
> > >Cc: Jiaxun Yang
> > >Subject: [FFmpeg-devel] [PATCH v6 0/6] MIPS MSA & MMI Runtime detection 
> > >support
> > >
> > >This series adds MIPS MSA & MMI runtime detection support
> > >
> > >Please review.
> > >
> > >Thanks!
> > >
> > >v2:
> > >  - Add CPUCFG support.
> > >  - Add "-mloongson-ext" to MMIFLAGS for Loongson-3 as well. (Loongson2F 
> > > don't need this flag)
> > >
> > >v3:
> > >  - Address reveiew suggestions from Shiyou Yin and Weixi Gu.
> > >
> > >v4:
> > >  - Disable DSP for generic CPU
> > >
> > >v5:
> > >  - Clean ups
> > >  - Address some GCC build warnings
> > >
> > >v6:
> > >  - Address more Shiyou's comments
> > >
> > >Jiaxun Yang (6):
> > >  ffbuild: Refine MIPS handling
> > >  libavutils: Add parse_r helper for MIPS
> > >  libavutil: Detect MMI and MSA flags for MIPS
> > >  libavcodec: Enable runtime detection for MIPS MMI & MSA
> > >  libavcodec: MIPS: MMI: Fix type mismatches
> > >  libavcodec: MIPS: MMI: Move sp out of the clobber list
> > >
> > > configure   | 172 ++--
> > > ffbuild/common.mak  |  10 +-
> > > libavcodec/mips/Makefile|   3 +-
> > > libavcodec/mips/blockdsp_init_mips.c|  40 +-
> > > libavcodec/mips/cabac.h |   2 +-
> > > libavcodec/mips/h263dsp_init_mips.c |  18 +-
> > > libavcodec/mips/h264chroma_init_mips.c  |  55 +-
> > > libavcodec/mips/h264dsp_init_mips.c | 225 +++--
> > > libavcodec/mips/h264dsp_mips.h  |  18 +-
> > > libavcodec/mips/h264dsp_mmi.c   |  56 +-
> > > libavcodec/mips/h264pred_init_mips.c| 207 ++--
> > > libavcodec/mips/h264qpel_init_mips.c| 412 
> > > libavcodec/mips/hevcdsp_init_mips.c | 992 ++--
> > > libavcodec/mips/hevcpred_init_mips.c|  40 +-
> > > libavcodec/mips/hpeldsp_init_mips.c | 180 ++--
> > > libavcodec/mips/idctdsp_init_mips.c |  74 +-
> > > libavcodec/mips/me_cmp_init_mips.c  |  50 +-
> > > libavcodec/mips/mpegvideo_init_mips.c   |  48 +-
> > > libavcodec/mips/mpegvideoencdsp_init_mips.c |  21 +-
> > > libavcodec/mips/pixblockdsp_init_mips.c |  63 +-
> > > libavcodec/mips/qpeldsp_init_mips.c | 270 +++---
> > > libavcodec/mips/vc1dsp_init_mips.c  | 186 ++--
> > > libavcodec/mips/videodsp_init.c |  10 +-
> > > libavcodec/mips/vp3dsp_init_mips.c  |  44 +-
> > > libavcodec/mips/vp8dsp_init_mips.c  | 240 +++--
> > > libavcodec/mips/vp9dsp_init_mips.c  |  16 +-
> > > libavcodec/mips/wmv2dsp_init_mips.c |  18 +-
> > > libavcodec/mips/wmv2dsp_mips.h  |   4 +-
> > > libavcodec/mips/wmv2dsp_mmi.c   |   4 +-
> > > libavcodec/mips/xvid_idct_mmi.c |   4 +-
> > > libavcodec/mips/xvididct_init_mips.c|  31 +-
> > > libavcodec/mips/xvididct_mips.h |   4 +-
> > > libavutil/cpu.c |  10 +
> > > libavutil/cpu.h |   3 +
> > > libavutil/cpu_internal.h|   2 +
> > > libavutil/mips/Makefile |   2 +-
> > > libavutil/mips/asmdefs.h|  42 +
> > > libavutil/mips/cpu.c| 134 +++
> > > libavutil/mips/cpu.h|  28 +
> > > libavutil/tests/cpu.c   |   3 +
> > > tests/checkasm/checkasm.c   |   3 +
> > > 41 files changed, 1919 insertions(+), 1825 deletions(-)
> > > create mode 100644 libavutil/mips/cpu.c
> > > create mode 100644 libavutil/mips/cpu.h
> > >
> > >--
> > >2.27.0
> > 
> > LGTM
> 
> will apply

next time please make sure the patches do not add tabs in .h / .c files
these cannot be pushed

thx

[...]

-- 
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
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3 1/3] libavcodec/jpeg2000dec: Fix codeblock decode check

2020-07-23 Thread Gautam Ramakrishnan

On Thu, Jul 23, 2020 at 7:56 PM Michael Niedermayer
 wrote:
>
> On Tue, Jul 21, 2020 at 11:37:13PM +0530, gautamr...@gmail.com wrote:
> > From: Gautam Ramakrishnan 
> >
> > The codeblock decoder checks whether the mqc decoder
> > has decoded the right number of bytes. However, this
> > check does not account for the fact that the mqc encoder's
> > flush routine adds 2 bytes of data which does not have to be
> > read by the decoder. The check is modified to account for
> > this. This patch solves issue #4827
> > ---
> >  libavcodec/jpeg2000dec.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> > index f5ad8402fb..5e9e97eb6a 100644
> > --- a/libavcodec/jpeg2000dec.c
> > +++ b/libavcodec/jpeg2000dec.c
> > @@ -1753,9 +1753,9 @@ static int decode_cblk(Jpeg2000DecoderContext *s, 
> > Jpeg2000CodingStyle *codsty,
> >  pass_cnt ++;
> >  }
> >
> > -if (cblk->data + cblk->length - 2*(term_cnt < cblk->nb_terminations) 
> > != t1->mqc.bp) {
> > +if (cblk->data + cblk->length - 2 > t1->mqc.bp) {
> >  av_log(s->avctx, AV_LOG_WARNING, "End mismatch 
> > %"PTRDIFF_SPECIFIER"\n",
>
> This changes a equals check to a larger than check, so it removes checking
> in one direction. The commit message doesnt explain this sufficiently i think
>
I think a good solution would be to add a check in the other direction
and warn when the added
0xFF bytes are read.
> thx
>
> [...]
> --
> 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
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".



-- 
-
Gautam |
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 1/2] libavcodec/jpeg2000dec: Fix codeblock decode check

2020-07-23 Thread gautamramk

From: Gautam Ramakrishnan 

The codeblock decoder checks whether the mqc decoder
has decoded the right number of bytes. However, this
check does not account for the fact that the mqc encoder's
flush routine adds 2 bytes of data which does not have to be
read by the decoder. The check is modified to account for
this. This patch solves issue #4827
---
 libavcodec/jpeg2000dec.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index e941ebb5d0..a470cf47da 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -1754,9 +1754,13 @@ static int decode_cblk(Jpeg2000DecoderContext *s, 
Jpeg2000CodingStyle *codsty,
 pass_cnt ++;
 }
 
-if (cblk->data + cblk->length - 2*(term_cnt < cblk->nb_terminations) != 
t1->mqc.bp) {
+if (cblk->data + cblk->length - 2 > t1->mqc.bp) {
 av_log(s->avctx, AV_LOG_WARNING, "End mismatch %"PTRDIFF_SPECIFIER"\n",
-   cblk->data + cblk->length - 2*(term_cnt < 
cblk->nb_terminations) - t1->mqc.bp);
+   cblk->data + cblk->length - 2 - t1->mqc.bp);
+}
+
+if (cblk->data + cblk->length < t1->mqc.bp) {
+av_log(s->avctx, AV_LOG_WARNING, "Synthetic End of Stream Marker 
Read.\n");
 }
 
 return 1;
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v4 2/2] libavcodec/jpeg2000dec: Support for PPM marker

2020-07-23 Thread gautamramk

From: Gautam Ramakrishnan 

This patch adds support for PPM marker for JPEG2000
decoder. It allows the samples p1_03.j2k and p1_05.j2k
to be decoded.
---
 libavcodec/jpeg2000dec.c | 107 +++
 1 file changed, 97 insertions(+), 10 deletions(-)

diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index a470cf47da..558cc6b4de 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -71,6 +71,7 @@ typedef struct Jpeg2000POC {
 typedef struct Jpeg2000TilePart {
 uint8_t tile_index; // Tile index who refers the tile-part
 const uint8_t *tp_end;
+GetByteContext header_tpg;  // bit stream of header if PPM header 
is used
 GetByteContext tpg; // bit stream in tile-part
 } Jpeg2000TilePart;
 
@@ -102,7 +103,13 @@ typedef struct Jpeg2000DecoderContext {
 uint8_t cbps[4];// bits per sample in particular components
 uint8_t sgnd[4];// if a component is signed
 uint8_t properties[4];
+
+uint8_t has_ppm;
+uint8_t *packed_headers; // contains packed headers. Used only 
along with PPM marker
+int packed_headers_size;
+GetByteContext  packed_headers_stream;
 uint8_t in_tile_headers;
+
 int cdx[4], cdy[4];
 int precision;
 int ncomponents;
@@ -929,6 +936,31 @@ static int get_plt(Jpeg2000DecoderContext *s, int n)
 return 0;
 }
 
+static int get_ppm(Jpeg2000DecoderContext *s, int n)
+{
+void *new;
+
+if (n < 3) {
+av_log(s->avctx, AV_LOG_ERROR, "Invalid length for PPM data.\n");
+return AVERROR_INVALIDDATA;
+}
+bytestream2_get_byte(&s->g); //Zppm is skipped and not used
+new = av_realloc(s->packed_headers,
+ s->packed_headers_size + n - 3);
+if (new) {
+s->packed_headers = new;
+} else
+return AVERROR(ENOMEM);
+s->has_ppm = 1;
+memset(&s->packed_headers_stream, 0, sizeof(s->packed_headers_stream));
+memcpy(s->packed_headers + s->packed_headers_size,
+   s->g.buffer, n - 3);
+s->packed_headers_size += n - 3;
+bytestream2_skip(&s->g, n - 3);
+
+return 0;
+}
+
 static int get_ppt(Jpeg2000DecoderContext *s, int n)
 {
 Jpeg2000Tile *tile;
@@ -1040,8 +1072,19 @@ static int getlblockinc(Jpeg2000DecoderContext *s)
 return res;
 }
 
-static inline void select_stream(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile,
+static inline void select_header(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile,
  int *tp_index)
+{
+s->g = tile->tile_part[*tp_index].header_tpg;
+if (bytestream2_get_bytes_left(&s->g) == 0 && s->bit_index == 8) {
+if (*tp_index < FF_ARRAY_ELEMS(tile->tile_part) - 1) {
+s->g = tile->tile_part[++(*tp_index)].tpg;
+}
+}
+}
+
+static inline void select_stream(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile,
+ int *tp_index, Jpeg2000CodingStyle *codsty)
 {
 s->g = tile->tile_part[*tp_index].tpg;
 if (bytestream2_get_bytes_left(&s->g) == 0 && s->bit_index == 8) {
@@ -1049,8 +1092,12 @@ static inline void select_stream(Jpeg2000DecoderContext 
*s, Jpeg2000Tile *tile,
 s->g = tile->tile_part[++(*tp_index)].tpg;
 }
 }
-if (bytestream2_peek_be32(&s->g) == JPEG2000_SOP_FIXED_BYTES)
-bytestream2_skip(&s->g, JPEG2000_SOP_BYTE_LENGTH);
+if (codsty->csty & JPEG2000_CSTY_SOP) {
+if (bytestream2_peek_be32(&s->g) == JPEG2000_SOP_FIXED_BYTES)
+bytestream2_skip(&s->g, JPEG2000_SOP_BYTE_LENGTH);
+else
+av_log(s->avctx, AV_LOG_ERROR, "SOP marker not found. instead 
%X\n", bytestream2_peek_be32(&s->g));
+}
 }
 
 static int jpeg2000_decode_packet(Jpeg2000DecoderContext *s, Jpeg2000Tile 
*tile, int *tp_index,
@@ -1065,10 +1112,12 @@ static int 
jpeg2000_decode_packet(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile,
 return 0;
 rlevel->band[0].prec[precno].decoded_layers = layno + 1;
 // Select stream to read from
-if (tile->has_ppt)
+if (s->has_ppm)
+select_header(s, tile, tp_index);
+else if (tile->has_ppt)
 s->g = tile->packed_headers_stream;
 else
-select_stream(s, tile, tp_index);
+select_stream(s, tile, tp_index, codsty);
 
 if (!(ret = get_bits(s, 1))) {
 jpeg2000_flush(s);
@@ -1179,9 +1228,12 @@ static int jpeg2000_decode_packet(Jpeg2000DecoderContext 
*s, Jpeg2000Tile *tile,
 }
 
 // Save state of stream
-if (tile->has_ppt) {
+if (s->has_ppm) {
+tile->tile_part[*tp_index].header_tpg = s->g;
+select_stream(s, tile, tp_index, codsty);
+} else if (tile->has_ppt) {
 tile->packed_headers_stream = s->g;
-select_stream(s, tile, tp_index);
+select_stream(s, tile, tp_index, codsty);
 }
 for (bandno = 0; bandno < rlevel->nbands; bandno++) {

Re: [FFmpeg-devel] [PATCH 14/14] [inline assembly] add mmx clobbers to cavsdsp

2020-07-23 Thread Michael Niedermayer

On Thu, Jul 23, 2020 at 04:00:35PM +0200, FRÉDÉRIC RECOULES wrote:
> Hi, 
> 
> I just realized that I have been unsubscribed from the mailing list (is there 
> a inactivity timeout?).

there is no inactivity timeout but occasionally something gets misclassified
as spam by some mail providers. For example GMX decided to mark all mails
from our server as spam for a few days. These things lead to bounces
the bounces cause unsubscriptions.
I did not check what happened in your case though specifically

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates

signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 8/8] swscale/yuv2rgb: cosmetics

2020-07-23 Thread Michael Niedermayer

On Wed, Jul 22, 2020 at 11:27:39PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang 
> 
> Signed-off-by: Limin Wang 
> ---
>  libswscale/yuv2rgb.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)

ok

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides

signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] lavc/aac_ac3_parser: fix the potential overflow

2020-07-23 Thread Alexander Strasser

On 2020-07-01 21:05 +0200, Alexander Strasser wrote:
> On 2020-07-01 16:23 +0200, Anton Khirnov wrote:
> > Quoting Jun Zhao (2020-06-29 15:23:10)
> > > From: Jun Zhao 
> > >
> > > Fix the potential overflow.
> > >
> > > Suggested-by: Alexander Strasser 
> > > Signed-off-by: Jun Zhao 
> > > ---
> > >  libavcodec/aac_ac3_parser.c | 9 +
> > >  libavcodec/aac_ac3_parser.h | 4 ++--
> > >  tests/ref/fate/adtstoasc_ticket3715 | 2 +-
> > >  3 files changed, 8 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/libavcodec/aac_ac3_parser.c b/libavcodec/aac_ac3_parser.c
> > > index 0746798..b26790d 100644
> > > --- a/libavcodec/aac_ac3_parser.c
> > > +++ b/libavcodec/aac_ac3_parser.c
> > > @@ -98,11 +98,12 @@ get_next:
> > >  }
> > >
> > >  /* Calculate the average bit rate */
> > > -s->frame_number++;
> > >  if (avctx->codec_id != AV_CODEC_ID_EAC3) {
> > > -avctx->bit_rate =
> > > -(s->last_bit_rate * (s->frame_number -1) + 
> > > s->bit_rate)/s->frame_number;
> > > -s->last_bit_rate = avctx->bit_rate;
> > > +if (s->frame_number < UINT64_MAX) {
> > > +s->frame_number++;
> > > +s->last_bit_rate += (s->bit_rate - 
> > > s->last_bit_rate)/s->frame_number;
> > > +avctx->bit_rate = (int64_t)llround(s->last_bit_rate);
> > > +}
> > >  }
> > >  }
> > >
> > > diff --git a/libavcodec/aac_ac3_parser.h b/libavcodec/aac_ac3_parser.h
> > > index b04041f..c53d16f 100644
> > > --- a/libavcodec/aac_ac3_parser.h
> > > +++ b/libavcodec/aac_ac3_parser.h
> > > @@ -55,8 +55,8 @@ typedef struct AACAC3ParseContext {
> > >  uint64_t state;
> > >
> > >  int need_next_header;
> > > -int frame_number;
> > > -int last_bit_rate;
> > > +uint64_t frame_number;
> > > +double last_bit_rate;
> >
> > This won't give the same result on all platforms anymore.
>
> It's also a bit different from what I had in mind.
>
> I was thinking more in the line of how it's implemented in
> libavcodec/mpegaudio_parser.c .
>
> There is a bit of noise there because of data that doesn't contain audio
> and also for the CBR case I think. Wouldn't be needed here AFAICT.
>
> I may well be missing something. If so understanding more would help me
> and we could fix both places. Otherwise if it's OK like it was done in
> mpegaudio_parser, we could maybe use the same strategy here too.
>
>
> Thanks for sending the patch and sorry for the delayed response.

I meant like this:

avctx->bit_rate += (s->bit_rate - avctx->bit_rate) / s->frame_number;

Patch attached. What do you think?

Would probably be even better to sum up in an uint64_t and divide
that sum to update the bit_rate field in AVCodecContext. Could be
implemented later for both parsers if it's considered worthwhile.


  Alexander
From d25595dfa825ee0f18b7ac43a198478d2f4469f6 Mon Sep 17 00:00:00 2001
From: Alexander Strasser 
Date: Fri, 17 Jul 2020 20:51:43 +0200
Subject: [PATCH] lavc/aac_ac3_parser: fix potential overflow when averaging
 bitrate

The new code is analog to how it's done in our mpegaudio parser.
---
 libavcodec/aac_ac3_parser.c | 5 ++---
 libavcodec/aac_ac3_parser.h | 1 -
 tests/ref/fate/adtstoasc_ticket3715 | 2 +-
 3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/libavcodec/aac_ac3_parser.c b/libavcodec/aac_ac3_parser.c
index 0746798dab..e5d4b53339 100644
--- a/libavcodec/aac_ac3_parser.c
+++ b/libavcodec/aac_ac3_parser.c
@@ -100,9 +100,8 @@ get_next:
 /* Calculate the average bit rate */
 s->frame_number++;
 if (avctx->codec_id != AV_CODEC_ID_EAC3) {
-avctx->bit_rate =
-(s->last_bit_rate * (s->frame_number -1) + s->bit_rate)/s->frame_number;
-s->last_bit_rate = avctx->bit_rate;
+avctx->bit_rate +=
+(s->bit_rate - avctx->bit_rate) / s->frame_number;
 }
 }

diff --git a/libavcodec/aac_ac3_parser.h b/libavcodec/aac_ac3_parser.h
index b04041f69d..8b93cbf84f 100644
--- a/libavcodec/aac_ac3_parser.h
+++ b/libavcodec/aac_ac3_parser.h
@@ -56,7 +56,6 @@ typedef struct AACAC3ParseContext {

 int need_next_header;
 int frame_number;
-int last_bit_rate;
 enum AVCodecID codec_id;
 } AACAC3ParseContext;

diff --git a/tests/ref/fate/adtstoasc_ticket3715 b/tests/ref/fate/adtstoasc_ticket3715
index 3b473ee99e..fbdeeb0582 100644
--- a/tests/ref/fate/adtstoasc_ticket3715
+++ b/tests/ref/fate/adtstoasc_ticket3715
@@ -1,4 +1,4 @@
-3e63cbb6bb6ec756d79fab2632fef305 *tests/data/fate/adtstoasc_ticket3715.mov
+29ef0632a8eb5c336bf45a1d5076626e *tests/data/fate/adtstoasc_ticket3715.mov
 33324 tests/data/fate/adtstoasc_ticket3715.mov
 #extradata 0:2, 0x00340022
 #tb 0: 1/44100
--
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above,

Re: [FFmpeg-devel] [PATCH v2 1/3] libavutil/imgutils: add utility to get plane sizes

2020-07-23 Thread Alexander Strasser

On 2020-07-22 11:56 +0200, Nicolas George wrote:
> James Almer (12020-07-20):
> > No, i'll push v3 soon if my argumentation below was not enough to
> > convince Nicolas or Michael. My intention is to use ints for the new
> > function, not to postpone committing it in any form indefinitely.
>
> Sorry, I missed you mail earlier, I only read your arguments nowish.
>
> You are emphasizing that the "future-proof" argument is rather weak,
> which I was already aware. And you are underplaying the fact that it
> belongs to a trend to always delay necessary changes.
>
> Anyway, even if all the arguments for using the proper types are all
> very weak, there are several, and together I am still convinced they
> exceed "consistency" easily.
>
> consistently good > inconsistently good and bad > consistently bad
> ^
> |
>  this is the discussion we are having

From what I have read so far this is not a simple black and white
decision.

I think it's a discussion about coarseness of change. Improving
everything at once will likely never happen in a good way. But
still there are more step sizes in between.

Here is a excerpt of what Michael wrote before:

> If not (as in its more mess than if its done later in some other way)
> then we should not try to do this now
>
> The idea is just to take a step towards how these functions/API should look
> ideally. Its not to make some inconvenient mess

Changing at a per function level is the finest possible way of
API adjustment. Changing a group of functions would be the next
coarser way to adjust the API, and that's what I think James
opts for.

I personally would be OK with that strategy. It emphasizes on
the value of API users. As an API user I would find it annoying
to have inconsistencies at a per function level, even in the
same group of functions that are tied together by name and
by header.

In the long term, I believe we should focus on even more
consistency among groups of functions and libraries and
even cut down on the number of API functions needed.

  Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/2] avcodec/alacdsp: fix integer overflow in decorrelate_stereo()

2020-07-23 Thread Michael Niedermayer

Fixes: signed integer overflow: -16777216 * 131 cannot be represented in type 
'int'
Fixes: 
23835/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALAC_fuzzer-5669943160078336

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/alacdsp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/alacdsp.c b/libavcodec/alacdsp.c
index 9996eb4319..8718d1b6b1 100644
--- a/libavcodec/alacdsp.c
+++ b/libavcodec/alacdsp.c
@@ -34,7 +34,7 @@ static void decorrelate_stereo(int32_t *buffer[2], int 
nb_samples,
 a = buffer[0][i];
 b = buffer[1][i];
 
-a -= (b * decorr_left_weight) >> decorr_shift;
+a -= (int)(b * (unsigned)decorr_left_weight) >> decorr_shift;
 b += a;
 
 buffer[0][i] = b;
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/2] avcodec/alac: Check decorr_shift to avoid invalid shift

2020-07-23 Thread Michael Niedermayer

Fixes: shift exponent 128 is too large for 32-bit type 'int'
Fixes: 
23860/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALAC_fuzzer-5751138914402304

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/alac.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/alac.c b/libavcodec/alac.c
index bf05406230..9040673528 100644
--- a/libavcodec/alac.c
+++ b/libavcodec/alac.c
@@ -302,6 +302,9 @@ static int decode_element(AVCodecContext *avctx, AVFrame 
*frame, int ch_index,
 decorr_shift   = get_bits(&alac->gb, 8);
 decorr_left_weight = get_bits(&alac->gb, 8);
 
+if (channels == 2 && decorr_left_weight && decorr_shift > 31)
+return AVERROR_INVALIDDATA;
+
 for (ch = 0; ch < channels; ch++) {
 prediction_type[ch]   = get_bits(&alac->gb, 4);
 lpc_quant[ch] = get_bits(&alac->gb, 4);
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Support HDR10+ metadata for HEVC

2020-07-23 Thread Mohammad Izadi

Please see my answers inline:

On Thu, Jul 16, 2020 at 2:34 PM James Almer  wrote:

> On 7/16/2020 4:23 PM, Mohammad Izadi wrote:
> > From: Mohammad Izadi 
> >
> > ---
> >  libavcodec/avpacket.c |   1 +
> >  libavcodec/decode.c   |   1 +
> >  libavcodec/hevc_sei.c |  40 +++---
> >  libavcodec/hevc_sei.h |   5 ++
> >  libavcodec/hevcdec.c  |   7 ++
> >  libavcodec/internal.h |   9 +++
> >  libavcodec/packet.h   |   9 +++
> >  libavcodec/utils.c| 180 ++
> >  libavcodec/version.h  |   2 +-
> >  9 files changed, 241 insertions(+), 13 deletions(-)
> >
> > diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> > index dce26cb31a..8307032335 <(830)%20703-2335> 100644
> > --- a/libavcodec/avpacket.c
> > +++ b/libavcodec/avpacket.c
> > @@ -394,6 +394,7 @@ const char *av_packet_side_data_name(enum
> AVPacketSideDataType type)
> >  case AV_PKT_DATA_CONTENT_LIGHT_LEVEL:return "Content light
> level metadata";
> >  case AV_PKT_DATA_SPHERICAL:  return "Spherical
> Mapping";
> >  case AV_PKT_DATA_A53_CC: return "A53 Closed
> Captions";
> > +case AV_PKT_DATA_DYNAMIC_HDR_PLUS:   return "HDR10+ Dynamic
> Metadata (SMPTE 2094-40)";
> >  case AV_PKT_DATA_ENCRYPTION_INIT_INFO:   return "Encryption
> initialization data";
> >  case AV_PKT_DATA_ENCRYPTION_INFO:return "Encryption
> info";
> >  case AV_PKT_DATA_AFD:return "Active Format
> Description data";
> > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > index de9c079f9d..cd3286f7fb 100644
> > --- a/libavcodec/decode.c
> > +++ b/libavcodec/decode.c
> > @@ -1698,6 +1698,7 @@ int ff_decode_frame_props(AVCodecContext *avctx,
> AVFrame *frame)
> >  { AV_PKT_DATA_MASTERING_DISPLAY_METADATA,
> AV_FRAME_DATA_MASTERING_DISPLAY_METADATA },
> >  { AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
> AV_FRAME_DATA_CONTENT_LIGHT_LEVEL },
> >  { AV_PKT_DATA_A53_CC, AV_FRAME_DATA_A53_CC
> },
> > +{ AV_PKT_DATA_DYNAMIC_HDR_PLUS,
>  AV_FRAME_DATA_DYNAMIC_HDR_PLUS },
> >  { AV_PKT_DATA_ICC_PROFILE,
> AV_FRAME_DATA_ICC_PROFILE },
> >  };
> >
> > diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
> > index a4ec65dc1a..096c414d91 100644
> > --- a/libavcodec/hevc_sei.c
> > +++ b/libavcodec/hevc_sei.c
> > @@ -25,6 +25,12 @@
> >  #include "golomb.h"
> >  #include "hevc_ps.h"
> >  #include "hevc_sei.h"
> > +#include "internal.h"
> > +
> > +static const uint8_t usa_country_code = 0xB5;
> > +static const uint16_t smpte_provider_code = 0x003C;
> > +static const uint16_t smpte2094_40_provider_oriented_code = 0x0001;
> > +static const uint16_t smpte2094_40_application_identifier = 0x04;
>
> No global state, please. You can just use the values in question and add
> a comment next to them to describe their meaning, like it's done for a
> lot other values in this file.
>
> Done.

> >
> >  static int decode_nal_sei_decoded_picture_hash(HEVCSEIPictureHash *s,
> GetBitContext *gb)
> >  {
> > @@ -242,8 +248,8 @@ static int
> decode_nal_sei_user_data_unregistered(HEVCSEIUnregistered *s, GetBitC
> >  static int decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s,
> GetBitContext *gb,
> >   int size)
> >  {
> > -uint32_t country_code;
> > -uint32_t user_identifier;
> > +uint8_t country_code;
> > +uint16_t provider_code;
> >
> >  if (size < 7)
> >  return AVERROR(EINVAL);
> > @@ -255,18 +261,27 @@ static int
> decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s, GetBitConte
> >  size--;
> >  }
> >
> > -skip_bits(gb, 8);
> > -skip_bits(gb, 8);
> > -
> > -user_identifier = get_bits_long(gb, 32);
> > -
> > -switch (user_identifier) {
> > -case MKBETAG('G', 'A', '9', '4'):
> > +provider_code = get_bits(gb, 16);
> > +
> > +if (country_code == usa_country_code &&
> > +provider_code == smpte_provider_code) {
> > +// A/341 Amendment – 2094-40
> > +uint16_t provider_oriented_code = get_bits(gb, 16);
> > +uint8_t application_identifier = get_bits(gb, 8);
> > +if (provider_oriented_code ==
> smpte2094_40_provider_oriented_code &&
> > +application_identifier ==
> smpte2094_40_application_identifier) {
> > +int err = ff_read_itu_t_t35_to_dynamic_hdr_plus(gb, s->
> dynamic_hdr_plus.info);
> > +if (err < 0 && s->dynamic_hdr_plus.info) {
> > +av_buffer_unref(&s->dynamic_hdr_plus.info);
> > +}
> > +return err;
> > +}
> > +} else {
> > +uint32_t  user_identifier = get_bits_long(gb, 32);
> > +if(user_identifier == MKBETAG('G', 'A', '9', '4'))
> >  return
> decode_registered_user_data_closed_caption(&s->a53_caption, gb, size);
> > -default:
> > -skip_bits_long(gb, size * 8);
> > -b

Re: [FFmpeg-devel] [PATCH] Support HDR10+ metadata for HEVC

2020-07-23 Thread Mohammad Izadi

Thanks,
Mohammad


On Thu, Jul 23, 2020 at 1:14 AM zhilizhao  wrote:

>
>
> > On Jul 17, 2020, at 5:47 AM, Steinar H. Gunderson <
> steinar+ffm...@gunderson.no> wrote:
> >
> > On Thu, Jul 16, 2020 at 06:34:31PM -0300, James Almer wrote:
> >>> static AVMutex codec_mutex = AV_MUTEX_INITIALIZER;
> >>> +static const uint8_t usa_country_code = 0xB5;
> >>> +static const uint16_t smpte_provider_code = 0x003C;
> >>> +static const uint16_t smpte2094_40_provider_oriented_code = 0x0001;
> >>> +static const uint16_t smpte2094_40_application_identifier = 0x04;
> >>> +static const int64_t luminance_den = 1;
> >>> +static const int32_t peak_luminance_den = 15;
> >>> +static const int64_t rgb_den = 10;
> >>> +static const int32_t fraction_pixel_den = 1000;
> >>> +static const int32_t knee_point_den = 4095;
> >>> +static const int32_t bezier_anchor_den = 1023;
> >>> +static const int32_t saturation_weight_den = 8;
> >> Same, no global state.
> >
> > It's not state if it can't be changed.
>
> If there is any chance to reuse these variables, I prefer current style
> than
> use a literal with comments next to it.
>
I am going to use them in both read/write. For now I moved them to the
local function and I will make them global when I added the write func.

>
> >
> > /* Steinar */
> > --
> > Homepage: https://www.sesse.net/
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 1/2] libavcodec/libaomenc.c: Add command-line options for tx tools.

2020-07-23 Thread James Zern

On Wed, Jul 22, 2020 at 4:12 PM Wang Cao  wrote:
>
> From: Wang Cao 
>
> Signed-off-by: Wang Cao 
> ---
>  doc/encoders.texi  | 20 
>  libavcodec/libaomenc.c | 30 ++
>  libavcodec/version.h   |  2 +-
>  3 files changed, 51 insertions(+), 1 deletion(-)
>

lgtm. I'll apply this soon if there aren't any comments.

> [...]
> @@ -1171,6 +1195,12 @@ static const AVOption options[] = {
>  { "enable-smooth-intra",  "Enable smooth intra prediction mode", 
>OFFSET(enable_smooth_intra),  AV_OPT_TYPE_BOOL, {.i64 = -1}, 
> -1, 1, VE},
>  { "enable-paeth-intra",   "Enable paeth predictor in intra 
> prediction", OFFSET(enable_paeth_intra),   AV_OPT_TYPE_BOOL, 
> {.i64 = -1}, -1, 1, VE},
>  { "enable-palette",   "Enable palette prediction mode",  
>OFFSET(enable_palette),   AV_OPT_TYPE_BOOL, {.i64 = -1}, 
> -1, 1, VE},
> +{ "enable-flip-idtx",  "Enable extended transform type", 
> OFFSET(enable_flip_idtx),  AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, 
> VE},
> +{ "enable-tx64",   "Enable 64-pt transform", 
> OFFSET(enable_tx64),   AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, 
> VE},
> +{ "reduced-tx-type-set",   "Use reduced set of transform types.",
> OFFSET(reduced_tx_type_set),   AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, 
> VE},

I dropped the '.' in the description to normalize the output.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] Support HDR10+ metadata for HEVC.

2020-07-23 Thread Mohammad Izadi

From: Mohammad Izadi 

HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that needs to be 
decoded from ITU-T T.35 in HEVC bitstream. The HDR10+ is transferred to side 
data packet to be used or passed through.
---
 libavcodec/avpacket.c |   1 +
 libavcodec/decode.c   |   1 +
 libavcodec/hevc_sei.c |  39 ++---
 libavcodec/hevc_sei.h |   5 ++
 libavcodec/hevcdec.c  |  16 
 libavcodec/internal.h |   9 +++
 libavcodec/packet.h   |   8 ++
 libavcodec/utils.c| 180 ++
 libavcodec/version.h  |   2 +-
 9 files changed, 248 insertions(+), 13 deletions(-)

diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index dce26cb31a..8307032335 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -394,6 +394,7 @@ const char *av_packet_side_data_name(enum 
AVPacketSideDataType type)
 case AV_PKT_DATA_CONTENT_LIGHT_LEVEL:return "Content light level 
metadata";
 case AV_PKT_DATA_SPHERICAL:  return "Spherical Mapping";
 case AV_PKT_DATA_A53_CC: return "A53 Closed Captions";
+case AV_PKT_DATA_DYNAMIC_HDR_PLUS:   return "HDR10+ Dynamic 
Metadata (SMPTE 2094-40)";
 case AV_PKT_DATA_ENCRYPTION_INIT_INFO:   return "Encryption 
initialization data";
 case AV_PKT_DATA_ENCRYPTION_INFO:return "Encryption info";
 case AV_PKT_DATA_AFD:return "Active Format 
Description data";
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index de9c079f9d..cd3286f7fb 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1698,6 +1698,7 @@ int ff_decode_frame_props(AVCodecContext *avctx, AVFrame 
*frame)
 { AV_PKT_DATA_MASTERING_DISPLAY_METADATA, 
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA },
 { AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
AV_FRAME_DATA_CONTENT_LIGHT_LEVEL },
 { AV_PKT_DATA_A53_CC, AV_FRAME_DATA_A53_CC },
+{ AV_PKT_DATA_DYNAMIC_HDR_PLUS,   
AV_FRAME_DATA_DYNAMIC_HDR_PLUS },
 { AV_PKT_DATA_ICC_PROFILE,AV_FRAME_DATA_ICC_PROFILE },
 };
 
diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index a4ec65dc1a..a490e752dd 100644
--- a/libavcodec/hevc_sei.c
+++ b/libavcodec/hevc_sei.c
@@ -25,6 +25,7 @@
 #include "golomb.h"
 #include "hevc_ps.h"
 #include "hevc_sei.h"
+#include "internal.h"
 
 static int decode_nal_sei_decoded_picture_hash(HEVCSEIPictureHash *s, 
GetBitContext *gb)
 {
@@ -242,8 +243,8 @@ static int 
decode_nal_sei_user_data_unregistered(HEVCSEIUnregistered *s, GetBitC
 static int decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s, 
GetBitContext *gb,
  int size)
 {
-uint32_t country_code;
-uint32_t user_identifier;
+uint8_t country_code;
+uint16_t provider_code;
 
 if (size < 7)
 return AVERROR(EINVAL);
@@ -255,18 +256,31 @@ static int 
decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s, GetBitConte
 size--;
 }
 
-skip_bits(gb, 8);
-skip_bits(gb, 8);
-
-user_identifier = get_bits_long(gb, 32);
-
-switch (user_identifier) {
-case MKBETAG('G', 'A', '9', '4'):
+provider_code = get_bits(gb, 16);
+
+const uint8_t usa_country_code = 0xB5;
+const uint16_t smpte_provider_code = 0x003C;
+if (country_code == usa_country_code &&
+provider_code == smpte_provider_code) {
+// A/341 Amendment – 2094-40
+uint16_t provider_oriented_code = get_bits(gb, 16);
+uint8_t application_identifier = get_bits(gb, 8);
+const uint16_t smpte2094_40_provider_oriented_code = 0x0001;
+const uint16_t smpte2094_40_application_identifier = 0x04;
+if (provider_oriented_code == smpte2094_40_provider_oriented_code &&
+application_identifier == smpte2094_40_application_identifier) {
+int err = ff_read_itu_t_t35_to_dynamic_hdr_plus(gb, 
s->dynamic_hdr_plus.info);
+if (err < 0 && s->dynamic_hdr_plus.info) {
+av_buffer_unref(&s->dynamic_hdr_plus.info);
+}
+return err;
+}
+} else {
+uint32_t  user_identifier = get_bits_long(gb, 32);
+if(user_identifier == MKBETAG('G', 'A', '9', '4'))
 return decode_registered_user_data_closed_caption(&s->a53_caption, 
gb, size);
-default:
-skip_bits_long(gb, size * 8);
-break;
 }
+skip_bits_long(gb, size * 8);
 return 0;
 }
 
@@ -453,4 +467,5 @@ void ff_hevc_reset_sei(HEVCSEI *s)
 av_buffer_unref(&s->unregistered.buf_ref[i]);
 s->unregistered.nb_buf_ref = 0;
 av_freep(&s->unregistered.buf_ref);
+av_buffer_unref(&s->dynamic_hdr_plus.info);
 }
diff --git a/libavcodec/hevc_sei.h b/libavcodec/hevc_sei.h
index 5ee7a4796d..e9e2d46ed4 100644
--- a/libavcodec/hevc_sei.h
+++ b/libavcodec/hevc_sei.h
@@ -104,6 +104,10 @@ typedef struct HEVCSEIMasteringDisplay {
 uint32_t mi

Re: [FFmpeg-devel] [PATCH] Support HDR10+ metadata for HEVC

2020-07-23 Thread Mohammad Izadi

I am not sure if you received the patch in reply to the thread? I used:
git send-email  0001-Support-HDR10-metadata-for-HEVC.patch --to=
ffmpeg-devel@ffmpeg.org --in-reply-to=
422719c5-f010-6b39-6415-b3bf46dcb...@rothenpieler.org


It seems it created a new thread. Did you receive it?

Thanks,
Mohammad


On Thu, Jul 23, 2020 at 3:29 PM Mohammad Izadi  wrote:

>
> Thanks,
> Mohammad
>
>
> On Thu, Jul 23, 2020 at 1:14 AM zhilizhao  wrote:
>
>>
>>
>> > On Jul 17, 2020, at 5:47 AM, Steinar H. Gunderson <
>> steinar+ffm...@gunderson.no> wrote:
>> >
>> > On Thu, Jul 16, 2020 at 06:34:31PM -0300, James Almer wrote:
>> >>> static AVMutex codec_mutex = AV_MUTEX_INITIALIZER;
>> >>> +static const uint8_t usa_country_code = 0xB5;
>> >>> +static const uint16_t smpte_provider_code = 0x003C;
>> >>> +static const uint16_t smpte2094_40_provider_oriented_code = 0x0001;
>> >>> +static const uint16_t smpte2094_40_application_identifier = 0x04;
>> >>> +static const int64_t luminance_den = 1;
>> >>> +static const int32_t peak_luminance_den = 15;
>> >>> +static const int64_t rgb_den = 10;
>> >>> +static const int32_t fraction_pixel_den = 1000;
>> >>> +static const int32_t knee_point_den = 4095;
>> >>> +static const int32_t bezier_anchor_den = 1023;
>> >>> +static const int32_t saturation_weight_den = 8;
>> >> Same, no global state.
>> >
>> > It's not state if it can't be changed.
>>
>> If there is any chance to reuse these variables, I prefer current style
>> than
>> use a literal with comments next to it.
>>
> I am going to use them in both read/write. For now I moved them to the
> local function and I will make them global when I added the write func.
>
>>
>> >
>> > /* Steinar */
>> > --
>> > Homepage: https://www.sesse.net/
>> > ___
>> > ffmpeg-devel mailing list
>> > ffmpeg-devel@ffmpeg.org
>> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> >
>> > To unsubscribe, visit link above, or email
>> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] Support HDR10+ metadata for HEVC.

2020-07-23 Thread Mohammad Izadi

From: Mohammad Izadi 

HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that needs to be 
decoded from ITU-T T.35 in HEVC bitstream. The HDR10+ is transferred to side 
data packet to be used or passed through.
---
 libavcodec/avpacket.c |   1 +
 libavcodec/decode.c   |   1 +
 libavcodec/hevc_sei.c |  39 ++---
 libavcodec/hevc_sei.h |   5 ++
 libavcodec/hevcdec.c  |  16 
 libavcodec/internal.h |   9 +++
 libavcodec/packet.h   |   8 ++
 libavcodec/utils.c| 180 ++
 libavcodec/version.h  |   2 +-
 9 files changed, 248 insertions(+), 13 deletions(-)

diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index dce26cb31a..8307032335 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -394,6 +394,7 @@ const char *av_packet_side_data_name(enum 
AVPacketSideDataType type)
 case AV_PKT_DATA_CONTENT_LIGHT_LEVEL:return "Content light level 
metadata";
 case AV_PKT_DATA_SPHERICAL:  return "Spherical Mapping";
 case AV_PKT_DATA_A53_CC: return "A53 Closed Captions";
+case AV_PKT_DATA_DYNAMIC_HDR_PLUS:   return "HDR10+ Dynamic 
Metadata (SMPTE 2094-40)";
 case AV_PKT_DATA_ENCRYPTION_INIT_INFO:   return "Encryption 
initialization data";
 case AV_PKT_DATA_ENCRYPTION_INFO:return "Encryption info";
 case AV_PKT_DATA_AFD:return "Active Format 
Description data";
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index de9c079f9d..cd3286f7fb 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1698,6 +1698,7 @@ int ff_decode_frame_props(AVCodecContext *avctx, AVFrame 
*frame)
 { AV_PKT_DATA_MASTERING_DISPLAY_METADATA, 
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA },
 { AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
AV_FRAME_DATA_CONTENT_LIGHT_LEVEL },
 { AV_PKT_DATA_A53_CC, AV_FRAME_DATA_A53_CC },
+{ AV_PKT_DATA_DYNAMIC_HDR_PLUS,   
AV_FRAME_DATA_DYNAMIC_HDR_PLUS },
 { AV_PKT_DATA_ICC_PROFILE,AV_FRAME_DATA_ICC_PROFILE },
 };
 
diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index a4ec65dc1a..a490e752dd 100644
--- a/libavcodec/hevc_sei.c
+++ b/libavcodec/hevc_sei.c
@@ -25,6 +25,7 @@
 #include "golomb.h"
 #include "hevc_ps.h"
 #include "hevc_sei.h"
+#include "internal.h"
 
 static int decode_nal_sei_decoded_picture_hash(HEVCSEIPictureHash *s, 
GetBitContext *gb)
 {
@@ -242,8 +243,8 @@ static int 
decode_nal_sei_user_data_unregistered(HEVCSEIUnregistered *s, GetBitC
 static int decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s, 
GetBitContext *gb,
  int size)
 {
-uint32_t country_code;
-uint32_t user_identifier;
+uint8_t country_code;
+uint16_t provider_code;
 
 if (size < 7)
 return AVERROR(EINVAL);
@@ -255,18 +256,31 @@ static int 
decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s, GetBitConte
 size--;
 }
 
-skip_bits(gb, 8);
-skip_bits(gb, 8);
-
-user_identifier = get_bits_long(gb, 32);
-
-switch (user_identifier) {
-case MKBETAG('G', 'A', '9', '4'):
+provider_code = get_bits(gb, 16);
+
+const uint8_t usa_country_code = 0xB5;
+const uint16_t smpte_provider_code = 0x003C;
+if (country_code == usa_country_code &&
+provider_code == smpte_provider_code) {
+// A/341 Amendment – 2094-40
+uint16_t provider_oriented_code = get_bits(gb, 16);
+uint8_t application_identifier = get_bits(gb, 8);
+const uint16_t smpte2094_40_provider_oriented_code = 0x0001;
+const uint16_t smpte2094_40_application_identifier = 0x04;
+if (provider_oriented_code == smpte2094_40_provider_oriented_code &&
+application_identifier == smpte2094_40_application_identifier) {
+int err = ff_read_itu_t_t35_to_dynamic_hdr_plus(gb, 
s->dynamic_hdr_plus.info);
+if (err < 0 && s->dynamic_hdr_plus.info) {
+av_buffer_unref(&s->dynamic_hdr_plus.info);
+}
+return err;
+}
+} else {
+uint32_t  user_identifier = get_bits_long(gb, 32);
+if(user_identifier == MKBETAG('G', 'A', '9', '4'))
 return decode_registered_user_data_closed_caption(&s->a53_caption, 
gb, size);
-default:
-skip_bits_long(gb, size * 8);
-break;
 }
+skip_bits_long(gb, size * 8);
 return 0;
 }
 
@@ -453,4 +467,5 @@ void ff_hevc_reset_sei(HEVCSEI *s)
 av_buffer_unref(&s->unregistered.buf_ref[i]);
 s->unregistered.nb_buf_ref = 0;
 av_freep(&s->unregistered.buf_ref);
+av_buffer_unref(&s->dynamic_hdr_plus.info);
 }
diff --git a/libavcodec/hevc_sei.h b/libavcodec/hevc_sei.h
index 5ee7a4796d..e9e2d46ed4 100644
--- a/libavcodec/hevc_sei.h
+++ b/libavcodec/hevc_sei.h
@@ -104,6 +104,10 @@ typedef struct HEVCSEIMasteringDisplay {
 uint32_t mi

Re: [FFmpeg-devel] [PATCH v2 2/2] libavcodec/libaomenc.c: Add command-line options for inter-coding tools

2020-07-23 Thread James Zern

On Wed, Jul 22, 2020 at 4:11 PM Wang Cao  wrote:
>
> From: Wang Cao 
>
> Signed-off-by: Wang Cao 
> ---
>  doc/encoders.texi  | 36 +
>  libavcodec/libaomenc.c | 60 ++
>  libavcodec/version.h   |  2 +-
>  3 files changed, 97 insertions(+), 1 deletion(-)
>

lgtm. I'll apply this soon if there aren't any comments.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2 1/2] avutil/timecode: fix av_timecode_get_smpte_from_framenum with 50/60 fps

2020-07-23 Thread Marton Balint

SMPTE 12M timecode can only count frames up to 39, because the tens-of-frames
value is stored in 2 bit. In order to resolve this 50/60 fps SMPTE timecode is
using the field bit (which is the same bit as the phase correction bit) to
signal the least significant bit of a 50/60 fps timecode. See SMPTE ST
12-1:2014 section 12.1.

Therefore we slightly change the format of the return value of
av_timecode_get_smpte_from_framenum and AV_FRAME_DATA_S12M_TIMECODE and start
using the previously unused Phase Correction bit as Field bit. (As the SMPTE
standard suggests)

We add 50/60 fps support to av_timecode_get_smpte_from_framenum by calling the
recently added av_timecode_get_smpte function in it which already handles this
properly.

This change affects the decklink indev and the DV and MXF muxers. MXF has no
fate test for 50/60fps content, DV does, therefore the changes.

MediaInfo (a recent version) confirms that half-frame timecode must be inserted
to DV. MXFInspect confirms valid timecode insertion to the System Item of MXF
files. For MXF, also see EBU R122.

Note that for DV the field flag is not used because in the HDV specs (SMPTE
370M) it is still defined as biphase mark polarity correction flag. So it
should not matter that the DV muxer overrides the field bit.

Signed-off-by: Marton Balint 
---
 libavutil/timecode.c   | 15 +--
 libavutil/timecode.h   |  7 +++
 tests/ref/vsynth/vsynth1-dv-hd |  2 +-
 tests/ref/vsynth/vsynth2-dv-hd |  2 +-
 tests/ref/vsynth/vsynth3-dv-hd |  2 +-
 tests/ref/vsynth/vsynth_lena-dv-hd |  2 +-
 6 files changed, 8 insertions(+), 22 deletions(-)

diff --git a/libavutil/timecode.c b/libavutil/timecode.c
index cca53d73c4..cb916970ef 100644
--- a/libavutil/timecode.c
+++ b/libavutil/timecode.c
@@ -65,20 +65,7 @@ uint32_t av_timecode_get_smpte_from_framenum(const 
AVTimecode *tc, int framenum)
 ss = framenum / fps  % 60;
 mm = framenum / (fps*60) % 60;
 hh = framenum / (fps*3600) % 24;
-return 0 << 31 | // color frame flag (0: unsync mode, 1: sync mode)
-   drop  << 30 | // drop  frame flag (0: non drop,1: drop)
-   (ff / 10) << 28 | // tens  of frames
-   (ff % 10) << 24 | // units of frames
-   0 << 23 | // PC (NTSC) or BGF0 (PAL)
-   (ss / 10) << 20 | // tens  of seconds
-   (ss % 10) << 16 | // units of seconds
-   0 << 15 | // BGF0 (NTSC) or BGF2 (PAL)
-   (mm / 10) << 12 | // tens  of minutes
-   (mm % 10) <<  8 | // units of minutes
-   0 <<  7 | // BGF2 (NTSC) or PC (PAL)
-   0 <<  6 | // BGF1
-   (hh / 10) <<  4 | // tens  of hours
-   (hh % 10);// units of hours
+return av_timecode_get_smpte(tc->rate, drop, hh, mm, ss, ff);
 }
 
 uint32_t av_timecode_get_smpte(AVRational rate, int drop, int hh, int mm, int 
ss, int ff)
diff --git a/libavutil/timecode.h b/libavutil/timecode.h
index 5801330921..e54b116e93 100644
--- a/libavutil/timecode.h
+++ b/libavutil/timecode.h
@@ -66,11 +66,11 @@ int av_timecode_adjust_ntsc_framenum2(int framenum, int 
fps);
  * the format description as follows:
  * bits 0-5:   hours, in BCD(6bits)
  * bits 6: BGF1
- * bits 7: BGF2 (NTSC) or PC (PAL)
+ * bits 7: BGF2 (NTSC) or FIELD (PAL)
  * bits 8-14:  minutes, in BCD(7bits)
  * bits 15:BGF0 (NTSC) or BGF2 (PAL)
  * bits 16-22: seconds, in BCD(7bits)
- * bits 23:PC (NTSC) or BGF0 (PAL)
+ * bits 23:FIELD (NTSC) or BGF0 (PAL)
  * bits 24-29: frames, in BCD(6bits)
  * bits 30:drop  frame flag (0: non drop,1: drop)
  * bits 31:color frame flag (0: unsync mode, 1: sync mode)
@@ -78,8 +78,7 @@ int av_timecode_adjust_ntsc_framenum2(int framenum, int fps);
  * @note Frame number adjustment is automatically done in case of drop 
timecode,
  *   you do NOT have to call av_timecode_adjust_ntsc_framenum2().
  * @note The frame number is relative to tc->start.
- * @note Color frame (CF), binary group flags (BGF) and biphase mark polarity
- *   correction (PC) bits are set to zero.
+ * @note Color frame (CF) and binary group flags (BGF) bits are set to zero.
  */
 uint32_t av_timecode_get_smpte_from_framenum(const AVTimecode *tc, int 
framenum);
 
diff --git a/tests/ref/vsynth/vsynth1-dv-hd b/tests/ref/vsynth/vsynth1-dv-hd
index 6b6d6e8159..3f2f9cc843 100644
--- a/tests/ref/vsynth/vsynth1-dv-hd
+++ b/tests/ref/vsynth/vsynth1-dv-hd
@@ -1,4 +1,4 @@
-22d1d62a834fe8416fe79c51760012c1 *tests/data/fate/vsynth1-dv-hd.dv
+b2bcafc74dec5f9ca516cb25dd07459b *tests/data/fate/vsynth1-dv-hd.dv
 1440 tests/data/fate/vsynth1-dv-hd.dv
 34b78cf725346c7f819c9d6209b8299a *tests/data/fate/vsynth1-dv-hd.out.rawvideo
 stddev:4.30 PSNR: 35.45 MAXDIFF:   74 bytes:  7603200/  7603200
diff --git a/tests/ref/vsynth/vsynth2-dv-hd b/tests/ref/vsynth/vsynth2-dv-hd
index c6dcb5a953..0a5046e4ec 100644
--- a/tests/ref/vsynth/vsynth2-dv-hd
+++ b/tests/ref/vsynth/vsynt

[FFmpeg-devel] [PATCH v2 2/2] avutil/timecode: cosmetics on av_timecode_get_smpte

2020-07-23 Thread Marton Balint

Signed-off-by: Marton Balint 
---
 libavutil/timecode.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/libavutil/timecode.c b/libavutil/timecode.c
index cb916970ef..b528e4a510 100644
--- a/libavutil/timecode.c
+++ b/libavutil/timecode.c
@@ -71,7 +71,7 @@ uint32_t av_timecode_get_smpte_from_framenum(const AVTimecode 
*tc, int framenum)
 uint32_t av_timecode_get_smpte(AVRational rate, int drop, int hh, int mm, int 
ss, int ff)
 {
 uint32_t tc = 0;
-uint32_t frames;
+int frames = ff;
 
 /* For SMPTE 12-M timecodes, frame count is a special case if > 30 FPS.
See SMPTE ST 12-1:2014 Sec 12.1 for more info. */
@@ -83,8 +83,6 @@ uint32_t av_timecode_get_smpte(AVRational rate, int drop, int 
hh, int mm, int ss
 else
 tc |= (1 << 23);
 }
-} else {
-frames = ff;
 }
 
 tc |= drop << 30;
@@ -95,7 +93,7 @@ uint32_t av_timecode_get_smpte(AVRational rate, int drop, int 
hh, int mm, int ss
 tc |= (mm / 10) << 12;
 tc |= (mm % 10) << 8;
 tc |= (hh / 10) << 4;
-tc |= (hh  % 10);
+tc |= (hh % 10);
 
 return tc;
 }
-- 
2.26.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] lavc/aac_ac3_parser: fix the potential overflow

2020-07-23 Thread myp...@gmail.com

On Fri, Jul 24, 2020 at 4:43 AM Alexander Strasser  wrote:
>
> On 2020-07-01 21:05 +0200, Alexander Strasser wrote:
> > On 2020-07-01 16:23 +0200, Anton Khirnov wrote:
> > > Quoting Jun Zhao (2020-06-29 15:23:10)
> > > > From: Jun Zhao 
> > > >
> > > > Fix the potential overflow.
> > > >
> > > > Suggested-by: Alexander Strasser 
> > > > Signed-off-by: Jun Zhao 
> > > > ---
> > > >  libavcodec/aac_ac3_parser.c | 9 +
> > > >  libavcodec/aac_ac3_parser.h | 4 ++--
> > > >  tests/ref/fate/adtstoasc_ticket3715 | 2 +-
> > > >  3 files changed, 8 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/libavcodec/aac_ac3_parser.c b/libavcodec/aac_ac3_parser.c
> > > > index 0746798..b26790d 100644
> > > > --- a/libavcodec/aac_ac3_parser.c
> > > > +++ b/libavcodec/aac_ac3_parser.c
> > > > @@ -98,11 +98,12 @@ get_next:
> > > >  }
> > > >
> > > >  /* Calculate the average bit rate */
> > > > -s->frame_number++;
> > > >  if (avctx->codec_id != AV_CODEC_ID_EAC3) {
> > > > -avctx->bit_rate =
> > > > -(s->last_bit_rate * (s->frame_number -1) + 
> > > > s->bit_rate)/s->frame_number;
> > > > -s->last_bit_rate = avctx->bit_rate;
> > > > +if (s->frame_number < UINT64_MAX) {
> > > > +s->frame_number++;
> > > > +s->last_bit_rate += (s->bit_rate - 
> > > > s->last_bit_rate)/s->frame_number;
> > > > +avctx->bit_rate = (int64_t)llround(s->last_bit_rate);
> > > > +}
> > > >  }
> > > >  }
> > > >
> > > > diff --git a/libavcodec/aac_ac3_parser.h b/libavcodec/aac_ac3_parser.h
> > > > index b04041f..c53d16f 100644
> > > > --- a/libavcodec/aac_ac3_parser.h
> > > > +++ b/libavcodec/aac_ac3_parser.h
> > > > @@ -55,8 +55,8 @@ typedef struct AACAC3ParseContext {
> > > >  uint64_t state;
> > > >
> > > >  int need_next_header;
> > > > -int frame_number;
> > > > -int last_bit_rate;
> > > > +uint64_t frame_number;
> > > > +double last_bit_rate;
> > >
> > > This won't give the same result on all platforms anymore.
> >
> > It's also a bit different from what I had in mind.
> >
> > I was thinking more in the line of how it's implemented in
> > libavcodec/mpegaudio_parser.c .
> >
> > There is a bit of noise there because of data that doesn't contain audio
> > and also for the CBR case I think. Wouldn't be needed here AFAICT.
> >
> > I may well be missing something. If so understanding more would help me
> > and we could fix both places. Otherwise if it's OK like it was done in
> > mpegaudio_parser, we could maybe use the same strategy here too.
> >
> >
> > Thanks for sending the patch and sorry for the delayed response.
>
> I meant like this:
>
> avctx->bit_rate += (s->bit_rate - avctx->bit_rate) / s->frame_number;
>
> Patch attached. What do you think?
>
> Would probably be even better to sum up in an uint64_t and divide
> that sum to update the bit_rate field in AVCodecContext. Could be
> implemented later for both parsers if it's considered worthwhile.
>
I see, my concern is

avctx->bit_rate += (s->bit_rate - avctx->bit_rate) / s->frame_number;

will lose precision in (s->bit_rate - avctx->bit_rate) /
s->frame_number, this is the reason I used the  double replace
uint64_t

I can give an example of you code, suppose we probe 4 ADTS AAC frames,
the s->bit_rate is 4Kbps 3Kbps 2Kbps 1Kbps respectively,

In this code, we will always get the bitrate 4Kbps, but in an ideal
situation, we want to get the average bitrate be close to  (4 + 3 + 2
+ 1) / 4 = 2.5Kbps after the probe
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 01/11] avformat/webmdashenc: Fix segfault when no filename is given when live

2020-07-23 Thread Andreas Rheinhardt

Andreas Rheinhardt:
> by checking a bit earlier.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/webmdashenc.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/webmdashenc.c b/libavformat/webmdashenc.c
> index eb286cab99..3eefd6df8b 100644
> --- a/libavformat/webmdashenc.c
> +++ b/libavformat/webmdashenc.c
> @@ -171,8 +171,7 @@ static int write_representation(AVFormatContext *s, 
> AVStream *stream, char *id,
>  AVDictionaryEntry *filename = av_dict_get(stream->metadata, FILENAME, 
> NULL, 0);
>  AVDictionaryEntry *bandwidth = av_dict_get(stream->metadata, BANDWIDTH, 
> NULL, 0);
>  const char *bandwidth_str;
> -if ((w->is_live && (!filename)) ||
> -(!w->is_live && (!irange || !cues_start || !cues_end || !filename || 
> !bandwidth))) {
> +if (!w->is_live && (!irange || !cues_start || !cues_end || !filename || 
> !bandwidth)) {
>  return AVERROR_INVALIDDATA;
>  }
>  avio_printf(s->pb, " @@ -380,7 +379,10 @@ static int write_adaptation_set(AVFormatContext *s, int 
> as_index)
>  av_dict_get(s->streams[as->streams[0]]->metadata, FILENAME, 
> NULL, 0);
>  char *initialization_pattern = NULL;
>  char *media_pattern = NULL;
> -int ret = parse_filename(filename->value, NULL, 
> &initialization_pattern,
> +int ret;
> +if (!filename)
> +return AVERROR(EINVAL);
> +ret = parse_filename(filename->value, NULL, &initialization_pattern,
>   &media_pattern);
>  if (ret) return ret;
>  avio_printf(s->pb, "\n",
> 

Will apply this patchset tomorrow unless there are objections.

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] hwcontext_vaapi: remove duplicate formats from sw_format list

2020-07-23 Thread Haihao Xiang

hwcontext_vaapi maps different VA fourcc to the same pix_fmt for U/V
plane swap cases, however duplicate formats are not expected in sw_format
list when merging formats.

For example:
ffmpeg -loglevel debug -init_hw_device vaapi -filter_hw_device vaapi0 \
-f lavfi -i smptebars -vf \
"hwupload=derive_device=vaapi,scale_vaapi,hwdownload,format=yuv420p" \
-vframes 1 -f null -

Without this fix, an auto scaler is required for the above command
   Duplicate formats in ff_merge_formats detected
   [auto_scaler_0 @ 0x560df58f4550] Setting 'flags' to value 'bicubic'
   [auto_scaler_0 @ 0x560df58f4550] w:iw h:ih flags:'bicubic' interl:0
   [Parsed_hwupload_0 @ 0x560df58f0ec0] auto-inserting filter
   'auto_scaler_0' between the filter 'graph 0 input from stream 0:0' and
   the filter 'Parsed_hwupload_0'

Signed-off-by: Haihao Xiang 
---
 libavutil/hwcontext_vaapi.c | 30 +-
 1 file changed, 25 insertions(+), 5 deletions(-)

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index b31cf95850..fb9be19647 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -268,14 +268,24 @@ static int vaapi_frames_get_constraints(AVHWDeviceContext 
*hwdev,
 }
 
 for (i = j = 0; i < attr_count; i++) {
+int k;
+
 if (attr_list[i].type != VASurfaceAttribPixelFormat)
 continue;
 fourcc = attr_list[i].value.value.i;
 pix_fmt = vaapi_pix_fmt_from_fourcc(fourcc);
-if (pix_fmt != AV_PIX_FMT_NONE)
+
+if (pix_fmt == AV_PIX_FMT_NONE)
+continue;
+
+for (k = 0; k < j; k++) {
+if (constraints->valid_sw_formats[k] == pix_fmt)
+break;
+}
+
+if (k == j)
 constraints->valid_sw_formats[j++] = pix_fmt;
 }
-av_assert0(j == pix_fmt_count);
 constraints->valid_sw_formats[j] = AV_PIX_FMT_NONE;
 }
 } else {
@@ -287,9 +297,19 @@ static int vaapi_frames_get_constraints(AVHWDeviceContext 
*hwdev,
 err = AVERROR(ENOMEM);
 goto fail;
 }
-for (i = 0; i < ctx->nb_formats; i++)
-constraints->valid_sw_formats[i] = ctx->formats[i].pix_fmt;
-constraints->valid_sw_formats[i] = AV_PIX_FMT_NONE;
+for (i = j = 0; i < ctx->nb_formats; i++) {
+int k;
+
+for (k = 0; k < j; k++) {
+if (constraints->valid_sw_formats[k] == 
ctx->formats[i].pix_fmt)
+break;
+}
+
+if (k == j)
+constraints->valid_sw_formats[j++] = ctx->formats[i].pix_fmt;
+}
+
+constraints->valid_sw_formats[j] = AV_PIX_FMT_NONE;
 }
 
 constraints->valid_hw_formats = av_malloc_array(2, sizeof(pix_fmt));
-- 
2.25.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v6 0/6] MIPS MSA & MMI Runtime detection support

2020-07-23 Thread Shiyou Yin

>-Original Message-
>From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org] 
>On Behalf Of
>Michael Niedermayer
>Sent: Thursday, July 23, 2020 11:24 PM
>To: FFmpeg development discussions and patches
>Subject: Re: [FFmpeg-devel] [PATCH v6 0/6] MIPS MSA & MMI Runtime detection 
>support
>
>On Thu, Jul 23, 2020 at 04:18:32PM +0200, Michael Niedermayer wrote:
>> On Tue, Jul 21, 2020 at 03:40:25PM +0800, Shiyou Yin wrote:
>> > >-Original Message-
>> > >From: ffmpeg-devel-boun...@ffmpeg.org
>> > >[mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Jiaxun Yang
>> > >Sent: Saturday, July 18, 2020 11:36 PM
>> > >To: ffmpeg-devel@ffmpeg.org
>> > >Cc: Jiaxun Yang
>> > >Subject: [FFmpeg-devel] [PATCH v6 0/6] MIPS MSA & MMI Runtime
>> > >detection support
>> > >
>> > >This series adds MIPS MSA & MMI runtime detection support
>> > >
>> > >Please review.
>> > >
>> > >Thanks!
>> > >
>> > >v2:
>> > >  - Add CPUCFG support.
>> > >  - Add "-mloongson-ext" to MMIFLAGS for Loongson-3 as well.
>> > >(Loongson2F don't need this flag)
>> > >
>> > >v3:
>> > >  - Address reveiew suggestions from Shiyou Yin and Weixi Gu.
>> > >
>> > >v4:
>> > >  - Disable DSP for generic CPU
>> > >
>> > >v5:
>> > >  - Clean ups
>> > >  - Address some GCC build warnings
>> > >
>> > >v6:
>> > >  - Address more Shiyou's comments
>> > >
>> > >Jiaxun Yang (6):
>> > >  ffbuild: Refine MIPS handling
>> > >  libavutils: Add parse_r helper for MIPS
>> > >  libavutil: Detect MMI and MSA flags for MIPS
>> > >  libavcodec: Enable runtime detection for MIPS MMI & MSA
>> > >  libavcodec: MIPS: MMI: Fix type mismatches
>> > >  libavcodec: MIPS: MMI: Move sp out of the clobber list
>> > >
>> > > configure   | 172 ++--
>> > > ffbuild/common.mak  |  10 +-
>> > > libavcodec/mips/Makefile|   3 +-
>> > > libavcodec/mips/blockdsp_init_mips.c|  40 +-
>> > > libavcodec/mips/cabac.h |   2 +-
>> > > libavcodec/mips/h263dsp_init_mips.c |  18 +-
>> > > libavcodec/mips/h264chroma_init_mips.c  |  55 +-
>> > > libavcodec/mips/h264dsp_init_mips.c | 225 +++--
>> > > libavcodec/mips/h264dsp_mips.h  |  18 +-
>> > > libavcodec/mips/h264dsp_mmi.c   |  56 +-
>> > > libavcodec/mips/h264pred_init_mips.c| 207 ++--
>> > > libavcodec/mips/h264qpel_init_mips.c| 412 
>> > > libavcodec/mips/hevcdsp_init_mips.c | 992 ++--
>> > > libavcodec/mips/hevcpred_init_mips.c|  40 +-
>> > > libavcodec/mips/hpeldsp_init_mips.c | 180 ++--
>> > > libavcodec/mips/idctdsp_init_mips.c |  74 +-
>> > > libavcodec/mips/me_cmp_init_mips.c  |  50 +-
>> > > libavcodec/mips/mpegvideo_init_mips.c   |  48 +-
>> > > libavcodec/mips/mpegvideoencdsp_init_mips.c |  21 +-
>> > > libavcodec/mips/pixblockdsp_init_mips.c |  63 +-
>> > > libavcodec/mips/qpeldsp_init_mips.c | 270 +++---
>> > > libavcodec/mips/vc1dsp_init_mips.c  | 186 ++--
>> > > libavcodec/mips/videodsp_init.c |  10 +-
>> > > libavcodec/mips/vp3dsp_init_mips.c  |  44 +-
>> > > libavcodec/mips/vp8dsp_init_mips.c  | 240 +++--
>> > > libavcodec/mips/vp9dsp_init_mips.c  |  16 +-
>> > > libavcodec/mips/wmv2dsp_init_mips.c |  18 +-
>> > > libavcodec/mips/wmv2dsp_mips.h  |   4 +-
>> > > libavcodec/mips/wmv2dsp_mmi.c   |   4 +-
>> > > libavcodec/mips/xvid_idct_mmi.c |   4 +-
>> > > libavcodec/mips/xvididct_init_mips.c|  31 +-
>> > > libavcodec/mips/xvididct_mips.h |   4 +-
>> > > libavutil/cpu.c |  10 +
>> > > libavutil/cpu.h |   3 +
>> > > libavutil/cpu_internal.h|   2 +
>> > > libavutil/mips/Makefile |   2 +-
>> > > libavutil/mips/asmdefs.h|  42 +
>> > > libavutil/mips/cpu.c| 134 +++
>> > > libavutil/mips/cpu.h|  28 +
>> > > libavutil/tests/cpu.c   |   3 +
>> > > tests/checkasm/checkasm.c   |   3 +
>> > > 41 files changed, 1919 insertions(+), 1825 deletions(-) create
>> > > mode 100644 libavutil/mips/cpu.c create mode 100644
>> > > libavutil/mips/cpu.h
>> > >
>> > >--
>> > >2.27.0
>> >
>> > LGTM
>>
>> will apply
>
>next time please make sure the patches do not add tabs in .h / .c files these 
>cannot be pushed
>
thank you for your reminder, will pay attention to it in the future.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/smacker: Support seeking to first frame

2020-07-23 Thread Andreas Rheinhardt

From: Timotej Lazar 

Add .read_seek function to the smacker demuxer for the special case of
seeking to ts=0. This is useful because smacker – like bink, with a
similar implementation – was mostly used to encode clips in video
games, where random seeks are rare but looping media are common.

Signed-off-by: Timotej Lazar 
---
 libavformat/smacker.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/libavformat/smacker.c b/libavformat/smacker.c
index 0ca5a87b8f..5507e7c169 100644
--- a/libavformat/smacker.c
+++ b/libavformat/smacker.c
@@ -349,6 +349,31 @@ next_frame:
 return ret;
 }
 
+static int smacker_read_seek(AVFormatContext *s, int stream_index,
+ int64_t timestamp, int flags)
+{
+SmackerContext *smk = s->priv_data;
+int64_t ret;
+
+/* only rewinding to start is supported */
+if (timestamp != 0) {
+av_log(s, AV_LOG_ERROR,
+   "Random seeks are not supported (can only seek to start).\n");
+return AVERROR(EINVAL);
+}
+
+if ((ret = avio_seek(s->pb, s->internal->data_offset, SEEK_SET)) < 0)
+return ret;
+
+smk->cur_frame = 0;
+smk->next_audio_index = 0;
+smk->new_palette = 0;
+memset(smk->pal, 0, sizeof(smk->pal));
+memset(smk->aud_pts, 0, sizeof(smk->aud_pts));
+
+return 0;
+}
+
 AVInputFormat ff_smacker_demuxer = {
 .name   = "smk",
 .long_name  = NULL_IF_CONFIG_SMALL("Smacker"),
@@ -356,4 +381,5 @@ AVInputFormat ff_smacker_demuxer = {
 .read_probe = smacker_probe,
 .read_header= smacker_read_header,
 .read_packet= smacker_read_packet,
+.read_seek  = smacker_read_seek,
 };
-- 
2.20.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter: add radial and circular blur video filter

2020-07-23 Thread Paul B Mahol

On 7/23/20, Michael Niedermayer  wrote:
> On Sun, Jul 19, 2020 at 09:45:44PM +0200, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol 
>> ---
>>  doc/filters.texi |  46 
>>  libavfilter/Makefile |   2 +
>>  libavfilter/allfilters.c |   2 +
>>  libavfilter/vf_rblur.c   | 558 +++
>>  4 files changed, 608 insertions(+)
>>  create mode 100644 libavfilter/vf_rblur.c
>>
>> diff --git a/doc/filters.texi b/doc/filters.texi
>> index a2c31ff610..62705db984 100644
>> --- a/doc/filters.texi
>> +++ b/doc/filters.texi
>> @@ -7231,6 +7231,29 @@ Set planes to filter. Default value is to filter
>> all
>>  planes except alpha plane.
>>  @end table
>>
>> +@section cblur
>> +Apply a circular blur filter.
>> +
>> +The filter accepts the following options:
>> +
>> +@table @option
>> +@item centerx, centery
>> +Set central point position of circular blur. Default is @code{0.5}.
>> +
>> +@item amount
>> +Set amount of circular blur. Default is @code{0.03}.
>> +
>> +@item planes
>> +Set which planes to filter. By default all planes are filtered.
>> +@end table
>> +
>> +@subsection Commands
>> +This filter supports same @ref{commands} as options.
>> +The command accepts the same syntax of the corresponding option.
>> +
>> +If the specified expression is not valid, it is kept at its current
>> +value.
>> +
>>  @section chromahold
>>  Remove all color information for all colors except for certain one.
>>
>> @@ -15768,6 +15791,29 @@ less than @code{0}, the filter will try to use a
>> good random seed on a
>>  best effort basis.
>>  @end table
>>
>> +@section rblur
>> +Apply a radial blur filter.
>> +
>> +The filter accepts the following options:
>> +
>> +@table @option
>> +@item centerx, centery
>> +Set central point position of radial blur. Default is @code{0.5}.
>> +
>> +@item amount
>> +Set amount of radial blur. Default is @code{0.03}.
>> +
>> +@item planes
>> +Set which planes to filter. By default all planes are filtered.
>> +@end table
>> +
>> +@subsection Commands
>> +This filter supports same @ref{commands} as options.
>> +The command accepts the same syntax of the corresponding option.
>> +
>> +If the specified expression is not valid, it is kept at its current
>> +value.
>> +
>>  @section readeia608
>>
>>  Read closed captioning (EIA-608) information from the top lines of a
>> video frame.
>
> Please add an example that produces high quality output.
> Iam asking so the filter can be tested in relation to the concerns that
> have been raised in previous reviews

any options set should give high quality output.

There are some inconsistency with centerx/centery options when different
than 0.5 but that can be fixed later.

>
> Thanks
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Nations do behave wisely once they have exhausted all other alternatives.
> -- Abba Eban
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/4] vaapi_encode_h265: Enable 4:2:2 support

2020-07-23 Thread Linjie Fu

On Mon, Jul 20, 2020 at 10:32 PM Linjie Fu  wrote:
>
> On Fri, May 15, 2020 at 3:21 PM Fu, Linjie  wrote:
> >
> > > From: ffmpeg-devel  On Behalf Of
> > > Mark Thompson
> > > Sent: Sunday, March 8, 2020 00:15
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: Re: [FFmpeg-devel] [PATCH 4/4] vaapi_encode_h265: Enable 4:2:2
> > > support
> > >
> > > On 05/03/2020 02:49, Fu, Linjie wrote:
> > > > 2. recon surface of Y210 or 444 (AYUV and Y410 in media-driver) depends
> > > on the surface hint [3] in
> > > > libva and corresponding code in media-driver to resize the recon surface
> > > which is not upstreamed
> > > > yet.
> > >
> > > What is the reasoning for forcing the user to pass new extra attributes 
> > > with
> > > this rather than handling it transparently so that it works like all other
> > > encoders?
> > >
> > > In some places in Mesa surfaces are reallocated with different properties
> > > when they are used for a purpose they don't currently support, which 
> > > avoids
> > > weird constraints being exported to the user (e.g. see
> > >  > > a/surface.c#n1000>).  Since reconstructed picture surfaces are pretty 
> > > unlikely
> > > to be used for anything else (just being copied out for debugging 
> > > maybe?), it
> > > seems like an answer like that would be simpler in this case too.  (Though
> > > perhaps I'm missing something weird about the Intel hardware which makes
> > > this case uglier.)
> > >
> >
> > Implemented the surface reallocation inside media driver in [1], merged the 
> > query
> > support in [2],  verified that it works for both AYUV(or XYUV)/Y410, 
> > yuyv422.
> >
> > And for Y210, it seems to be better to implement render target support in
> > vaapi_encoder in this patch as well:
> > { "YUV422_10", VA_RT_FORMAT_YUV422_10,10, 3, 1, 0 },
> >
> > Hence patch LGTM with or without above modifications, thx.
> >
> > [1] < https://github.com/intel/media-driver/pull/915>
> > [2] < https://github.com/intel/media-driver/pull/855>
>
> Since it's well supported for now, prefer to apply this soon
> together with the patch for 422 10-bit encoding :
>
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/1595254554-12809-1-git-send-email-linjie...@intel.com/

Applied, thx.

- Linjie
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

38 matches

Mail list logo