[FFmpeg-devel] [PATCH v5 0/2] Support long file names on Windows

This patchset adds support for long file and directory paths on Windows. The implementation follows the same logic that .NET is using internally, with the only exception that it doesn't expand short path components in 8.3 format. .NET does this as the same function is also used for other purposes,

[FFmpeg-devel] [PATCH v5 1/2] avutil/wchar_filename, file_open: Support long file names on Windows

From: softworkz Signed-off-by: softworkz --- libavutil/file_open.c | 2 +- libavutil/wchar_filename.h | 166 + 2 files changed, 167 insertions(+), 1 deletion(-) diff --git a/libavutil/file_open.c b/libavutil/file_open.c index fb64c2e4ee..58a6073353 10

[FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support long file names on Windows

From: softworkz Signed-off-by: softworkz --- libavformat/os_support.h | 16 +++- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/libavformat/os_support.h b/libavformat/os_support.h index 5e6b32d2dc..d4c07803a5 100644 --- a/libavformat/os_support.h +++ b/libavformat/os

Re: [FFmpeg-devel] [PATCH v5] avcodec/mfenc: Dynamically load MFPlat.DLL

On Sat, 21 May 2022, Trystan Mata wrote: Changes since the v4: - Avoid having two mf_init function declared (missing #if !HAVE_UWP) - Better commit message about linking with UWP Changes since the v3: - Library handle and function pointer are no longer in MFContext. - If UWP is enabled, avcod

Re: [FFmpeg-devel] [PATCH] qsv: add requirement for the mininal version of libmfx

> > -Original Message- > > From: ffmpeg-devel On Behalf Of Haihao > > Xiang > > Sent: Sunday, May 22, 2022 2:19 PM > > To: ffmpeg-devel@ffmpeg.org > > Cc: Haihao Xiang > > Subject: [FFmpeg-devel] [PATCH] qsv: add requirement for the mininal > > version of libmfx > > > > libmfx 1.28 was r

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc: expose only supported options

On Thu, 2022-05-19 at 12:54 -0700, Dmitry Rogozhkin wrote: > vp9, hevc, avc, mpeg2 QSV encoders inherit common list > of options (QSV_COMMON_OPTS) while bunch of options is not > actually supported by current qsv code. The only codec which > supportes everything is avc, followed by hevc, while vp9

Re: [FFmpeg-devel] [PATCH v7 0/2] use av_fopen_utf8() instead of plain fopen()

On Mon, 23 May 2022, ffmpegagent wrote: Unify file access operations by replacing usages of direct calls to posix fopen() v2: Remove changes to fftools for now v3: Add some additional replacements v4: Fix and improve commit messages v5: Add patch to remap ff_open in libavfilter for MSVC on Wind

Re: [FFmpeg-devel] [PATCH v5 1/2] avutil/wchar_filename, file_open: Support long file names on Windows

On Tue, 24 May 2022, softworkz wrote: From: softworkz Signed-off-by: softworkz --- libavutil/file_open.c | 2 +- libavutil/wchar_filename.h | 166 + 2 files changed, 167 insertions(+), 1 deletion(-) diff --git a/libavutil/file_open.c b/libavutil/file_

Re: [FFmpeg-devel] [PATCH] avfilter: Add blockdetect filter

Am 18.05.22 um 15:42 schrieb Thilo Borgmann: Am 09.05.22 um 14:24 schrieb Thilo Borgmann: Hi, $subject based on http://www.eurasip.org/Proceedings/Eusipco/Eusipco2005/defevent/papers/cr1042.pdf v2 with minimal changes from IRC. Applying soon. Pushed, thanks! -Thilo

Re: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support long file names on Windows

On Tue, 24 May 2022, softworkz wrote: From: softworkz Signed-off-by: softworkz --- libavformat/os_support.h | 16 +++- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/libavformat/os_support.h b/libavformat/os_support.h index 5e6b32d2dc..d4c07803a5 100644 --- a/libavf

Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8

On Mon, 23 May 2022, Soft Works wrote: Great. I rebased and resubmitted both patchsets. The primary long-path patchset didn't need any change. Considerations for the latter were: - Should the file wchar_filename.h be renamed as it is now containing the path prefixing code? I guess we could

Re: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support long file names on Windows

> -Original Message- > From: Martin Storsjö > Sent: Tuesday, May 24, 2022 11:23 AM > To: FFmpeg development discussions and patches > Cc: softworkz ; Hendrik Leppkes > > Subject: Re: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support > long file names on Windows > > On Tue, 24

Re: [FFmpeg-devel] [PATCH v2 1/2] avutil/wchar_filename, file_open: Support long file names on Windows

> -Original Message- > From: ffmpeg-devel On Behalf Of Soft > Works > Sent: Monday, May 23, 2022 5:48 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] avutil/wchar_filename, > file_open: Support long file names on Windows > > > > >

Re: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support long file names on Windows

On Tue, 24 May 2022, Soft Works wrote: -Original Message- From: Martin Storsjö Sent: Tuesday, May 24, 2022 11:23 AM To: FFmpeg development discussions and patches Cc: softworkz ; Hendrik Leppkes Subject: Re: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support long file names on

Re: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support long file names on Windows

> -Original Message- > From: Martin Storsjö > Sent: Tuesday, May 24, 2022 12:26 PM > To: Soft Works > Cc: FFmpeg development discussions and patches ; > Hendrik Leppkes > Subject: RE: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support > long file names on Windows > > On Tue, 2

Re: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support long file names on Windows

On Tue, 24 May 2022, Soft Works wrote: -Original Message- From: Martin Storsjö Sent: Tuesday, May 24, 2022 12:26 PM To: Soft Works Cc: FFmpeg development discussions and patches ; Hendrik Leppkes Subject: RE: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support long file names o

[FFmpeg-devel] [PATCH] lavc/aarch64: add hevc horizontal qpel/uni/bi

checkasm --benchmark on Ampere Altra (Neoverse N1): put_hevc_qpel_bi_h4_8_c: 173.7 put_hevc_qpel_bi_h4_8_neon: 77.0 put_hevc_qpel_bi_h6_8_c: 385.7 put_hevc_qpel_bi_h6_8_neon: 125.7 put_hevc_qpel_bi_h8_8_c: 680.7 put_hevc_qpel_bi_h8_8_neon: 137.5 put_hevc_qpel_bi_h12_8_c: 1480.0 put_hevc_qpel_bi_h1

Re: [FFmpeg-devel] [PATCH 1/4] lavfi/vf_v360: drop nonsense inline specifier

set approved by Paul on IRC and pushed with trivial changes -- 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.o

Re: [FFmpeg-devel] [PATCH 1/4] tests/fate/vcodec: drop unnecessary options

set pushed -- 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 1/9] fftools/ffmpeg: share the code encoding a single frame between video and audio

