Re: [FFmpeg-devel] [PATCH 1/6] avutil/cpu: add AVX512 Icelake flag
Ping.
> From: Wu, Jianhua
> Sent: Wednesday, March 2, 2022 1:34 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: RE: [PATCH 1/6] avutil/cpu: add AVX512 Icelake flag
>
> Ping.
> > From: Wu, Jianhua
> > Sent: Wednesday, February 23, 2022 4:58 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Wu, Jianhua
> > Subject: [PATCH 1/6] avutil/cpu: add AVX512 Icelake flag
> >
> > From: Wu Jianhua
> >
> > Signed-off-by: Wu Jianhua
> > ---
> > configure | 13 +++---
> > libavutil/cpu.c | 1 +
> > libavutil/cpu.h | 1 +
> > libavutil/x86/cpu.c | 8 --
> > libavutil/x86/cpu.h | 1 +
> > libavutil/x86/x86inc.asm | 53
> > ---
> > tests/checkasm/checkasm.c | 35 +-
> > 7 files changed, 63 insertions(+), 49 deletions(-)
> >
> > diff --git a/configure b/configure
> > index 1535dc3c5b..d88c2ae979 100755
> > --- a/configure
> > +++ b/configure
> > @@ -444,6 +444,7 @@ Optimization options (experts only):
> >--disable-fma4 disable FMA4 optimizations
> >--disable-avx2 disable AVX2 optimizations
> >--disable-avx512 disable AVX-512 optimizations
> > + --disable-avx512icl disable AVX-512ICL optimizations
> >--disable-aesni disable AESNI optimizations
> >--disable-armv5tedisable armv5te optimizations
> >--disable-armv6 disable armv6 optimizations
> > @@ -2098,6 +2099,7 @@ ARCH_EXT_LIST_X86_SIMD="
> > avx
> > avx2
> > avx512
> > +avx512icl
> > fma3
> > fma4
> > mmx
> > @@ -2666,6 +2668,7 @@ fma3_deps="avx"
> > fma4_deps="avx"
> > avx2_deps="avx"
> > avx512_deps="avx2"
> > +avx512icl_deps="avx512"
> >
> > mmx_external_deps="x86asm"
> > mmx_inline_deps="inline_asm x86"
> > @@ -6128,10 +6131,11 @@ EOF
> > elf*) enabled debug && append X86ASMFLAGS $x86asm_debug ;;
> > esac
> >
> > -enabled avx512 && check_x86asm avx512_external "vmovdqa32
> > [eax]{k1}{z}, zmm0"
> > -enabled avx2 && check_x86asm avx2_external "vextracti128 xmm0,
> > ymm0, 0"
> > -enabled xop&& check_x86asm xop_external"vpmacsdd xmm0,
> > xmm1, xmm2, xmm3"
> > -enabled fma4 && check_x86asm fma4_external "vfmaddps ymm0,
> > ymm1, ymm2, ymm3"
> > +enabled avx512&& check_x86asm avx512_external"vmovdqa32
> > [eax]{k1}{z}, zmm0"
> > +enabled avx512icl && check_x86asm avx512icl_external
> > + "vpdpwssds
> > zmm31{k1}{z}, zmm29, zmm28"
> > +enabled avx2 && check_x86asm avx2_external "vextracti128
> > xmm0, ymm0, 0"
> > +enabled xop && check_x86asm xop_external "vpmacsdd
> > xmm0,
> > xmm1, xmm2, xmm3"
> > +enabled fma4 && check_x86asm fma4_external "vfmaddps
> ymm0,
> > ymm1, ymm2, ymm3"
> > check_x86asm cpunop "CPU amdnop"
> > fi
> >
> > @@ -7471,6 +7475,7 @@ if enabled x86; then
> > echo "AVX enabled ${avx-no}"
> > echo "AVX2 enabled ${avx2-no}"
> > echo "AVX-512 enabled ${avx512-no}"
> > +echo "AVX-512ICL enabled${avx512icl-no}"
> > echo "XOP enabled ${xop-no}"
> > echo "FMA3 enabled ${fma3-no}"
> > echo "FMA4 enabled ${fma4-no}"
> > diff --git a/libavutil/cpu.c b/libavutil/cpu.c index
> > 1368502245..833c220192
> > 100644
> > --- a/libavutil/cpu.c
> > +++ b/libavutil/cpu.c
> > @@ -137,6 +137,7 @@ int av_parse_cpu_caps(unsigned *flags, const char
> *s)
> > { "cmov", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> > AV_CPU_FLAG_CMOV },.unit = "flags" },
> > { "aesni",NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> > AV_CPU_FLAG_AESNI},.unit = "flags" },
> > { "avx512" , NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> > AV_CPU_FLAG_AVX512 },.unit = "flags" },
> > +{ "avx512icl", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> > AV_CPU_FLAG_AVX512ICL }, .unit = "flags" },
> > { "slowgather", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> > AV_CPU_FLAG_SLOW_GATHER }, .unit = "flags" },
> >
> > #define CPU_FLAG_P2 AV_CPU_FLAG_CMOV | AV_CPU_FLAG_MMX diff
> -- git
> > a/libavutil/cpu.h b/libavutil/cpu.h index ce9bf14bf7..9711e574c5
> > 100644
> > --- a/libavutil/cpu.h
> > +++ b/libavutil/cpu.h
> > @@ -54,6 +54,7 @@
> > #define AV_CPU_FLAG_BMI10x2 ///< Bit Manipulation
> Instruction
> > Set 1
> > #define AV_CPU_FLAG_BMI20x4 ///< Bit Manipulation
> Instruction
> > Set 2
> > #define AV_CPU_FLAG_AVX512 0x10 ///< AVX-512 functions:
> > requires OS support even if YMM/ZMM registers aren't used
> > +#define AV_CPU_FLAG_AVX512ICL 0x20 ///<
> >
> +F/CD/BW/DQ/VL/VNNI/IFMA/VBMI/VBMI2/VPOPCNTDQ/BITALG/GFNI/V
> > AES/VPCLMULQD
> > +Q
> > #define AV_CPU_FLAG_SLOW_GATHER 0x200 ///< CPU has slow
> gathers.
> >
> > #define AV_CPU_FLAG_ALTIVEC 0x0001 ///< standard
> > diff --git
Re: [FFmpeg-devel] [PATCH] d3d11va: let user can create SRV from output
On Wed, Mar 9, 2022 at 7:56 AM Wang Chuan wrote:
>
> Starting from Windows 8, users can create SRV from video resource
> and bind it to shaders directly. This can avoid unnecessary memcpy
> (ID3D11DeviceContext::CopyResource, etc), so create texture with
> [D3D11_BIND_SHADER_RESOURCE] as decoder's output if possible.
>
> Signed-off-by: Wang Chuan
> ---
> libavcodec/dxva2.c| 2 +-
> libavutil/hwcontext_d3d11va.c | 10 ++
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
> index 568d686f39..15b25d793c 100644
> --- a/libavcodec/dxva2.c
> +++ b/libavcodec/dxva2.c
> @@ -645,7 +645,7 @@ int ff_dxva2_common_frame_params(AVCodecContext *avctx,
> if (frames_ctx->format == AV_PIX_FMT_D3D11) {
> AVD3D11VAFramesContext *frames_hwctx = frames_ctx->hwctx;
> -frames_hwctx->BindFlags |= D3D11_BIND_DECODER;
> +frames_hwctx->BindFlags |= (D3D11_BIND_DECODER |
> D3D11_BIND_SHADER_RESOURCE);
> }
> #endif
> diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
> index 8ab96bad25..97ffd745bd 100644
> --- a/libavutil/hwcontext_d3d11va.c
> +++ b/libavutil/hwcontext_d3d11va.c
> @@ -203,6 +203,11 @@ static AVBufferRef
> *d3d11va_alloc_single(AVHWFramesContext *ctx)
> };
>hr = ID3D11Device_CreateTexture2D(device_hwctx->device, ,
> NULL, );
> +if (FAILED(hr) && (texDesc.BindFlags & D3D11_BIND_SHADER_RESOURCE)) {
> +av_log(ctx, AV_LOG_ERROR, "Could not create the texture with
> [D3D11_BIND_SHADER_RESOURCE] flag");
> +texDesc.BindFlags &= ~D3D11_BIND_SHADER_RESOURCE;
> +hr = ID3D11Device_CreateTexture2D(device_hwctx->device,
> , NULL, );
> +}
> if (FAILED(hr)) {
> av_log(ctx, AV_LOG_ERROR, "Could not create the texture
> (%lx)\n", (long)hr);
> return NULL;
> @@ -278,6 +283,11 @@ static int d3d11va_frames_init(AVHWFramesContext *ctx)
> }
> } else if (!(texDesc.BindFlags & D3D11_BIND_RENDER_TARGET) &&
> texDesc.ArraySize > 0) {
> hr = ID3D11Device_CreateTexture2D(device_hwctx->device,
> , NULL, >texture);
> +if (FAILED(hr) && (texDesc.BindFlags &
> D3D11_BIND_SHADER_RESOURCE)) {
> +av_log(ctx, AV_LOG_ERROR, "Could not create the texture
> with [D3D11_BIND_SHADER_RESOURCE] flag");
> +texDesc.BindFlags &= ~D3D11_BIND_SHADER_RESOURCE;
> +hr = ID3D11Device_CreateTexture2D(device_hwctx->device,
> , NULL, >texture);
> +}
I really don't like these fallbacks. If a caller requests a certain
set of flags, it should fullfill these, or fail, and not change them.
Especially special-casing this one flag just makes it extra iffy, and
I know why you added it, but that doesn't help.
IMHO, its also not entirely unreasonable that if you require anything
but the default flags, to let the user just manage their own frames
context, the effort required is not that high and there is never a set
of flags you can set that'll cover every use case (for example, I use
surface sharing, thats not set by default either).
- Hendrik
___
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] d3d11va: let user can create SRV from output
Starting from Windows 8, users can create SRV from video resource
and bind it to shaders directly. This can avoid unnecessary memcpy
(ID3D11DeviceContext::CopyResource, etc), so create texture with
[D3D11_BIND_SHADER_RESOURCE] as decoder's output if possible.
Signed-off-by: Wang Chuan
---
libavcodec/dxva2.c| 2 +-
libavutil/hwcontext_d3d11va.c | 10 ++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 568d686f39..15b25d793c 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -645,7 +645,7 @@ int ff_dxva2_common_frame_params(AVCodecContext *avctx,
if (frames_ctx->format == AV_PIX_FMT_D3D11) {
AVD3D11VAFramesContext *frames_hwctx = frames_ctx->hwctx;
-frames_hwctx->BindFlags |= D3D11_BIND_DECODER;
+frames_hwctx->BindFlags |= (D3D11_BIND_DECODER |
D3D11_BIND_SHADER_RESOURCE);
}
#endif
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 8ab96bad25..97ffd745bd 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -203,6 +203,11 @@ static AVBufferRef
*d3d11va_alloc_single(AVHWFramesContext *ctx)
};
hr = ID3D11Device_CreateTexture2D(device_hwctx->device, ,
NULL, );
+if (FAILED(hr) && (texDesc.BindFlags & D3D11_BIND_SHADER_RESOURCE)) {
+av_log(ctx, AV_LOG_ERROR, "Could not create the texture with
[D3D11_BIND_SHADER_RESOURCE] flag");
+texDesc.BindFlags &= ~D3D11_BIND_SHADER_RESOURCE;
+hr = ID3D11Device_CreateTexture2D(device_hwctx->device,
, NULL, );
+}
if (FAILED(hr)) {
av_log(ctx, AV_LOG_ERROR, "Could not create the texture
(%lx)\n", (long)hr);
return NULL;
@@ -278,6 +283,11 @@ static int d3d11va_frames_init(AVHWFramesContext *ctx)
}
} else if (!(texDesc.BindFlags & D3D11_BIND_RENDER_TARGET) &&
texDesc.ArraySize > 0) {
hr = ID3D11Device_CreateTexture2D(device_hwctx->device,
, NULL, >texture);
+if (FAILED(hr) && (texDesc.BindFlags &
D3D11_BIND_SHADER_RESOURCE)) {
+av_log(ctx, AV_LOG_ERROR, "Could not create the texture
with [D3D11_BIND_SHADER_RESOURCE] flag");
+texDesc.BindFlags &= ~D3D11_BIND_SHADER_RESOURCE;
+hr = ID3D11Device_CreateTexture2D(device_hwctx->device,
, NULL, >texture);
+}
if (FAILED(hr)) {
av_log(ctx, AV_LOG_ERROR, "Could not create the texture
(%lx)\n", (long)hr);
return AVERROR_UNKNOWN;
--
2.35.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 v8 1/1] avformat: Add IPFS protocol support.
On Wed, Mar 9, 2022 at 12:45 AM Michael Niedermayer wrote: > On Tue, Mar 08, 2022 at 01:49:22PM +0100, Mark Gaiser wrote: > > On Fri, Mar 4, 2022 at 7:09 PM Michael Niedermayer < > mich...@niedermayer.cc> > > wrote: > > > > > On Thu, Mar 03, 2022 at 03:58:53PM +0100, Mark Gaiser wrote: > > > > On Tue, Mar 1, 2022 at 11:01 PM Michael Niedermayer < > > > mich...@niedermayer.cc> > > > > wrote: > > > > > > > > > On Mon, Feb 28, 2022 at 02:09:15PM +0100, Tomas Härdin wrote: > > > > > > sön 2022-02-27 klockan 15:29 +0100 skrev Mark Gaiser: > > > > > > > Ping 2 > > > > > > > > > > > > > > I'd really like to get this merged! > > > > > > > This kinda blocks me right now from proceeding with IPFS > > > integration > > > > > > > in > > > > > > > Kodi, MPV and VLC. Implementations in those (who rely on > ffmpeg) > > > are > > > > > > > significantly easier once this patch is finally landed in > ffmpeg. > > > > > > > > > > > > I'd like to hear at least one other dev chime in on this one > > > > > > > > > > what exactly are you not sure about ? > > > > > what exactly needs a 2nd look ? > > > > > > > > > > > > > My assumption. > > > > In general just a second look by someone other than Tomas. > > > > And, as he was skeptical about this patch at first, likely another > > > opinion > > > > if this makes sense to add in ffmpeg. > > > > To me it does very much but i'm biased :) > > > > > > ipfs support makes sense to be added to ffmpeg. ive seen ipfs urls and > ive > > > already been annoyed that some tools dont "just" work with them. > > > While if i compare this to many other formats which i have never seen > > > outside the context of FFmpeg. So from this biased single sample that i > > > am, ipfs seems more widespread and thats why iam in favor of its > support > > > > > > thx > > > > > > Great to have your support :) > > Reading that is quite motivating to work on it, no joke! > > > > Just to be clear here. Having this in ffmpeg won't make it "just work" > yet. > > For a minimal feeling of "hey, it works out of the box" you'd need: > > - The next or version after the next IPFS. > > - MPV support which relies on this patch to even be supported in mpv > > - Have a node running locally > > if theres no local node it should fallback to a public node > ATM > IPFS_GATEWAY=https://dweb.link ./ffplay ipfs://... > works > so such a fallback is all thats needed for it to just work > Yes, the beauty of gateways. Are you suggesting that I update the patch to add this default? I would prefer not to add that even though it would give a feeling of "just works". I'm mostly concerned about the bandwidth usage it could cause on that site. But also about potential hacks. If this is a default and well used then it becomes quite appealing for hackers to take control of dweb.link and send back data that wasn't requested. If you insist this would be really better to add then I'll need to go find the ones managing that site (paying for it) to ask permission if this would be allowed. > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > If the United States is serious about tackling the national security > threats > related to an insecure 5G network, it needs to rethink the extent to which > it > values corporate profits and government espionage over security.-Bruce > Schneier > ___ > 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 v8 1/1] avformat: Add IPFS protocol support.
On Tue, Mar 08, 2022 at 01:49:22PM +0100, Mark Gaiser wrote: > On Fri, Mar 4, 2022 at 7:09 PM Michael Niedermayer > wrote: > > > On Thu, Mar 03, 2022 at 03:58:53PM +0100, Mark Gaiser wrote: > > > On Tue, Mar 1, 2022 at 11:01 PM Michael Niedermayer < > > mich...@niedermayer.cc> > > > wrote: > > > > > > > On Mon, Feb 28, 2022 at 02:09:15PM +0100, Tomas Härdin wrote: > > > > > sön 2022-02-27 klockan 15:29 +0100 skrev Mark Gaiser: > > > > > > Ping 2 > > > > > > > > > > > > I'd really like to get this merged! > > > > > > This kinda blocks me right now from proceeding with IPFS > > integration > > > > > > in > > > > > > Kodi, MPV and VLC. Implementations in those (who rely on ffmpeg) > > are > > > > > > significantly easier once this patch is finally landed in ffmpeg. > > > > > > > > > > I'd like to hear at least one other dev chime in on this one > > > > > > > > what exactly are you not sure about ? > > > > what exactly needs a 2nd look ? > > > > > > > > > > My assumption. > > > In general just a second look by someone other than Tomas. > > > And, as he was skeptical about this patch at first, likely another > > opinion > > > if this makes sense to add in ffmpeg. > > > To me it does very much but i'm biased :) > > > > ipfs support makes sense to be added to ffmpeg. ive seen ipfs urls and ive > > already been annoyed that some tools dont "just" work with them. > > While if i compare this to many other formats which i have never seen > > outside the context of FFmpeg. So from this biased single sample that i > > am, ipfs seems more widespread and thats why iam in favor of its support > > > > thx > > > > Great to have your support :) > Reading that is quite motivating to work on it, no joke! > > Just to be clear here. Having this in ffmpeg won't make it "just work" yet. > For a minimal feeling of "hey, it works out of the box" you'd need: > - The next or version after the next IPFS. > - MPV support which relies on this patch to even be supported in mpv > - Have a node running locally if theres no local node it should fallback to a public node ATM IPFS_GATEWAY=https://dweb.link ./ffplay ipfs://... works so such a fallback is all thats needed for it to just work thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If the United States is serious about tackling the national security threats related to an insecure 5G network, it needs to rethink the extent to which it values corporate profits and government espionage over security.-Bruce Schneier 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".
[FFmpeg-devel] [PATCH] avcodec/mlp_parser: Do not drop data before a major sync
This does not attempt to split the data prior to a major sync so it all is in one blob, but it is not dropped anymore. Signed-off-by: Michael Niedermayer --- libavcodec/mlp_parser.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/mlp_parser.c b/libavcodec/mlp_parser.c index 9fea7db955..db8ac6d156 100644 --- a/libavcodec/mlp_parser.c +++ b/libavcodec/mlp_parser.c @@ -96,6 +96,9 @@ static int mlp_parse(AVCodecParserContext *s, return ret; } +*poutbuf = buf; +*poutbuf_size = buf_size; + return i - 7; } -- 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 v3 4/4] vaapi_encode_h265: Query encoding block sizes and features
On Fri, 2022-03-04 at 16:37 +0800, Fei Wang wrote:
> From: Mark Thompson
>
> Signed-off-by: Fei Wang
> ---
> libavcodec/vaapi_encode_h265.c | 112 +++--
> 1 file changed, 106 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
> index cafc860772..b9cf3209b3 100644
> --- a/libavcodec/vaapi_encode_h265.c
> +++ b/libavcodec/vaapi_encode_h265.c
> @@ -56,6 +56,9 @@ typedef struct VAAPIEncodeH265Context {
> VAAPIEncodeContext common;
>
> // Encoder features.
> +uint32_t va_features;
> +// Block size info.
> +uint32_t va_bs;
> uint32_t ctu_size;
> uint32_t min_cb_size;
>
> @@ -427,9 +430,9 @@ static int
> vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
> vps->vps_max_latency_increase_plus1[i];
> }
>
> -// These have to come from the capabilities of the encoder. We have no
> -// way to query them, so just hardcode parameters which work on the Intel
> -// driver.
> +// These values come from the capabilities of the first encoder
> +// implementation in the i965 driver on Intel Skylake. They may
> +// fail badly with other platforms or drivers.
> // CTB size from 8x8 to 32x32.
> sps->log2_min_luma_coding_block_size_minus3 = 0;
> sps->log2_diff_max_min_luma_coding_block_size = 2;
> @@ -447,6 +450,42 @@ static int
> vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
>
> sps->pcm_enabled_flag = 0;
>
> +// update sps setting according to queried result
> +#if VA_CHECK_VERSION(1, 13, 0)
> +if (priv->va_features) {
> +VAConfigAttribValEncHEVCFeatures features = { .value = priv-
> >va_features };
> +
> +// Enable feature if get queried result is VA_FEATURE_SUPPORTED |
> VA_FEATURE_REQUIRED
> +sps->amp_enabled_flag =
> +!!features.bits.amp;
> +sps->sample_adaptive_offset_enabled_flag =
> +!!features.bits.sao;
> +sps->sps_temporal_mvp_enabled_flag =
> +!!features.bits.temporal_mvp;
> +sps->pcm_enabled_flag =
> +!!features.bits.pcm;
> +}
> +
> +if (priv->va_bs) {
> +VAConfigAttribValEncHEVCBlockSizes bs = { .value = priv->va_bs };
> +sps->log2_min_luma_coding_block_size_minus3 =
> +ff_ctz(priv->min_cb_size) - 3;
> +sps->log2_diff_max_min_luma_coding_block_size =
> +ff_ctz(priv->ctu_size) - ff_ctz(priv->min_cb_size);
> +
> +sps->log2_min_luma_transform_block_size_minus2 =
> +bs.bits.log2_min_luma_transform_block_size_minus2;
> +sps->log2_diff_max_min_luma_transform_block_size =
> +bs.bits.log2_max_luma_transform_block_size_minus2 -
> +bs.bits.log2_min_luma_transform_block_size_minus2;
> +
> +sps->max_transform_hierarchy_depth_inter =
> +bs.bits.max_max_transform_hierarchy_depth_inter;
> +sps->max_transform_hierarchy_depth_intra =
> +bs.bits.max_max_transform_hierarchy_depth_intra;
> +}
> +#endif
> +
> // STRPSs should ideally be here rather than defined individually in
> // each slice, but the structure isn't completely fixed so for now
> // don't bother.
> @@ -539,6 +578,23 @@ static int
> vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
> pps->cu_qp_delta_enabled_flag = (ctx->va_rc_mode != VA_RC_CQP);
> pps->diff_cu_qp_delta_depth = 0;
>
> +// update pps setting according to queried result
> +#if VA_CHECK_VERSION(1, 13, 0)
> +if (priv->va_features) {
> +VAConfigAttribValEncHEVCFeatures features = { .value = priv-
> >va_features };
> +if (ctx->va_rc_mode != VA_RC_CQP)
> +pps->cu_qp_delta_enabled_flag =
> +!!features.bits.cu_qp_delta;
> +
> +pps->transform_skip_enabled_flag =
> +!!features.bits.transform_skip;
> +// set diff_cu_qp_delta_depth as its max value if cu_qp_delta
> enabled. Otherwise
> +// 0 will make cu_qp_delta invalid.
> +if (pps->cu_qp_delta_enabled_flag)
> +pps->diff_cu_qp_delta_depth = sps-
> >log2_diff_max_min_luma_coding_block_size;
> +}
> +#endif
> +
> if (ctx->tile_rows && ctx->tile_cols) {
> int uniform_spacing;
>
> @@ -640,8 +696,8 @@ static int
> vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
>
> .coded_buf = VA_INVALID_ID,
>
> -.collocated_ref_pic_index = 0xff,
> -
> +.collocated_ref_pic_index = sps->sps_temporal_mvp_enabled_flag ?
> +0 : 0xff,
> .last_picture = 0,
>
> .pic_init_qp= pps->init_qp_minus26 + 26,
> @@ -674,6 +730,8 @@ static int
> vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
> .entropy_coding_sync_enabled_flag = pps-
> >entropy_coding_sync_enabled_flag,
> .loop_filter_across_tiles_enabled_flag =
>
Re: [FFmpeg-devel] [PATCH V2 8/8] libavfilter: Remove DNNReturnType from DNN Module
-Original Message- From: ffmpeg-devel On Behalf Of Shubhanshu Saxena Sent: 2022年3月3日 2:06 To: ffmpeg-devel@ffmpeg.org Cc: Shubhanshu Saxena Subject: [FFmpeg-devel] [PATCH V2 8/8] libavfilter: Remove DNNReturnType from DNN Module This patch removes all occurences of DNNReturnType from the DNN module. This commit replaces DNN_SUCCESS by 0 (essentially the same), so the functions with DNNReturnType now return 0 in case of success, the negative values otherwise. Signed-off-by: Shubhanshu Saxena --- libavfilter/dnn/dnn_backend_common.c | 10 ++-- libavfilter/dnn/dnn_backend_common.h | 8 +-- libavfilter/dnn/dnn_backend_native.c | 16 +++--- .../dnn/dnn_backend_native_layer_avgpool.c| 2 +- .../dnn/dnn_backend_native_layer_conv2d.c | 4 +- .../dnn/dnn_backend_native_layer_dense.c | 2 +- .../dnn_backend_native_layer_depth2space.c| 2 +- libavfilter/dnn/dnn_backend_openvino.c| 48 libavfilter/dnn/dnn_backend_tf.c | 56 +-- libavfilter/dnn/dnn_io_proc.c | 14 ++--- libavfilter/dnn_interface.h | 2 - libavfilter/vf_derain.c | 2 +- libavfilter/vf_dnn_classify.c | 4 +- libavfilter/vf_dnn_detect.c | 4 +- libavfilter/vf_dnn_processing.c | 8 +-- libavfilter/vf_sr.c | 4 +- 16 files changed, 92 insertions(+), 94 deletions(-) Thanks, LGTM, will push soon. ___ 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] avcodec/hevc_refs: don't use the frame's AVBufferRef sizes when initializing planes
Use the actual plane sizes instead.
Signed-off-by: James Almer
---
libavcodec/hevc_refs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index 35b8e5e696..fe18ca2b1d 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -401,9 +401,9 @@ static HEVCFrame *generate_missing_ref(HEVCContext *s, int
poc)
if (!s->avctx->hwaccel) {
if (!s->ps.sps->pixel_shift) {
-for (i = 0; frame->frame->buf[i]; i++)
-memset(frame->frame->buf[i]->data, 1 << (s->ps.sps->bit_depth
- 1),
- frame->frame->buf[i]->size);
+for (i = 0; frame->frame->data[i]; i++)
+memset(frame->frame->data[i], 1 << (s->ps.sps->bit_depth - 1),
+ frame->frame->linesize[i] *
AV_CEIL_RSHIFT(s->ps.sps->height, s->ps.sps->vshift[i]));
} else {
for (i = 0; frame->frame->data[i]; i++)
for (y = 0; y < (s->ps.sps->height >> s->ps.sps->vshift[i]);
y++) {
--
2.35.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 v3 7/7] avformat/concat: refactor to use ff_rescale_interval()
p...@sandflow.com (12022-03-07): > From: Pierre-Anthony Lemieux > > --- > libavformat/concatdec.c | 18 -- > 1 file changed, 4 insertions(+), 14 deletions(-) This patch still LGTM. Regards, -- Nicolas George 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 2/2] lavu/tests/opts: add tests for filepath options
On Tue, Mar 08, 2022 at 08:47:17AM +0100, J. Dekker wrote: > > > On 5 Mar 2022, at 20:16, Michael Niedermayer wrote: > > > On Fri, Mar 04, 2022 at 04:03:07PM +0100, Niklas Haas wrote: > >> From: Niklas Haas > >> > >> Using the venerable HEADER.txt as a small file to load. > >> --- > >> libavutil/tests/opt.c| 38 +- > >> tests/fate/libavutil.mak | 2 +- > >> tests/ref/fate/opt | 4 > >> 3 files changed, 42 insertions(+), 2 deletions(-) > > > > Please add tests which tries to load > > id_rsa > > ~/.ssh/id_rsa > > shadow > > /etc/shadow > > .bash_history > > ... > > > > The idea here is of course that such attempts fail > > There is absolutely no way we can or should try to implement a path based > blacklist. did i ask for one ? what i asked for is that you write an exploit to show that it fails. > Untrusted inputs should be sanitised externally by whichever script is being > used to call ffmpeg. my suggestion isnt really affected by this, please implement a test of this you can put a script around the call to ffmpeg in the fate test but show that it achieves the security. If you cannot do this, then please do not suggest that this is the way to sanitize untrusted data. > > > Also document the security implications of this feature in > > doc/APIchanges / release notes if there is a security implication > > > > Adjusting the parameters of most components could previously > > not read arbitrary files so a application could previously > > pass a string from a untrusted user to it. > > If this changes it needs to be justfied and documented > > If it doesnt change and its still safe that should be documented. > > If it depends on whitelists and callbacks that should be actually > > implemented > > in ffmpeg and the relevant examples > > > > And i do like this feature, if it can be done without security issues > > There aren't any extra security implications here, if a user is allowed to > specify filter arguments themselves then they can already use the > movie/amovie filter etc. This new option is just a way to unify the way in > which filters which already (and will) require to load files can do so. hmm So above you say "Untrusted inputs should be sanitised externally by whichever script is being used to call ffmpeg." and that script now lets say blocks movie and amovie (and others) before your patch thats safe, afterwards its not how would the developer know that a git pull --rebase requires him to rewrite that script? Or maybe the script has a list of safe filters and safe arguments, maybe scale, crop, and a few others with width/height and so on such script needs an update too if the binary option gains the ability to read arbitrary files. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri 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] avcodec/hevc_refs: don't use the frame's AVBufferRef sizes when initializing planes
Quoting James Almer (2022-03-08 13:58:33)
>
>
> On 3/8/2022 9:49 AM, Anton Khirnov wrote:
> > Quoting James Almer (2022-03-06 16:39:39)
> >> Use the actual plane sizes instead.
> >>
> >> Signed-off-by: James Almer
> >> ---
> >> libavcodec/hevc_refs.c | 14 +++---
> >> 1 file changed, 11 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
> >> index 35b8e5e696..b0035356ac 100644
> >> --- a/libavcodec/hevc_refs.c
> >> +++ b/libavcodec/hevc_refs.c
> >> @@ -22,6 +22,7 @@
> >>*/
> >>
> >> #include "libavutil/avassert.h"
> >> +#include "libavutil/imgutils.h"
> >>
> >> #include "thread.h"
> >> #include "hevc.h"
> >> @@ -401,9 +402,16 @@ static HEVCFrame *generate_missing_ref(HEVCContext
> >> *s, int poc)
> >>
> >> if (!s->avctx->hwaccel) {
> >> if (!s->ps.sps->pixel_shift) {
> >> -for (i = 0; frame->frame->buf[i]; i++)
> >> -memset(frame->frame->buf[i]->data, 1 <<
> >> (s->ps.sps->bit_depth - 1),
> >> - frame->frame->buf[i]->size);
> >> +size_t sizes[4];
> >> +ptrdiff_t linesizes[4];
> >> +for (i = 0; i < 4; i++)
> >> +linesizes[i] = frame->frame->linesize[i];
> >> +if (av_image_fill_plane_sizes(sizes, frame->frame->format,
> >> frame->frame->height, linesizes) < 0) {
> >> +ff_hevc_unref_frame(s, frame, ~0);
> >> +return NULL;
> >> +}
> >> +for (i = 0; frame->frame->data[i]; i++)
> >> +memset(frame->frame->data[i], 1 << (s->ps.sps->bit_depth
> >> - 1), sizes[i]);
> >
> > wouldn't it be simpler and shorter to use linesize[i] * (height >>
> > sps->vshift)?
>
> That's what av_image_fill_plane_sizes() does to fill sizes[].
> If we do it manually we also need to ensure to do it only for i > 0, so
> it's not that much of a simplification. But ok, will send a patch with
> that change.
vshift is a per-plane array, so you don't have to
>
> Could we for that matter change AVFrame linesize to ptrdiff_t in the
> next bump? Alongside the relevant imgutils helpers, if possible.
> Half this patch is just doing int -> ptrdiff_t, which is why it looks so
> big.
Might be a lot of work, but I'm certainly not against.
--
Anton Khirnov
___
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] avcodec/hevc_refs: don't use the frame's AVBufferRef sizes when initializing planes
On Tue, Mar 8, 2022 at 1:58 PM James Almer wrote: > > Could we for that matter change AVFrame linesize to ptrdiff_t in the > next bump? Alongside the relevant imgutils helpers, if possible. > Half this patch is just doing int -> ptrdiff_t, which is why it looks so > big. Its definitely long overdue, having half the frame API already use size_t/ptrdiff_t makes for really annoying conversion loops when trying to use them. - Hendrik ___ 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] avcodec/hevc_refs: don't use the frame's AVBufferRef sizes when initializing planes
On 3/8/2022 9:49 AM, Anton Khirnov wrote:
Quoting James Almer (2022-03-06 16:39:39)
Use the actual plane sizes instead.
Signed-off-by: James Almer
---
libavcodec/hevc_refs.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index 35b8e5e696..b0035356ac 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -22,6 +22,7 @@
*/
#include "libavutil/avassert.h"
+#include "libavutil/imgutils.h"
#include "thread.h"
#include "hevc.h"
@@ -401,9 +402,16 @@ static HEVCFrame *generate_missing_ref(HEVCContext *s, int
poc)
if (!s->avctx->hwaccel) {
if (!s->ps.sps->pixel_shift) {
-for (i = 0; frame->frame->buf[i]; i++)
-memset(frame->frame->buf[i]->data, 1 << (s->ps.sps->bit_depth
- 1),
- frame->frame->buf[i]->size);
+size_t sizes[4];
+ptrdiff_t linesizes[4];
+for (i = 0; i < 4; i++)
+linesizes[i] = frame->frame->linesize[i];
+if (av_image_fill_plane_sizes(sizes, frame->frame->format,
frame->frame->height, linesizes) < 0) {
+ff_hevc_unref_frame(s, frame, ~0);
+return NULL;
+}
+for (i = 0; frame->frame->data[i]; i++)
+memset(frame->frame->data[i], 1 << (s->ps.sps->bit_depth - 1),
sizes[i]);
wouldn't it be simpler and shorter to use linesize[i] * (height >> sps->vshift)?
That's what av_image_fill_plane_sizes() does to fill sizes[].
If we do it manually we also need to ensure to do it only for i > 0, so
it's not that much of a simplification. But ok, will send a patch with
that change.
Could we for that matter change AVFrame linesize to ptrdiff_t in the
next bump? Alongside the relevant imgutils helpers, if possible.
Half this patch is just doing int -> ptrdiff_t, which is why it looks so
big.
___
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] lavu: add syntax for loading AV_OPT_TYPE_BINARY from files
On Tue, 08 Mar 2022 12:48:35 +0100 Anton Khirnov wrote: > Quoting Niklas Haas (2022-03-04 16:03:06) > > From: Niklas Haas > > > > I arbitrarily decided to use the syntax 'opt=@filename' to match e.g. > > `curl -Ffield=@filename`, and also because @ is not a valid hex > > character, nor does it conflict with any other common shell or ffmpeg > > syntax. > > > > This is arguably somewhat clunky because it does not round-trip with > > av_opt_get - you will get back a hex interpretation of the loaded file, > > rather than the filename it was loaded from. It also implies a (perhaps > > unnecessary) memcpy from mapped file memory into a allocated memory. > > This is unfortunately necessary because there's no way for us to know > > whether av_free or av_file_unmap is needed to clean up previous option > > values. > > > > The motivating use case was the introduction of several new binary > > options for vf_libplacebo, but other filters that currently rely on > > manual file-path loading could benefit from it as well. > > Sorry, I think having an arbitrary file loader in the options parser > will be an endless security nightmare. > > The alternative I had in mind was having ffmpeg.c itself do the file > loading. This will be require some modification of the options parsing > code in cmdutils.c and also extending the mechanisms we use to pass > options to filters. > > I can try to make a POC in a few days. I think that is the better approach, too. I went for this approach because it was the easiest to implement, not because it makes the most sense. I do think that it's fine for ffmpeg.c to do this, but springing it upon unsuspecting API users *in general* is, well, in retrospect, not something I want to have my name attached to. I think that I would drop the second half of this commit (keeping only the introduction of `av_set_string_from_filepath`), and then make ffmpeg.c use it for cmdlist arguments starting with '@' as a separate commit. ___ 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 v8 1/1] avformat: Add IPFS protocol support.
On Fri, Mar 4, 2022 at 7:09 PM Michael Niedermayer wrote: > On Thu, Mar 03, 2022 at 03:58:53PM +0100, Mark Gaiser wrote: > > On Tue, Mar 1, 2022 at 11:01 PM Michael Niedermayer < > mich...@niedermayer.cc> > > wrote: > > > > > On Mon, Feb 28, 2022 at 02:09:15PM +0100, Tomas Härdin wrote: > > > > sön 2022-02-27 klockan 15:29 +0100 skrev Mark Gaiser: > > > > > Ping 2 > > > > > > > > > > I'd really like to get this merged! > > > > > This kinda blocks me right now from proceeding with IPFS > integration > > > > > in > > > > > Kodi, MPV and VLC. Implementations in those (who rely on ffmpeg) > are > > > > > significantly easier once this patch is finally landed in ffmpeg. > > > > > > > > I'd like to hear at least one other dev chime in on this one > > > > > > what exactly are you not sure about ? > > > what exactly needs a 2nd look ? > > > > > > > My assumption. > > In general just a second look by someone other than Tomas. > > And, as he was skeptical about this patch at first, likely another > opinion > > if this makes sense to add in ffmpeg. > > To me it does very much but i'm biased :) > > ipfs support makes sense to be added to ffmpeg. ive seen ipfs urls and ive > already been annoyed that some tools dont "just" work with them. > While if i compare this to many other formats which i have never seen > outside the context of FFmpeg. So from this biased single sample that i > am, ipfs seems more widespread and thats why iam in favor of its support > > thx > > Great to have your support :) Reading that is quite motivating to work on it, no joke! Just to be clear here. Having this in ffmpeg won't make it "just work" yet. For a minimal feeling of "hey, it works out of the box" you'd need: - The next or version after the next IPFS. - MPV support which relies on this patch to even be supported in mpv - Have a node running locally Once you have those then a "mpv ipfs://" works without any additional configuration. We're getting there and this is one (admittedly very significant) step in that direction. Lastly. merge time? Could you do the honors? As I don't have the required permissions. > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Everything should be made as simple as possible, but not simpler. > -- Albert Einstein > ___ > 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] avcodec/hevc_refs: don't use the frame's AVBufferRef sizes when initializing planes
Quoting James Almer (2022-03-06 16:39:39)
> Use the actual plane sizes instead.
>
> Signed-off-by: James Almer
> ---
> libavcodec/hevc_refs.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
> index 35b8e5e696..b0035356ac 100644
> --- a/libavcodec/hevc_refs.c
> +++ b/libavcodec/hevc_refs.c
> @@ -22,6 +22,7 @@
> */
>
> #include "libavutil/avassert.h"
> +#include "libavutil/imgutils.h"
>
> #include "thread.h"
> #include "hevc.h"
> @@ -401,9 +402,16 @@ static HEVCFrame *generate_missing_ref(HEVCContext *s,
> int poc)
>
> if (!s->avctx->hwaccel) {
> if (!s->ps.sps->pixel_shift) {
> -for (i = 0; frame->frame->buf[i]; i++)
> -memset(frame->frame->buf[i]->data, 1 <<
> (s->ps.sps->bit_depth - 1),
> - frame->frame->buf[i]->size);
> +size_t sizes[4];
> +ptrdiff_t linesizes[4];
> +for (i = 0; i < 4; i++)
> +linesizes[i] = frame->frame->linesize[i];
> +if (av_image_fill_plane_sizes(sizes, frame->frame->format,
> frame->frame->height, linesizes) < 0) {
> +ff_hevc_unref_frame(s, frame, ~0);
> +return NULL;
> +}
> +for (i = 0; frame->frame->data[i]; i++)
> +memset(frame->frame->data[i], 1 << (s->ps.sps->bit_depth -
> 1), sizes[i]);
wouldn't it be simpler and shorter to use linesize[i] * (height >> sps->vshift)?
--
Anton Khirnov
___
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] lavfi/drawtext: Add localtime_ms for millisecond precision
Am 06.03.22 um 21:38 schrieb Thilo Borgmann: Am 22.02.22 um 12:36 schrieb Thilo Borgmann: Am 08.02.22 um 11:41 schrieb Thilo Borgmann: Am 08.02.22 um 10:27 schrieb Andreas Rheinhardt: Thilo Borgmann: Am 01.02.22 um 00:40 schrieb Andreas Rheinhardt: Thilo Borgmann: Am 31.01.22 um 14:08 schrieb Nicolas George: Thilo Borgman (12022-01-31): v10 attached. Also going to apply soon if there are no more comments. I think you neglected to attach the file. omg stupid me. Here it is... -Thilo Seems like I misunderstood your code and ignored the outer while. Your code can leak if there are multiple 'N', because (as I said) + + if (fmt_new && fmt_new != argv[0] && fmt_new != fmt_default) + av_freep(_new); + does not free fmt if it is already allocated. It is possible to fix this by adding an char *fmt_allocated = NULL; at outer scope and a fmt_new in the block that is executed if a 'N' is executed. (You have to free fmt_allocated immediately after av_asprintf().) But maybe it would be best to use an AVBPrint to write the new string instead of allocating a new string for every %N encountered. v11 does it that way. + av_bprintf(_bp, "%s", fmt_begin); + av_bprint_finalize(_bp, (char**)); + if (!fmt) + return AVERROR(ENOMEM); + av_bprint_strftime(bp, fmt, ); + av_freep(); + This is not how one uses an AVBPrint: You are loosing the small-string-optimization that way. Furthermore, you do not check for truncation. v12 including IRC comments. Ping. Will push soon if there are no more comments. Pushed, thanks! -Thilo ___ 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: Added siti filter
Am 07.03.22 um 20:06 schrieb Paul B Mahol:
On 3/7/22, Thilo Borgmann wrote:
Am 06.03.22 um 22:25 schrieb Paul B Mahol:
On 3/6/22, Thilo Borgmann wrote:
Am 22.02.22 um 12:30 schrieb Thilo Borgmann:
Am 18.02.22 um 17:08 schrieb Paul B Mahol:
On Sat, Feb 12, 2022 at 11:55 AM Thilo Borgmann
wrote:
Am 31.01.22 um 12:55 schrieb James Almer:
On 1/31/2022 8:53 AM, Anton Khirnov wrote:
Quoting Thilo Borgmann (2022-01-18 14:58:07)
Violations of code style.
Enhanced.
Not enough. There are still many remaining, e.g.
* opening brace of a function definition should be on its own line
* the context should generally be the first argument
* unsigned char* should be uint8_t*
* mixed declarations and code (the compiler should warn about that)
I think someone said that clang (or some versions) is apparently not
warning about this, hence why so many of these end up being missed in
reviews or even by the patch author.
This and all of Anton's comments in v3. Also removed some more
obviously
useless doubles.
Why it uses doubles in so many places?
Is there any real benefit in that, except extra slowdown?
I guess because it's originating in some c Matlab code.
I did %s#double#float#g for v4, loosing some precision we can ignore
IMHO.
v3:
Total frames: 2
Spatial Information:
Average: 165.451985
Max: 165.817542
Min: 165.086427
Temporal Information:
Average: 1.007263
Max: 2.014525
Min: 0.00
v4:
Total frames: 2
Spatial Information:
Average: 164.385895
Max: 164.742325
Min: 164.029480
Temporal Information:
Average: 1.007241
Max: 2.014483
Min: 0.00
Ping.
Into wrong section of changelog added entry.
Useless cast of allocation results.
Does filter changes pixels? If not, add metadata flag to appropriate
place.
All addressed in v5, thx!
Changelog entry is still in wrong, 5.0, section.
Fixed in v6.
Also added a FATE test for it.
-Thilo
From e47e552344866fdba6fa3b1064e218e2447f7a26 Mon Sep 17 00:00:00 2001
From: Boris Baracaldo
Date: Tue, 8 Mar 2022 13:23:58 +0100
Subject: [PATCH v6] lavfilter: Add SITI filter
Calculate Spatial Info (SI) and Temporal Info (TI) scores for a video, as
defined
in ITU-T P.910: Subjective video quality assessment methods for multimedia
applications.
---
Changelog | 1 +
doc/filters.texi | 23 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/version.h | 2 +-
libavfilter/vf_siti.c | 349 ++
tests/fate-run.sh | 9 +
tests/fate/filter-video.mak | 3 +
tests/ref/fate/filter-refcmp-siti-yuv | 15 ++
9 files changed, 403 insertions(+), 1 deletion(-)
create mode 100644 libavfilter/vf_siti.c
create mode 100644 tests/ref/fate/filter-refcmp-siti-yuv
diff --git a/Changelog b/Changelog
index 3af8aa032b..200bd82680 100644
--- a/Changelog
+++ b/Changelog
@@ -5,6 +5,7 @@ version 5.1:
- dialogue enhance audio filter
- dropped obsolete XvMC hwaccel
- pcm-bluray encoder
+- SITI filter
version 5.0:
diff --git a/doc/filters.texi b/doc/filters.texi
index 26c5b4db48..9f50fd899f 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -19944,6 +19944,29 @@ ffmpeg -i input1.mkv -i input2.mkv -filter_complex
"[0:v][1:v] signature=nb_inpu
@end itemize
+@anchor{siti}
+@section siti
+
+Calculate Spatial Info (SI) and Temporal Info (TI) scores for a video, as
defined
+in ITU-T P.910: Subjective video quality assessment methods for multimedia
+applications. Available PDF at
@url{https://www.itu.int/rec/T-REC-P.910-199909-S/en }.
+
+It accepts the following option:
+
+@table @option
+@item print_summary
+If set to 1, Summary statistics will be printed to the console. Default 0.
+@end table
+
+@subsection Examples
+@itemize
+@item
+To calculate SI/TI metrics and print summary:
+@example
+ffmpeg -i input.mp4 -vf siti=print_summary=1 -f null -
+@end example
+@end itemize
+
@anchor{smartblur}
@section smartblur
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 56d33e6480..43653597d8 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -456,6 +456,7 @@ OBJS-$(CONFIG_SMARTBLUR_FILTER) +=
vf_smartblur.o
OBJS-$(CONFIG_SOBEL_FILTER) += vf_convolution.o
OBJS-$(CONFIG_SOBEL_OPENCL_FILTER) += vf_convolution_opencl.o
opencl.o \
opencl/convolution.o
+OBJS-$(CONFIG_SITI_FILTER) += vf_siti.o
OBJS-$(CONFIG_SPLIT_FILTER) += split.o
OBJS-$(CONFIG_SPP_FILTER)+= vf_spp.o qp_table.o
OBJS-$(CONFIG_SR_FILTER) += vf_sr.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index f5caee3a62..9fbaaacf47 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -432,6 +432,7 @@ extern const AVFilter ff_vf_shuffleplanes;
extern const AVFilter ff_vf_sidedata;
Re: [FFmpeg-devel] [PATCH 1/2] lavu: add syntax for loading AV_OPT_TYPE_BINARY from files
Quoting Niklas Haas (2022-03-04 16:03:06) > From: Niklas Haas > > I arbitrarily decided to use the syntax 'opt=@filename' to match e.g. > `curl -Ffield=@filename`, and also because @ is not a valid hex > character, nor does it conflict with any other common shell or ffmpeg > syntax. > > This is arguably somewhat clunky because it does not round-trip with > av_opt_get - you will get back a hex interpretation of the loaded file, > rather than the filename it was loaded from. It also implies a (perhaps > unnecessary) memcpy from mapped file memory into a allocated memory. > This is unfortunately necessary because there's no way for us to know > whether av_free or av_file_unmap is needed to clean up previous option > values. > > The motivating use case was the introduction of several new binary > options for vf_libplacebo, but other filters that currently rely on > manual file-path loading could benefit from it as well. Sorry, I think having an arbitrary file loader in the options parser will be an endless security nightmare. The alternative I had in mind was having ffmpeg.c itself do the file loading. This will be require some modification of the options parsing code in cmdutils.c and also extending the mechanisms we use to pass options to filters. I can try to make a POC in a few days. -- Anton Khirnov ___ 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] avcodec: Add dv marker bsf
On 08/03/2022 00:17, Michael Niedermayer wrote: Signed-off-by: Michael Niedermayer --- doc/bitstream_filters.texi | 15 libavcodec/Makefile | 1 + libavcodec/bitstream_filters.c | 1 + libavcodec/dv_error_marker_bsf.c | 117 +++ 4 files changed, 134 insertions(+) create mode 100644 libavcodec/dv_error_marker_bsf.c diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi index a0092878c8..6a882ade97 100644 --- a/doc/bitstream_filters.texi +++ b/doc/bitstream_filters.texi @@ -132,6 +132,21 @@ the header stored in extradata to the key packets: ffmpeg -i INPUT -map 0 -flags:v +global_header -c:v libx264 -bsf:v dump_extra out.ts @end example +@section dv_error_marker + +Blocks in DV which are marked as damaged are replaced by blocks of the specified color. + +@table @option +@item color +The color to replace damaged blocks by +@item sta +The error status to replace. If -1 then the stamask is used. -1 is the default. +@item stamask +A 16 bit mask which specifies which of the 16 possible error status values are +to be replaced by colored blocks. 0xFFFE is the default which replaces all non 0 +error status values. +@end table + @section eac3_core [...] In my opinion it would be more user-friendly to use a single "status" option of AV_OPT_TYPE_FLAGS with "s0" ... "s15" constants, instead of the "sta"/"stamask" option pair. Maybe there also could be constants for hard errors (STA = 0111 / ) and error concealment types A/B/C to make the option value readable. Also it would be nice to add the link to S314M documentation pages also in the option documentation. Regards, Tobias ___ 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".