set pushed -- 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 1/2] avutil/wchar_filename, file_open: Support long file names on Windows

> If we would > want to get rid of this, we could define the struct as follows: > > struct win32_stat > { > union > { > struct _stati64; > struct _stati64 stat; > }; > }; > > The union is anonymous and includes _stati64 twice: once anonymous > and once named. > > This would allow us to define our w

Re: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support long file names on Windows

> -Original Message- > From: Martin Storsjö > Sent: Tuesday, May 24, 2022 1:26 PM > To: Soft Works > Cc: FFmpeg development discussions and patches ; > Hendrik Leppkes > Subject: RE: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support > long file names on Windows > > On Tue, 24

Re: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support long file names on Windows

On Tue, 24 May 2022, Soft Works wrote: -Original Message- From: Martin Storsjö Sent: Tuesday, May 24, 2022 1:26 PM To: Soft Works Cc: FFmpeg development discussions and patches ; Hendrik Leppkes Subject: RE: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support long file names on

[FFmpeg-devel] [PATCH] avcodec: add bink2 video decoder

Signed-off-by: Paul B Mahol --- configure |1 + libavcodec/Makefile |1 + libavcodec/allcodecs.c |1 + libavcodec/bink2.c | 479 + libavcodec/bink2f.c | 1234 libavcodec/bink2g.c | 1479 +

Re: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support long file names on Windows

> -Original Message- > From: ffmpeg-devel On Behalf Of Martin > Storsjö > Sent: Tuesday, May 24, 2022 2:44 PM > To: Soft Works > Cc: Hendrik Leppkes ; FFmpeg development discussions > and patches > Subject: Re: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support > long file name

Re: [FFmpeg-devel] [PATCH v4 0/1] [WIP] avutil/csp changes

On Mon, May 23, 2022 at 05:01:38PM -0400, Leo Izen wrote: > Changes in v4: > - Provide the patch with an AVCIExy struct so we can discuss its > potential pros and cons > > Changes in v3: > - increase precision for AVR() macro to 100k, at haasn's request > - add #define AVUTIL_CSP_DENOM 10 >

[FFmpeg-devel] [PATCH v6 0/2] Support long file names on Windows

This patchset adds support for long file and directory paths on Windows. The implementation follows the same logic that .NET is using internally, with the only exception that it doesn't expand short path components in 8.3 format. .NET does this as the same function is also used for other purposes,

[FFmpeg-devel] [PATCH v6 1/2] avutil/wchar_filename, file_open: Support long file names on Windows

From: softworkz Signed-off-by: softworkz --- libavutil/file_open.c | 2 +- libavutil/wchar_filename.h | 180 + 2 files changed, 181 insertions(+), 1 deletion(-) diff --git a/libavutil/file_open.c b/libavutil/file_open.c index fb64c2e4ee..58a6073353 10

[FFmpeg-devel] [PATCH v6 2/2] avformat/os_support: Support long file names on Windows

From: softworkz Signed-off-by: softworkz --- libavformat/os_support.h | 87 +--- 1 file changed, 63 insertions(+), 24 deletions(-) diff --git a/libavformat/os_support.h b/libavformat/os_support.h index 5e6b32d2dc..179b926293 100644 --- a/libavformat/os_suppo

Re: [FFmpeg-devel] [PATCH 2/2] libavfi/dnn: add LibTorch as one of DNN backend

Hi Jean-Baptiste, I am trying to add this backend since we got some users who have interest in doing PyTorch model(BasicVSR model) inference with FFmpeg. And as we all know, the PyTorch is one of the most popular AI inference engines and it has large number of models. So, I think if LibTorch is

Re: [FFmpeg-devel] [PATCH 2/2] libavfi/dnn: add LibTorch as one of DNN backend

> -Original Message- > From: ffmpeg-devel On Behalf Of Fu, Ting > Sent: Tuesday, May 24, 2022 4:03 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH 2/2] libavfi/dnn: add LibTorch as one > of DNN backend > > Hi Jean-Baptiste, > > I am trying to

Re: [FFmpeg-devel] [PATCH 2/2] libavfi/dnn: add LibTorch as one of DNN backend

Hello, On Tue, 24 May 2022, at 16:03, Fu, Ting wrote: > I am trying to add this backend since we got some users who have > interest in doing PyTorch model(BasicVSR model) inference with FFmpeg. I think you are missing my point here. We already have 3 backends (TF, Native, OpenVino) in FFmpeg. T

Re: [FFmpeg-devel] [PATCH v4 1/1] avutil/csp: create public API for colorspace structs

Quoting Leo Izen (2022-05-23 23:01:39) > diff --git a/libavutil/csp.h b/libavutil/csp.h > new file mode 100644 > index 00..ea7400d1e5 > --- /dev/null > +++ b/libavutil/csp.h > @@ -0,0 +1,53 @@ > +/* > + * Copyright (c) 2016 Ronald S. Bultje > + * This file is part of FFmpeg. > + * > + * FF

Re: [FFmpeg-devel] [PATCH v4 1/1] avutil/csp: create public API for colorspace structs

On Mon, May 23, 2022 at 11:02 PM Leo Izen wrote: > This commit moves some of the functionality from avfilter/colorspace > into avutil/csp and exposes it as a public API so it can be used by > libavcodec and/or libavformat. It also converts those structs from > double values to AVRational to make

Re: [FFmpeg-devel] [PATCH 2/2] libavfi/dnn: add LibTorch as one of DNN backend

> -Original Message- > From: ffmpeg-devel On Behalf Of Jean- > Baptiste Kempf > Sent: Tuesday, May 24, 2022 4:52 PM > To: ffmpeg-devel > Subject: Re: [FFmpeg-devel] [PATCH 2/2] libavfi/dnn: add LibTorch as one > of DNN backend > > Hello, > > On Tue, 24 May 2022, at 16:03, Fu, Ting wr

Re: [FFmpeg-devel] [PATCH v4 1/1] avutil/csp: create public API for colorspace structs

On 5/24/22 11:28, Vittorio Giovara wrote: On Mon, May 23, 2022 at 11:02 PM Leo Izen > wrote: This commit moves some of the functionality from avfilter/colorspace into avutil/csp and exposes it as a public API so it can be used by libavcodec and/or lib

[FFmpeg-devel] [PATCH v5 0/1] avutil/csp: create public API for colorspace structs

It appears a consensus has been reached that this api should be public with av_ instead of avpriv_, and that AVRationals work better here than floating points. As a result, I've unmarked it as [WIP]. Changes in v5: - Unmark as [WIP], ready for review and merging - rename public functions to namesp

[FFmpeg-devel] [PATCH v5 1/1] avutil/csp: create public API for colorspace structs

This commit moves some of the functionality from avfilter/colorspace into avutil/csp and exposes it as a public API so it can be used by libavcodec and/or libavformat. It also converts those structs from double values to AVRational to make regression testing easier and more consistent. --- libavfi

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vc1_loopfilter: Factor duplicate code in vc1_b_h_intfi_loop_filter()

Michael Niedermayer: > Fixes: CID1435168 > > Signed-off-by: Michael Niedermayer > --- > libavcodec/vc1_loopfilter.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/libavcodec/vc1_loopfilter.c b/libavcodec/vc1_loopfilter.c > index 0f990cccef..ee694ede28 100644 > ---

Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8

> -Original Message- > From: ffmpeg-devel On Behalf Of Martin > Storsjö > Sent: Tuesday, May 24, 2022 11:29 AM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8 > > On Mon, 23 May 2022, Soft Works wrote: > > >

Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8

On Tue, 24 May 2022, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of Martin Storsjö Sent: Tuesday, May 24, 2022 11:29 AM To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8 On Mon, 23 May 2022, S

Re: [FFmpeg-devel] [PATCH] checkasm: improve hevc_sao test

On Tue, 17 May 2022, J. Dekker wrote: The HEVC decoder can call these functions with smaller widths than the functions themselves are designed to operate on so we should only check the relevant output Signed-off-by: J. Dekker --- tests/checkasm/hevc_sao.c | 51 -

Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8

> -Original Message- > From: ffmpeg-devel On Behalf Of Martin > Storsjö > Sent: Tuesday, May 24, 2022 10:22 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8 > > On Tue, 24 May 2022, Soft Works wrote: > > >>

Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8

On Tue, 24 May 2022, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of Martin Storsjö Sent: Tuesday, May 24, 2022 10:22 PM To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8 On Tue, 24 May 2022, S

Re: [FFmpeg-devel] [PATCH v6 1/2] avutil/wchar_filename, file_open: Support long file names on Windows

On Tue, 24 May 2022, softworkz wrote: From: softworkz Signed-off-by: softworkz --- libavutil/file_open.c | 2 +- libavutil/wchar_filename.h | 180 + 2 files changed, 181 insertions(+), 1 deletion(-) This looks ok to me now, thanks! // Martin __

Re: [FFmpeg-devel] [PATCH v5 1/1] avutil/csp: create public API for colorspace structs

Leo Izen: > This commit moves some of the functionality from avfilter/colorspace > into avutil/csp and exposes it as a public API so it can be used by > libavcodec and/or libavformat. It also converts those structs from > double values to AVRational to make regression testing easier and > more cons

Re: [FFmpeg-devel] [PATCH v6 2/2] avformat/os_support: Support long file names on Windows

On Tue, 24 May 2022, softworkz wrote: From: softworkz Signed-off-by: softworkz --- libavformat/os_support.h | 87 +--- 1 file changed, 63 insertions(+), 24 deletions(-) diff --git a/libavformat/os_support.h b/libavformat/os_support.h index 5e6b32d2dc..179b9

Re: [FFmpeg-devel] [PATCH v5 1/1] avutil/csp: create public API for colorspace structs

On 5/24/22 16:56, Andreas Rheinhardt wrote: Leo Izen: +#define AVUTIL_CSP_DENOM 10 Why not 30 given that the denominator of one of the constants has a factor of three? (Sorry if this has already been answered before.) I suggested this to haasn, but he pointed out that the 1/3 can

Re: [FFmpeg-devel] [PATCH v6 2/2] avformat/os_support: Support long file names on Windows

> -Original Message- > From: Martin Storsjö > Sent: Tuesday, May 24, 2022 10:59 PM > To: softworkz > Cc: ffmpeg-devel@ffmpeg.org; Soft Works ; Hendrik > Leppkes > Subject: Re: [PATCH v6 2/2] avformat/os_support: Support long file names > on Windows > > On Tue, 24 May 2022, softworkz w

[FFmpeg-devel] [PATCH v7 0/3] Support long file names on Windows

This patchset adds support for long file and directory paths on Windows. The implementation follows the same logic that .NET is using internally, with the only exception that it doesn't expand short path components in 8.3 format. .NET does this as the same function is also used for other purposes,

[FFmpeg-devel] [PATCH v7 1/3] avutil/wchar_filename, file_open: Support long file names on Windows

From: softworkz Signed-off-by: softworkz --- libavutil/file_open.c | 2 +- libavutil/wchar_filename.h | 180 + 2 files changed, 181 insertions(+), 1 deletion(-) diff --git a/libavutil/file_open.c b/libavutil/file_open.c index fb64c2e4ee..58a6073353 10

[FFmpeg-devel] [PATCH v7 2/3] avformat/os_support: Support long file names on Windows

From: softworkz Signed-off-by: softworkz --- libavformat/os_support.h | 106 ++- 1 file changed, 81 insertions(+), 25 deletions(-) diff --git a/libavformat/os_support.h b/libavformat/os_support.h index 5e6b32d2dc..1c3b234b06 100644 --- a/libavformat/os_suppo

[FFmpeg-devel] [PATCH v7 3/3] avformat/file: remove _WIN32 condition

From: softworkz stat is now re-mapped with long path support in os_support.h Signed-off-by: softworkz --- libavformat/file.c | 4 1 file changed, 4 deletions(-) diff --git a/libavformat/file.c b/libavformat/file.c index 063d7c5aa2..98c9e81bcb 100644 --- a/libavformat/file.c +++ b/libavfo

Re: [FFmpeg-devel] [PATCH] Update ReadMe.md for PR submission and reference Developer Documentation

> -Original Message- > From: softworkz > Sent: Thursday, February 3, 2022 10:28 PM > To: ffmpeg-devel@ffmpeg.org > Cc: softworkz ; softworkz > Subject: [PATCH] Update ReadMe.md for PR submission and reference > Developer Documentation > > From: softworkz > > Signed-off-by: softworkz

Re: [FFmpeg-devel] [PATCH v2] avcodec/libaomenc: Add unmet target level warning

On Tue, May 17, 2022 at 12:45 PM James Zern wrote: > > On Tue, Apr 19, 2022 at 11:20 AM Bohan Li > wrote: > > > > When target levels are set, this patch checks whether they are > > satisfied by libaom. If not, a warning is shown. Otherwise the output > > levels are also logged. > > > > This patch

Re: [FFmpeg-devel] [PATCH 2/2] libavfi/dnn: add LibTorch as one of DNN backend

> -Original Message- > From: ffmpeg-devel On Behalf Of Soft > Works > Sent: Tuesday, May 24, 2022 10:24 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 2/2] libavfi/dnn: add LibTorch as one of > DNN backend > > > > > -Or

Re: [FFmpeg-devel] [PATCH 2/2] libavfi/dnn: add LibTorch as one of DNN backend

> -Original Message- > From: ffmpeg-devel On Behalf Of > Jean-Baptiste Kempf > Sent: Tuesday, May 24, 2022 10:52 PM > To: ffmpeg-devel > Subject: Re: [FFmpeg-devel] [PATCH 2/2] libavfi/dnn: add LibTorch as one of > DNN backend > > Hello, > > On Tue, 24 May 2022, at 16:03, Fu, Ting wr

[FFmpeg-devel] [PATCH v5] avcodec/mfenc: Dynamically load MFPlat.DLL

Firstly, thank you for your review. > You shouldn't use win32_dlopen directly (there's no preexisting code that > does that). If you want to use the helpers from w32dlfcn.h, call dlopen > and dlclose, which then redirect to those functions. But here I don't see > any need to use that wrapp

Re: [FFmpeg-devel] [PATCH v5] avcodec/mfenc: Dynamically load MFPlat.DLL

Firstly, thank you for your review. > You shouldn't use win32_dlopen directly (there's no preexisting code that > does that). If you want to use the helpers from w32dlfcn.h, call dlopen > and dlclose, which then redirect to those functions. But here I don't see > any need to use that wrapper w